**** BEGIN LOGGING AT Tue May 17 10:45:53 2011
May 17 10:46:07 <ka6sox-away> okay that fixed it.
May 17 10:47:26 <JaMa> RP__: not really, I've updated my irssi config to autojoin and log, so I'm fine without bot
May 17 11:00:54 <ka6sox-away> bluelightning, can you see: http://logs.nslu2-linux.org/livelogs/yocto.txt ?
May 17 11:02:48 <bluelightning> ka6sox-away: yep, works
May 17 11:03:21 <ka6sox-away> okay...later there will be a -prev and a dir for previous days.
May 17 11:04:34 <ka6sox-away> they rotate @ 00:00UTC
May 17 12:02:02 <RP__> ka6sox-away: cool, thanks
May 17 12:13:21 <ikkeT> hi, any pointers to where to begin to build yocto for beagleboard?
May 17 12:13:54 <ikkeT> ERROR: Nothing PROVIDES 'poky-image-sato'
May 17 12:18:41 <ikkeT> ERROR: Nothing PROVIDES 'poky-image-sato-sdk'
May 17 12:25:28 <bluelightning> ikkeT: which version are you using?
May 17 12:25:59 <ikkeT> bluelightning, git head
May 17 12:26:17 <bluelightning> ikkeT: ok, it's core-image* in git master
May 17 12:26:25 <bluelightning> there was a big rename
May 17 12:26:44 <bluelightning> although DISTRO is still poky
May 17 12:26:59 <ikkeT> thanks, so bitbake core-image-sato-sdk ?
May 17 12:27:50 <ikkeT> i think i better try the qemu build first just to see it works...
May 17 12:30:37 <ikkeT> i admit i didn't read the reference manual yet. going for it now...
May 17 12:32:24 <otavio> Hello
May 17 13:06:01 <bluelightning> hi otavio
May 17 13:29:12 * zeddii can't get gcc 4.6 to build, to even get at the kernel fixes
May 17 13:29:17 <zeddii> http://pastebin.com/DQiAsHp0
May 17 13:48:17 <otavio> zeddii: ugly; mine is building fine.
May 17 13:48:35 <otavio> zeddii: I am at db0c5df63775c48ff8eb0b909c31d9bd47849b67
May 17 13:49:03 <otavio> zeddii: not sure if it is on the repo; bfb95dc78076ef6f26b8f1378fcb6b5d1b3d8cb9 is
May 17 13:59:53 <dvhart> morning all
May 17 14:00:33 <otavio> morning
May 17 14:00:48 <bluelightning> morning dvhart
May 17 14:01:24 <dvhart> otavio, have you had a chance to review the *pull-request patches?
May 17 14:01:33 * dvhart is anxious to get those behind him
May 17 14:01:48 <otavio> dvhart: I looked at it ...
May 17 14:02:12 <otavio> dvhart: I didn't apply them locally since I am using oe-core, not poky
May 17 14:02:22 <dvhart> otavio, that series is applicable to oe-core
May 17 14:02:28 <dvhart> I fixed the first patch
May 17 14:02:47 <otavio> dvhart: they seem OK and got all the issues I wanted for now ... so it seems ready for me.
May 17 14:03:09 <dvhart> ok, mind just sending a response to 0/15 with your Acked-by?
May 17 14:03:17 <otavio> dvhart: sure not
May 17 14:03:37 <dvhart> khem, with the new git-send-email usage, have I addressed your concerns?
May 17 14:05:05 <otavio> dvhart: done
May 17 14:05:13 <dvhart> thanks otavio
May 17 14:05:28 <dvhart> otavio, you OK with me adding that to the entire series?
May 17 14:05:33 <dvhart> (for the commit log)
May 17 14:06:17 <otavio> it is OK for sure
May 17 14:06:22 <dvhart> great
May 17 14:07:32 <otavio> dvhart: zeddii seems busy, can you help me with kernel?
May 17 14:07:53 <dvhart> otavio, I probably only have a couple minutes until the kiddos wake up, then I'm out until 8
May 17 14:07:56 <dvhart> but let's try
May 17 14:10:05 <zeddii> otavio, I'm not busy, I didn't see a question.
May 17 14:11:23 <zeddii> well, I'm busy, but I can answer questions that I see.
May 17 14:14:19 <otavio> zeddii: you seemed off for me, I am sorry
May 17 14:14:45 <otavio> I got kernel built using my branch but as far as I can tell it used the config of qemu
May 17 14:15:01 <otavio> now I want to work on meta to get it with mine
May 17 14:15:33 <otavio> where I can check the .config produced? on work? where it saves it?h
May 17 14:15:36 <zeddii> you need to pass it some sort of configuration, yes, either a defconfig, or you create your own .scc file (using the other boards as an example) on meta.
May 17 14:15:54 <zeddii> the .config shows up in the out dir. linux-<machine>-build
May 17 14:16:05 * otavio looks
May 17 14:17:40 <otavio> ahhh got it
May 17 14:22:34 <otavio> zeddii: where I add features that I can make  a machine to use?
May 17 14:22:43 <otavio> zeddii: I want to add squashfs and aufs
May 17 14:23:47 <otavio> zeddii: to be eaiser to share patches with you I will change my meta branch to ossystems-meta
May 17 14:23:53 <otavio> zeddii: this ought to work right?
May 17 14:25:02 <zeddii> keep it as meta. the tools assume that in some places. I've got a set of changes that make it variable, but due to the transition from the 'old' way to the 'new' way in 1.0, I had to leave some hard checks in the tools.
May 17 14:25:23 <zeddii> but having the same branch name as 'meta' shouldn't be a problem for sharing changes.
May 17 14:32:03 <zeddii> otavio, for aufs, you want to merge the out of tree stuff, and for squashfs, is it new code, or just the configs ?
May 17 14:40:33 <otavio> zeddii: squashfs just configs
May 17 14:40:39 <otavio> zeddii: aufs needs patching
May 17 14:49:55 <otavio> It seems unionfs is supported; for me it works fine if it is stable
May 17 14:51:26 <zeddii> I typically use unionfs here as well.
May 17 14:51:58 <otavio> and the init scripts has support for it?
May 17 14:52:09 <otavio> on OE we used to have a initramfs module to support it
May 17 14:52:16 <otavio> (aufs on this case )
May 17 14:52:56 <zeddii> hmmm. that, I bet not.  I've got some live-cd stuff that uses it, but not the oe/poky environment.
May 17 14:54:03 <otavio> OK so this is something I will need to get working
May 17 14:54:05 <otavio> no problem
May 17 14:58:59 <otavio> I am confused. We have features/vfat and cfg/vfat ...
May 17 14:59:08 <otavio> what's the difference?
May 17 15:00:02 <dvhart> otavio, features is the one for the patent patches
May 17 15:00:11 <dvhart> otavio, cfg just enables the CONFIG_VFAT
May 17 15:00:19 <dvhart> otavio, badly named
May 17 15:03:00 <zeddii> yah. the 1.1 revisit will cleanup all the chaos-named options and remove the rest of the cruft.
May 17 15:10:37 <otavio> so basically to squashfs that no patches are needed we just need cfg?
May 17 15:12:11 <zeddii> yes. and you don't have to do it as a separate feature, it can always just go in a BSP config. but if we want to use it in multiple places, etc, etc, creating a squashfs feature fragment makes sense.
May 17 15:12:24 <zeddii> assuming that the mainline squashfs is good enough for you.
May 17 15:13:08 <otavio> zeddii: it makes sense to have it globally supported
May 17 15:13:50 <otavio> zeddii: and in case of squashfs that multiple compressors are available is it possible to have squashfs-lzma squashfs-lzo (as example) depending on squashfs config?
May 17 15:14:06 <zeddii> in various kernels in the past few years, we've had it both ways, but it doesn't hurt to enable it, small configs can always turn it off again.
May 17 15:14:36 * fray just realized he forgot to log into IRC this morning.. :)
May 17 15:15:56 <zeddii> otavio. we tend to just specify them, and let lkc thrown them out if the dependencies aren't met (or maybe I'm misunderstanding the comment).
May 17 15:16:48 <otavio> zeddii: for example, if I enable squashfs-lzma I need to enable a config for it that is not the squashfs support
May 17 15:16:53 <otavio> zeddii: as the same for lzo
May 17 15:17:33 <otavio> zeddii: so I though about having multiple cfgs that adds the one we want and depends on squashfs itself
May 17 15:18:29 * zeddii thinks
May 17 15:18:53 <otavio> CONFIG_SQUASHFS=m
May 17 15:18:53 <otavio> # CONFIG_SQUASHFS_XATTR is not set
May 17 15:18:53 <otavio> # CONFIG_SQUASHFS_LZO is not set
May 17 15:18:53 <otavio> # CONFIG_SQUASHFS_XZ is not set
May 17 15:18:53 <otavio> # CONFIG_SQUASHFS_EMBEDDED is not set
May 17 15:18:57 <otavio> for example
May 17 15:19:02 <zeddii> and when you say enable, what's the mechanism ? I have options, but need to know the trigger.
May 17 15:19:23 <otavio> let's say to have a cfg called
May 17 15:19:30 <otavio> squashfs-xz
May 17 15:19:41 <otavio> it would set CONFIG_SQUASHFS too
May 17 15:20:06 <otavio> but to avoid duplicating it, I'd have a squashfs or squashfs-common
May 17 15:21:12 <zeddii> that's one way to do it, having the frags standalone with some duplication is another option that is sometimes more appropriate.
May 17 15:26:34 <JaMa> RP__: still cannot push to oe-core repo?
May 17 15:27:00 <RP__> JaMa: correct, its not working
May 17 15:27:04 <JaMa> RP__: because I see only commits 24hours old and not those where you replied "merged to master" today
May 17 15:27:07 <JaMa> ah ok
May 17 15:27:23 <otavio> RP__: did you see my mail about gitpkgv not working?
May 17 15:27:42 <otavio> RP__: gitpkgv is on meta-oe but it used to work well and stoped to work
May 17 15:28:10 <otavio> RP__: checking bitbake -e it is properly expanded but the recipe is not reparsed so PKGV is not updated
May 17 15:28:13 * zeddii needs to step out for food
May 17 15:28:18 <RP__> JaMa: I have a queue waiting and I did merge the corresponding commits to poky master
May 17 15:31:00 <nitink> Good Morning All !
May 17 15:31:15 <dvhart> morning nitink
May 17 15:31:23 <nitink> morning dvhart
May 17 15:32:23 <RP__> otavio: I saw the message but I've not had any time to look at it
May 17 15:33:05 <otavio> RP__: ok
May 17 15:33:43 <JaMa> otavio: didn't you switch to bitbake with scmdata= param support?
May 17 15:33:51 <RP__> otavio: I still don't understand why you can't use the functionality in bitbake's fetcher for that
May 17 15:34:19 <otavio> JaMa: tell me more... dunno
May 17 15:34:35 <otavio> RP__: I need it to evaluate to git describe output
May 17 15:34:44 <JaMa> otavio: do you have .git dir in ${WORKDIR}/sources ?
May 17 15:35:40 <otavio> JaMa: on DL_DIR?
May 17 15:35:42 <otavio> JaMa: no
May 17 15:35:58 <otavio> JaMa: I have DLDIR/git2/
May 17 15:36:18 <JaMa> otavio: do you use srctree with it?
May 17 15:36:32 <JaMa> if not then I realy mean in WORKDIR
May 17 15:37:15 <otavio> JaMa: you mean using .bb on the git repository itself to build it locally?
May 17 15:37:18 <JaMa> otavio: I had really strange issue http://git.shr-project.org/git/?p=meta-shr.git;a=commit;h=81220849540600d9e675bd3622b8a98b7425a489 which was caused exactly because .git is missing with fetch1
May 17 15:37:18 <otavio> JaMa: I don't
May 17 15:38:09 <JaMa> or in ${S}
May 17 15:38:19 <JaMa> to be more exact then ${WORKDIR}/sources
May 17 15:38:26 <otavio> JaMa: no; it is not my case; we use it to clone a git and use git describe to fill PKGV
May 17 15:38:37 <otavio> JaMa: take a look at gitpkv class in meta-oe or oe-dev
May 17 15:39:17 <JaMa> gitver or gitpkgv?
May 17 15:39:23 <otavio> JaMa: I think it has something todo with cached data but I have no clue about it
May 17 15:39:24 <otavio> JaMa: pkgv
May 17 15:39:46 <otavio> JaMa: freerdp uses it, as libinih does as well
May 17 15:40:49 <JaMa> ah ok gitver is using ${S}/.git not gitpkgv
May 17 15:47:50 <otavio> JaMa: yep
May 17 15:47:54 * otavio if off
May 17 17:24:58 <jzhang> nitink: ping
May 17 17:25:30 <nitink> jzhang: pong
May 17 17:27:25 <jzhang> nitink: I'm running into a strange build error with a clean meta-toolchain build against lastest master http://pastebin.com/v7wnT5as, so are we using gcc4.6 or 4.5 and is it something related?
May 17 17:28:45 <nitink> we are still on gcc 4.5.1
May 17 17:30:35 <nitink> jzhang: was qemu-nativesdk recipe changed recently ?
May 17 17:36:01 <jzhang> nitink: not that I am aware of...
May 17 17:38:19 <otavio> To start with how can I create a defconfig for the kernel to use?
May 17 17:38:30 <otavio> I mean, providing a  defconfig on meta... possible?
May 17 17:38:42 * otavio still missing on it
May 17 17:44:37 <zeddii> otavio. you can do a full defconfig. Are you referencing one of the existing BSPs ?
May 17 17:44:59 <otavio> zeddii: to start with I'd prefer to get mine and build it to get it started
May 17 17:45:37 <zeddii> I phrased that badly. Are you referencing one of the existing BSP decriptions on meta, rather than the config.
May 17 17:54:52 <nitink> jzhang: can you open a bug for it ?
May 17 18:08:58 <jzhang> nitink: sure
May 17 18:13:19 <otavio> where should I send a patch to meta-intel?
May 17 18:22:04 <tomz1> otavio: the yocto list
May 17 18:24:31 <otavio> tomz1: mind to give the address to me? I am not on it
May 17 18:25:16 <tomz1> otavio: sure, 	  yocto@yoctoproject.org
May 17 18:30:40 <otavio> tomz1: trivial documentation patch but worth it
May 17 18:30:48 <otavio> tomz1: take a look when you can
May 17 18:32:02 <tomz1> otavio: ok, will do, thx
May 17 18:38:21 * zeddii crosses his fingers that gcc 4.6.0 will finally build.
May 17 18:43:49 * zeddii cheers. 
May 17 18:43:58 <zeddii> deleting sstate seems to have been the ticket.
May 17 18:45:19 <otavio> zeddii: someone said about having problems with sstate yestarday or so
May 17 18:45:44 <otavio> zeddii: help me with my last doubt (at least for now) ...
May 17 18:46:03 <otavio> zeddii: how I choose the meta machine will be used? is it going to match with machine name?
May 17 18:47:15 * zeddii reads
May 17 18:48:33 <zeddii> the MACHINE variable is passed in as the filter for looking for the board description, so they match.
May 17 18:52:36 * zeddii is actually happy to see his kernel fail to build with gcc 4.6.0, I can now actually debug the problem.
May 17 19:35:44 <otavio> how the machine name is matched? ${MACHINE}-${KTYPE} then ${MACHINE} ?
May 17 19:39:36 <zeddii> at the moment, it looks for the machine name in the description file (.scc) that would create the branch being built. which ends up with what you have there. but that's changing to be simpler at some point (but will be transparent).  are you seeing a mismatch ?
May 17 20:13:55 <otavio> zeddii: I am trying to understand how common-pc-standard and preempt-rt are match
May 17 20:17:28 <zeddii> the parent branch, in this case the ktype.
May 17 20:18:18 <zeddii> that's the part that I'm changing the new support is less structured, so giving it some more flexibility is almost done.
May 17 20:19:07 <otavio> please document it somewhere ... it is a bit confusing for someone out of it
May 17 20:19:23 <otavio> (the new design obviously)
May 17 20:21:36 <zeddii> doc updates are happening while I change it, so it will definitely be there. for the most part, it is transparent .. if it largely isn't invisible, I've messed up.
May 17 20:24:03 <otavio> is it available somewhere I can browse?
May 17 20:24:10 <otavio> so I could avoid too much asking
May 17 20:25:05 <zeddii> new changes, or docs or both ?
May 17 20:25:10 <otavio> docs
May 17 20:25:32 <otavio> primary concern atm
May 17 20:25:33 <otavio> heh
May 17 20:25:38 <zeddii> indeed.
May 17 20:26:01 <zeddii> I'll double check the yocto docs, a lot was dumped there, but it may not be to the detail level you are asking about.
May 17 20:28:57 <zeddii> I have to head out in about 5 mins, but will dig up those docs. it's on a yellow post-it on my monitor now (I'm old school for reminders :)
May 17 20:30:48 <otavio> haha ok np
May 17 21:30:28 <khem> RP__: around
May 17 22:24:53 <khem> I am seeing bitbake taking noticeable more time in preparing runqueue after updating to latest master. my snapshot before that was 12112102dd2808534505d4bfbb171904794428c2
May 17 22:24:59 <khem> anyone else seeing it
May 17 23:01:26 <khem> hmmm I think FILESPATHPKG does not work on oe-core
**** ENDING LOGGING AT Wed May 18 02:59:57 2011

**** BEGIN LOGGING AT Wed May 18 02:59:57 2011
May 18 04:19:00 <otavio> zeddii: I did the meta updating however it didn't seem to work for my case. Could you take a look on what I did wrong on the meta branch?
May 18 06:58:56 <RP__> morning all
May 18 07:07:22 <JaMa> morning
May 18 07:58:43 <JaMa> RP__: the patch for sigdata in stamps breaks old oe.dev (without sstate) but otherwise looks good to me
May 18 07:59:21 <RP__> JaMa: ok, I should be able to fix that, thanks for the note :)
May 18 07:59:34 <JaMa> RP__: AttributeError: 'SignatureGenerator' object has no attribute 'dump_sigtask' paste.pocoo.org/show/391051/
May 18 08:00:34 <JaMa> RP__: I'll try to reproduce those run.do_install which are the same but sigdata says that are different checksums
May 18 08:00:35 <RP__> JaMa: We just need to add a dummy function for this
May 18 08:12:27 <dcui-mobl1> hi
May 18 08:22:55 <sgw> RP__: Morning
May 18 08:24:52 * sgw -> Zzzz (thought I might catch RP, but I am fading).
May 18 09:51:34 <ikkeT> guys, what's the procedure with bugs found? do you accept bug reports against git version?
May 18 09:51:56 <ikkeT> like, tzcode package points to incorrect url and can't be compiled?
May 18 09:56:35 <ikkeT> s/tzdata2009s/tzdata2011g/
May 18 09:57:41 <JaMa> RP__: quick question, I've applied your allarch patch, now everything seems to rebuild, is it expected with that siteinfo.bbclass change?
May 18 09:59:21 <RP__> JaMa: Hmm, I'd not have quite expected that :/
May 18 09:59:37 <RP__> JaMa: but I guess through dependencies it might happen
May 18 09:59:54 <RP__> ikkeT: We accept bug reports against git, yes
May 18 10:00:05 <ikkeT> ok, I create one now for it then
May 18 10:00:09 <RP__> ikkeT: we also take patches on the mailing list :)
May 18 10:00:18 <JaMa> RP__: ok, lets see how it behaves after I got both machines built
May 18 10:00:49 <RP__> JaMa: My tests showed it was a lot happier but there are the configure issues I mentioned still to fix
May 18 10:01:08 <RP__> (or we stop marking those as "all" until we do fix them)
May 18 10:01:20 <ikkeT> RP__, i'll attach patch as well
May 18 10:01:35 <ikkeT> maybe I should join mailing list...
May 18 10:02:24 <RP__> ikkeT: bug reports are good, patches are better :)
May 18 12:46:27 <otavio> Hello
May 18 13:23:40 <RP__> hi otavio
May 18 13:59:07 <otavio> :-)
May 18 14:02:15 * zeddii is in, digging through email. 240 unread. 
May 18 14:16:57 <otavio> zeddii: I got the kernel built but it seems to haven't built any module package so seems it has taken the wrong config. Can you look at my change at https://github.com/OSSystems/linux-yocto-2.6.37/commit/a5d2953fe940c6f07b6abbeef7227424b78ba6f7 ?
May 18 14:31:18 <zeddii> otavio. I will definitely have a look.
May 18 14:31:33 * zeddii clicks through
May 18 15:04:53 <dvhart> morning all
May 18 15:06:30 <zeddii> otavio: for your meta commit, you want to inherit from common-pc, so you'd want to change the leaf line to be: scc_leaf bsp/common_pc/common_pc-standard ossystems-x86
May 18 15:30:12 <otavio> zeddii: do you mind to explain me why the change?
May 18 15:31:33 <nitink> Good Morning All !
May 18 15:32:07 <otavio> nitink: morning
May 18 15:32:35 <nitink> morning otavio, where are you located ?
May 18 15:34:00 <otavio> Brazil
May 18 15:34:05 <otavio> what about you?
May 18 15:36:19 <nitink> I am in US, bay area
May 18 15:36:38 <otavio> zeddii: just built it; no change. It seems it is not following my recipe even thought it is appending the revision on it
May 18 15:36:47 <otavio> nitink: nice :-)
May 18 15:37:07 * otavio is out for lunch time :-D yey!
May 18 15:37:09 <zeddii> otavio. hmm. that makes no sense.
May 18 15:37:17 <zeddii> otavio, before you go, if I clone, will I have your latest ?
May 18 15:37:22 <zeddii> I'll do a build here.
May 18 15:38:49 <nitink> otavio: njoy your lunch :)
May 18 15:38:56 <nitink> or lunch time
May 18 15:51:28 <bluelightning> RP__: I notice that BBFILE_* parsing errors don't actually cause bitbake to bail out currently... is that deliberate? (cooker.py - handleCollections() )
May 18 15:51:43 <RP__> bluelightning: no :/
May 18 15:52:07 <bluelightning> hmm ok, I will address that along with the dependency checking
May 18 16:00:36 <sgw> Morning folks
May 18 16:01:11 <bluelightning> hi sgw
May 18 16:53:51 <sgw> RP__: ping
May 18 16:55:10 * otavio is back
May 18 16:55:23 <otavio> zeddii: did you get anything?
May 18 16:57:21 <RP__> sgw: pong
May 18 16:58:20 <zeddii> otavio. it's building the toolchain now :) I updated my config to match your branches. I'm actively looking at this now, so I'll know shortly.
May 18 16:58:33 <sgw> RP__: I am pulling together the patches from this morning (including Bruces) but have left some of khem distrovars and jzhang's adt stuff since it sounds like you are working those.
May 18 16:58:48 <otavio> zeddii: nice. Do you see any stupid mistake from my side off hand?
May 18 16:59:02 <sgw> RP__: I am going to run a quick build/boot pass and then send them up to you.
May 18 16:59:13 <zeddii> looking now. I wanted to start my build and let it run. then look, so I'm browsing gitweb now.
May 18 16:59:20 <RP__> sgw: Its Liping's bitbake patches I'm working on
May 18 16:59:32 <otavio> zeddii: ah ok; no problem. I can wait.
May 18 16:59:36 <sgw> Oh, so I will grap up the adt patches then
May 18 17:00:07 <zeddii> otavio. you have a slightly different usecase, so although frustrating (hopefully only slightly) for you, it's an excellent thing to work through and I want to get it seamlessly working.
May 18 17:00:14 <otavio> RP__: since you're looking at bitbake could you take a look on the gitpkgv problem?
May 18 17:00:34 <zeddii> so I'm off to look at the branches now that my gcc 4.6.0 patches are out.
May 18 17:01:12 <otavio> zeddii: no problem. I was expecting issues when moving to oe-core so this is OK; especially because you and other people are giving me an awesome support :-)
May 18 17:01:17 <RP__> otavio: As I said previously, I really don't have the bandwidth to look at that problem. It would likely take me a couple of hours as I've never even used that class before
May 18 17:01:37 * RP__ wishes he could look at every problem out there but I need to pick them :(
May 18 17:01:39 <sgw> RP__: BTW, has anyone else seen a problem with perl referencing perl-5.12.3.real?
May 18 17:01:59 <RP__> sgw: First I've heard of it
May 18 17:02:46 <otavio> RP__: right but is there any way I can gather the information you need? I have that setup and working on OE (dev) and doesn't working on oe-core. It really seem to be a bitbake change that broke it since  I used it with oe-core before.
May 18 17:03:23 <otavio> RP__: I runned it with -e and it shows the PKGV being expanded but seems like recipe is not reparsed so the built package dosen't get the updated values
May 18 17:03:25 <sgw> RP__: Ok, that makes me wonder if it's just my system setup then.  I tweaked create_warpper to add readlink inaddition to dirname, let me test more and see if I can reproduce on a clean build.
May 18 17:04:54 <sgw> pidge: ping
May 18 17:06:15 <pidge> sgw: pong
May 18 17:06:39 <RP__> otavio: Looking at this I don't think PKGV has been ported from oe to oe-core so likely its never worked in oe-core
May 18 17:06:41 <sgw> pidge: where's autobuilder pulling today?
May 18 17:07:02 <pidge> sgw: mut IIRC
May 18 17:07:21 <sgw> pidge: thanks, can I fire up a build at my call?
May 18 17:07:26 <pidge> sgw: rather, last build was mut
May 18 17:07:29 <pidge> sure
May 18 17:07:35 <otavio> RP__: I will check it then
May 18 17:07:44 <pidge> http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/126/steps/shell_1/logs/stdio
May 18 17:08:07 <pidge> I echo where I pull from now, to limit confuddlement
May 18 17:08:07 <otavio> Someone got a build fail with gnutls 2.10.4?
May 18 17:08:18 <sgw> great thanks
May 18 17:08:37 <sgw> Was not sure about the back end setup for firing off a new one!
May 18 17:09:35 <pidge> sgw: NP
May 18 17:14:50 <sushisan> hi
May 18 17:15:10 <otavio> RP__: you're right; it hasn't been ported. I am looking at it
May 18 17:15:43 <sushisan> I'm new in yoct but I've some experience in OE. My question is, whats is different btw yocto and OE?
May 18 17:18:17 <fray> sushisan they're related but different..
May 18 17:18:44 <fray> for the 1.0 (and before releases) the have similar code bases, but they're really parallel tracks of development.. with patches moving back and forth solving specific issues..
May 18 17:18:58 <fray> in the up comming "fall" release (1.1) the work/code is being merged..
May 18 17:19:14 <fray> oe, yocto, angrstrom and others will all be based on a single "oe-core" + local distribution modifications
May 18 17:19:16 <sushisan> then will be the same?
May 18 17:19:33 <sushisan> ahhhh
May 18 17:19:48 <fray> Yocto will continue to focus on both improving oe-core (which everyone benefits) as well as providing their own software in their meta-yocto layer...
May 18 17:20:06 <sushisan> ok
May 18 17:20:16 <fray> meta-yocto will include demo/sample code, tooling or components that are not appropriate, ready, or... for oe..
May 18 17:20:25 <fray> meta-openembedded will be the equivalent within the OE project..
May 18 17:20:40 <fray> meta-angstrom will be the angstrom specific items sitting on top of oe-core..  etc..
May 18 17:20:57 <sushisan> there are some date for release of the meta-yocto layer ?
May 18 17:21:11 <fray> (goal is to shrink the duplication of effort over time..  this wasn't there for 0.9 and 1.0 simply due to timing, negotiations between projects, etc..)
May 18 17:21:33 <fray> meta-yocto is already available in the yoctoproject tree.. the work for 1.1 has begun, but it's not yet what I would call "Stable"
May 18 17:22:31 <sushisan> txs!!!
May 18 17:22:36 <RP__> meta-yocto is also intended to be very minimal on top of oe-core, just adding in some real hardware as reference implementations (and even that will be based off upstreams where possible)
May 18 17:22:37 <fray> no prolbem
May 18 17:22:48 <fray> yup.. should have mentioned that as well
May 18 17:23:11 <sushisan> then, for a new project, you recccomend now- yocto or OE?
May 18 17:23:22 <otavio> RP__: why doesn't it merge with meta-oe?
May 18 17:24:06 <RP__> sushisan: I'd base it on oe-core
May 18 17:24:13 <fray> sushisan for a new project I recomment oe-core
May 18 17:24:23 <RP__> otavio: meta-oe is way too large for what we need (4 reference machines)
May 18 17:24:25 <fray> the meta-yocto, meta-oe, etc should be used based on your requirements..
May 18 17:24:41 <sushisan> ok.
May 18 17:25:04 <sushisan> txs
May 18 17:29:33 <otavio> RP__: do you see any problem in using PV instead of PKGV (for git based versions)
May 18 17:29:39 <otavio> ?
May 18 17:29:53 <RP__> otavio: using it where?
May 18 17:30:00 <otavio> RP__: on the recipe
May 18 17:30:12 <otavio> RP__: in this case: freerdp is my test case
May 18 17:30:45 <RP__> otavio: there is a reason that recipe uses PKGV which is that PV needs to be expandable at parse time so you know which WORKDIR to place it in for example
May 18 17:31:06 <sgw> nitink: ping
May 18 17:31:12 <nitink> sgw: pong
May 18 17:31:17 <RP__> otavio: if you make that class use PV it all blows up as when you expand the variable, the source isn't present so it can't work out what the variable should be
May 18 17:31:23 <otavio> RP__: yes; after a clean all it fails.
May 18 17:31:34 <RP__> its why I have a dislike of that code :/
May 18 17:31:45 <sgw> can you take a quick look at this failure: http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/126/steps/shell_1/logs/stdio
May 18 17:31:46 <RP__> otavio: It also wouldn't build from scratch as far as I can see
May 18 17:32:05 <otavio> RP__: right I also dislike the code but I like the end result of it
May 18 17:32:08 <zenlinux> So I'm trying to create an example recipe for demonstrating how to use the new inherit useradd I'm working on. The recipe does not package any files - I'm using it to try testing that the packages which get generated include custom preinst scripts.
May 18 17:32:17 <otavio> RP__: you see any alternative? or just backporting PKGV ?
May 18 17:32:35 <zenlinux> During do_package, I'm getting an error about a missing debugsources.list - where is that expected to come from?
May 18 17:32:42 <RP__> otavio: PKGV was my suggestion to resolve this
May 18 17:32:48 <RP__> otavio: I still think its ugly
May 18 17:33:03 <otavio> RP__: OK; will work at backporting it to oe-core then
May 18 17:33:10 <nitink> sgw: nothing much at that URL
May 18 17:33:32 <sgw> sorry I grabbed the wrong one
May 18 17:34:10 <sgw> nitink: hangon will pastebin it.
May 18 17:34:29 <nitink> sgw: is it withg gcc 4.6.0 ?
May 18 17:35:17 <sgw> nitink: yes, building eglibc for meta-toolchain-gmae
May 18 17:37:04 <sgw> nitink: http://pastebin.com/MiA94thK
May 18 17:37:12 <sgw> nitink: also please check pm
May 18 17:37:41 <nitink> sgw: pm ?
May 18 17:37:54 <nitink> sgw: this is same thing what jessica reported yday
May 18 17:41:33 <sgw> nitink: pm => private message, I don't know what jessica reported yesterday
May 18 17:44:59 <zenlinux> any packaging experts? I'm not packaging any files with this recipe, so I'm not seeing how I can trigger the debugsourcedir processing that's happening withing packages.bbclass
May 18 17:47:16 <sgw> zenlinux: started looking at it give me a minute or two
May 18 17:51:32 <zenlinux> here's the demo recipe I'm experimenting with (WIP): http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/commit/?h=sgarman/user-group-creation&id=7729c4de2283af91ea3698b1da0a952e27d1c159
May 18 18:07:49 <zenlinux> btw, I just added ALLOW_EMPTY_${PN}-dev = "1" and ALLOW_EMPTY_${PN}-dbg = "1" to my recipe and it made no difference
May 18 18:08:25 <sgw> zenlinux: as a tempary thing add INHIBIT_PACKAGE_DEBUG_SPLIT = "1" and see what happens
May 18 18:09:18 <zenlinux> sgw, thanks, that serves as a workaround that unblocks me
May 18 18:12:14 <sgw> zenlinux: great, how about a general ALLOW_EMPTY_${PN} = 1, would that work?
May 18 18:12:29 <zenlinux> sgw, I had that originally and it didn't help
May 18 18:15:38 <khem> RP__: it seems bitbake does not know appended tmpdir
May 18 18:16:03 <khem> RP__: so we endup with ${TMPDIR} and ${TMPDIR}-${TCLIBC} dirs
May 18 18:16:35 <khem> and in bitbake.conf
May 18 18:16:36 <khem> # Forcefully set CACHE now so future changes to things like
May 18 18:16:39 <khem> # MACHINE don't change the path to the cache
May 18 18:16:42 <khem> CACHE := "${CACHE}"
May 18 18:17:21 <RP__> khem: kergoth and I were talking about that on #poky. At least for some of it, it looks like a bitbake bug
May 18 18:17:25 <khem> RP__: I looked at the preprocessed output and there are no references to ${TMPDIR} only ${TMPDIR}-${TCLIBC} is used everywhere
May 18 18:17:40 <khem> oh there is a #poky channel too ?
May 18 18:17:52 <RP__> khem: been one for years and years
May 18 18:17:58 <khem> oe yocto and poky they all should be in one room :)
May 18 18:18:02 * khem was kidding
May 18 18:18:44 <khem> RP__: otherwise the change seems fine except now perl is failing to build
May 18 18:18:51 <khem> I havent figured out the real cause
May 18 18:19:05 <khem> if its related to TMPDIR change or something else
May 18 18:19:45 <RP__> khem: sgw also mentioned this
May 18 18:19:52 <RP__> I wonder if it was Tom Rini's change?
May 18 18:20:13 <khem> | env: ./perl5.12.3.real: No such file or directory
May 18 18:20:13 <khem> | make[1]: *** [lib/Config_git.pl] Error 127
May 18 18:20:13 <sgw> RP__: yes it's related to the create_wrapper
May 18 18:20:43 <sgw> problem is that the miniperl script uses dirname to derive the real path, and the symlink is not getting followed correctly.
May 18 18:20:56 <sgw> I have a fix for it with readlink, will send the patch now.
May 18 18:21:03 <sgw> for review
May 18 18:21:11 <incandescant> cool :-)
May 18 18:22:23 <khem> sgw: I can test it
May 18 18:23:49 <khem> there are so many changes in my sandbox I dont even know who to blame
May 18 18:24:03 <khem> when something breaks
May 18 18:24:15 <khem> stastically 81% of time its me
May 18 18:27:05 <sgw> khem, RP__: mail sent as RFC to see if it solves problem first.
May 18 18:27:28 * khem kicks fetchmail
May 18 18:30:38 <khem> ts rebuilding everything after that patch :( will be a while before I  know if works
May 18 18:31:00 <sgw> khem, just realized I could simply that fix
May 18 18:31:04 * khem is waiting for Tour of California pass by his home today
May 18 18:45:20 <khem> sgw:
May 18 18:45:27 <sgw> khem: go
May 18 18:45:28 <khem> the patch breaks autoconf
May 18 18:45:30 <khem> | env: /home/kraj/work/newoe/build/tmp-angstrom_2010_x-eglibc/work/x86_64-linux/perl-native-5.12.3-r2/temp/perl.real: No such file or directory
May 18 18:45:33 <khem> | configure: error: Perl 5.005_03 or better is required
May 18 18:46:29 <khem> its absolute link into build area
May 18 18:46:36 <khem> and not into native sysroot
May 18 18:47:19 <sgw> that's weird, then autoconf is wrong, it should go to sysroot not build area.  Maybe this is part of that workaround we pull recently.
May 18 18:49:59 <sgw> khem, I have a fresh build going here also, I will see what I get.
May 18 18:51:00 <khem> realpath=/home/kraj/work/newoe/build/tmp-angstrom_2010_x-eglibc/work/x86_64-linux/perl-native-5.12.3-r2/temp/run.do_install.6903
May 18 18:51:04 <khem> exec env PERL5LIB=$PERL5LIB:/home/kraj/work/newoe/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/lib/perl/5.12.3:/home/kraj/work/newoe/build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/lib/perl/ `dirname $realpath`/perl.real "$@"
May 18 18:51:08 <khem> thats content of wrapper
May 18 18:51:11 <khem> which is wrong
May 18 18:51:39 <khem> see realpath
May 18 18:52:00 <sgw> khem, correctly, what's the script linked to?
May 18 18:52:30 <khem> the above is content of build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/perl
May 18 18:52:37 <sgw> in both sysroot/..//perl/ and is there a link to that?
May 18 18:52:57 <sgw> realpath is set?
May 18 18:53:02 <khem> there is build/tmp-angstrom_2010_x-eglibc/sysroots/x86_64-linux/usr/bin/perl.real too
May 18 18:53:11 <khem> yes realpath is calculated at build time
May 18 18:53:16 <khem> and put into the wrapper
May 18 18:53:18 <sgw> that's wrong
May 18 18:53:40 <khem> so that readlink thingy is not ok
May 18 18:53:41 <sgw> I thought it was going to be at runtime, that's my problem then.
May 18 18:53:47 <khem> yep
May 18 18:53:54 <sgw> readlink is correct if executed at runtime.
May 18 18:53:58 <khem> hah
May 18 18:54:03 <khem> you asked it to run at build time
May 18 18:54:12 <khem> realpath=`readlink -fn \$0`
May 18 18:54:32 <sgw> it's inside a cat
May 18 18:54:34 <khem> realpath=\`readlink -fn \$0\`
May 18 18:54:41 <sgw> Doh!
May 18 18:54:44 <sgw> right
May 18 18:54:50 <sgw> that's why it's an RFC!
May 18 18:55:01 <khem> I am just guessing
May 18 18:55:14 <khem> havent tried it
May 18 18:55:17 <khem> but lemme
May 18 18:55:19 <sgw> your right, bone head move on my part!
May 18 18:57:06 <khem> send V2
May 18 18:57:31 <sgw> khem: It was late last night when I did this, did the \' work?
May 18 18:57:55 <khem> still cooking
May 18 18:58:00 <khem> may be another couple of mins
May 18 19:01:31 <khem> sgw: realpath=`readlink -fn $0` appears in the bash script wrapper
May 18 19:01:39 <khem> seems to be correct
May 18 19:01:48 <sgw> khem: good that's what I expected!
May 18 19:01:49 <khem> and autoconf configure succeeded as well
May 18 19:05:02 <sgw> great!
May 18 19:37:26 * zeddii just built otavio's BSP. and slaps his head for missing the obvious.
May 18 19:41:19 * otavio is curious about the obvious
May 18 19:43:55 <zeddii> otavio, I'll send you two patches, with an explanation. easier to type in email.
May 18 19:44:03 <zeddii> sending them in the next few minutes.
May 18 19:44:10 <zeddii> (patches to your meta)
May 18 19:44:14 <zeddii> and then  I'll find you those docs.
May 18 19:58:56 <otavio> zeddii: OK :-) Nice!
May 18 20:05:21 <sgw> jama: ping
May 18 20:11:54 <JaMa> pong
May 18 20:13:07 <sgw> JaMa: Have you had any problems with developer.imendio.com recently?  It seems to be down I am trying to pull gconf-dbus  (for a squeaky clean build)
May 18 20:13:57 <JaMa> yes, about month ago.. since then I've gconf-dbus blacklisted (and using gconf itself)
May 18 20:14:18 <sgw> Right OK, was it working a month ago or failing then also?
May 18 20:15:23 <JaMa> no it was failing but iirc I've found tarballed svn checkouts for right SRCREV on yocto source mirror
May 18 20:16:24 <JaMa> and I still have ~/downloads/trunk_developer.imendio.com_.svn.gconf-dbus_705_.tar.gz
May 18 20:16:26 <sgw> right that the expected behavior, like I said was checking a really clean with no mirror settings verifying upstream availability, which found a few problems!
May 18 20:16:36 <sgw> I also have a copy.
May 18 20:17:10 <JaMa> so I can confirm that this problem was there on Mar  8 already
May 18 20:17:32 <sgw> more inquiring if you knew about the web site itself, I will work to contact those maintainers.
May 18 20:18:55 <JaMa> no idea about that site.. actually when I discovered it I expected it's some temporary issue as nobody was complaining..
May 18 20:19:14 <sgw> It's clearly more long term (maybe gone)
May 18 20:19:45 <JaMa> why not drop gconf-dbus from oe-core as was already proposed on ML iirc?
May 18 20:20:03 <JaMa> maybe the site is down because nobody needed it for really long
May 18 20:20:24 <sgw> JaMa:  Yes, I it's on the list for deeper consideration, it's rapidly moving up!
May 18 20:20:48 <JaMa> hehe :) then it's moving in right direction
May 18 20:29:58 <nitink> sgw: looks like upgrading eglibc to 2.13 solves the problem
May 18 20:31:36 <sgw> JaMa: that patch is still pending due to the lack of a patch with a gconf recipe/package itself, that patch would not be buildable in oe-core!
May 18 20:32:01 <sgw> nitink: OK, this cropped up with 4.6 and eglibc 2.13 address it, then please update.
May 18 20:32:25 <nitink> sgw: eglibc 2.13: need more testing though
May 18 20:32:58 <sgw> pull it in for testing with 4.6 and have 2.12 and 2.13 temporarily.
May 18 20:38:33 <sgw> bluelightning: ping
**** ENDING LOGGING AT Thu May 19 02:59:58 2011

**** BEGIN LOGGING AT Thu May 19 02:59:58 2011
May 19 07:20:52 * Jay7 is reading minutes from TSC meeting
May 19 07:21:04 <Jay7> /yocto still has no sysadmin, infrastructure somewhat stalled
May 19 07:21:38 * Jay7 is sysadmin ;)
May 19 07:40:16 <Jay7> about 'OE need more HW' - we need infrastructure that allow distributed building and stats collecting like it was done in OE
May 19 07:40:25 <Jay7> autobuilder is really useful
May 19 07:41:05 <Jay7> but easy way to get stats from LOT of builds is to allow our users to report stats somewhere
May 19 07:41:28 <Jay7> we are working slowly on this, but seems too slow
May 19 07:55:41 <RP__> morning all
May 19 07:56:44 <RP__> Jay7: totally agree on the infrastructure
May 19 07:57:15 <RP__> The sysadmin thing is complex and based at a specific US location FWIW
May 19 07:58:23 <Jay7> RP__: well.. anyway, if you will need remote admin one time - note me ;)
May 19 08:02:41 * RP__ will keep it in mind
May 19 08:38:22 * bluelightning -> office
May 19 09:03:45 <JaMa> RP__: Hi, I've extended your allarch.bbclass patch to recipes in meta-oe and meta-smartphone layers and found another issue with it :/
May 19 09:05:11 <JaMa> RP__: I'm using debian.bblass for naming, but allarch recipes doesn't take right runtime package names into account, so ie gtk-theme-e17lookalike depends on "gtk+" instead of "libgtk-2.0"
May 19 09:06:00 <JaMa> RP__: so do_rootfs fails in the end because cannot find "gtk+"
May 19 09:06:51 <RP__> JaMa: ouch
May 19 09:07:24 <RP__> JaMa: Its because we zero'd out PACKAGE_EXTRA_ARCHS which is used as a search path for dynamic renaming
May 19 09:07:34 * JaMa almost ready to /PACKAGE_ARCH.*all/d :/
May 19 09:07:57 <RP__> JaMa: "all" arch packages have always been ugly :(
May 19 09:08:14 <RP__> sstate just shows us all the ways they were broken
May 19 09:08:54 <RP__> JaMa: We might have to allow PACKAGE_EXTRA_ARCHS and just exclude the dependencies on it
May 19 09:14:13 <JaMa> what do you mean by exclude dependencies?
May 19 09:15:18 <JaMa> and btw I'm not sure if allarch was enought for some recipes (like that encodings, font-alias..) in the end I did -c cleanall for all recipes in question.. but then was hit by this do_rootfs error (before checking sigdata)
May 19 09:46:52 <RP__> JaMa: I mean vardepsexclude()
May 19 09:47:10 <RP__> i.e. stop that variable affecting the checksum from some usecases
May 19 10:20:12 <JaMa> ah, I see
May 19 12:35:42 <otavio> Morning ...
May 19 12:40:03 <bluelightning> hi otavio
May 19 12:57:54 <otavio> zeddii: around? I will paste the file you asked for...
May 19 12:58:34 <otavio> zeddii: http://paste.debian.net/117375/
May 19 13:06:44 <zeddii> otavio. I'm around, going for coffee and will have a look!
May 19 13:07:15 <otavio> zeddii: nice; I am with one at my right side :-D
May 19 13:11:41 <dbire1> Hi, I have a problem with bitbake -fc clean xxxx => Error Directory not empty. Does it tell you something ?
May 19 13:20:01 <RP__> dbire1: Are there some files your current user can't delete or something like that?
May 19 13:23:52 <otavio> I fail to understand which problem remote PR try to solve ... can someone clear it to me?
May 19 13:25:12 <RP__> otavio: Building consistent package feeds whilst allowing PR to autoincrement when sstate checksums change
May 19 13:30:54 <JaMa> RP__: I tried PACKAGE_ARCHS[vardepsexclude] = "PACKAGE_EXTRA_ARCHS" in allarch but looks like it's not right syntax or missing renames are caused by something else too
May 19 13:35:18 <otavio> RP__: ahhhhh
May 19 13:47:05 <zeddii> otavio. the meta-series you have, is consistent with what I'd expect .. when it isn't working, and what I saw and fixed yesterday. and what I didn't get when I cloned your tree and ran my clean build last night. I'm going to have to figure out a way to instrument your build, since I can no longer reproduce the issue here.
May 19 13:47:48 <zeddii> can you confirm that between pushing my fixes to your meta branch that you completed removed the old build ? i.e. rm -rf'd the whole thing ? if the src tree was re-used at all, it would have picked up the old autogenerated description first.
May 19 13:55:12 <otavio> zeddii: the git repo, from download, I didn't
May 19 13:55:43 <otavio> zeddii: but I expected it to update it, no?
May 19 13:59:35 <zeddii> it should update. I'm being paranoid, since it should have been fixed. and you did a clean on linux-yocto before rebuilding and confirmed it went away ? again being paranoid, since it doesn't make sense yet.
May 19 14:00:15 <otavio> zeddii: I did a clean, not clean all...
May 19 14:00:39 <otavio> zeddii: just to confirm .. it ought to build the modules if my defconfig has those right?
May 19 14:01:14 <zeddii> it should. but the meta-series you posed wouldn't have picked up your defconfig, it went a generated a stock one to give you 'something'.
May 19 14:01:45 <otavio> zeddii: my machine name is right I think ...
May 19 14:02:15 <otavio> zeddii: want me to do a cleanall?
May 19 14:03:38 <zeddii> it's worth a try, just the refetch time to wait through :)
May 19 14:04:00 <otavio> zeddii: doing
May 19 14:04:03 <otavio> zeddii: :-(
May 19 14:04:34 <zeddii> and if that fails, I'm getting some more debug options ready. I intend to see this fixed today.
May 19 14:04:49 <otavio> zeddii: me too
May 19 14:05:00 <otavio> zeddii: I need it to advance the rest of the image
May 19 14:05:19 <otavio> zeddii: the worse is it ought to be a stupid thing in either side
May 19 14:06:23 <zeddii> definitely. but what you had there, is *exactly* what I had here when looking at your meta files, but it's still fixed here. hence my head scratching.
May 19 14:07:46 <otavio> NOTE: package linux-yocto-2.6.37+git4+403a3bf1e0882bc99d941fa370b1766177318b63_1+5f8bb26f6ee2e181996634b98e553b39e95a00fe-r18.oss.0: task do_fetch: Started
May 19 14:49:13 <sgw> morning folks
May 19 14:49:22 <otavio> sgw: welcome back
May 19 14:57:56 <zenlinux_laptop> morning all
May 19 14:58:23 <zenlinux_laptop> fray, will you have time to chat later today?
May 19 15:02:29 <fray> yes I should.. calling into the go/no-go now
May 19 15:04:22 <fray> I'm here too.. ;)
May 19 15:05:08 <fray> Umm you guys can't hear me
May 19 15:05:14 <fray> I've been talking
May 19 15:05:24 <fray> I'll dial back in
May 19 15:05:37 <sgw> fray: no voice sorry
May 19 15:15:12 <fray> no objection
May 19 15:29:03 <otavio> zeddii: we have a problem ..
May 19 15:29:18 <otavio> zeddii: I have done cleanall and it built fine. So what was missing?
May 19 15:30:39 <zeddii> otavio, something didn't get purged on your previous fetch and clean. I'm not 100% in the know there. do you recall the steps you used, maybe someone with deeper bitbake roots can spot what went wrong.
May 19 15:30:48 <zeddii> but I'm glad to hear that the kernel config finally got picked up.
May 19 15:31:17 <otavio> zeddii: I just did bitbake linux-yocto
May 19 15:31:38 <otavio> zeddii: after I pushed the two commits you sent me I did it once again
May 19 15:32:05 <otavio> zeddii: and it built but seems to haven't take the last update ... or something like that
May 19 15:32:50 <otavio> zeddii: what bothers me is that it seems to have taken the right hash of meta branch
May 19 15:32:53 <zeddii> in the exiting build. hmm. it should have refetched (unless autorev let us down). and in theory triggered the kernel rebuild, but unless the src tree (in your build) was actually removed, the autogenerated helper would have gotten in the way.
May 19 15:32:55 * zeddii thinks
May 19 15:33:24 <otavio> zeddii: yes but it seems it has done it ...
May 19 15:33:44 <otavio> zeddii: only if the revision has been taken but the branch wasn't really update
May 19 15:34:12 <otavio> zeddii: so it would update PV but not the data and as result the tarball would be outdated and then a rebuild wouldn't fix it.
May 19 15:34:37 <nitink> Good Morning All !
May 19 15:34:48 <otavio> nitink: good :-D now that I have a built kernel :-D
May 19 15:34:49 <otavio> heh
May 19 15:35:21 <nitink> otavio: great ! :)
May 19 15:35:44 * otavio was driving zeddii crazy :-D
May 19 15:36:04 <zeddii> definitely not! I'll deny it
May 19 15:36:09 <otavio> zeddii: does what I said makes any sense to you?
May 19 15:37:37 <sgw> pidge: sanity check on the crownbay bernard build, you are using the bernard branch, correct?
May 19 15:37:38 * otavio goes to have lunch ... bbl
May 19 15:37:41 <zeddii> it seems so. I'm not familar enough about the PV -> data update chain. I'm looking at code to learn a bit.
May 19 15:37:47 <zeddii> mmm. food. good idea.
May 19 17:04:04 <sgw> RP__: pidge: fray: I understand the failure from libzypp 1.0.1 and crownbay, it's in poky-arch.h because of how PACKAGE_EXTRA_ARCHS is contructed in 1.0 vs 1.1
May 19 17:05:49 <sgw> 1.0 constructs it with a PACKAGE_EXTRA_ARCHS with a +=, and crownbay has a PACKAGE_EXTRA_ARCHS defined with x86 in it, while in 1.1 PACKAGE_EXTRA_ARCHS is defined with = in tune-atom and crownbay has removed it's PACKAGE_EXTRA_ARCHS, therefor x86 is not duplicated in that list.
May 19 17:05:59 <sgw> I will send email also.
May 19 17:06:28 <tomz1> sgw: I cherry picked the crownbay changes from master and pushed them to bernard
May 19 17:06:37 <tomz1> sgw: should be good to go
May 19 17:07:01 <sgw> thanks
May 19 17:07:32 <tomz1> tomz1: still wonders why this started happening just now - bernard 1.0 has never had problems until now
May 19 17:08:23 <sgw> RP__: ping
May 19 17:08:24 <zeddii> sgw: speaking of. What's the 1.0.1 status, is there time to do the defconfig fix that I mentioned on the mailing list yesterday ?
May 19 17:08:36 <sgw> huh?
May 19 17:08:50 <zeddii> aha. caught not reading kernel email
May 19 17:09:16 <sgw> zeddii: I missed any fix suggestion for 1.0.1 and we are making the go/no-go today
May 19 17:09:25 <zeddii> a build failure in bernard when using a defconfig. I found it post 1.0 and fixed it in master. but it's a 3 line fix to the yocto kernel class to get it working there.
May 19 17:09:53 <zeddii> none of the qemu* or yocto boards need it. only if you do a defconfig, and there's still a work around, so I won't rock the boat on it.
May 19 17:10:55 <otavio> zeddii: better talk to you later?
May 19 17:11:29 <sgw> zeddii: OK, might grab it up later for a post 1.0.1 patch list, but not so close to 1.0.1 closure.
May 19 17:24:44 <RP__> sgw: pong
May 19 17:26:21 <zaraza> hi
May 19 17:26:29 <zaraza> I have a problem with oe-core
May 19 17:26:52 <zaraza> in : bitbake core-image-minimal
May 19 17:26:54 <sgw> RP__: I noticed you took the patch, you will find a conflict with the consoildated pull, I noticed that the patch was not complete and updated it in the consolidated pull
May 19 17:27:04 <sgw> zaraza: hi, what's your issue?
May 19 17:27:22 <zaraza> at perl compilation breaks with:  env: ./perl5.12.3.real: No such file or directory
May 19 17:27:38 <otavio> zaraza: it has been fixed today on oe-core AFAIK
May 19 17:27:48 <otavio> zaraza: you might want to rebase your tree ;-)
May 19 17:27:51 <zaraza> ahhhhhhhhhhh
May 19 17:27:53 <zaraza> txs!!!!
May 19 17:27:54 <sgw> zaraza:  there is a fix for that I think it's in oe-core now you will need to clean perl-native if you have a build already.
May 19 17:28:16 <otavio> sgw: clean or cleanall?
May 19 17:28:40 <sgw> otavio: a simple clean should work in this case, it needs to rebuild the wrapper script
May 19 17:28:48 <otavio> sgw: ah ok
May 19 17:29:02 <davest> sgw: got a minute?
May 19 17:29:29 <sgw> I can drop from the training review call if you want to talk now
May 19 17:29:47 <davest> sgw:nah, how about the top of the hour?
May 19 17:30:26 <sgw> davest: check pm
May 19 17:39:26 <Crofton|work> life must suck with managers tracking you down on irc
May 19 17:39:29 <Crofton|work> :)
May 19 17:41:36 <sgw> Crofton|work: the joys or downfalls of remote work
May 19 17:42:03 <Crofton|work> yeah
May 19 17:42:15 <zaraza> perl5.12.3.real: No such file or directory
May 19 17:42:16 <zaraza> same error
May 19 17:42:32 <sgw> zaraza: you did a bitbake -c clean perl-native?
May 19 17:43:01 <zaraza> ooops nop...sorry
May 19 18:43:23 <otavio> zeddii: now my next step is to have a way to know the version (the internal one) of kernel is being build. So I can store it somewhere.
May 19 18:43:45 <otavio> zeddii: any clue how to "get" it?
May 19 18:44:35 * zeddii reads
May 19 18:46:01 <zeddii> ah. yes. you mentioned this before. can you remind me of the use case ? there's a variable in the recipes that always has the version that is the base of the tree.
May 19 18:52:08 <otavio> zeddii: I need to know the final file that will be deployed into image dir since I use it to generate a description file used by our deploy infra structure here
May 19 18:52:48 <otavio> zeddii: so I need the version
May 19 18:53:21 <otavio> zeddii: I noticed you're rebasing all stuff to 2.6.39 ... would be a problem if I base my tree on it?
May 19 18:55:26 <zeddii> should be safe, that's the leading edge of the wedge. it'll will follow through the latest continually and fork for 1.1 at the appropriate time.
May 19 18:59:15 <otavio> zeddii: EPARSEERROR
May 19 18:59:20 <otavio> zeddii: heh
May 19 18:59:49 <zeddii> the -dev recipe is on 2.6.39. it'll follow 2.6.40 as well.
May 19 19:00:00 <zeddii> when we get to the 1.1 decision point, that tree becomes the base for 1.1, etc.
May 19 19:00:21 <zeddii> your branch as it stands, would work right on that tree, with the meta updates applied.
May 19 19:00:51 <otavio> zeddii: ah right but noone will work at maintain .39 one on it right?
May 19 19:01:19 <otavio> zeddii: and for .40 you'll do a rebase again or a merge?
May 19 19:02:02 <zeddii> right. 39 is transient, but everything in it (say we had a feature) would go forward.
May 19 19:02:37 <zeddii> the content is minimal to .39 at the moment, so a merge is possible, but more likely a rebase, it'll only rebase at version switch points (for now). just to keep it clean.
May 19 19:04:27 <otavio> better to stay at 37 for now then; after I clean up my builds I can do the same for next one
May 19 19:05:26 <zeddii> yep. I've got a build running I nuked my images, I want to look at the deploy directory :)
May 19 19:05:30 * otavio doing a build from scratch with clean sstate
May 19 19:42:19 <RP__> sgw: ouch, ok
May 19 19:42:40 <RP__> I'm trying to get through stuff today but the pull request isn't looking like its going to make it tbh
May 19 19:42:54 <sgw> RP__: Just sent you an updated pull request
May 19 19:44:06 <sgw> RP__: OK, If I queue up more do you want it in a different branch or a V3 of this one?
May 19 19:44:23 <RP__> sgw: different branch and on top of this one
May 19 19:44:24 <sgw> We really do nedd to cherry-pick in the U-boot fix
May 19 19:44:59 <RP__> sgw: I've totally screwed up my working tree trying to do too many things at once
May 19 19:45:04 <sgw> RP__: that way beth can get the beagleboard built for PRC QA today
May 19 19:45:21 <RP__> sgw: ok, ok, ok
May 19 19:45:51 <sgw> RP__: Sorry to hear that.  I know the feeling, I messed stuff up yesterday myself, I will leave you to it then no rush on any of the other stuff.
**** ENDING LOGGING AT Fri May 20 03:00:00 2011

**** BEGIN LOGGING AT Fri May 20 03:00:00 2011
May 20 08:09:38 <ant_work> hello bluelightning
May 20 08:10:34 <bluelightning> hi ant_work
May 20 10:14:22 <RP__> morning all
May 20 10:14:35 <RP__> JaMa: Did you have any fixes on top of my allarch patch?
May 20 10:22:25 <JaMa> RP__: only those I wrote yesterday about
May 20 10:24:55 <RP__> JaMa: You didn't fix any of the font* configure issues?
May 20 10:25:11 * RP__ is just checking to avoid duplicating anything
May 20 10:25:21 <JaMa> font-alias
May 20 10:25:51 <JaMa> which was in dep-tree of my image, but then I got stuck on that EXTRA_PACKAGE_ARCH..
May 20 10:26:15 <RP__> JaMa: If you could post that patch to the list it would be good, then it saves someone else doing it
May 20 10:26:30 <RP__> one way or another we'll get this fixed :)
May 20 10:29:14 <RP__> JaMa: this is probably a good thing to share a topic branch on in the contrib tree actually
May 20 10:29:31 <RP__> then whenever someone fixes pieces of it we can update it
May 20 10:30:28 <JaMa> I wanted to test it properly first :/, so is this syntax wrong or you meant something else? 15:27 < JaMa> RP__: I tried PACKAGE_ARCHS[vardepsexclude] = "PACKAGE_EXTRA_ARCHS" in allarch but looks like it's not right syntax or missing renames are caused by something else too
May 20 10:31:34 <JaMa> and I also did my changes without PR bumps, because I don't want to break upgrade-paths on target before it's ready to be pushed
May 20 10:31:53 <JaMa> OK, I'll push what I have to contrib
May 20 10:32:14 <RP__> JaMa: I don't know the exact syntax of that variable at this point but let me take a look
May 20 10:33:18 <JaMa> this was also used in your shared state description on ML
May 20 10:35:57 <RP__> Hmm, PACKAGE_ARCHS[vardepsexclude] = "PACKAGE_EXTRA_ARCHS" should have done it
May 20 10:36:30 <RP__> you added that, did you still zero PACKAGE_EXTRA_ARCHS?
May 20 10:39:15 <JaMa> no
May 20 10:40:07 <JaMa> RP__: jansa/allarch in oe-core-contrib
May 20 10:41:16 <RP__> JaMa: conf/bitbake.conf:PACKAGE_ARCHS[vardepsexclude] = "MACHINE_ARCH"
May 20 10:41:25 <RP__> JaMa: I wonder if we need to use += :)
May 20 10:41:46 <JaMa> ah, I'll try :)
May 20 11:16:36 <JaMa> RP__: still wrong names :/
May 20 11:35:41 <RP__> JaMa: :(
May 20 11:36:10 <JaMa> I shouldn't zero PACKAGE_EXTRA_ARCHS in allarch, right?
May 20 11:45:41 <JaMa> RP__: image build finished without those 2 using allarch, now I can at least check if checksums are the same now :)
May 20 11:46:33 <JaMa> RP__: btw is it known that -b something causes different sstate checksums? I use it to build something after fix (to save parsing time) but then starting image build it rebuilds it again
May 20 12:02:59 <JaMa> RP__: now it looks better http://paste.pocoo.org/show/392191/
May 20 12:06:41 <JaMa> RP__: can we get rid of those _setscene tasks for allarch?
May 20 12:18:09 <JaMa> RP__: bc1a87f3806e021e868bf455a342fccf97a7394d was pushed to origin/maste (without R)
May 20 13:36:41 <RP__> JaMa|Off: no, the setscene needs to run
May 20 13:36:51 <RP__> (populate the appropriate sysroot for the machine)
May 20 15:02:33 <sgw> morning folks
May 20 15:10:39 <sgw> dvhart: morning
May 20 15:11:11 <dvhart> sgw, not so much looks like :/
May 20 15:11:31 <dvhart> I have an idea, investigating
May 20 15:12:34 <sgw> dvhart: you mean it's not morning?  The sun is out today afterall peeking up from the east!
May 20 15:12:42 <sgw> ;-)
May 20 15:13:06 <dvhart> :) beagleboard failures are weird
May 20 15:13:12 <dvhart> and my idea doesn't pan out
May 20 15:13:22 <dvhart> no idea why the ab and prc are seeing what they are seeing
May 20 15:13:29 <dvhart> I confirmed this as working on 3 boards
May 20 15:16:35 <sgw> dvhart: what's the git HEAD rev? I am going to look at the ab sources
May 20 15:17:08 <dvhart> 53b15f2732cef26473ff651f86da3e4808616989
May 20 15:17:11 <dvhart> that's for bernard
May 20 15:17:42 <dvhart> the weird thing is prc (and robert earlier) reported the name was 2011.03, but the binary contained strings for 2010.12
May 20 15:17:58 <dvhart> that would explain the MD5SUM errors you saw - if this is a fetcher problem
May 20 15:18:13 <sgw> right, saw that last night, I am checking now.
May 20 15:19:45 <sgw> This is the top commit in the AB:
May 20 15:19:45 <sgw> commit 8d4addc3c3fe1a9ea160a5a1a20a1f934ff3fe97
May 20 15:19:45 <sgw> Merge: 367c665 26e5f79
May 20 15:19:45 <sgw> Author: Wolfgang Denk <wd@denx.de>
May 20 15:19:45 <sgw> Date:   Sun Feb 6 22:41:53 2011 +0100
May 20 15:20:10 <sgw> somethings not right
May 20 15:21:19 <sgw> unfortunately because AB uses rm_work, there's no way for me to see the checked-out git repo
May 20 15:21:43 <dvhart> oh sorry
May 20 15:21:52 <dvhart> you wanted the git head of u-boot?
May 20 15:22:23 <dvhart> commit 19b54a701811220221fc4d5089a2bb18892018ca
May 20 15:22:23 <dvhart> Author: Wolfgang Denk <wd@denx.de>
May 20 15:22:23 <dvhart> Date:   Thu Mar 31 23:45:36 2011 +0200
May 20 15:23:10 <dvhart> sgw, the hash you reported:
May 20 15:23:13 <dvhart> Precedes: v2011.03-rc2
May 20 15:23:32 <dvhart> so that is older, and probably explains the MD5SUM issues as well as the strings issues
May 20 15:24:11 <sgw> yes, I am looking at the fetcher logs and also, I have a local build that I am checking on.
May 20 15:25:14 * dvhart kicks off a clean build on rage
May 20 15:37:49 <sgw> dvhart: sanity check, so that we maybe see the same stuff, I did a cleanall on u-boot, verified that the git2/git.denx... was gone along with the tarball, looks like the fetcher grabbed it from the auto builder (which has the older version).
May 20 15:38:03 <sgw> dvhart: question is why we are not fetching the newer version
May 20 15:38:18 * dvhart nods
May 20 15:38:30 <dvhart> I just purged everything as well, build at 50%
May 20 15:39:34 <nitink> Good Morning All !
May 20 15:48:12 <sgw> Looking at my debug logs now, and digging into fetcher2/git.py and init.py!
May 20 15:59:17 <dvhart> sgw, fun times ;-)
May 20 16:01:24 <RP__> remember that the autobuilder's source directory is a copy of the upstream so looking at the clone directory is not a good judge of what its using
May 20 16:02:01 <sgw> dvhart, what's in your poky-default-revisions.inc file for u-boot?
May 20 16:02:16 <sgw> dvhart: that would be in meta/conf/distro/include
May 20 16:02:49 <dvhart> SRCREV_pn-u-boot ??= "v2010.12"
May 20 16:03:41 <sgw> RP__: a ??= question, SRCREV_pn-u-boot ??= "v2010.12", but the recipe file contains a SRCREV = "v2011.03", the fetcher is seeing the v2010..12 version, what's wrong with this picture?
May 20 16:04:04 <RP__> nothing, thats working exactly as intended
May 20 16:04:39 <RP__> SRCREV_pn-u-boot ??= "v2010.12" means assign SRCREV_pn-u-boot the value of "v2010.12" if nothing else sets it
May 20 16:04:45 <sgw> So what's the right way to set SRCREV in the recipe, or for 1.0.1 that's not the right way, it has to be done in the .inc file?
May 20 16:05:17 <sgw> Right, but the recipe sets SRCREV, or should it be setting SRCREV_${PN}?
May 20 16:05:17 <RP__> sgw: get rid of the SRCREV_pn-u-boot ??= "v2010.12"
May 20 16:05:33 <sgw> RP__: ok, got it.
May 20 16:05:36 <RP__> sgw: SRCREV_pn-u-boot overrides SRCREV if set
May 20 16:05:44 <dvhart> ah right
May 20 16:05:51 <dvhart> has nothing to do with ??= in this case
May 20 16:06:03 <RP__> no
May 20 16:06:15 <RP__> now if the recipe set SRCREV_pn-u-boot = "xxx"...
May 20 16:06:33 <sgw> right, then it would have worked.
May 20 16:06:52 <dvhart> understood
May 20 16:06:54 <sgw> dvhart: are you going to patch or am I?
May 20 16:07:21 <dvhart> sgw, I think it would be the most expedient for you to just drop the u-boot line from default revisions
May 20 16:07:27 <dvhart> since that is the direction master went
May 20 16:07:28 <sgw> dvhart:  also do you need to kill the omap3 one?
May 20 16:08:20 <dvhart> it can go too
May 20 16:08:25 <dvhart> we no longer have that recipe
May 20 16:08:38 <sgw> Ok, updated patch coming shortly, I need to fix up the checksums also!
May 20 16:08:48 <dvhart> sgw, why?
May 20 16:09:02 <dvhart> sgw, I believe that was an artifact of the wrong checkout being used
May 20 16:09:23 <sgw> because I checked into master the older checksum again
May 20 16:09:31 <dvhart> what?
May 20 16:09:33 <dvhart> bah
May 20 16:09:35 <dvhart> yeah, undo that
May 20 16:09:48 <dvhart> that should have been a clue right there
May 20 16:10:10 * RP__ wondered about that patch
May 20 16:10:16 <sgw> revert, RP is not wild abourt reverts, yeah, well was in a rush and thought maybe ..., any way what's done is done.
May 20 16:10:50 <dvhart> a revert is appropriate here IMO, but I didn't mean "git revert" necessarily - just undo
May 20 16:11:40 <RP__> sgw: I can revert it if its easiest?
May 20 16:12:03 <sgw> Let me verify what's going on and I will let you know.
May 20 16:12:19 <sgw> from the bernard standpoint, it's not fully pushed yet
May 20 16:12:54 <sgw> I put it in a staging area, so we could revert my commit in master and then just take the .inc file update, let me finish the build here first.
May 20 16:13:07 <dvhart> .inc file update?
May 20 16:13:16 <dvhart> oh
May 20 16:13:24 <dvhart> the def-rev inc, right
May 20 16:13:31 <dvhart> (thought you meant u-boot.inc)
May 20 16:14:13 <dvhart> so what this means is I never checked the output of my bernard build of this patch
May 20 16:14:26 <dvhart> I did run it, but I failed to confirm the resulting binary :/
May 20 16:14:38 <dvhart> (or the build itself I guess, since it should have failed0
May 20 16:15:20 <sgw> I am still not sure how you got the new git so that the chksum's where updated?
May 20 16:15:23 <dvhart> sgw, I'm building with the inc fix now
May 20 16:15:34 <dvhart> sgw, develop in master, cherry pick to barnard
May 20 16:15:36 <dvhart> bernard
May 20 16:15:47 <dvhart> master doesn't have the def rev issue
May 20 16:15:50 <sgw> yup, that would have done it.
May 20 16:16:06 <dvhart> lesson learned
May 20 16:16:31 <dvhart> I did actually build in bernard, but had to leave the machine to go into the office or some such, and never got back to check on the build - bad dvhart
May 20 16:16:46 <sgw> All around, check thy checksums and code, they are there for a reason, bad sgw!
May 20 16:17:23 <sgw> yup, for a reverted batch, just the def-rev.inc patch is all that's needed.
May 20 16:17:33 <sgw> s/batch/patch/
May 20 16:18:36 <sgw> dvhart: what should I look for to verify the u-boot image?
May 20 16:19:06 <dvhart> sgw, working on that now....
May 20 16:19:23 <sgw> strings looks ok this time
May 20 16:19:36 <dvhart> me too
May 20 16:19:45 <dvhart> let me toss it on a bbxm
May 20 16:20:00 <dvhart> doing it now
May 20 16:20:29 <sgw> Different commit ref than above
May 20 16:22:45 <dvhart> bernard boot u-boot validated, kernel booting
May 20 16:22:56 <dvhart> $ git diff
May 20 16:22:56 <dvhart> diff --git a/meta/conf/distro/include/poky-default-revisions.inc b/meta/conf/dis
May 20 16:22:56 <dvhart> index 97998f6..20f54d9 100644
May 20 16:23:01 <dvhart>  SRCREV_pn-trace-cmd ??= ${TRACECMDREV}
May 20 16:23:03 <dvhart>  SRCREV_pn-kernelshark ??= ${TRACECMDREV}
May 20 16:23:05 <dvhart>  SRCREV_pn-tidy ??= "e25416e1293e1074bfa6727c80527dcff5b1f3cb"
May 20 16:23:07 <dvhart> -SRCREV_pn-u-boot-omap3 ??= "f40f6db278f602b55820693634a7256b0b4e4b80"
May 20 16:23:09 <dvhart> -SRCREV_pn-u-boot ??= "v2010.12"
May 20 16:23:11 <dvhart>  SRCREV_pn-ubootchart ??= "10"
May 20 16:23:13 <dvhart>  SRCREV_pn-webkit-gtk ??= "72836"
May 20 16:23:15 <dvhart>  SRCREV_pn-web-webkit ??= "130"
May 20 16:23:17 <dvhart> that is the fix I used
May 20 16:23:19 <dvhart> to bernard
May 20 16:23:36 <dvhart> sgw, you can add my Acked-by to the patch
May 20 16:23:43 <sgw> dvhart: what's the the u-boot work directory?
May 20 16:23:46 <sgw> Ok
May 20 16:24:02 <dvhart> tmp/work/beagle.../u-boot...
May 20 16:24:11 <sgw> dvhart: what's the git rev in your work directory name?
May 20 16:25:40 <dvhart> hrm
May 20 16:26:55 <dvhart> 8d4addc3c3fe1a9ea160a5a1a20a1f934ff3fe97
May 20 16:26:59 <dvhart> which I don't think is right
May 20 16:27:10 * dvhart rebuilds
May 20 16:27:29 <sgw> RP__: So for master, we need to revert my change (checksum modes), since there is no def-rev.inc, and in bernard, I just push the change to def-rev.inc
May 20 16:27:55 * sgw has 
May 20 16:27:57 <sgw> b29fbb347698286935bfc401c08499a6f63479de
May 20 16:28:03 <RP__> sgw: "u-boot: fix LIC_FILE_CHKSUM"
May 20 16:28:14 <RP__> ?
May 20 16:28:23 <sgw> RP__: yes
May 20 16:28:33 <RP__> sgw: ok, I can push that now?
May 20 16:28:44 <sgw> the ref hash is for u-boot upstream, not oe-core
May 20 16:28:52 <sgw> RP__: yes
May 20 16:29:03 <RP__> sgw: done
May 20 16:30:10 <dvhart> sgw, I'm still not building the v2011.03 tag
May 20 16:30:17 <dvhart> something still isn't right
May 20 16:31:56 <dvhart> sgw, what do you have for HEAD?
May 20 16:32:28 <sgw> dvhart: that's what I said above b29fbb347698286935bfc401c08499a6f63479de
May 20 16:32:42 <sgw> I am doing a local private clone to see that's all there.
May 20 16:32:55 <dvhart> which is what I would expect
May 20 16:33:09 <dvhart> so your build looks right
May 20 16:34:46 <sgw> dvhart: shouldn't be  19b54a701811220221fc4d5089a2bb18892018ca?
May 20 16:35:04 <dvhart> the hash you have is for the tag
May 20 16:35:11 <dvhart> do a git show b29fbb347698286935bfc401c08499a6f63479de
May 20 16:35:15 <dvhart> it's right
May 20 16:35:46 <sgw> Ok, sorry was confused by that at first, you are right
May 20 16:36:08 <sgw> OK, so I will move foward with one more staging test on the ab before pushing to bernard proper.
May 20 16:36:56 <dvhart> sgw, I am so confused!
May 20 16:37:10 <dvhart> my work dir is: u-boot-v2011.03+git1+b29fbb3476...
May 20 16:37:26 <sgw> dvhart: that looks right
May 20 16:37:30 <dvhart> but when I do a git log in the git dir, I see the 8d4addc3c3fe1a9ea160a5a1a20a1f934ff3fe97
May 20 16:37:50 <dvhart> as HEAD
May 20 16:37:55 <sgw> OK so do for that matter
May 20 16:37:56 <dvhart> which is wrong
May 20 16:38:36 <dvhart> does the git fetcher not know how to deal with tags?
May 20 16:38:48 * dvhart changes SRCREV to 19b54a701811220221fc4d5089a2bb18892018ca
May 20 16:41:17 <dvhart> SRCREV didn't help
May 20 17:05:44 <nitink> khem ping
May 20 17:05:52 <khem> nitink: yes
May 20 17:06:09 <nitink> gcc 4.6.0 recipes are not producing the libssp0 patckage for nativesdk
May 20 17:06:21 <khem> hmm
May 20 17:06:29 <khem> check if disable-ssp is being passed
May 20 17:06:40 <nitink> it is in the cross-canadian
May 20 17:07:01 <khem> ok
May 20 17:07:10 <khem> does your host system has ssp
May 20 17:07:14 <khem> installed
May 20 17:07:16 <khem> clear
May 20 17:07:49 <nitink> so does gcc 4.5.1, and gcc 4.5.1 does produce libspp0 for nativesdk
May 20 17:07:54 <nitink> let me check my build system
May 20 17:08:24 <khem> it depends I think if it finds capability in the host
May 20 17:08:37 <nitink> khem: my build system is fedora 14 and it does not have libssp0 installed
May 20 17:08:48 <nitink> khem: but how come it is working for gcc 4.5.1 recipes
May 20 17:09:31 <khem> hmm
May 20 17:09:55 <khem> its gcc-runtime correct
May 20 17:10:00 <nitink> may be packaging differences in 4.5.1 & 4.6.0
May 20 17:10:44 <nitink> gcc-runtime should not affect nativesdk , right ?
May 20 17:12:06 <khem> well somehow its detecting ssp disabled in eglibc-nativesdk i think
May 20 17:12:32 <khem> so check the config.log inside gcc-runtime-nativesdk builddir
May 20 17:12:39 <khem> and look for ssp
May 20 17:12:44 <nitink> I also have updated eglibc
May 20 17:12:51 <nitink> to you 2.13 recipes
May 20 17:12:57 <khem> it should show the test results
May 20 17:13:04 <khem> ok
May 20 17:13:07 <nitink> ok let me check
May 20 17:13:40 <khem> which package should I build to see it
May 20 17:14:48 <nitink> khem try bitbake meta-toolchain
May 20 17:14:56 <khem> i have to leave soon I will check if i see it
May 20 17:15:10 <nitink> Configuring libssp
May 20 17:15:10 <nitink> configure: WARNING: unrecognized options: --disable-silent-rules, --with-libtool-sysroot, --enable-languages, --enable-threads, --enable-c99, --enable-long-long, --enable-libstdcxx-pch, --enable-target-optspace, --enable-lto, --enable-libssp, --disable-bootstrap, --disable-libgomp, --disable-libmudflap, --enable-cheaders, --with-local-prefix, --with-gxx-include-dir, --with-sysroot, --with-build-sysroot, --disable-libunwind-exceptions, --enable-n
May 20 17:15:44 <nitink> that line is from here: tmp/work/x86_64-nativesdk-pokysdk-linux/gcc-runtime-nativesdk-4.6.0-r2/temp/log.do_configure
May 20 17:16:03 <khem> thats not the one
May 20 17:16:18 <khem> you have to check into configure's config.log
May 20 17:16:30 <nitink> I see
May 20 17:16:33 <khem> which will be under build tree
May 20 17:16:42 <khem> along with objects
May 20 17:19:47 <otavio> RP__: you pushed 'maste' instead of master
May 20 17:20:00 <otavio> RP__: oe-core has a mistaken branch pushed
May 20 17:20:25 <nitink> khem: http://pastebin.com/QcRKE6Yv
May 20 17:38:29 <zenlinux_laptop> fray, have some questions for you regarding user/group creation
May 20 18:11:35 <RP__> otavio: I know, I don't have permission to remove it
May 20 18:11:48 <RP__> khem: perhaps you can help as the commit hooks won't let me fix it
May 20 18:12:26 <khem> hmm
May 20 18:12:30 <RP__> dvhart: see the git fetcher bug I filed
May 20 18:12:48 <khem> RP__: ok lemme try
May 20 18:12:50 <RP__> dvhart: the fetcher is providing the correct source but the git tree is in a nasty state
May 20 18:12:55 <khem> if not I will ping cbrake
May 20 18:13:02 <RP__> dvhart: See the output of git status
May 20 18:13:16 <RP__> khem: worse case just ssh in and remove it ;-
May 20 18:13:18 <RP__> ;-)
May 20 18:13:33 <khem> hmm heh
May 20 18:13:44 <khem> RP__: now you are here
May 20 18:13:56 <khem> hardfp do u have any opinion on those patches
May 20 18:14:40 <RP__> khem: I've been meaning to revisit them. I'm not a fan of having so many magic switches :/
May 20 18:14:48 <dvhart> RP__, /me looks
May 20 18:15:11 <khem> RP__: yeah unfortunately ARM is still a maturing arch
May 20 18:15:15 <khem> unlike others
May 20 18:15:29 <khem> they did not have FPU or say standardized FPU
May 20 18:15:43 <RP__> khem: MACHINE_FEATURES might be a better place/way to express something like this?
May 20 18:15:44 <khem> that compilers could use until vfp came out
May 20 18:15:54 <khem> RP__: yeah
May 20 18:16:05 <khem> probably
May 20 18:16:10 <khem> that could be better
May 20 18:16:21 <RP__> khem: It just doesn't scale if we add a new variable every time we hit something like this
May 20 18:16:23 <sgw> RP__: fetch question when you are done with khem_
May 20 18:16:28 <dvhart> RP__, thanks
May 20 18:16:32 <RP__> sgw: just go for it
May 20 18:16:34 <khem> hmm but we still want folks to use softfp even when hardfp is possible
May 20 18:17:01 <khem> gitorious.org is PITA with our fetchers
May 20 18:17:04 <khem> it just times out
May 20 18:17:11 <khem> I have had same issue with Classic oe
May 20 18:17:15 <khem> and in oe-core
May 20 18:17:16 <sgw> RP__: so why is the git fetch using read-tree and checkout-index instead of checking out a specific ref or tag?
May 20 18:17:35 <RP__> sgw: read-tree takes a specific ref ;-)
May 20 18:17:37 <sgw> RP__:  this caused all sorts of confusion for dvhart_ and myself this morning.
May 20 18:17:50 <RP__> sgw: The fetcher resolves things to a specific ref and then sets the tree up in that state
May 20 18:17:59 <sgw> RP__: right, but it leaves the log state at HEAD
May 20 18:18:33 <RP__> sgw: hence the bug I filed
May 20 18:18:38 <sgw> RP__:  so a git log showed the future or the past, not the ref we really expected.
May 20 18:18:43 <sgw> which bug?
May 20 18:18:49 <dvhart> 1089
May 20 18:18:55 <RP__> sgw: The one you processed the other day ;-)
May 20 18:19:07 <sgw> I must have not seen this converstaion here.
May 20 18:19:41 <sgw> RP__: too much stuff going on, did not equate the two issues.
May 20 18:19:58 <sgw> RP__ and only scanned the description.
May 20 18:20:10 <RP__> Its spelt out in that bug and its the same problem, it confuses people
May 20 18:20:26 <RP__> On the plus side, the fetcher is at least correct in providing the right source which is something
May 20 18:21:09 <sgw> RP__: at this point yes, it does.
May 20 18:21:27 <RP__> sgw: there is some point where it doesn;t?
May 20 18:22:04 <sgw> RP__: How about this to fix for the non-gplv3 issue:
May 20 18:22:04 <sgw> -MACHINE_ESSENTIAL_EXTRA_RDEPENDS = "qemu-config"
May 20 18:22:04 <sgw> +MACHINE_ESSENTIAL_EXTRA_RDEPENDS = ${@base_contains("INCOMPATIBLE_LICENSE", "GPLv3", "", "qemu-config",d)}
May 20 18:23:26 <sgw> RP__: re: fetcher, other than my .gitconfig headaches, which I need to file a bug on also, I don't think so, but clearly I have a broken usage model ;-)
May 20 18:24:34 <RP__> sgw: The .gitconfig thing is a different problem and I'm not claiming your usage model is wrong. I do believe the fetcher is always providing the source requested though and I will defend that viewpoint ;-)
May 20 18:25:39 <RP__> When you compare the read-tree call forcing to a revision with the complexities in adding the correct branchnames, setting the tree onto the correct branch, and then ensuring that branch matches the requested tag/revision, you can understand why the code does what it does at least
May 20 18:26:02 <RP__> This is just more visible since the fetch2 changes adding .git into the WORKDIR
May 20 18:26:40 <RP__> sgw: That qemu-config change is ugly, the machine shouldn't care about GPLv3
May 20 18:26:56 <RP__> so its an abstraction violation. I'm not sure how to fix it though
May 20 18:32:14 <sgw> it's specific to qemu, and qemu-config, we need to somehow black list qemu-config, possibly in a similar way to what you where suggesting for dvhart_ and u-boot?
May 20 18:32:47 <sgw> RP__: So change the qemu-config to skip itself if GPLv3 is set?
May 20 18:34:54 <dvhart> RP__, I'm clearly missing what the "complexities in adding the correct branchnames..." are
May 20 18:35:17 <RP__> dvhart: clearly you haven't tried writing a git fetcher ;-)
May 20 18:35:23 <dvhart> I would think a bare mirror to create the download tarball followed by a clone and checkout would be adequate
May 20 18:35:28 <dvhart> RP__, clearly
May 20 18:35:56 <RP__> dvhart: Please just send the obviously simple patch to fix it ;-)
May 20 18:37:00 <dvhart> I was simply stating that your statement of comparing it with xyz required more context, at least for me, to understand the point you were making.
May 20 18:37:38 <RP__> dvhart: I am sorry but I really don't have time to have that discussion right now
May 20 18:37:44 <dvhart> that's fine
May 20 18:37:57 <zenlinux_laptop> RP__, I've defined a bash function in my useradd.bbclass I'd like to run before do_install. If I define a do_install_prepend () and then try to invoke my custom bash function, the bitbake parser doesn't like it and thinks its an unknown variable
May 20 18:38:18 <zenlinux_laptop> do I need to do something special to export the custom bash function to use it?
May 20 18:38:23 <RP__> sgw: That won't help :/
May 20 18:38:55 <RP__> zenlinux_laptop: You know about the prefuncs task flag?
May 20 18:39:10 <zenlinux_laptop> RP__, no, but I'll checkout examples of its use
May 20 18:39:17 <RP__> zenlinux_laptop: sstate uses it I think
May 20 18:41:56 <RP__> sgw: I'm trying to think of a better way to handle this but I'm not finding anything
May 20 18:45:26 <sgw> RP__: I thought an anonymous snipet in qemu-config which does the skippackage, but as you say it has similar issues of abstract violations, does not make sense to go in the distrovars either (where the WHITELISTS are).
May 20 18:46:03 <RP__> sgw: you need to kill the dependency, not the recipe itself
May 20 18:46:51 <RP__> sgw: We could have a REMOVED_DEPENDENCY style variable which just eats blacklisted dependencies
May 20 18:47:01 <RP__> There is a hook we could use for it
May 20 18:47:23 <sgw> Ok, there is only one, which is the oprofileui-server
May 20 18:47:24 <RP__> runtime_mapping_rename()
May 20 18:47:31 <sgw> Let me look into that.
May 20 18:48:07 <RP__> better is get_package_mapping()
May 20 18:48:11 <sgw> tomz1: ping
May 20 18:51:41 * RP__ steps afk
May 20 19:52:18 <sgw> nitin ping
May 20 19:52:24 <sgw> nitink: ping
May 20 20:24:05 <sgw> pidge: ping
May 20 20:24:19 <pidge> sgw: pomg
May 20 20:24:23 <pidge> pong even
May 20 20:24:43 <sgw> I return the autobuild to you for m1 setup
May 20 20:24:59 <pidge> weee
May 20 20:25:01 <pidge> ty
May 20 20:26:10 <sgw> dvhart: ping
May 20 20:26:15 <dvhart> pong
May 20 20:26:19 <sgw> U-Boot 2011.03-00038-g8d4addc-dirty
May 20 20:26:21 * pidge wonders if she should hold onto the mystique of autobuilder setup or be honest and admit that she has the switch down to a fairly easy :%s/yocto/poky/g
May 20 20:26:22 <sgw> that look right?
May 20 20:26:58 <sgw> pidge: I am betting it's more that that, what about branches?
May 20 20:27:16 <sgw> dvhart: does that U-Boot string look right to you? (your probably checking).
May 20 20:27:32 <dvhart> where is the 00038 coming from?
May 20 20:27:32 <pidge> oh, for branches, it's like... 5 lines IIRC?
May 20 20:27:45 <dvhart> I don't see that in my binary
May 20 20:27:59 <sgw> dvhart: :-(, what now?
May 20 20:28:21 <dvhart> my string reads as:
May 20 20:28:23 <dvhart> U-Boot 2011.03-dirty
May 20 20:28:37 <dvhart> this is from strings u-boot | grep -i u-boot, right?
May 20 20:28:46 <sgw> yup
May 20 20:29:08 <sgw> do you have a system to test on?
May 20 20:29:13 <dvhart> yes
May 20 20:29:14 <sgw> http://autobuilder.yoctoproject.org/nightly/20110520-1/machines/beagleboard/arm/
May 20 20:29:19 <sgw> that's the url to the files.
May 20 20:29:48 <sgw> dvhart: at least we are both dirty!
May 20 20:29:52 <dvhart> testing
May 20 20:29:55 <dvhart> ;)
May 20 20:31:57 <dvhart> sgw, works fine
May 20 20:32:02 <dvhart> sgw, ship it
May 20 20:32:16 <sgw> Ok
May 20 20:34:10 <otavio> dvhart: Why you depends on .from to be set on sendemail?
May 20 20:34:46 <dvhart> otavio, git send-email will fail without it
May 20 20:34:49 <otavio> dvhart: you ought to depend on name and email
May 20 20:35:07 <otavio> dvhart: it does not; it asks confirmation for it
May 20 20:35:07 <dvhart> otavio, however, I should not depend on smtpserver as that defaults to sendmail (I discovered later)
May 20 20:35:16 <dvhart> otavio, ah....
May 20 20:35:37 <dvhart> otavio, does it do so in a way that makes it clear how to make the question go away?
May 20 20:35:49 <otavio> dvhart: let me check
May 20 20:36:03 <dvhart> if so, feel free to send a patch to the config check
May 20 20:38:20 <otavio> dvhart: the whole check is bogus ... not required
May 20 20:38:37 <otavio> dvhart: from defaults to git user and email
May 20 20:38:53 <otavio> dvhart: and smtpserver defaults to sendmail as you noticed
May 20 20:38:53 <dvhart> otavio, write it up and send it along, I'll ack it
May 20 20:39:03 <otavio> Ok
May 20 20:42:49 <nitink> sgw: pong
May 20 20:43:18 <otavio> dvhart: did it locally; will do the request when I have something else to the pull
May 20 20:43:27 <dvhart> otavio, sure thing - thanks!
May 20 20:44:08 <otavio> dvhart: https://github.com/OSSystems/oe-core/commit/a181e53a15a9dc2648c5447a8152ee7fbb2038c8 <= in case you want to look at
May 20 20:44:58 <dvhart> otavio, you can add my Acked-by if you like, looks good
May 20 20:45:10 <sgw> nitink: I know you are working on a couple different issues any update on the eglibc issue?
May 20 20:45:29 <otavio> dvhart: which info I add? I mean email
May 20 20:45:45 <dvhart> Acked-by: Darren Hart <dvhart@linux.intel.com>
May 20 20:46:01 <nitink> sgw: you mean libssp0 issue ?
May 20 20:46:01 <sgw> nitink: are we ready to switch to the newer version or hold?
May 20 20:46:20 <nitink> sgw: not yet
May 20 20:46:28 <nitink> need to solve the libssp0 issue
May 20 20:46:29 <sgw> not sure, I am reverting to the stack_chk_guard issue
May 20 20:47:05 <sgw> sorry s/reverting/refering/
May 20 20:48:04 <nitink> sgw: I think it is related to the libssp too
May 20 20:49:02 <otavio> dvhart: done and thx
May 20 20:49:43 <sgw> nitink: OK any eta on a fix?
May 20 20:49:48 <nitink> sgw: I am seeing this issue : http://bugzilla.pokylinux.org/show_bug.cgi?id=1076
May 20 20:50:08 <nitink> sgw: working with khem on fixing it
May 20 20:50:22 <nitink> I find that libssp0 package is missing for 4.6.0
May 20 20:50:28 <sgw> So the fix is to move to 2.13, how much testing have you got?
May 20 20:50:45 <nitink> need more investigation, will try to fix it today if not then early next week
May 20 20:51:10 <sgw> Ok I will leave you to it then, adding a third set of hand may not be helpful, but let me know OK
May 20 20:51:18 <nitink> sgw: couldn't finish testing because of the libssp0 issue
May 20 20:51:35 <nitink> meta-toolchain can not be built for all architectures yet
May 20 20:52:07 <nitink> sgw: if needed I will request help earlier next week
May 20 20:52:27 <sgw> OK
May 20 20:53:13 <nitink> sgw: do you have a bug open for eglibc issue
May 20 20:53:27 <nitink> if not can you open it please, it will help me track it
May 20 20:54:01 <nitink> my laptop crashed over night, and I lost the link of pastebin from you
May 20 20:54:21 <sgw> OK will do so now
May 20 21:01:07 <nitink> thanks sgw
May 20 21:01:09 <nitink> khem ping
May 20 21:01:25 <otavio> RP__: any objection to have mdev enabled by default on busybox?
May 20 21:02:24 <sgw> otavio: can you set up the mdev recipe so that it's an alternative to busybox?
May 20 21:04:10 <otavio> sgw: another recipe?
May 20 21:04:29 <otavio> sgw: IMO this is no sense since it would bring 2 or 4 bytes more
May 20 21:05:45 <otavio> sgw: I can amend the recipe in my layer but seems not worth it
May 20 21:05:50 <otavio> sgw: but will do it for now.
May 20 21:05:58 <sgw> otavio: sorry, I am confused, let's try this again
May 20 21:06:23 <sgw> otavio: I thought there was an external recipe already, hard to keep track of them all
May 20 21:06:23 <otavio> sgw: I added support to split the config and like into another package, if  enabled
May 20 21:06:44 <otavio> sgw: busybox has it enableable ...
May 20 21:06:52 <sgw> Yes, I recall the patch
May 20 21:07:01 <otavio> sgw: and since core is like a base it seems logical to have it enabled
May 20 21:08:18 <ReaperOfSouls>  Would it make sense to support config fragments like the kernel since the internal mechanism for busybox config is the same? Just a thought.
May 20 21:08:32 <sgw> It's been talked about
May 20 21:08:58 <otavio> ReaperOfSouls: for now, I think it is too much complexity
May 20 21:10:51 <sgw> otavio: what will happen if udev is also installed with mdev?
May 20 21:11:09 <otavio> sgw: nothing
May 20 21:11:20 <otavio> sgw: since busybox-mdev won't be installed
May 20 21:22:09 <sgw> otavio: I understand now, I had to re-load my cache with the details.  I think this makes sense, RP might overrule.
May 20 21:22:10 <sgw> Since the comment mentions busybox-mdev for IMAGE_DEV_MANAGER, and if it's not there then someone will have a failure.
May 20 21:25:21 <otavio> sgw: will handle it then
May 20 21:26:54 <sgw> otavio: thanks
May 20 21:32:14 <khem> mdev is sort of DISTRO/IMAGE feature
May 20 21:33:02 <khem> I think it would make more sense to have it selected via IMAGE_FEAUTES or some such
May 20 21:39:57 <sgw> khem: if it could be trigged by IMAGE_DEV_MANAGER containing it would make sense
May 20 22:03:37 <zenlinux> can I use bash in a package preinst script or do I have to assume it could be dash?
May 20 22:04:42 <sgw> zenlinux: can your write so it does not care (I can't remember if one can do that really).
May 20 22:05:19 <zenlinux> sgw, I'd rather not, but am looking into my options
May 20 22:05:57 <zenlinux> Is $IFS a bash-only thing?
May 20 22:09:25 <sgw> zenlinux: I was tring to find the FM to RTFM, but it's hidden!
May 20 22:09:57 <zenlinux> sgw, looks like it's okay to use IFS with dash, except in an edge case where you're trying to use non-printing characters with IFS
May 20 22:10:12 <sgw> verified found dash.1 in the git tree!
May 20 22:10:24 <sgw> IFS is usable
May 20 22:10:49 <zenlinux> Looks like the problem is with my redirection into a while loop. http://pastebin.com/3Kc8mdMN
May 20 22:22:24 * dvhart disagrees - it is never OK to use dash
May 20 22:22:32 <dvhart> ;-)
May 20 22:22:50 <khem> dash is faster than bash
May 20 22:23:05 <dvhart> khem, if you want it to be fast - don't write it in shell
May 20 22:23:24 <khem> when you have two then you can compare
May 20 22:23:36 <khem> its not comparing means to get it fast or slow
May 20 22:24:13 <dvhart> zenlinux, I'd say the bigger concern would be the busybox shell
May 20 22:24:23 * dvhart wonders what that is
May 20 22:24:38 <khem> heh its called ash
May 20 22:24:39 <khem> :)
May 20 22:24:44 <dvhart> right
May 20 22:24:55 <khem> very limited in functionality
May 20 22:25:04 <khem> but i guess something for little systems
May 20 22:25:08 <dvhart> right, so that would be the one to worry about for preinst scripts
May 20 22:25:20 <khem> correct
May 20 22:25:48 <zenlinux> figures
May 20 22:25:54 <dvhart> zenlinux, ?
May 20 22:25:55 <zenlinux> I guess I shouldn't try to do anything clever with shell
May 20 22:26:05 <dvhart> zenlinux, typically not, no
May 20 22:26:14 <dvhart> not if you want it to be at all portable
May 20 22:26:17 <zenlinux> just trying to split up a string separated by semicolons into an array
May 20 22:26:26 <zenlinux> there are plenty of ways to do it
May 20 22:27:06 <Jay7> cut :)
May 20 22:27:29 <dvhart> IFS is not bash only
May 20 22:28:01 <dvhart> IFS should allow you to split params on ; just fine
May 20 22:28:08 <dvhart> that's not overly hinky
May 20 22:28:28 <Jay7> ah, yes.. IFS=';' for field in $string; do something; done :)
May 20 22:28:36 <zenlinux> well I found dash didn't know about using <<< to redirect input from a variable name (as opposed to a file)
May 20 22:28:47 <zenlinux> and apparently it's read function doesn't handle the -a option
May 20 22:29:06 <dvhart> nor does ash
May 20 22:29:15 <dvhart> (re -a)
May 20 22:29:34 <khem> zenlinux: what are you trying
May 20 22:30:53 <zenlinux> one sec
May 20 22:31:37 <zenlinux> khem, this is the big picture: http://pastebin.com/jkbyeKRp
May 20 22:32:31 <zenlinux> GROUPADD_PARAM is just a semicolon-separate listed of command line options to the groupadd command, and I want to support an arbitrary number of groups to add
May 20 22:33:28 <zenlinux> so my thought was just to break it up into an array using IFS and process the array
May 20 22:33:54 <nitink> khem: I find that gcc-runtime-nativesdk
May 20 22:33:54 <nitink>  failing to build
May 20 22:34:20 <nitink> khem: http://pastebin.com/EVRPdnuQ
May 20 22:35:20 <khem> zenlinux: use pipes
May 20 22:35:35 <dvhart> that was my thinking as well
May 20 22:36:13 <zenlinux> khem, dvhart: yep
May 20 22:36:47 <khem> nitink: unrecognized option '-nostdlib++' thats strange
May 20 22:36:49 <khem> hmm
May 20 22:36:53 <khem> I think I added that
May 20 22:37:15 <nitink> khem: yes that patch is different for 4.6.0 than 4.5.1
May 20 22:37:22 <khem> yes I know
May 20 22:37:35 <khem> this is g++ hmm ok
May 20 22:39:43 <nitink> khem: I see RP's name on the optional_libstdc.patch
May 20 22:39:44 <RP__> fwiw dash is more limited than dash in general
May 20 22:40:09 <dvhart> RP__, ?
May 20 22:40:09 <RP__> nitink: yes, our standalone runtime libs won't work without that
May 20 22:40:19 <RP__> dash is more limited than ash
May 20 22:40:23 <dvhart> ah
May 20 22:40:29 * RP__ is typing in the dark
May 20 22:40:44 <dvhart> Fn-PgUp
May 20 22:40:46 <dvhart> ;)
May 20 22:40:48 <sgw> RP should be asleep!
May 20 22:40:56 * dvhart nods
May 20 22:41:41 <Jay7> dvhart have thinkpad
May 20 22:41:44 <Jay7> I suspect :)
May 20 22:42:00 <dvhart> Jay7, of course - but so does RP, more importantly ;)
May 20 22:42:30 <Jay7> my x61t model have no light :(
May 20 22:43:17 <nitink> khem, RP__: the use of OPT_nostdlib__ does not look right/complete in the patch
May 20 22:44:34 <khem> nitink: can you see if gcc accepts this option
May 20 22:44:55 <nitink> khem let me try
May 20 22:45:02 <khem> nitink: in what sense ?
May 20 22:45:52 <nitink> khem: it is used in the case statement, but seems like not defined anywhere
May 20 22:47:06 <khem> gcc/c-family/c.opt
May 20 22:47:08 <khem> defines it
May 20 22:47:19 <khem> there is option munging machinery in gcc
May 20 22:47:46 <khem> but since I added it to gcc/cp/g++spec.c
May 20 22:47:52 <khem> I thought g++ is good
May 20 22:47:56 <khem> but may not be the case
May 20 22:48:11 <nitink> khem: if ++ is getting converted to __ somehow then it makes sense
May 20 22:49:13 <khem> yes it gets converted
May 20 22:53:17 <nitink> khem: strange, in a devshell both gcc & g++ are happy about nostdlib++ option
May 20 22:54:19 <khem> hmm
May 20 22:54:31 <khem> x86_64-pokysdk-linux-g++ is 4.6 build for host machine right
May 20 22:55:53 <RP__> dvhart: If this was the thinkpad keyboard...
May 20 22:56:06 <khem> nitink: can you try with option -x c++-header
May 20 22:56:08 <dvhart> RP__, *gasp*
May 20 22:56:24 <RP__> dvhart: Its on the docking station ;-)
May 20 22:57:03 <RP__> Much as I love it, the 24" monitor is easier for day to day work
May 20 22:57:36 <nitink> khem: I was running in the devshell of bash (bitbake bash -c devshell) somehow the devshell for gcc-runtime-nativesdk failed to open
May 20 22:57:43 <dvhart> I'm in the same boat, I just noticed my USB ThinkPad keyboard (with nub, Fn keys, ThikVantage key, etc) does not have the ThinkLight on PgUp
May 20 22:58:08 <nitink> I used  i586-poky-linux-g++  -nostdlib++ /tmp/t.c
May 20 23:00:07 <khem> nitink: try i586-poky-linux-g++ -x c++-header -c /dev/null
May 20 23:00:48 <nitink> khem: btw in the bash's devshell I did not find the x86_64-pokysdk-linux-g++ in the path
May 20 23:01:04 <nitink> possibly it is only in in path for nativesdk recipes
May 20 23:02:28 <khem> nitink: the error you posted is from x86_64-pokysdk-linux-g++
May 20 23:02:50 <nitink> khem: right
May 20 23:03:01 <khem> is i586-poky-linux-g++ also 4.6
May 20 23:03:36 <nitink> khem: ]$ x86_64-pokysdk-linux-g++ -x c++-header -c /dev/null
May 20 23:03:36 <nitink> /dev/null:1:0: fatal error: can't create precompiled header /dev/null.gch: Permission denied
May 20 23:03:36 <nitink> compilation terminated.
May 20 23:05:06 <nitink> khem: this failed similarl to the pastebin error: ]$ x86_64-pokysdk-linux-g++ -nostdlib++ -c /tmp/t.c
May 20 23:05:18 <nitink> so sdk g++ has the issue
May 20 23:06:26 <khem> nitink: ok
May 20 23:06:39 <khem> nitink: is x86_64-pokysdk-linux-g++ and i586-poky-linux-g++ both gcc-4.6 ?
May 20 23:06:49 <nitink> khem: right
May 20 23:07:00 <nitink> both 4.6
May 20 23:08:29 <khem> works in one case
May 20 23:08:37 <khem> and does not work in another
May 20 23:09:26 <nitink> khem: I take it back
May 20 23:09:39 <nitink> x86_64 is not 4.6.0 it is 4.5.1
May 20 23:09:56 <khem> so 4.6.0 works but 4.5.1 does not ?
May 20 23:10:19 * khem is getting (confused ^ 2)
May 20 23:10:25 <khem> less sleep is not good
May 20 23:12:11 <nitink> khem: I am wondering why x86_64 gcc is not 4.6.0
May 20 23:12:35 <khem> might have missed some PREFERRED_VERSION setting
May 20 23:12:51 <nitink> should not be
May 20 23:12:54 <khem> paste bitbake -g <target> output somewhere
May 20 23:13:04 <nitink> there is same setting for x86 & x86-64
May 20 23:16:07 <nitink> khem: this did not give any matches: grep gcc pn-depends.dot  package-depends.dot  task-depends.dot  | grep 4.5.1
May 20 23:17:33 <nitink> khem: do you still want to see the output of bitbake -g gcc-runtime-nativesdk
May 20 23:19:32 <nitink> khem: btw ]$ x86_64-poky-linux-g++ --version is 4.6.0
May 20 23:19:52 <nitink> adding more confusion :)
May 20 23:21:45 <nitink> looks like sdk specific issue
May 20 23:24:05 <khem> ok if 4.5.1 is not being picked up then why is it in path
May 20 23:24:25 <nitink> I also find that x86_64-pokysdk-linux-gcc-4.5.1 & x86_64-pokysdk-linux-gcc-4.6.0 are also in the path
May 20 23:25:26 <khem> hmm
May 20 23:25:49 <khem> that machine is gccfied
May 20 23:25:57 <nitink> :)
May 20 23:26:13 <nitink> let me do a cleanall on gcc-runtime-nativesdk-4.5.1, and see if that helps
May 20 23:30:28 <nitink> khem: I think I understand why the problem is coming up like this
May 20 23:32:15 <nitink> we have configured gcc 4.6.0 for x86, x86-64 & arm, and 4.5.1 for mips & ppc, so when nativesdk is built for x86 machine, then 4.6.0 sdk toolchain is built, and when meta-toolchain is built for ppc machine then 4.5.1 sdk toolchain is built
May 20 23:32:43 <khem> ah
May 20 23:33:07 <khem> I would say for nativesdk choose 4.6 for all arches
May 20 23:33:37 <khem> after all PREFERRED_VERSIONS :)
May 20 23:34:01 <nitink> khem, good point
May 20 23:34:26 <khem> just differentiate the cross recipes
May 20 23:34:33 <nitink> we still have kernel compilation issues with gcc 4.6.0 on mips & ppc
May 20 23:34:34 <khem> and may be target one too
May 20 23:34:47 <khem> are they fixed or need attention
May 20 23:35:37 <nitink> bruce is working on it, dvhart do you know the kernel issue for mips & ppc fixed for gcc 4.6.0 ?
May 20 23:35:59 <dvhart> I believe 1035 and 1036 were just closed by sgw
May 20 23:36:34 <nitink> dvhart: great, I will check the commit log and switch to 4.6.0 for all
May 20 23:36:45 * dvhart shakes in his boots
May 20 23:36:49 <dvhart> ... well, socks anyway
May 20 23:38:20 <sgw_away> nitink: do we have the toolchain issues resolved now?
May 20 23:38:56 <nitink> sgw_Away: if kernel issues are fixed then we can switch to 4.6.0 for all arches, then it should get rid of the toolchain issue, but need to verify
May 20 23:39:38 <sgw> I can fire up a build here, any other changes then PREFERRED_VERSIONS?
May 20 23:40:40 <nitink> sgw: nope
May 20 23:42:35 <sgw> nitink: what about eglibversion bump it also?
May 20 23:43:02 <nitink> sgw: not yet, need verification
May 20 23:43:39 <nitink> if your builds work with the eglibc version bump then go ahead
May 20 23:43:54 <sgw> I will try without first
May 20 23:44:06 <nitink> sgw: I am also verifying it here with eglibc version bump
**** ENDING LOGGING AT Sat May 21 02:59:58 2011

**** BEGIN LOGGING AT Sat May 21 02:59:58 2011
May 21 03:58:33 <pidge|away> 1.1_M1.rc1 is off and running. woot.
May 21 04:07:43 <ka6sox-work> w00t
May 21 16:57:31 <nitink> sgw: meta-toolchain built fine for all arches with upreved gcc & eglibc, now I am building core-image-lsb-sdk images
May 21 17:26:07 <sgw> nitin, built fine, any runtime testing?
May 21 17:26:21 <sgw> nitink: ^^^^
May 21 17:26:49 <nitink> sgw: will test with sdk images
May 21 17:28:46 <sgw> nitink: thanks for checking in.
May 21 17:31:42 <sgw> nitink: can you take a quick look at the Autobuilder beagleboard failure, might be compiler issue
May 21 17:37:38 <sgw> nitink: looks like there is a patch pending: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00381.html
May 21 17:39:44 <sgw> oops better to look at this one: http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01734.html
May 21 18:30:02 <nitink> sgw: will lookinto it
May 22 01:25:49 <zwj> hi, every one
May 22 01:26:31 <zwj> now i enterconunt a problem about gettext
May 22 01:28:30 <zwj> when i cross compile it successfully an install it, it report a error
May 22 01:28:33 <zwj> | /opt/windriver/linux/cgl/devkit/p2020/toolchain/x86-linux2/bin/../lib/gcc/powerpc-wrs-linux-gnu/4.4.1/../../../../powerpc-wrs-linux-gnu/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6
May 22 01:28:33 <zwj> | /opt/windriver/linux/cgl/devkit/p2020/toolchain/x86-linux2/bin/../lib/gcc/powerpc-wrs-linux-gnu/4.4.1/../../../../powerpc-wrs-linux-gnu/bin/ld: cannot find /lib/libc.so.6
May 22 01:28:33 <zwj> | collect2: ld returned 1 exit status
May 22 01:29:15 <zwj> it seems that i find lib path in host, not from sysroot path
**** ENDING LOGGING AT Sun May 22 02:59:58 2011

**** BEGIN LOGGING AT Sun May 22 02:59:58 2011
May 22 03:22:46 <wenjie> anyone can help me?
May 22 03:38:45 <ka6sox-away> 0430 in .eu and anywhere from 20:35-23:35 in the US on a saturday...
May 22 03:38:53 <ka6sox-away> what help do you need wenjie
May 22 03:42:27 <nitink> sgw: the build of lsb-sdk images succeeded for all arches with gcc 4.6.0 & eglibc 2.13
May 22 03:50:42 <sgw> nitink: great
May 22 03:52:57 <otavio> oh man ... it is saturday :-)
May 22 03:53:06 <otavio> and I am not the only one working ... great.
May 22 03:53:07 <otavio> hehehe
May 22 03:53:18 <otavio> or better; now it is sunday .... grr
May 22 03:53:56 <sgw> otavio: yeah, I be working then too, but only for a few hours here and there, mostly in the garden!
May 22 03:54:16 <otavio> sgw: grr ...
May 22 03:55:52 <sgw> otavio: the joys of getting a milestone out the door, now it's off to the movies for the evening.
May 22 03:58:24 <ka6sox-away> I thought I was off...but I got called in :P
May 22 04:00:11 <nitink> I was out in afternoon for daughter's dance competition
May 22 04:00:26 <nitink> the build ran successfully meanwhile :)
May 22 04:06:44 <nitink> sgw: lsb images are working fine, except I do not get X (graphical) stuff
May 22 04:11:50 <otavio> sgw: I am looking at busybox issue ... we have a problem
May 22 04:12:01 <otavio> sgw: busybox can have, or not, a conffile ...
May 22 04:12:22 <otavio> sgw: technically OK for both ways and it is even possible to disable it on def config
May 22 04:13:16 <otavio> sgw: the problem is that we can detect if it was enable on the defconfig but if it is not we'd need to provide an empty file or set CONFFILES depending on it
May 22 14:30:23 <egonzalez_ergio> hi
May 22 14:31:07 <egonzalez_ergio> I'm trying to compile yocto with uclibc but breaks with: "ERROR: Nothing PROVIDES 'glib-2.0-native' "
May 22 14:31:24 <egonzalez_ergio> ant is trus...the glib-2.0-native recipe don't exist
May 22 14:58:50 <egonzalez_ergio> nobody???
May 22 16:05:47 <nitink> egonzalez_ergio, glibc-2.0-native package provider should be uclibc for your case
May 22 16:06:09 <nitink> oops its not glibc, it is glib
May 22 16:06:34 <egonzalez_ergio> uclibc is not working yet in oe-core
May 22 16:06:35 <egonzalez_ergio> :-
May 22 16:06:37 <egonzalez_ergio> :-(
May 22 16:07:32 <nitink> and in yocto I see meta/recipes-core/glib-2.0/glib-2.0_2.28.6.bb present
May 22 16:07:52 <nitink> sgw: eglibc gcc uprevving has worked well so far
May 22 17:16:33 <nitink> sgw: sent pull requests for eglibc & gcc rev bumping
May 22 17:17:19 <nitink> egonzalex_ergio: khem is maintainer for uclibc in oe-core,
May 22 22:11:03 <zenlinux> guess I shouldn't have rebased my branch to master - eglibc failing do_compile? build-i586-poky-linux/elf/ld.so.lds:186: syntax error
May 22 22:13:12 * zenlinux tries cherry-picking form nitink 's misc branch
May 22 22:23:29 <zenlinux> much better, thanks nitink
May 22 22:27:37 <zenlinux> gah, I spoke to soon - eglibc-initial built, but still running into the same error during eglibc's do_compile
May 22 22:31:53 <zenlinux> wierd - it's a syntax error in that file all right, a commented line isn't commented properly
May 22 22:55:30 <egonzalez_ergio> hi
May 22 22:55:38 <egonzalez_ergio> me again! :-)
May 22 22:55:40 <egonzalez_ergio> haha
May 22 22:56:17 <egonzalez_ergio> I triyng to remake a core-image-base after a git pull
May 22 22:56:22 <egonzalez_ergio> and I have an error in cairo
May 22 22:56:42 <egonzalez_ergio> cairo-mutex-impl-private.h:262:3: error: #error "XXX: No mutex implementation found.  Cairo will not work with multiple threads.  Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
May 22 22:56:46 <egonzalez_ergio> and related errors
May 22 22:57:00 <egonzalez_ergio> some idea?
May 22 23:58:24 <egonzalez_ergio> I triyng to remake a core-image-base after a git pull and I have an error in cairo
May 22 23:58:30 <egonzalez_ergio> cairo-mutex-impl-private.h:262:3: error: #error "XXX: No mutex implementation found.  Cairo will not work with multiple threads.  Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
May 22 23:58:34 <egonzalez_ergio> and related errors
May 22 23:58:38 <egonzalez_ergio> some idea?
May 23 02:49:20 <wooster> ERROR: Function 'File: '/home/bobo/src/poky-5.0-build/downloads/distcc-2.18.3.tar.bz2' has md5 checksum 733bde40f259edfb44c84fc4b0163ad0 when 0d6b80a1efc3a3d816c4f4175f63eaa2 was expected (from URL: 'http://distcc.samba.org/ftp/distcc/distcc-2.18.3.tar.bz2')' failed
May 23 02:52:44 <khem> wooster: bitbake -c cleanall distcc;bitbake distcc
May 23 02:56:24 <wooster> k
May 23 02:58:22 <wooster>   table wider than line width
May 23 02:58:22 <wooster>   table wider than line width
May 23 02:58:22 <wooster>   table wider than line width
May 23 02:58:22 <wooster> make[2]: *** [libX11.ps] Error 1
May 23 02:58:22 <wooster> rm libX11.ps
May 23 02:58:22 <wooster> make[2]: Leaving directory `/home/bobo/src/poky-5.0-build/tmp/work/x86_64-linux/libx11-native-1_1.3.4-r0/libX11-1.3.4/specs/libX11'
**** ENDING LOGGING AT Mon May 23 02:59:58 2011

**** BEGIN LOGGING AT Mon May 23 02:59:58 2011
May 23 13:35:01 <otavio> morning
May 23 14:18:51 <otavio> bitbake (on oe-core) is crazy regarding autorev handling
May 23 14:18:56 <otavio> it is really broken
May 23 14:54:47 <pidge_work> sgw: ping
May 23 15:01:25 <RP__> otavio: broken how?
May 23 15:08:31 <dbire1> hello all, how to configure to use the standard poky distro (poky.conf) but telling poky to use TARGET_OS = linux-gnueabi ?
May 23 15:11:17 <sgw> pidge_work: pong
May 23 15:12:52 <pidge_work> sgw: I'm rolling another build off your sgw/stage to see if we have fixes. if so, I'll cherry pick them into 1.1_M1 and roll rc2
May 23 15:13:45 <pidge_work> I'll also have a license.bbclass pull today (crossing fingers)
May 23 15:14:29 <sgw> pidge_work: Please hold for a bit, we can cherry pick the changes into 1.1_M1 from master at this point
May 23 15:15:26 <pidge_work> ah, ok. I'll kill it then
May 23 15:17:04 <otavio> RP__: If I commit something on the repository and ask for build, the package is not update
May 23 15:17:16 <otavio> RP__: if I do clean and a build, it also keeps with same
May 23 15:18:31 <zenlinux> morning all
May 23 15:41:52 <nitink> Good Morning All !
May 23 15:54:16 <sgw> fray ping
May 23 15:54:41 <fray> morning
May 23 15:55:31 <sgw> fray: morning, last we we talked briefly about create repo and update_index_rpm
May 23 15:55:50 <fray> ya, did anything happen there?  or do you need me to help out?
May 23 15:56:58 <sgw> Just want to verify that it's safe to call createrepo all the time on a update_index_rpm, I noted that the createrepo is commented out in rootfs_rpm_do_rootfs() and that's different that update_index_rpm
May 23 15:57:07 <fray> yes it should be
May 23 15:57:21 <fray> it was commented out specifically because (at the time the code was written) I simply didn't know how to do it
May 23 15:58:46 <sgw> Ok, then I will add it directly into the package_update_index_rpm, does that mean that other code in there can be cleaned up?  Or does it serve an additional purpose?
May 23 15:59:02 <fray> which code specifically?  in that function?
May 23 16:00:07 <fray> The package_update_index_rpm isn't actually the createrepo stuff..  it's the code we use to create the install manifesting..
May 23 16:00:30 <sgw> OK, that partly answers the question then
May 23 16:00:54 <fray> it's the stuff that modified the internal dep-resolver for RPM.. this is -only- used on the rootfs creation..
May 23 16:01:02 <fray> I'd very much be for renaming the function if it's confusing
May 23 16:01:16 <sgw> so to continue, should package_update_index_rpm call createrepo so should it be split out in 2 parts?  I ask because for dep and ipkg that's the functionality.
May 23 16:01:29 <fray> (eventually I want the existing code to go away and be replaced by proper sat-solver/zypper resolution)
May 23 16:01:56 <fray> sgw -- it could, but it unlike deb and ipkg, the files would never be used..
May 23 16:02:00 <RP__> It was commented out in rootfs_rpm_do_rootfs as createrepo-native was broken
May 23 16:02:05 <sgw> OK, in the mean time, I guess 2 functions, one for the current code and seperate createrepo() call
May 23 16:02:17 * RP__ did the commenting out, I'd look at the commit log
May 23 16:02:54 <fray> that's what I would suggest
May 23 16:03:43 <sgw> RP__: createrepo seems to be fixed now, we we could uncomment that as well, different location and different meaning.
May 23 17:06:08 * nitink is noticing bitbake is taking long time to start the build now days
May 23 17:06:55 <nitink> me: nothing comes up for long time after "Parsing recipes: 100%" line
May 23 17:07:54 <nitink> RP__: are you aware of it ^^^
May 23 17:08:28 <RP__> nitink: I've heard people mention it, I don't know the cause
May 23 17:09:06 * RP__ suspects a cache getting too large with stale data or something
May 23 17:09:15 <RP__> nitink: Are there any large files in tmp/cache ?
May 23 17:09:26 <nitink> RP__: don't know
May 23 17:09:32 <nitink> I can do du on it
May 23 17:12:05 <nitink> RP__: 8.6G	sstate-cache
May 23 17:12:18 <RP__> nitink: in tmp/cache ?
May 23 17:12:34 <fray> it'd be nice to be able to clean it of stale data.. but defining "stale" data could be interesting
May 23 17:13:22 <nitink> RP__: 35M	tmp/cache/
May 23 17:14:41 <RP__> nitink: How big is tmp/cache/bb_codeparser.dat ?
May 23 17:15:43 <nitink> RP__: 4Mb
May 23 17:15:59 <RP__> nitink: unlikely to be what I was thinking then :/
May 23 17:17:40 <nitink> RP__: i hope it is not my build disk
May 23 17:17:42 <sgw> RP__: I can provide you with a consistent test that shows this slowness on nhm
May 23 17:19:22 <nitink> RP__: I found a bitbake process which was 1 month old, just killed it
May 23 17:23:03 <RP__> sgw: If you send me the details I might try and debug it. I suspect its contention of the cache lockfile though and I'm not sure what we can do about it :/
May 23 17:28:27 <otavio> RP__: I need to leave since I am going to ESC Brazil ...
May 23 17:28:37 <otavio> RP__: but did you see my description of the issue?
May 23 17:32:10 <sgw> RP__: email sent
May 23 17:36:01 <egonzalez_ergio_> hi
May 23 17:36:55 <egonzalez_ergio_> I'm trying to remake core-image-minimal. I have update git and I have an error in cairo:
May 23 17:36:56 <egonzalez_ergio_> cairo-mutex-impl-private.h:262:3: error: #error "XXX: No mutex implementation found.  Cairo will not work with multiple threads.  Define CAIRO_NO_MUTEX to 1 to acknowledge and accept this limitation and compile cairo without thread-safety support."
May 23 17:38:36 <RP__> otavio: I did, it needs looking into...
May 23 17:38:49 <sgw> egonzalez_ergio_: just to confirm, you are getting this error while doing a bitbake core-image-minimal?
May 23 17:38:53 <RP__> otavio: Nothing springs to mind :/
May 23 17:39:03 <RP__> sgw: thanks
May 23 17:39:04 <otavio> RP__: ok; I ought to be able to test a patch if you cook it
May 23 17:39:13 <otavio> RP__: please send it to my mail if need
May 23 17:39:13 <egonzalez_ergio> sgw: yes
May 23 17:40:07 <otavio> RP__: it needs changing the checksum of recipe
May 23 17:40:26 <otavio> RP__: IMO it ought to always fail the checksum of recipe checking in case autorev is used
May 23 17:40:40 <RP__> otavio: Is SRCPV in PV?
May 23 17:40:45 <otavio> RP__: yes
May 23 17:41:00 <RP__> otavio: that should change everything then...
May 23 17:41:09 <egonzalez_ergio> sgw: I only chage DISTRO ?= in local.conf
May 23 17:41:13 <egonzalez_ergio> is relevant?
May 23 17:41:17 <RP__> otavio: You set SRCREV = "${AUTOREV}" ?
May 23 17:41:33 <sgw> egonzalez_ergio: trying to understand how is in the dependency of core-image-minimal, have you made any changes?
May 23 17:41:35 <otavio> RP__: yes
May 23 17:42:07 <sgw> egonzalez_ergio: what's did you set DISTRO to?
May 23 17:43:09 * otavio needs to go
May 23 17:43:12 <egonzalez_ergio> a fantasy name
May 23 17:43:20 <otavio> RP__: mail me if you need something from my side
May 23 17:44:46 <sgw> egonzalez_ergio: do you have a ${DISTRO}.conf that matches your fantasy name?
May 23 17:46:29 <egonzalez_ergio> mmm...nop
May 23 17:46:32 <egonzalez_ergio> :-(
May 23 17:47:28 <sgw> egonzalez_ergio: If that's your only change, can you undo that and try a build, I am still mystified why cairo is getting built for minimal, which should be a non-graphical image
May 23 17:47:42 <egonzalez_ergio> ok
May 23 17:47:53 <egonzalez_ergio> building ...
May 23 18:31:11 <egonzalez_ergio> sgw: another error
May 23 18:31:34 <egonzalez_ergio> in eglibc
May 23 18:31:50 <egonzalez_ergio> /home/opt/Yocto/ErgiOS_embedded/ErgiOS_yocto/build/tmp/sysroots/x86_64-linux/usr/libexec/i586-poky-linux.gcc-cross-intermediate/gcc/i586-poky-linux/4.6.0/ld:/home/opt/Yocto/ErgiOS_embedded/ErgiOS_yocto/build/tmp/work/i586-poky-linux/eglibc-2.12-r13/build-i586-poky-linux/elf/ld.so.lds:186: syntax error
May 23 18:31:51 <egonzalez_ergio> | collect2: ld returned 1 exit status
May 23 18:33:31 <egonzalez_ergio> sgw: http://pastebin.com/089FRhUZ
May 23 18:38:39 <sgw> egonzalez_ergio: looking
May 23 18:39:56 <sgw> egonzalez_ergio: what is your machines Distro and Version?
May 23 18:41:45 <egonzalez_ergio> BB_VERSION        = "1.11.0"
May 23 18:41:46 <egonzalez_ergio> METADATA_BRANCH   = "master"
May 23 18:41:48 <egonzalez_ergio> METADATA_REVISION = "fc55b224caa3eeac4abda099ec9ed505db59fb28"
May 23 18:41:49 <egonzalez_ergio> TARGET_ARCH       = "i586"
May 23 18:41:51 <egonzalez_ergio> TARGET_OS         = "linux"
May 23 18:41:52 <egonzalez_ergio> MACHINE           = "qemux86"
May 23 18:41:54 <egonzalez_ergio> DISTRO            = "poky"
May 23 18:41:55 <egonzalez_ergio> DISTRO_VERSION    = "1.0+snapshot-20110523"
May 23 18:41:57 <egonzalez_ergio> TARGET_FPU        = ""
May 23 19:32:17 <zenlinux_laptop> sgw, I ran into that same eglibc error over the weekend when I tried to build the latest master. I gave up on it and reverted back to my older tree
May 23 19:32:43 <zenlinux_laptop> I can kick off a build of master on my Fedora 14 system to see if it's likely to be Ubuntu-specific
May 23 19:40:17 <sgw> zenlinux_laptop: same issue as egonzalez?
May 23 19:40:39 <zenlinux_laptop> sgw, yep, the syntax error in build-i586-poky-linux/elf/ld.so.lds
May 23 19:41:01 <zenlinux_laptop> The error is at the line that starts with /DISCARD/, which at first I thought was supposed to be a comment (which would be the wrong syntax)
May 23 19:41:19 <zenlinux_laptop> but after doing some research it looked like that's actually a meaningful directive
May 23 19:41:19 <sgw> hmm, maybe an F14 issue, nitin updated eglibc to 2.13, wonder if that will fix it.
May 23 19:41:50 <zenlinux_laptop> sgw, the build failed on my Ubuntu 10.10 system, I'm building now on Fedora 14 to see if it's distro-specific
May 23 19:42:07 <zenlinux_laptop> also, over the weekend I tried cherry-picking from nitin's misc branch to upgrade eglibc and that didn't help
May 23 19:42:18 <sgw> I just did a build on F13 and U11.04 with no issues.
May 23 19:42:19 <nitink> sgw: xenlinux_laptop: I have been testing on fedora 14
May 23 19:42:49 <zenlinux_laptop> ok, well I have a build running in the background on my F14 system now so it may end up being a useful data point - or maybe not
May 23 19:42:50 <nitink> I would suggest build from scratch
May 23 19:43:04 <zenlinux_laptop> yes, it happened when building from scratch
May 23 19:43:37 <nitink> I didn't get hit by that issue while running scratch build of master on fedora14
May 23 19:43:53 <zenlinux_laptop> In other news, I managed to copy the sstate-cache directory from my desktop to laptop this morning and did a build, and it actually worked as I expected it to :)
May 23 19:44:03 <zenlinux_laptop> built entirely from sstate-cache
May 23 19:44:35 <nitink> zenlinux_laptop: what failed ?
May 23 19:45:25 <zenlinux_laptop> nitink, same error egonzalez_ergio reported: "/build-i586-poky-linux/elf/ld.so.lds:186: syntax error"
May 23 19:46:22 <nitink> the pastebin link above is showing eglibc 2.12
May 23 19:46:28 <nitink> that latest eglibc is 2.13
May 23 19:46:47 <nitink> or the master is configured for eglibc 2.13 now
May 23 19:48:12 <zenlinux_laptop> nitink, I saw the error on my home system (Ubuntu 10.10) over the weekend using eglibc 2.12 and also 2.13 - I cherry-picked from your misc branch hoping it would fix it, and did a rebuild from scratch. I still got the error.
May 23 19:48:31 <zenlinux_laptop> ok, going to kick off a master build on my home system too
May 23 19:49:08 <nitink> zenlinux_laptop: and your build host was fedora14?
May 23 19:49:28 <zenlinux_laptop> nitink, no - I've only seen the error on my Ubuntu 10.10 system at home
May 23 19:50:20 <nitink> I see
May 23 19:56:29 <zenlinux_laptop> well, apparently I can't ssh home anymore - my IP must have changed
May 23 19:59:28 <nitink> zenlinux: you can use dyndns kind of free service to get over changing ips
May 23 21:54:25 <zenlinux_laptop> nitink, FYI eglibc built fine on my F14 system
May 23 22:09:00 <RP__> Hmm, those errors sound linker specific
May 23 22:09:33 <RP__> I wonder if moving to gcc 4.6 has somehow triggered some linker syntax older linkers in ubuntu 10.10 etc. don't have?
May 23 22:10:17 <RP__> zenlinux_laptop: Is there a bug open on this and if so can you record your host binutils versions that worked and didn't work please?
May 23 22:18:03 <nitink> RP__: thanks for looking into it, I don't have a ubuntu system to test
May 23 22:42:14 <zenlinux_laptop> RP__, I will verify when I have access to the system that triggered it again, and if verified, I will file a bug
**** ENDING LOGGING AT Tue May 24 01:08:22 2011

**** BEGIN LOGGING AT Tue May 24 05:32:15 2011
May 24 07:14:15 <RP__> morning all
May 24 15:31:46 <nitink> morning RP__
May 24 15:31:53 <nitink> Good Morning All !
May 24 16:05:12 * RP__ notes his toolchain breaking cairo :/
May 24 16:05:41 <fray> won't the Egyptians be upset?  ;)
May 24 16:06:08 <RP__> fray: quite likely :)
May 24 16:09:50 <RP__> summary, need a zlib-native dependency on binutils-cross
May 24 16:12:40 <_elias_> Hi folks, anybody know something about yocto janitors?
May 24 16:13:50 <dvhart> _elias_, hey _elias_ , I wrote up the initial wiki page
May 24 16:13:56 <dvhart> so I'm probably as good as anyone ;-)
May 24 16:13:58 <dvhart> what's up?
May 24 16:15:32 <_elias_> Hi dvhart, yes, I was reading initial wiki page.
May 24 16:15:40 * sgw biab
May 24 16:17:14 <dvhart> _elias_, did you have a question about it?
May 24 16:18:18 <_elias_> I'm sorry, I'm a little bit busy.
May 24 16:18:30 <_elias_> yes, about kernel.
May 24 16:19:11 <_elias_> what kernel modules?
May 24 16:19:47 <dvhart> The task is about general infrastructure to enable building any out-of-tree module on the target device.
May 24 16:20:06 <dvhart> This requires installing the sysroots/kernel tree on the target
May 24 16:20:32 <dvhart> with some cleanup around the host-specific files, like the compiled binaries in scripts for example
May 24 16:25:06 <_elias_> uhm...ok, I'll read about this.
May 24 16:28:29 <dvhart> _elias_, feel free to send mail to the list if you have questions on how to get started and can't muster up help in here.
May 24 16:29:34 <_elias_> ok, thanks a lot.
May 24 16:36:26 * sgw back
May 24 16:45:05 * nitink is being brave, upgrading autoconf
May 24 16:54:42 <sgw> nitink: could you look at the autobuild beagleboard failure, may be a compiler issue
May 24 16:55:40 <nitink> sgw: can you send me link again? or a bugid
May 24 16:59:53 <sgw> nitink: http://autobuilder.pokylinux.org:8010/builders/nightly-external/builds/132/steps/shell_21/logs/stdio
May 24 17:00:03 <sgw> nitink: I will file a bug also
May 24 17:00:11 <zenlinux> nitink, RP__: good news - eglibc built using today's master on my ubuntu 10.10 system. So the issue reported yesterday may be resolved
May 24 17:00:31 <nitink> sgw: thank you :)
May 24 17:00:37 <nitink> zenlinux: good to know :)
May 24 17:10:12 <sgw> Nitin, sent you the wrong link, there are 2 issues that one and this is the compiler issue, which I will file a bug on also:
May 24 17:10:12 <sgw> http://autobuilder.pokylinux.org:8010/builders/nightly-external/builds/132/steps/shell_19/logs/stdio
May 24 17:10:41 <nitink> sgw: ok
May 24 17:12:44 <nitink> sgw: are these arch dependent bugs ?
May 24 17:21:00 <nitink> khem: ping
May 24 17:25:19 <khem> nitink: yes
May 24 17:25:41 <nitink> gcc 4.6.0 is meeting internal compiler error for arm
May 24 17:26:00 <nitink> khem: http://autobuilder.pokylinux.org:8010/builders/nightly-external/builds/132/steps/shell_19/logs/stdio
May 24 17:26:56 <nitink> khem: checking if you know it already, or have a fix
May 24 17:28:46 <khem> nitink: the error message is common one
May 24 17:28:55 <khem> nitink: if you can preprocess svga_tgsi_insn.c
May 24 17:29:02 <khem> and send my way I can have a look
May 24 17:29:13 <nitink> khem: what do you mean by preprocess ?
May 24 17:29:30 <khem> this has been fixed in linaro IIRC
May 24 17:29:39 <khem> but I am not sure
May 24 17:29:55 <khem> so it might work with gcc 4.6 from meta-oe
May 24 17:30:01 <khem> yes preprocess
May 24 17:30:46 <khem> nitink: try this patch here http://gcc.gnu.org/ml/gcc-cvs/2011-03/msg00119.html
May 24 17:33:09 <nitink> khem: thanks, I will give it a try, and I do not understand what do you mean by preprocess, but we can get to it later
May 24 17:34:03 <khem> preprocess means take the commandline for that given C file and add -E option to it and remove -c from it save the resulting file and send that over
May 24 17:36:18 <nitink> I see so that you don't have to deal with include files
May 24 17:53:49 <nitink> khem: i guess it right, but just wanted to make sure, I will send you preprocessed file in case the patch does not help.
May 24 20:17:33 <nitink> khem: that patch is already in the gcc-4.6.0 recipe
May 24 20:18:21 <khem> hmm
May 24 20:18:23 <khem> ok
May 24 20:18:32 <khem> nitink: send me the preprocessed file
May 24 20:18:39 <nitink> khem: ok
May 24 21:49:47 <zenlinux> fray: have a short question for you if you're around
May 24 22:37:33 <dvhart> where did the ${POKYBASE}/LICENSE move to?
May 24 22:38:29 <dvhart> COREBASE perhaps...
May 24 22:41:22 <RP__> dvhart: POKYBASE became COREBASE. yes
May 24 22:41:27 <dvhart> thanks
May 24 22:42:05 <RP__> making the codeparser cache scale over 40 cores isn't easy :/
May 24 22:42:20 <dvhart> :-)
May 24 22:42:24 <dvhart> what are you running into?
May 24 22:42:39 <dvhart> tomz3, ping
May 24 22:42:58 <dvhart> tomz3, did I send you the FILESEXTRAPATHS change for meta-intel for review? I thought I had, but I'm not seeing it on the list
May 24 22:43:19 <RP__> dvhart: python's threading implementation and trying to write to a single pickled object
May 24 22:43:32 <RP__> dvhart: I think I have an approach that will scale though
May 24 22:43:56 <dvhart> RP__, yeah, that isn't surprising. I think you're really pushing pythons limits there.
May 24 22:44:45 <RP__> dvhart: Basically I have each thread writing out the differences, then back in a single thread, collecting them up and saving the new file
May 24 22:45:02 <RP__> A ton of code complexity but fast
May 24 22:45:26 <RP__> complexity being 100 lines so its relative
May 24 22:45:32 <dvhart> RP__, is the global interpreter lock still a problem though?
May 24 22:46:40 <RP__> dvhart: not with the way multiprocessing is used here afaik
May 24 22:47:09 <RP__> We're using the multiprocessing module, not threading
May 24 22:47:11 <dvhart> I wonder if it is causing some of our other scaling issues though
May 24 22:47:16 <dvhart> oh
May 24 22:47:25 <dvhart> I shall have to look into how that's different
May 24 22:47:37 <RP__> and for forked off tasks we really do fork them
May 24 22:47:54 <RP__> I'm dealing with a parsing problem with the caches
May 24 22:47:59 <dvhart> ack
May 24 22:49:22 * RP__ needs to clear out the wip patches I have :/
May 24 22:49:49 * dvhart is doing the same
May 24 22:50:12 <dvhart> tomz3, just cc'd you on the FILESEXTRAPATHS patch, could you... oh... it's 7pm
May 24 22:50:15 <dvhart> hrm
May 24 23:05:38 <nitink> khem: I think this is the right patch for the arm issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43137
May 24 23:24:21 <nitink> khem: never mind, that patch is already in
May 25 00:24:35 <sgw> nitink: ping
May 25 00:24:54 <nitink> sgw: pong
May 25 00:25:13 <sgw> nitink: I know you have been working away on the compiler issues today, any progress?
May 25 00:26:55 <nitink> sgw: not much, the arm issue is still worked on, and the ppc issue I could not reproduce it with qemuppc
May 25 00:28:01 <sgw> Ok, thanks, the ppc one I believe is related to not the mklibs work, but the other work you did with dynamic library stuff, forgot the term right now.
May 25 00:28:44 <nitink> I understand, the not automatic linking
May 25 00:28:52 <sgw> right
May 25 00:29:47 <nitink> and I am also testing the autoconf upgrade on the side
May 25 00:29:55 <sgw> Ok great
May 25 02:20:02 <nitink> sgw: I tried this: MACHINE=mpc8315e-rdb bitbake xserver-xf86-lite
May 25 02:20:02 <nitink>  and did not get the error what you saw on autobuilder
May 25 02:32:37 <nitink> maybe autoconf upgrade fixed it ?
**** ENDING LOGGING AT Wed May 25 02:59:57 2011

**** BEGIN LOGGING AT Wed May 25 02:59:57 2011
May 25 08:03:47 <lipingke> hi, RP, one thing about where to put HobRecipeInfo. You said put it under hob.py? My concern is that HobRecipeInfo actually has nothing to do with hob, it's named because it's introduced by hob, so we saved it into bb_extrache_hobxxx.dat. In the future, maybe XXXservice also needs this three extra field. it can use this too without redefinition. We don't need to save the three same extra fields into different cache file and reparse again. Is it?  I have made a
May 25 08:03:53 <lipingke> I paste current implementation http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=lke/cache_latest
May 25 09:12:10 <bluelightning> morning all
May 25 14:15:32 <sgw> RP__: ping
May 25 14:40:08 <RP__> sgw: pong
May 25 14:40:47 <RP__> sgw: Working up to your pull request. The laptop which was struggling along fell over today and its taken me a while to coax it back to life
May 25 14:41:13 <RP__> (when it came to rebooting, it didn't want to boot again)
May 25 14:42:06 * sgw -> dr appt back later
May 25 14:42:27 <sgw> RP__: gnutls is bad drop it.
May 25 14:42:43 <RP__> sgw: ok
May 25 14:47:02 <RP__> sgw: Did you resolve the eglibc parallel make thing with khem?
May 25 15:19:31 <bluelightning> RP__: is there an easy way currently of finding skipped recipes?
May 25 15:19:56 <RP__> bluelightning: no :/
May 25 15:20:04 <bluelightning> I dug around in cooker etc. for a while this morning but couldn't quite figure out if there was
May 25 15:21:18 <zenlinux> RP__, good morning. Is there an equivalent of a post-install hook I can use to execute some custom shell code after a package gets installed from sstate?
May 25 15:22:02 <zenlinux> for example, I have a package that needs to install some files into the sysroot
May 25 15:22:15 <zenlinux> and then process them
May 25 15:25:20 <RP__> zenlinux: Currently I think the answer is no
May 25 15:25:32 <RP__> zenlinux: We've managed without them
May 25 15:26:00 <zenlinux> yikes
May 25 15:26:11 <RP__> zenlinux: Do you mean the sysroot or do you mean something else?
May 25 15:26:21 <zenlinux> no, I mean the sysroot
May 25 15:26:32 <RP__> zenlinux: What do you want to do to the sysroot?
May 25 15:26:39 <zenlinux> this is how we need to be able to add users and groups to the passwd/group files in the sysroot
May 25 15:26:48 <RP__> You realise the sysroot is not under control of pseudo?
May 25 15:27:33 <fray> we need to run just the user/group add under pseudo
May 25 15:27:36 <RP__> zenlinux: The one "post-install" like thing we do is triggered by   if os.path.isfile(fixmefn): in sstate.bbclass
May 25 15:27:37 <zenlinux> right, but in order to chown/chgrp the ownership of the files during packaging, they need to refer to a passwd/group file to understand the ownership, and Mark and I thought the most sensible place to keep that information was in the sysroot
May 25 15:28:37 <zenlinux> RP__, so what I'm hearing is that this approach is not feasible, and what we'll need to do is copy/create a passwd/group file on a per-recipe basis and muck around with that?
May 25 15:28:39 <RP__> zenlinux: that makes more sense but I start getting worried about races. Shouldn't this file be in WORKDIR?
May 25 15:29:35 <RP__> zenlinux, fray: I guess this file would have some "default" entries (root and so on) + the package specific additions?
May 25 15:29:58 <RP__> Would you want every package specific addition that had packaged in any build there or not?
May 25 15:31:39 <RP__> zenlinux: I'd suggest adding a file like the "fixmepath" path one called something like "fixmeuser" which has the required information in it
May 25 15:31:59 <RP__> zenlinux: It will need hardcoded handling of the file in sstate but I don't think that is a big issue
May 25 15:32:45 <RP__> but please do consider the implications of putting it in the sysroot as a shared location
May 25 15:33:21 <zenlinux> RP__, digesting all of this....
May 25 15:35:25 <zenlinux> RP__, what this also means is that the SGML packages are broken when being built from sstate, too. Because the packages rely on updating the sysroot SGML catalogs as each new package gets installed
May 25 15:35:53 <RP__> zenlinux: Well, we did fix that by using one of the hooks didn't we?
May 25 15:36:03 <RP__> I'm just not sure that hook will help in this context?
May 25 15:36:04 <zenlinux> RP__, ah, yes,
May 25 15:36:12 <zenlinux> let me take a look at that again
May 25 15:37:34 <nitink> Good Morning all !
May 25 15:39:50 <zenlinux> RP__, I'd like to try using SSTATEPOSTINSTFUNCS, why don't you think it would work (other than risking race conditions)?
May 25 15:54:33 <RP__> zenlinux: I just missed it in the codepath. It likely will work
May 25 16:05:58 * nitink1 is getting this error after upgrading autoconf: | checking size of unsigned long... configure: error: in `/build_disk/poky_build/build0/tmp/work/x86_64-nativesdk-pokysdk-linux/unfs-server-nativesdk-2.1+2.2beta47-r0/nfs-server-2.2beta47': | configure: error: cannot run test program while cross compiling
May 25 16:06:56 <nitink1> and adding ac_cv_sizeof_unsigned_long=${ac_cv_sizeof_unsigned_long=4} to meta/site/powerpc-linux did not help :(
May 25 16:07:11 <nitink1> RP__: any clues ^^^
May 25 16:07:12 <zenlinux> nitink1, I was just going to suggest that
May 25 16:08:00 <nitink1> zenlinux: :)
May 25 16:20:41 <khem> nitink1: thats a nativesdk package it wont read meta/site/powerpc-linux
May 25 16:20:49 <khem> that would be read for target packages
May 25 16:21:13 * khem 's workhorse machine is down today
May 25 16:21:56 <nitink1> khem: they why error: cannot run test program while cross compiling
May 25 16:22:02 <khem> nitink1: what is your SDKMACHINE and host
May 25 16:22:13 <nitink1> both x86-64 -linux
May 25 16:22:42 <khem> ok
May 25 16:22:51 <khem> then it should have worked
May 25 16:22:54 <khem> give me few mins
May 25 16:22:54 <nitink1> khem: this is with upgraded autoconf
May 25 16:23:07 <khem> hmm I see
May 25 16:23:09 <khem> what version
May 25 16:23:40 <nitink1> 2.68 & also updated m4 to 1.4.16
May 25 16:23:56 <khem> ok
May 25 16:24:11 <khem> does your sdk gcc work ok
May 25 16:24:16 <nitink1> most of the packages are working fine with upgraded autoconf
May 25 16:24:24 <khem> ok
May 25 16:24:33 <nitink1> khem: what do you mean by work ok ?
May 25 16:25:03 <khem> compile a helloworld with sdk gcc and try to run it on your host
May 25 16:25:16 <khem> since its a runtime test thats failing
May 25 16:25:24 <khem> I am suspecting compiler installtion
May 25 16:25:47 <nitink1> it has worked that way before. it is 4.6.0 gcc, if after upgrading autoconf anything has changed, then I don't know it yet
May 25 16:26:36 <khem> autconf can impact in many ways but for gcc we dont autoreconf so it should impact gcc
May 25 16:26:47 <khem> but it could be other factors
May 25 16:27:54 <nitink1> I generally test sdk compiler by creating qemu sdk image, and working inside qemu
May 25 16:28:11 <nitink1> but with these failures I will not be able to create the sdk image
May 25 16:28:48 <khem> hmmm ok inside the build dir autconf must have created a config.log
May 25 16:29:08 <nitink1> khem: yes it is there
May 25 16:29:15 <khem> ok pastebin it
May 25 16:31:20 <nitink1> khem: http://pastebin.com/GWLnzDnE
May 25 16:38:06 <dvhart> zeddii, ping
May 25 16:40:56 <khem> nitink1: ok so it figures out that we are cross compiling in this case and refuses to run the runtime tests
May 25 16:41:34 <nitink1> khem: right
May 25 16:41:49 <khem> nitink1: which I think is correct since I think SDKMACHINE can be i686 and build machine can be x86_64 or any other combination
May 25 16:42:07 <nitink1> khem: right
May 25 16:43:01 <khem> nitink1: I think you need to add it to x86_64-linux site config files
May 25 16:43:19 <khem> and also to x86 ones
May 25 16:43:26 <nitink1> khem: makes sense, let me try
May 25 16:43:32 <khem> for if SDKMACHINE is i686
May 25 16:45:05 <nitink1> khem: meta/site/x86-64 already has ac_cv_sizeof_unsigned_long defined
May 25 16:45:16 <khem> hmm
May 25 16:45:21 <nitink1> I mean meta/site/x86_64-linux
May 25 16:45:47 <khem> ok pastebin the output of bitbake -DDD unfs-server-nativesdk
May 25 16:46:21 <khem> add -n too
May 25 16:51:37 <nitink1> khem: ok
May 25 16:55:38 <khem> I think it should read in site/x86_64-linux
May 25 16:55:48 <khem> so this var should be cached
May 25 17:05:00 <khem> nitink1: can you also pastebin the run.do_configure of this package
May 25 17:05:36 <khem> nitink1: and also log.do_configure
May 25 17:05:53 <zeddii> dvhart, pong. from lunch to a meeting. but I'll be distractedly available for the next hour and then better after that :)
May 25 17:06:06 <dvhart> zeddii, do you have the bbc4 ?
May 25 17:06:18 <dvhart> zeddii, we're in a pinch on documentation and I need someone with hw to test
May 25 17:06:35 <nitink1> khem: bitbake -DDD  output is too large for pastebin, any good place to share it ?
May 25 17:06:45 <khem> thats fine
May 25 17:06:48 <khem> dont need it
May 25 17:06:51 <zeddii> lemme look once I'm untethered from a phone. was it a bbc4 that we had @ ELC ?
May 25 17:11:55 <dvhart> zeddii, yes
May 25 17:12:00 <dvhart> erm no
May 25 17:12:02 <dvhart> elc was the xm
May 25 17:12:09 <dvhart> c4 at cambridge
May 25 17:14:53 <khem> I am seeing this error while compiling shared-mime-info
May 25 17:14:54 <khem> http://pastebin.com/LGqzpSGy
May 25 17:15:03 <khem> anyone else seen it
May 25 17:15:10 <khem> x86_64/ubuntu
May 25 17:18:46 <zenlinux_laptop> ok, I've thoroughly confused myself now how files get installed into the target sysroot. For example, I'm seeing usr/share/bison/ files in a target sysroot, but bison doesn't have a -cross recipe or BBCLASSEXTEND="cross"
May 25 17:19:10 <zenlinux_laptop> anyone with a cluebat?
May 25 17:19:51 <khem> zenlinux_laptop: they prefix sysroot
May 25 17:20:47 <zenlinux_laptop> khem, sorrry....prefix sysroot, how?
May 25 17:21:51 <khem> well you have package sysroot which then gets copied over into TARGET_SYSROOT as it is in populate_sysroot task
May 25 17:22:39 <nitink1> khem: run.do_configure: http://pastebin.com/PzFcpb65
May 25 17:22:56 <zenlinux_laptop> khem, ok, but I notice for example that very few files get populated in the target sysroot, and I'm looking at recipes trying to figure out how they are specifying whether or not to install into the sysroot
May 25 17:24:17 <nitink1> khem: & log.do_configure: http://pastebin.com/azSRxFud
May 25 17:25:03 <khem> zenlinux: look into sysroot_stage_dirs function
May 25 17:25:14 <khem> in staging.bbclass
May 25 17:25:18 <khem> you will see it
May 25 17:26:07 * nitink1 away for keybaord
May 25 17:27:30 <zenlinux_laptop> khem, thanks! now I see that it specifically targets the datadir and libdir files
May 25 17:27:59 <khem> nitink1: ok the problem is that configure is not loading the site scripts
May 25 17:32:07 <khem> nitink1: it seems its ignoring CONFIG_SITE env var
May 25 17:47:54 <zenlinux> fray, please see my email from last night about whether to make USERADD_PARAM/GROUPADD_PARAM global to the recipe since we want to inject the code into all packages that get generated for that recipe.
May 25 17:48:26 <zenlinux> (i.e, as opposed to using USERADD_PARAM_packagename and setting USERADD_PACKAGES)
May 25 19:17:04 <nitink1> khem: thanks for identifying the issue
May 25 19:18:10 <nitink1> khem: I also was suspecting faintly on that line. But now surprised to see so many packages are building fine
May 25 19:18:53 <dvhart> hrm.... I need to do an append to a variable using immediate expansion
May 25 19:19:12 <dvhart> but I can't do C := "${C}append" as C may not have been assigned yet
May 25 19:19:26 <dvhart> and bitbake will fail to expand it and complain of a circular reference
May 25 19:20:29 <dvhart> can the _append override help here?
May 25 19:21:55 <khem> nitink1: building but they may not run
May 25 19:22:32 <khem> dvhart: _append will work its evaluated very last
May 25 19:22:46 <dvhart> khem, I tried:
May 25 19:22:49 <khem> even after virtclasses and python
May 25 19:22:53 <dvhart> FILESEXTRAPATHS_append := " ${THISDIR}/${PN}"
May 25 19:22:56 <dvhart> and this results in:
May 25 19:23:00 <khem> hmmm no :=
May 25 19:23:02 <dvhart> FILESEXTRAPATHS=/home/dvhart/source/poky.git/layers/meta-boottime/recipes-kernel/linux/linux-yocto ${THISDIR}/${PN}
May 25 19:23:04 <dvhart> ok
May 25 19:23:30 <dvhart> same deal
May 25 19:23:41 <dvhart> I need to immediate expand ${THISDIR...
May 25 19:24:24 <khem> then assign SAVEDTHISDIR := ${THISDIR}
May 25 19:24:31 <dvhart> yup, doing that now :-)
May 25 19:26:07 <dvhart> pfff... it would help if I was modifying the files on the same machine I was running the test build on ;-/
May 25 19:27:56 <dvhart> khem, ok, _append is right, but it does need :=
May 25 19:27:58 <dvhart> FILESEXTRAPATHS_append := " ${THISDIR}/${PN}"
May 25 19:27:59 <dvhart> that works
May 25 19:28:07 <khem> sit back and take a breath
May 25 19:46:34 <khem> dvhart: yes I see it will evaluate THISDIR and PN immediately
May 25 19:46:47 <khem> so if PN is modified later then it wont get it
May 25 19:47:02 <khem> like PN is probably changed in virtclasses
May 25 19:47:07 <dvhart> hrm
May 25 19:47:57 <khem> dvhart: try it with something like a nativesdk recipe
May 25 19:48:15 <dvhart> this seems to be how most FILESEXTRAPATHS are assigned in bbappends
May 25 19:48:28 <dvhart> just with := I mean, not the _append
May 25 19:49:09 <dvhart> I'm not familiar with virtclasses
May 25 19:49:21 <khem> but in this case it may not matter
May 25 19:49:35 <khem> since we are adding paths
May 25 19:49:54 <khem> and I dont think FILESPATH cares for bbclassextend
May 25 19:50:19 <dvhart> yeah, if the dirname matches PN as it is in the bbappend, you don't want it to change later
May 25 19:51:25 <khem> virtclasses on one hand has made recipes look prettier on other it needs care all the time
May 25 20:07:43 <nitink1> khem: any update on the yday's arm gcc issue
May 25 20:10:48 <khem> no
May 25 20:10:57 <khem> my machine with builds is down
May 25 20:11:02 <khem> have to fix it
May 25 21:44:09 <zenlinux> hmmm... ftp.debian.org is flaking out
May 25 22:24:18 * dvhart looks for a cluebat for guido
May 25 22:24:20 <dvhart> http://docs.python.org/library/string.html#string.split
May 25 22:24:29 <dvhart> that caveat tacked on to the end of split... that's just rude
May 25 22:28:13 <nitink> khem: yday's arm gcc issue also happens with linaro patches, so I think meta-oe gcc will hit the same issue
May 25 22:30:59 <khem> nitink: ok I will know tonight
May 25 22:31:04 <khem> thanks for heads up
May 25 22:32:06 <bluelightning> dvhart: I thought so too
May 25 22:32:19 <dvhart> grrr
May 25 22:34:03 <incandescant> that's one of the items on my "hate python" list
May 25 22:42:16 <dvhart> bluelightning, incandescant: ok, this doesn't even match what I expected - nor what the code in utils.bbclass expects either apparently!
May 25 22:42:17 <dvhart> In [3]: "".split(":")
May 25 22:42:18 <dvhart> Out[3]: ['']
May 25 22:42:18 <dvhart> In [4]: ":".split(":")
May 25 22:42:18 <dvhart> Out[4]: ['', '']
May 25 22:42:18 <dvhart> In [5]: "".split()
May 25 22:42:20 <dvhart> Out[5]: []
May 25 22:42:47 <dvhart> I expected In [4] to return an empty list
May 25 22:42:56 <dvhart> not TWO empty strings in a list
May 25 22:43:49 * dvhart finds two bugs in FILESEXTRAPATHS handling in trying to do it right in meta-intel
May 25 22:43:59 <bluelightning> dvhart: the docs don't contradict your findings though
May 25 22:44:12 <dvhart> no, they don't call out that case at all
May 25 22:44:15 <bluelightning> in fact I would have expected that behaviour
May 25 22:44:38 <dvhart> I was probably biased by the comments in utils.bbclass
May 25 22:44:47 <dvhart> base_set_filespath()
May 25 22:45:45 <davest> Hello world - quick quetion... Does EXTRA_IMAGE_FEATURES call out classes?  Or just packages and groups of packages?
May 25 22:46:29 <bluelightning> dvhart: the only comment in there makes sense, apparently we want an empty item at the end and adding an extra separator will force that... ?
May 25 22:47:01 <dvhart> ah... hrm
May 25 22:47:18 <dvhart> ok, I read empty as [] but it means ""
May 25 22:47:35 <bluelightning> davest: AFAIK it's a list of "features"; elsewhere we check this list for certain feature keywords and include packages / make other mods based upon the presence/absence of them
May 25 22:50:36 <bluelightning> davest: we have an appendix in the poky ref manual that covers features
May 25 22:52:09 <bluelightning> ok, so scratch the "make other mods" - we really only use them to add packages or tasks (i.e. groups of packages) to the image
May 25 22:56:55 <davest> bluelightning: danke
May 25 22:58:31 <davest> bluelightning: interesting that we don't explain EXTRA_IMAGE_FEATURES anyplace in the ref manual, other than to clear it when setting INCOMPATIBLE_LICENSE to be "GPLv3". :-)
May 25 23:01:30 <incandescant> davest: we explain IMAGE_FEATURES a bit, we may not clearly point out that you can set them EXTRA_IMAGE_FEATURES
May 25 23:01:55 <incandescant> davest: http://pokylinux.org/doc/poky-handbook.html#ref-features-image
May 25 23:05:57 <davest> incandescant: it's definitely missing in the manual. I feel a bugzilla coming on
May 25 23:06:37 <nitink> khem: I have updated gcc bugzilla for arm issue: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47719 I could not reopen the fixed bug though
May 25 23:07:29 <incandescant> davest: I agree :-)
May 25 23:07:51 * incandescant wants to make the reference manual a required read for each team member on a regular cadence
May 25 23:18:24 <dvhart> incandescant, nod
May 25 23:21:41 <bluelightning> crap, bitbake -c cleanall does not do what we would expect with oe-dev :/
May 25 23:28:39 <incandescant> bluelightning: looks like some out of sync classes, can't say I'm surprised
May 26 00:36:35 <ReaperOfSouls> Who handles the layer configs for meta-intel?
May 26 00:39:07 <bluelightning> ReaperOfSouls: dvhart and tomz3
May 26 00:40:12 <ReaperOfSouls> dvhart: tomz3 around? :)
May 26 00:40:18 <ReaperOfSouls> bluelightning: thank you.
May 26 00:55:07 <ReaperOfSouls> guess not, fired off to the yocto list.
May 26 02:10:55 <sgw> meilei007: ping
May 26 02:11:08 <meilei007> pang
May 26 02:11:33 <sgw> meilei007: did you see the  branch I sent you?
**** ENDING LOGGING AT Thu May 26 02:59:57 2011

**** BEGIN LOGGING AT Thu May 26 02:59:57 2011
May 26 08:22:44 <JaMa|Wrk> RP__: small question wrt YOCTO #1074, are stamps somehow cleaned after build? I do see ie do_configure.sigdata.d8a4a0ec87cc4508cee3768f881b1386 during build, but when it's finished (will check if after build or rm_work) I had only sigdata from package_setscene,package_write_ipk,populate_sysroot,rm_work and the other tasks are removed
May 26 09:19:59 <bluelightning> morning all
May 26 09:31:42 <JaMa|Wrk> RP__: small patch for rm_work.bbclass addressing this sent to ML
May 26 09:33:56 <JaMa|Wrk> Is it OK to send single patch without pull request or do you prefer also single patches wrapped in pull request? especially when it's something small I find it more annoying to read pull request on ML saying exactly the same as the patch itself..
May 26 09:50:38 <RP__> JaMa|Wrk: I'm ok with single patches
May 26 09:50:52 <RP__> JaMa|Wrk: and yes, sounds like rm_work needed tweaking, good catch :)
May 26 09:51:22 <RP__> morning all
May 26 10:07:57 <bluelightning> hi RP__
May 26 10:34:00 <JaMa|Wrk> RP__: the warning with BBFILE_PATTERN_nokia-layer is still shown with todays bitbake master
May 26 10:34:26 <RP__> JaMa|Wrk: There must be some other case to do with skipped recipes we have then as you mentioned :/
May 26 10:34:40 <JaMa|Wrk> RP__: and that gcc rebuild is just weird.. I've tried to switch machine override for BBFILE_COLLECTIONS and no rebuild now
May 26 14:46:39 <zenlinux_laptop> gm all
May 26 14:47:00 <zenlinux_laptop> egonzalez_ergio, I believe that eglibc build error you ran into a few days ago is now fixed in poky master
May 26 14:47:44 <egonzalez_ergio> hi!
May 26 14:48:39 <zenlinux_laptop> I ran into it myself (seemed to only happen on Ubuntu hosts) and was able to do a successful build a couple of days later
May 26 14:50:15 <egonzalez_ergio> Im trying to make my own image addi packages to core.minimal image
May 26 14:50:47 <egonzalez_ergio> I have me image bb with an include ov image-minimal bake
May 26 14:51:12 <egonzalez_ergio> and via IMAGE_INSTALL =+  I add packages
May 26 14:51:19 <egonzalez_ergio> this work very weel
May 26 14:51:21 <egonzalez_ergio> well
May 26 14:51:36 <egonzalez_ergio> BUT when I add kernel-module-bluetooth
May 26 14:51:45 <egonzalez_ergio> the bitbake stop with:
May 26 14:52:07 <egonzalez_ergio> Unable to find package kernel-module-bluetooth!
May 26 14:52:10 <egonzalez_ergio> in do_root
May 26 14:52:25 <egonzalez_ergio> where I can to add this config?
May 26 14:53:26 <zenlinux_laptop> egonzalez_ergio, I'm not sure off the top of my head. I think also that bluetooth may be a feature that needs to be enabled elsewhere (e.g, a machine feature).
May 26 14:53:46 <zenlinux_laptop> oh, a kernel guy just dropped in
May 26 14:54:17 <zenlinux_laptop> dvhart, egonzalez_ergio is trying to add  kernel-module-bluetooth to his image, and is having problems. Would you know much about this?
May 26 14:54:39 <egonzalez_ergio> my problem is that bluez bake in yocto forse to compile dbus and gstreamers features...and I dont want this
May 26 14:54:57 <egonzalez_ergio> I have my oen bake without this
May 26 14:55:03 <dvhart> "bake" ?
May 26 14:55:08 <egonzalez_ergio> but is now my responsabilty to add the kernel module
May 26 14:55:10 <dvhart> the recipe?
May 26 14:55:14 <egonzalez_ergio> yes
May 26 14:55:17 <egonzalez_ergio> sorry
May 26 14:55:37 <dvhart> ok, so what's the trouble adding the module?
May 26 14:55:56 <egonzalez_ergio> when I add to IMAGE_INSTALL =+
May 26 14:55:58 <egonzalez_ergio> kernel-module-bluetooth
May 26 14:56:04 <egonzalez_ergio> itbake stop with
May 26 14:56:08 <egonzalez_ergio>  Unable to find package kernel-module-bluetooth!
May 26 14:56:11 <egonzalez_ergio> in do_root
May 26 14:56:51 <dvhart> one sec, verifying something
May 26 14:58:12 <dvhart> is this a new recipe for the kernel module or are you trying to install a bluetooth module built with the linux-yocto kernel recipe?
May 26 15:00:31 <egonzalez_ergio> the second option
May 26 15:01:53 <dvhart> ok, and have you confirmed that CONFIG_BLUETOOTH is in your .config ?
May 26 15:02:20 <dvhart> tmp/work/$machine.../linux-yocto.../linux...build/.config
May 26 15:03:15 <egonzalez_ergio> ehhhm, nop
May 26 15:03:19 <egonzalez_ergio> let me see
May 26 15:03:35 <dvhart> egonzalez_ergio, which machine are you building for ?
May 26 15:04:52 <egonzalez_ergio> qemux86
May 26 15:05:17 <dvhart> uhm...
May 26 15:05:32 <dvhart> how would you test this/
May 26 15:05:33 <dvhart> ?
May 26 15:06:04 <egonzalez_ergio> i think to boot the rootfs from a atompc after
May 26 15:06:55 <dvhart> egonzalez_ergio, grep for BLUE in your .config - what do you find?
May 26 15:07:07 * dvhart doubts the qemux86 has a bluetooth module
May 26 15:07:43 <egonzalez_ergio> .config of tmp/sysroots/qemux86/kernel/.config has not BLUETOOTH
May 26 15:08:40 <egonzalez_ergio> what machine you recommend to me? "atom-pc"  maybe?
May 26 15:09:03 <dvhart> egonzalez_ergio, I'm looking to see if we enable bluetooth by default for any of these
May 26 15:09:15 <dvhart> egonzalez_ergio, the alternative is to add a config fragment to your recipe
May 26 15:09:30 <dvhart> I cover this in my ELC kernel development video
May 26 15:09:46 <dvhart> I really need to write that up so it can just be read
May 26 15:10:20 <dvhart> egonzalez_ergio, http://free-electrons.com/blog/elc-2011-videos/
May 26 15:10:41 <dvhart> search for "Yocto Project: Practical Kernel Development Tutorial"
May 26 15:11:41 <egonzalez_ergio> yes..a I see the vedeo
May 26 15:11:44 <egonzalez_ergio> video
May 26 15:12:00 <dvhart> egonzalez_ergio, do you know what the name of the CONFIG options you need are?
May 26 15:13:04 <dvhart> egonzalez_ergio, looks like CONFIG_BT
May 26 15:13:23 <dvhart> followed by one of several drivers
May 26 15:14:09 <dvhart> from what I can see, CONFIG_BT is not enabled in any of the default machines in linux-yocto
May 26 15:14:16 <dvhart> this is easy to add though
May 26 15:14:43 <egonzalez_ergio> mmm
May 26 15:15:02 <dvhart> and the package will not be named kernel-module-bluetooth
May 26 15:15:27 <dvhart> egonzalez_ergio, so, here is what I recommend:
May 26 15:15:39 <dvhart> 1) save the default .config you have now
May 26 15:15:48 <dvhart> 2) run bitbake -c menuconfig linux-yocto
May 26 15:16:01 <dvhart> make your config changes, enabling CONFIG_BT and some BT drivers
May 26 15:16:17 <dvhart> 3) take a diff of the old .config with the new .config and save as bt.cfg
May 26 15:16:33 <dvhart> copy that to the files dir for a linux-yocto.bbappend of your own
May 26 15:16:44 <dvhart> and add it to the SRCURI
May 26 15:16:51 <dvhart> then rebuild and test
May 26 15:17:11 <egonzalez_ergio> txs...now I'll try
May 26 15:17:21 <dvhart> you'll either need to set the options to "y" or set them to "m" and list each module in IMAGE_INSTALL
May 26 15:17:38 <dvhart> this is the first approach taken in the video
May 26 15:17:55 <dvhart> if you need a framework to help you get started I can send you the meta-elc layer I used for the demo
May 26 15:18:11 <dvhart> hrm... sounds like I have a wiki page to write :-)
May 26 15:18:17 <dvhart> egonzalez_ergio, thanks for the use-case!
May 26 15:18:27 <egonzalez_ergio> if you cat to send me I'll appreciate a lot
May 26 15:18:31 <egonzalez_ergio> can
May 26 15:18:41 <dvhart> egonzalez_ergio, msg me an email address
May 26 15:45:02 * zeddii reads. was afk. looks handled!
May 26 15:50:36 <nitink> Good Morning all !
May 26 15:51:41 <zenlinux_laptop> hey nitink, happy Thursday and all that jazz
May 26 15:51:59 <nitink> same to you zenlinux_laptop :)
May 26 18:04:13 <nitink> good news on the gcc arm issue, removing -O2 avoids the ICE
May 26 18:18:01 <pidge> nitink: CC me on a pull request so I can pull it into 1.1_M1
May 26 18:18:17 <nitink> pidge : sure
May 26 18:37:20 <sgw> nitink: great news, I will work with RP to get it in quickly, I have a couple other changes also.
May 26 18:47:30 <sgw> fray: ping
May 26 18:47:36 <fray> hey
May 26 18:47:54 <sgw> Afternoon, hope some of those storms are passing you by!
May 26 18:48:09 <fray> heh it's bright and sunny out right now
May 26 18:48:29 <sgw> fray: regarding createrepo, the current version is clearly the wrong version for us because of the yum dependencies
May 26 18:49:02 <sgw> fray: my question : Is there an older version that's usable?  Or do we need to do some other magic to get the repo and package-index stuff working?
May 26 18:50:11 <fray> I'm not sure.. I thought that the version that was in 1.0 didn't have any yum dependencies.. maybe they updated and threw away support for everything else?
May 26 18:50:35 <fray> I don't know much about this, but I would assume Zypper needs something.. I'd suggest we check with SuSE and/or MeeGo.. since they are using Zypper (AFAIK)
May 26 18:52:55 <sgw> Ok, I will look around suse, I think meego might still be yum
May 26 18:53:18 <sgw> RP: you still around?
May 26 19:08:17 <nitink> how to trim CFLAGS effectively ?
May 26 19:11:55 <sgw> nitink: good question, I am thinking there is a pythonish way to strip something from a variable.
May 26 19:12:26 <nitink> sgw: I have a shell script way 1 liner
May 26 19:24:49 <RP__> sgw: kind of
May 26 19:25:46 <sgw> I think I am going to have to revert the createrepo upgrade change, so expect that, we need to go to a pre-yum version
May 26 19:25:56 <fray> that seems reasonable right now..
May 26 19:26:01 <RP__> sgw: ok
May 26 19:26:25 <sgw> also, Koen's dbus change broke my build!
May 26 19:31:12 <RP__> sgw: broke how? :/
May 26 19:31:38 <sgw> the RDEPENDS was not satisfied for dbus-launch, nothing provided it
May 26 19:31:47 <sgw> in x11-common
May 26 19:32:33 <RP__> sgw: hmm, odd :/
May 26 19:33:47 <sgw> missing PR bump somewhere?
May 26 19:42:00 <pidge> tomz: ping
May 26 19:46:32 <tomz1> pidge: pong
May 26 19:47:50 <pidge> tomz: for rc2, did changes you make to meta-intel master get pulled to the 1.1_M1 branch?
May 26 19:48:22 <pidge> atomz: also, there was a distcc error on my last crownbay build (this time with the correct EMGD version *doh)
May 26 19:49:42 <tomz1> pidge: rc2?
May 26 19:49:56 <tomz1> pidge: never seen distcc problems before
May 26 19:49:59 <pidge> tomz: 1.1 M1 release candidate 2
May 26 19:50:32 <tomz1> I only see a 1.1_M1 branch
May 26 19:50:40 <pidge> http://autobuilder.yoctoproject.org:8010/builders/crownbay/builds/80/steps/shell_15/logs/stdio
May 26 19:50:59 <pidge> yes, that's where I build the rc from
May 26 19:51:41 <sgw> pidge: that's another one of those nasty autoconf failures, similar to what we have else where, some thing wonky with autoconf
May 26 19:51:45 <tomz1> pidge: the distcc is new to me - have you ever seen it on other builds/machines?
May 26 19:52:07 <sgw> pidge: not really a BSP failure
May 26 19:53:18 <pidge> sgw: 'kay. tomz: if there is anything BSP related that you want pulled into M1 that isn't in the M1_1.1 branch, let me know.
May 26 19:53:20 <tomz1> pidge: so 1.1_M1 is two commits behind master, one of them a doc .  Dunno, I didn't create that branch
May 26 19:53:30 <pidge> tomz: i did
May 26 19:53:37 <tomz1> pidge: yeah, sure, just update to master
May 26 19:53:57 <pidge> tomz: ok. thanks!
May 26 19:54:11 * pidge is trying to not have a crazy friday :)
May 26 19:54:25 <sgw> right, good idea
May 26 20:08:02 <otavio> Hello
May 26 20:08:11 <egonzalez_ergio> hi
May 26 20:08:19 <otavio> sgw: why the busybox change was left out?
May 26 20:10:13 <sgw> otavio:  There was some discussion from Phil, and you replied in the affirmative about maintaining them in your own distro layer.
May 26 20:10:40 <sgw> Did I mis-understand your reply?
May 26 20:12:15 <otavio> sgw: it was about the mdev.conf
May 26 20:12:23 <otavio> sgw: not the mdev by default
May 26 20:12:52 <otavio> msm: I have overriden it in my layer to add a conf but IMO mdev ought to be provided by default
May 26 20:19:37 <otavio> sgw: ^
May 26 20:20:11 <sgw> otavio: I saw and I  understand your comment.
May 26 20:22:45 <egonzalez_ergio> there are some manual/list of the internal predefined variables? (like THISDIR)
May 26 20:29:08 <sgw> incandescant: want to followup with the ROOTFS Size for minimal, what exactly is your concern with letting the OVERHEAD FACTOR guide the size?
May 26 20:29:37 <incandescant> isn't OVERHEAD_FACTOR user configurable? what if the user sets it lower and therefore the size is smaller than required
May 26 20:30:16 <sgw> incandescant: so -initrams is about 13M internal and 16M ext3 image size (just for FYI)
May 26 20:30:21 <JaMa> RP__: while changing rm_work.bbclass I noticed that packages-split/package are kept for sstate tasks, there is no way to remove this dependency?
May 26 20:31:13 <sgw> incandescant: If they set it smaller, then they will have less available space, it a configuration knob, we can give reasonable defaults, which we have, and then they can tune.
May 26 20:31:28 <sgw> incandescant: I guess I am not seeing exactly what your concern is
May 26 20:31:46 <incandescant> sgw, yeah, but shouldn't the reasonable default accommodate the actual size of the image now, not the goal size?
May 26 20:32:41 <incandescant> IMAGE_OVERHEAD should be for *extra* space not image contents IMO
May 26 20:32:42 <sgw> Then we would need defaults for sato, lsb, sato-sdk, lsb-sdk, ...  For minimal, we want the smallest possible image
May 26 20:33:01 <JaMa> RP__: because I've cleaned whole tmp/work directory and now I got ugly error like this http://paste.pocoo.org/show/395802/
May 26 20:33:16 <RP__> JaMa: removing them caused some problems, we need to address that problem
May 26 20:33:20 <sgw> OVERHEAD is for the core image overheard, ie for post-install and first startup generation
May 26 20:33:38 <RP__> JaMa: Just haven't found time. You could file a feature enhancement request
May 26 20:34:26 <JaMa> RP__: ok, I'll, I just needed confirmation that this isn't final state and that tmp/work should be discardable again
May 26 20:36:28 <sgw> incandescant: image contents (ie actual diskspace used is determined via the du at rootfs time) then add the factor on top of that for operational space.  ROOTFS_IMAGE_EXTRA_SPACE is for user and data space, or installing additional items.  Or set IMAGE_ROOTFS_SIZE to arbitrarily large size and you have all the space you need!
May 26 20:36:58 <otavio> RP__: did you look at the bitbake issue regarading autorev?
May 26 20:37:02 <RP__> JaMa: it needs more investigation and thought. Those directories aren't large
May 26 20:37:12 <RP__> otavio: no, ran out of time, sorry
May 26 20:37:39 <RP__> otavio: Wasn't this a problem with PKGV?
May 26 20:37:57 <RP__> There are some patches on the mailing list regarding that
May 26 20:38:23 <incandescant> sgw, so my question is; what if IMAGE_ROOTFS_SIZE is smaller than image contents? 8M*1.2 is less then the 9.9M size of qemux86 minimal
May 26 20:38:45 <otavio> RP__: dunno
May 26 20:38:52 <otavio> RP__: was them merged already
May 26 20:38:53 <otavio> ?
May 26 20:39:11 <incandescant> sgw, clearly this isn't cut and dry so perhaps some documentation of these variables and how they all work together? :-)
May 26 20:41:35 <RP__> otavio: no, not merged yet
May 26 20:43:42 <otavio> RP__: ok
May 26 20:43:43 <sgw> incandescant: then it's actual content size * 1.3 (default overhead), which is what we have actual content is 9.9M * 1.3 = 13M ROOTFS_SIZE (ext3 image size).
May 26 20:44:44 <incandescant> sgw, ok, thanks. That answers my question. I still think it's confusing and needs documenting though
May 26 20:44:59 <sgw> incandescant: Like I said I am missing something, Ok file a docs bug and I will help scott write it up
May 26 20:45:03 <incandescant> I probably need to be able to read shell script better as reading the code that wasn't obvuous
May 26 20:47:15 <RP__> incandescant: you can't execute shell script in your head yet? Shameful ;-)
May 26 20:48:07 <JaMa> RP__: filled as #1109
May 26 20:49:39 <JaMa> RP__: and those directories are quite large.. I got 1G tmp/work only because of dbus PR change..
May 26 20:51:32 <RP__> JaMa: I think it may be hard to remove them due to the way sstate works but we can investigate
May 26 20:52:29 <incandescant> RP__, sgw: turns out it's easier to parse when you have more context lines though...
May 26 20:52:55 <RP__> JaMa: FWIW, making rm_work just use sstate was a great code simplification and makes everything so much more consistent
May 26 20:57:07 <JaMa> RP__: agreed, I'm not blaming sstate.. just feels sad to call -c cleanall just because of missing tmp/work directories..
May 26 20:57:46 <sgw> RP__: so are you going to pull Nitin's & Koen's updates or do you want me to give you the the consolidated version
May 26 20:59:01 <JaMa> sgw: don't forget my rm_work change :)
May 26 20:59:26 <sgw> JaMa: right sorry, was focused on some build failures
May 26 20:59:45 <sgw> I would have pulled into also, just see what RP's preference was
May 26 21:10:51 <JaMa> RP__: and is it really expected that ie PR change in dbus causes whole dependency tree below it to rebuild (stuff like glib/gtk/efl)?
May 26 21:28:25 <nitink> sgw: RP__: I have updated the bugfix commit in the tree, please pull the newer version of the commit
May 26 21:31:11 <sgw> nitink: what changed?
May 26 21:31:17 <sgw> PR bump?
May 26 21:31:20 <nitink> comment & PR
May 26 21:31:23 <nitink> yes
May 26 21:32:36 <sgw> nitink: actaully should that change be only for the arm or the beagle board not all ?
May 26 21:33:06 <nitink> sgw: the issue is only for beagleboard
May 26 21:34:08 <nitink> if you can make it armv7 specific, go ahead.
May 26 21:38:31 <nitink> sgw: pull one more time please. I also added gcc bugzilla there.
May 26 23:00:53 <RP__> sgw: so what am I doing? :)
May 26 23:01:12 <ka6sox-away> RP__, lol...thats funny.
May 26 23:01:26 <sgw> hmm, going to bed ;-)
May 26 23:01:48 <RP__> sgw: There is some stuff that needs pulling in now?
May 26 23:01:50 <sgw> I can have a consolidated pull here shortly
May 26 23:02:09 <RP__> sgw: well, that or just point me at the commits that are urgent
May 26 23:02:19 * RP__ has just spent too long staring at maps :/
May 26 23:02:28 <sgw> Koen's, nitin's
May 26 23:02:58 <sgw> I have a couple that are going witht he consolidated pull, but I can split them out.
May 26 23:04:09 <RP__> sgw: Er, nitin's bugfix is not a good way to do this
May 26 23:04:23 <RP__> did dropping to v5 for arm not help?
May 26 23:04:30 <nitink> RP__: feel free to change it
May 26 23:04:54 <nitink> RP__ as removing -O2 solved the problem I did not try armv5
May 26 23:05:09 <RP__> nitink: well, this change removes optimisations on mips/ppc/x86
May 26 23:05:16 <RP__> which as far as I know were not broken
May 26 23:05:39 <RP__> Also -O is a brute force method and things like dropping the arch used are much more gentle
May 26 23:06:13 <nitink> RP__: ok, I can see if changing armv5 helps,
May 26 23:06:25 <nitink> RP__: also is there a way to change CFLAGS only for arm ?
May 26 23:06:37 <RP__> nitink: CFLAGS_append_arm ?
May 26 23:06:55 <RP__> nitink: That patch really just doesn't cut it :/
May 26 23:06:56 <nitink> RP__: that would also get the same effect
May 26 23:07:06 <RP__> nitink: Please test v5
May 26 23:07:15 <nitink> RP__: ok will do
May 26 23:09:10 <sgw> RP consulidated pull send (it happens to include this bad patch).
May 26 23:09:14 <sgw> RP__: timing
May 26 23:11:22 <nitink> RP__: I just tried with -march=armv5
May 26 23:11:26 <nitink> and did not get the error
May 26 23:11:45 <nitink> so this would be patch:
May 26 23:11:46 <nitink> CFLAGS_append_arm += " -march=armv5"
May 26 23:14:15 <RP__> nitink: really you want to apply it to the armv7 machines
May 26 23:14:47 <nitink> RP__: not clean what you mean
May 26 23:15:11 <nitink> RP__: do you want to make beagleboard armv5 ?
May 26 23:16:21 <nitink> or do you mean: CFLAGS_append_armv7 += " -march=armv5"
May 26 23:18:05 <RP__> nitink: Really you want something like TARGET_CC_ARCH_pn-mesa-xlib_beagleboard = "-march=armv5 -mfpu=vfp -mfloat-abi=softfp"
May 26 23:18:53 <nitink> RP__: I see, where that line will go ?
May 26 23:19:21 <RP__> nitink: I'm trying to find the best way to do this
May 26 23:19:38 <RP__> nitink: conceptually it should be in tcmode-default.inc with the other toolchain defines
May 26 23:19:49 <RP__> this being a specific workaround for that toolchain combination
May 26 23:20:18 <RP__> it should really manipulate TARGET_CC_ARCH there and change any armv7 for armv5 for the mesa-xlib case
May 26 23:20:46 <nitink> RP__: ok, if you have not already cooked, I will try it out here
May 26 23:21:53 <RP__> TARGET_CC_ARCH_arm_pn-mesa-xlib := "${@'${TARGET_CC_ARCH}'.replace('armv7','armv5')}"
May 26 23:22:00 <RP__> Totally random untested guess
May 26 23:30:13 <nitink> RP__: ok I will give it a test, BTW what does tcmode mean ?
May 26 23:31:03 <RP__> nitink: toolchain mode
May 26 23:32:29 <nitink> good to know :)
May 26 23:37:34 <nitink> RP__: I hope armv5 binaries can run on armv7-a machine (beagleboard)
May 26 23:42:12 <RP__> nitink: they can
May 26 23:42:56 <nitink> I can't do runtime test anyway (don't have beagleboard)
May 26 23:46:08 <nitink> RP__: how about this, it builds mesa-xlib  fine for beagleboard machine
May 26 23:46:20 <nitink> http://git.pokylinux.org/cgit/cgit.cgi/poky-contrib/log/?h=nitin/bugfixes
May 26 23:56:37 <RP__> nitink: You've confirmed it works fine?
May 26 23:56:54 <nitink> RP__: build test done, run test, I can't
May 26 23:57:15 <RP__> nitink: building is better than not building :)
May 26 23:57:23 <nitink> RP__: yes :)
May 26 23:57:48 <RP__> nitink: merged, thanks
May 26 23:58:07 <nitink> RP__: thanks for merging
May 27 00:12:00 <sgw> yuke: ping
May 27 00:18:33 <yuke> sgw: pong
May 27 00:22:49 <sgw> yuke, wanted to check in with you about 1108 since it's a blocker for M1
May 27 00:23:55 <yuke> sgw: ok, i will look @ it now.
May 27 00:24:12 <yuke> sgw: put it as highest priority
May 27 00:25:58 <sgw> yuke: thanks, I have verified it on my machine, I have also started to look at the formfactor/machconf and xorg.conf files, they are correct, so there is either a kernel issue or something with the xserver
May 27 00:25:59 <yuke> sgw: BTW, for the dl issue, i remember you mention you see it in other machine?could i ask help to verify my patch?
May 27 00:26:31 <yuke> sgw: ok, thanks for the info
May 27 00:26:33 <sgw> Please email me a branch, I am going to try a build on the AB machine tonight.
May 27 00:26:45 <yuke> sgw: Ok
May 27 00:28:33 <sgw> yuke, if you need an image with the failure, I have one you can look at to start with, may help may not, it could save time if you don't have an available build
May 27 00:30:14 <yuke> sgw: that should be helpful, can you send me the url?
**** ENDING LOGGING AT Fri May 27 02:59:58 2011

**** BEGIN LOGGING AT Fri May 27 02:59:58 2011
May 27 04:21:58 <sgw> yuke: ping
May 27 05:11:58 <yuke> sgw: pong
May 27 05:18:09 <sgw> yuke: any news one our missing input?
May 27 05:19:55 <yuke> sgw: not yet, still looking
May 27 05:26:26 <sgw> yuke: ok, thanks for taking the time on this issue.
May 27 05:27:26 <yuke> sgw: np. will update you and the bugzilla by today
May 27 05:28:30 <sgw> Ok, thanks
May 27 07:00:15 <yuke> sgw: find the root cause of the x server missing kerboard
May 27 07:01:57 <yuke> sgw: the new xserver use the hotplug, so the old kbd driver is disabled. it requires new config entry using evdev driver in xorg.conf
May 27 07:01:58 <sgw> yuke, great what was it and is it fixable today?
May 27 07:02:20 <yuke> sgw: adding the new entry in xorg.conf will make the keyborad back to work
May 27 07:02:20 <sgw> do the BSP need to be fixed also?
May 27 07:02:30 <yuke> sgw: i think so
May 27 07:02:55 <yuke> if BSP reuse the oe-core xorg conf, then things should be fine
May 27 07:03:01 <sgw> Hard question, why was this not seen when the xserver was updated?
May 27 07:03:42 <sgw> not all BSP do that, so please make sure you send email to oe-core and to tomz1 and dvhart
May 27 07:05:03 <sgw> yuke: great job tracking that down, I will look for a patch in the morning.
May 27 07:05:09 * sgw -> Zzz
May 27 07:05:17 <dvhart> yuke, nice
May 27 07:05:28 <yuke> sgw: my fault. i only try qemu and see the xserver up, and click mouse  to open application
May 27 07:05:47 <yuke> sgw: i should do more test next time when upgrading xserver
May 27 08:15:17 <RP__> morning all
May 27 08:18:08 <JaMa> morning
May 27 08:20:55 <mnemoc> hi, I'm trying to build yocto^Wpoky (git master) on a remote server but it's asking me to install gnome-terminal after building pseudo-native-1.0-r0. can I tell it somehow to just drop me on a shell instead?
May 27 08:23:13 <RP__> mnemoc: There is a variable for that
May 27 08:23:54 <RP__> mnemoc: Look at the TERMCMD and TERMCMDRUN variables
May 27 08:25:10 <mnemoc> RP__: so I can just put /bin/bash there even if it's not the list in local.conf ?
May 27 08:25:30 <RP__> mnemoc: no, you'll need something like screen
May 27 08:25:53 <mnemoc> I'm already inside screen and nesting doesn't work nice :-/
May 27 08:25:54 <RP__> mnemoc: The problem with parallel builds is that multiple builds can want to drop to a shell at the same time
May 27 08:26:01 <mnemoc> ah, ok
May 27 08:30:29 <JaMa> sgw: ping
May 27 08:31:02 <JaMa> sgw: ffc32d6436bcd11bd9a431affb9d2508fdb3992e breaks gnutls-native, because we don't have libcap-native (or I don't have it)
May 27 08:32:24 <JaMa> sgw: and libcap has EXTRA_OEMAKE_virtclass-native but no BBCLASSEXTEND
May 27 08:34:04 <RP__> JaMa: He'll be asleep atm :/
May 27 08:35:38 <JaMa> I have patch adding native to libcap, I'll send it to list after test
May 27 08:35:45 <RP__> JaMa: thanks
May 27 08:36:54 <JaMa> RP__: btw it's going to rebuild a lot again.. and now I'm sure I'm using "basic", should I try with "noop" too?
May 27 08:43:59 <RP__> JaMa: It shouldn't be rebuilding all the time with basic
May 27 08:44:23 <RP__> JaMa: Are you wiping out the build dir and trying to just use the sstate packages?
May 27 08:45:06 <bluelightning> morning all
May 27 08:45:19 <RP__> JaMa: btw, you can write your own siggen.py handler that has the behaviour you desire for variable dependency handling
May 27 08:45:21 <RP__> hi bluelightning
May 27 08:52:11 <JaMa> RP__: no I'm not wiping anything (except tmp/work sometimes)
May 27 08:52:34 <RP__> JaMa: You're 100% sure you're not using basichash?
May 27 08:52:35 <JaMa> RP__: so the checksum changes I listed in that long email are expected behavior of basic or no?
May 27 08:52:38 <JaMa> yes
May 27 08:53:07 <JaMa> I've tried even to remove basichash implementation with same efect
May 27 08:53:19 <RP__> JaMa: The checksums should change and that is expected but that shouldn't force you to rebuild everything
May 27 08:53:58 <RP__> "basic" means use the sstate checksums only when building from sstate but handle the stamps directory as per original OE
May 27 08:54:01 <JaMa> everything like "whatever is below dbus in dependency tree of image" right?
May 27 08:54:22 <RP__> JaMa: yes
May 27 08:54:34 <RP__> but as I said, it should only effect sstate, not an existing build tree
May 27 08:55:35 <JaMa> I'll compare bitbake master to poky bitbake, because only difference I see between basic and basichash is "def stampfile", but that's probably right
May 27 08:56:34 <JaMa> if I understood what you just said then "if the stampfile is the same as before then it shouldn't rebuild it"
May 27 08:58:38 <RP__> JaMa: correct, and basic doesn't include the checksum in the stamp
May 27 09:00:45 <JaMa> so using "basic
May 27 09:01:01 <JaMa> " is also confirmed because I have stamps file like this "tmp/stamps/armv4t-oe-linux-gnueabi/dbus-1.4.1-r4.do_package_write"
May 27 09:02:03 <RP__> JaMa: right. so dbus should have rebuild with a PR bump but not anything else...
May 27 09:12:54 <JaMa> RP__: dry run -n doesn't show them correctly it seems http://paste.pocoo.org/show/396070/
May 27 09:13:30 <JaMa> and now it does build ie shared-mime-info again..
May 27 09:16:08 <JaMa> RP__: I'll send build stats in 2 hours or so when it finishes
May 27 09:20:45 <JaMa> RP__: isn't it because rm_work removes most stamps and then PR change somewhere triggers "evaluation" of stamps for depending recipes and finds out that they are missing?
May 27 09:41:47 <RP__> JaMa: I suspect something is wrong with rm_work, yes
May 27 09:42:23 * JaMa running another build without rm_work
May 27 09:42:26 <RP__> JaMa: Does shr use any unusual classes which add extra tasks or anything/
May 27 09:42:28 <RP__> ?
May 27 09:42:40 <JaMa> then another PR bump and another try
May 27 09:43:05 <RP__> You see its even running glib-2.0 fetch
May 27 09:43:11 <RP__> fetch depends on very very little
May 27 09:43:30 <JaMa> testlab blacklist debian shr-mirrors, only testlab adds task iirc
May 27 09:44:11 <RP__> JaMa: I'm wondering if even bitbake -k shr-lite-image; bitbake -k shr-lite-image would show this
May 27 09:44:25 * RP__ should look at the testlab code
May 27 09:44:31 <JaMa> without PR bump in between? no
May 27 09:45:30 <JaMa> it adds task only to IMAGE_POSTPROCESS_COMMAND so probably cannot cause this
May 27 09:45:44 <RP__> JaMa: no, sounds unlikely
May 27 09:50:13 <JaMa> debian.bbclass also hooks to do_package but probably cannot cause this
May 27 09:51:15 <JaMa> I need to create smaller/faster testcase for this.. then I can add/remove stamps in rm_work and find which one is causing this (if I'll be able to confirm it's caused by rm_work :))
May 27 09:51:47 <RP__> JaMa: poky uses debian.bbclass too and I'm not seeing this
May 27 09:53:01 <RP__> JaMa: ok, I do see this on poky master with rm_work
May 27 09:53:33 <RP__> JaMa: bitbake glib-2.0-native;bump dbus-native PR, bitbake glib-2.0-native and it rebuilds glib-2.0
May 27 09:54:09 <RP__> so this confirms its something to do with rm_work...
May 27 09:54:22 <RP__> and we have a simpler test case
May 27 09:56:36 <JaMa> great /me already not that sad as yesterday evening :)
May 27 09:58:04 <RP__> JaMa: Something is certainly broken as it shouldn't be doing this. Please don't give up on sstate just yet :)
May 27 09:58:52 <JaMa> does *do_setscene* match something? I see only ie do_package_setscene
May 27 09:59:49 <JaMa> it should be retained, but I don't see any *do_setscene* in tmp/stamps...
May 27 10:01:31 <RP__> JaMa: backwards compatibility. It used to exist but we removed it
May 27 10:02:43 <JaMa> ok, another one, cannot we keep do_fetch?
May 27 10:02:45 <RP__> JaMa: I'm not sure this is rm_work at fault :/
May 27 10:03:32 <RP__> JaMa: It you run bitbake -DDD glib-2.0 after bumping the dbus PR, you don't see glib-2.0 listed in the setscene covered tasks
May 27 10:03:36 <JaMa> if do_unpack is first to populate tmp/work from fetched data and rm_work is not cleaning downloads/ dir?
May 27 10:04:50 <RP__> JaMa: If setscene doesn't find the stamps and mark the tasks as covered, nothing else will which is why its rerunning things
May 27 10:05:02 <RP__> bluelightning: I think this is the return of your nemesis :/
May 27 10:05:30 <JaMa> RP__: ah ;/
May 27 10:05:38 <bluelightning> argh :(
May 27 10:05:39 <RP__> JaMa: rm_work is implying the dependency on the sstate checksums
May 27 10:06:37 <JaMa> RP__: there is more weird in this build.. same target once "NOTE: Running task 3758 of 6513" second run "NOTE: Running task 4271 of 4881", why is total count of tasks so different (same MACHINE)..
May 27 10:07:26 <RP__> JaMa: truncated task graph as setscene skipped parts?
May 27 10:08:31 <JaMa> ah
May 27 10:12:05 <JaMa> so worst case I can do with sometimes removing tmp/work (and not using rm_work) is that ie -c compile something will fail because it's not there but expects it unpacked (because of stamp) and sometimes sstate failing because of missing package/packages-split as reported yesterday in #1109 ? or something else move evil?
May 27 10:12:10 <JaMa> more
May 27 10:13:27 <RP__> JaMa: I think there are a variety of messy situations you can end up in :/
May 27 10:14:00 <RP__> JaMa: The intent of the way rm_work was changed was to make it as if the system had been built from sstate packages
May 27 10:14:09 <RP__> Which would just mean one code path to maintain
May 27 10:14:24 <RP__> since building from sstate effectively also means tmp/work is missing
May 27 10:14:32 <RP__> (with some exceptions I know)
May 27 10:16:12 <JaMa> but then you need same sstate checksums as before, right?
May 27 10:16:48 <JaMa> and that's the problem for me.. I have the same stamps but that's not enough with rm_work
May 27 10:18:25 <JaMa> If I stop building in smaller but much faster raid0, used space in tmp/work wouldn't be so big issue, but now I have something like 17G tops and it's also shared for portage builds, so sometimes I need ie 8G free for libreoffice build :)
May 27 10:20:16 <RP__> JaMa: well, we need to at least figure out what the correct behaviour should be here
May 27 10:20:27 <RP__> I can at least see why bitbake is doing what its doing now :/
May 27 10:20:28 <Jay7> JaMa: most loaded part of build is workdir
May 27 10:20:54 <Jay7> you may just bind-mount raid0 to workdir only
May 27 10:21:13 <Jay7> at least it was true for old OE :)
May 27 10:26:07 <bluelightning> RP__: hmm I'm starting to wonder if what I put in earlier was just a band-aid over this issue
May 27 10:26:48 <RP__> bluelightning: I'm just looking at this code and wondering what planet the author was on ;-)
May 27 10:27:43 <bluelightning> hopefully earth, we don't need aliens messing with our code now too
May 27 10:29:43 <RP__> bluelightning: bug #1 with this code is that the valid_new[] bit in runqueue takes no notice of exiting stamp files
May 27 10:30:10 <RP__> The sstate package may not exist but if the stamp does, we should be trusting the stamp
May 27 10:32:48 <JaMa> Jay7: I'm binding only tmp/work
May 27 10:33:32 <Jay7> JaMa: well.. then no easy way out afaik
May 27 10:34:05 <Jay7> I'm sure bitbake task scheduling may be changed WRT rm_work task
May 27 10:34:16 <JaMa> Jay7: I can live with those 2 issues I listed.. so before it's fixed (if it could be fixed) I'll clean tmp/work when needed
May 27 10:35:37 <Jay7> imho, rm_work should be called right after latest package task
May 27 10:35:51 <Jay7> even with latest package task
May 27 10:35:58 <Jay7> (iirc, do_build)
May 27 10:36:10 <JaMa> after do_build finish please
May 27 10:36:32 * JaMa likes -c build when he want's to keep workdir intact
May 27 10:37:52 <Jay7> well, after do_build
May 27 10:38:03 <Jay7> w/o scheduling as for other tasks
May 27 10:38:16 <Jay7> looks like hack :(
May 27 10:38:50 * RP__ has a patch which hacks bitbake to make this roughly work correctly
May 27 10:39:03 <Jay7> one time I've proposed to split fetching, unpacking and  building threads
May 27 10:39:04 * RP__ needs to chase down a few bugs though
May 27 10:39:19 <Jay7> because they are using different resources by different way
May 27 10:39:44 <Jay7> seems now I should propose separate garbage collector :)
May 27 10:39:46 <RP__> and figure out if this really is a good idea
May 27 10:40:52 <RP__> Jay7: I don't see what is special about the rm_work task ;-)
May 27 10:41:26 <RP__> Jay7: You're proposing we write special case logic for every task so we might as well merge bitbake and OE and hardcode all the task logic
May 27 10:41:34 <Jay7> do_fetch is depend on inet/network bandwidth, do_unpack/do_rm_work is depend on hdd i/o bandwidth, do_build is depend on CPU and hdd i/o
May 27 10:41:52 <Jay7> RP__: special thing is scheduling
May 27 10:42:02 <Jay7> I don't know internals
May 27 10:42:23 <RP__> Jay7: We have the scheduler abstracted so you can write your own
May 27 10:42:25 <Jay7> but I'm sure that there is no easy way to 'glue' do_build and do_rm_work :)
May 27 10:42:43 <RP__> Jay7: I'd love to see one which scheduled based on task type and various load indicators
May 27 10:42:54 <Jay7> yeah..
May 27 10:43:56 <RP__> The bitbake schedulers are really really really simplistic. I did it deliberately hoping someone would write a good one
May 27 10:44:08 <RP__> Sadly, people have tried and can't really get better performance :/
May 27 10:44:55 <Jay7> speed is one really used imho
May 27 10:45:09 <Jay7> completion scheduler isn't better
May 27 10:45:13 <RP__> Jay7: and completion with rm_work
May 27 10:45:41 <RP__> completion should keep the disk cache hotter and some have see it faster
May 27 10:45:44 <Jay7> it doesn't help much to save space
May 27 10:45:47 <RP__> Its never faster on my system
May 27 10:46:03 * RP__ would welcome any fixes
May 27 10:46:30 <Jay7> I would happy to do some but I'm not experienced with python enough :)
May 27 10:54:58 <RP__> Jay7: You know I still don't claim to be able to program in python? ;-)
May 27 10:55:12 * JaMa lunch
May 27 10:55:26 <RP__> JaMa: http://tim.rpsys.net/bitbakefix.patch might help you
May 27 10:55:41 <RP__> er, ignore the dbus bit
May 27 11:17:39 <RP__> http://tim.rpsys.net/bitbakefix2.patch is a cleaned up version
May 27 11:32:31 <JaMa> RP__: testing now, fwiw: previous double build without rm_work behaved right (only dbus/dbus-native was rebuilt)
May 27 11:33:10 <RP__> JaMa: makes sense, rm_work changing things to _setscene stamps is the cause of this
May 27 11:33:18 <RP__> JaMa: but I think the bug is in bitbake
May 27 11:48:21 * bluelightning -> work
May 27 11:48:30 <bluelightning> or rather -> office
May 27 13:18:02 * sgw -> office back on around 8:45ish
May 27 13:28:40 <dbire1> Hi All, Please Help! task-poky-boot, error: Failed dependencies:  --> http://paste.ubuntu.com/613760/
May 27 13:37:32 <fray> look at your tmp/deploy/rpm directory.. do you have something called "tinylogin*"?
May 27 13:37:54 <fray> but it does look like your omap5430-evm configuration is broken..
May 27 13:38:13 <fray> it only built for 3 "archs"..  omap5430-evm (machine arch), "all", and "all" again..
May 27 13:38:18 <fray> it's missing the armv... arch
May 27 13:38:49 <fray> this could be a mistake in the way the BSP is configuring its compatible architectures..
May 27 13:39:04 <fray> (sorry, I don't know how to fix it if thats the problem....)
May 27 13:39:52 <dbire1> I have tmp/deploy/rpm/armv7a/tinylogin-1.4-r6.armv7a.rpm
May 27 13:40:11 <fray> ya.. from the log the armv7a was never consulted for the packages to install into the ROOTFS..
May 27 13:40:50 <fray> The variable being consulted is "PACKAGE_ARCHS".
May 27 13:41:18 <fray> that variable should contain, omap5430-evm, armv7a, and all.. (and possibly others)
May 27 13:41:26 <fray> but it appears to contain: omap5430-evm, all and all
May 27 13:42:23 <dbire1> where is the best place to define "PACKAGE_ARCHS".
May 27 13:42:48 <fray> it should be defined either automatically or as part of the BSP.. I'm not sure..  This is outside of the area I normally work on..
May 27 13:43:04 <fray> but the value of PACKAGE_ARCHS is wrong..  if you can figure out why, that will lead you to the solution
May 27 13:44:39 <dbire1> Thank you fray, I have at least a place to start searching :)
May 27 13:45:40 <fray> The definition is:
May 27 13:45:41 <fray> ./conf/bitbake.conf:PACKAGE_ARCHS = "all any noarch ${PACKAGE_EXTRA_ARCHS} ${MACHINE_ARCH}"
May 27 13:46:09 <fray> so it's likely it's getting "all any noarch <blank> omap..."
May 27 13:46:13 <fray> it's the blank that is the problem..
May 27 13:46:46 <fray> in the conf/machine/* is where that is set..  I eleive the omap should use the tune-cortexa8.inc
May 27 13:47:13 <fray> but I'm not sure how to connect the pieces..
May 27 13:58:58 <dbire1> It seems that I was missing PACKAGE_EXTRA_ARCHS += "armv4 armv4t armv5te armv6 armv7 armv7a" - I am progressing :) but  another error -->  http://paste.ubuntu.com/613772/
May 27 14:01:55 <JaMa> RP__: your fix works :) great.. I'll use it for a while to see if there are any unwelcome side-effects, but seems fine sofar
May 27 14:02:02 <fray> lines 40 and 41 are the only true errors
May 27 14:02:31 <fray> 42-49 are actually warnings
May 27 14:02:46 <fray> look for a package named eglibc, do you have one?
May 27 14:03:31 <RP__> JaMa: sounds like a plan. In the meantime I'll clean this and a few other things up for more testing too
May 27 14:06:52 <JaMa> RP__: thanks a lot!
May 27 14:07:19 <JaMa> you're saving me hours and hours literally :)
May 27 14:08:15 <RP__> JaMa: I'm just pleased we've found and fixed it. It certainly shouldn't have been doing that...
May 27 14:15:18 <JaMa> should I reply to my long email with url to your fix or will you?
May 27 14:15:37 <JaMa> you can describe the problem and solution better and with fewer words :)
May 27 14:24:47 <dbire1> fray: yes I have  ./tmp/work/armv7a-poky-linux-gnueabi/eglibc-2.12-r13/
May 27 14:28:44 <RP__> JaMa: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/bb2&id=9fc36a5448ba30d2e557539573b6ec609f34184c
May 27 14:28:59 <RP__> JaMa: I'm trying to clean up all my odd fixes I have lying around...
May 27 14:51:55 <dvhart> is there a way to force a redownload on a failed MD5SUM check?
May 27 14:52:16 <RP__> dvhart: -c cleanall. Its not automated (yet)
May 27 14:52:33 <dvhart> but that's per recipe right?
May 27 14:52:44 <RP__> dvhart: yes. How many did you corrupt?!
May 27 14:52:59 <dvhart> I've had to cleanall about 10 so far
May 27 14:53:05 <dvhart> I hit this periodically
May 27 14:53:18 <RP__> dvhart: proxy corrupting things? interrupted downloads?
May 27 14:53:20 <dvhart> I'll just replace my downloads dir with an empty one
May 27 14:53:25 <dvhart> neither of those
May 27 14:53:43 <RP__> sounds like a bad router or something :/
May 27 14:54:01 <dvhart> possible
May 27 14:54:11 <dvhart> I've hit this both at home and at work
May 27 14:54:28 <RP__> dvhart: You seem ill fated with hardware ;-)
May 27 14:54:40 <dvhart> tis the truth
May 27 14:55:00 <dvhart> although I haven't noticed any other networking issues
May 27 14:55:11 <JaMa> I was wandering if we have enough information to cleanup downloads dir of older version, keep all tar balls, checkouts needed to rebuild from scratch, but delete everything else?
May 27 14:55:55 <RP__> JaMa: rebuild what from scratch is always the question
May 27 14:56:15 <RP__> JaMa: We don't have an easy way to iterate over a list of MACHINEs collecting that data
May 27 14:56:25 <RP__> [or images]
May 27 14:56:34 <bluelightning> I don't think it would be too hard to do though
May 27 14:56:46 <RP__> bluelightning: Its just a mess of corner cases
May 27 14:57:02 <RP__> Certainly possible but very hard to get 100% right
May 27 14:57:22 <bluelightning> surely it would be a case of doing a "fake" fetch where it just returns where it would have saved the file locally
May 27 14:57:30 <JaMa> RP__: ah I see and something like keep everything which has do_fetch stamp and it's highest PV-PR for PN?
May 27 14:58:09 <RP__> JaMa: I'd do it from the metadata - query it for a list of files it would use, then delete anything leftover
May 27 14:58:21 <RP__> bluelightning: getting that piece of information is the trivial bit
May 27 14:58:44 <RP__> Its figuring out that grub only builds for x86 but still is referred to by the metadata for x86 builds
May 27 14:58:54 <JaMa> RP__: with everything in downloads hopefully replacable, it wouldn't be so big problem with few false positives or few leftovers
May 27 14:59:11 <RP__> JaMa: no, it wouldn't be that painful
May 27 14:59:19 <RP__> but I can see the bug reports
May 27 14:59:28 <RP__> Do something well or not at all IMO
May 27 14:59:48 <JaMa> ok, fair enough
May 27 15:01:00 <JaMa> btw: gentoo has eclean-dist which does exactly this and has -p (pretend) param (which can filter few bug reports as user see what will be removed if he confirms it)
May 27 15:04:51 <RP__> JaMa: I'm not against having it but it isn't trivially easy to do
May 27 15:37:55 <nitink> Good Morning All !
May 27 15:41:07 <RP__> hi nitink
May 27 15:41:18 <nitink> hi RP__
May 27 15:41:20 <RP__> nitink: Phil posted a patch for the gcc issue, could you take a look at it please?
May 27 15:41:37 <nitink> RP__: sure, where is the patch
May 27 15:41:50 <RP__> nitink: oe-core mailing list
May 27 15:42:00 <nitink> RP__: ok, looking
May 27 16:38:31 <sgw> bluelightning: ping
May 27 16:38:48 <bluelightning> hi sgw
May 27 16:40:19 <sgw> bluelightning: I have a quick request, could you look at the beagleboard failure of Qt on the autobuilder?  It might be a GCC 4.6 related issue (similar to the what nitink worked on yesterday).
May 27 16:40:56 <nitink> sgw: we might have a fix for gcc 4.6.0
May 27 16:41:26 <sgw> nitink: great news
May 27 16:41:45 <nitink> sgw: I am testing a fix posted by phil
May 27 16:42:05 <otavio> bluelightning: did you look at qt4-native for oe-core?
May 27 16:42:27 <sgw> nitink: Ok, are you building beagleboard?
May 27 16:43:11 <bluelightning> sgw: looking
May 27 16:43:20 <bluelightning> otavio: I haven't yet no, but it's on my list
May 27 16:43:40 <otavio> bluelightning: any ETA?
May 27 16:43:47 <nitink> sgw: I am building mesa-xlib for beagleboard
May 27 16:44:02 <bluelightning> otavio: it's not high on the list I have to admit
May 27 16:44:32 <otavio> bluelightning: this is important to me since I depend on it  to get some missing apps included on my layer
May 27 16:44:42 <otavio> bluelightning: is it possible to move it a little up?
May 27 16:45:17 <bluelightning> I'll see if I can make some time early next week
May 27 16:45:38 <otavio> bluelightning: that would help a lot
May 27 16:46:41 <sgw> nitink: please ensure you build qt4-x11-free also
May 27 16:46:54 <sgw> I want to see if that fixes the autobuilder failure
May 27 16:46:57 <bluelightning> sgw: do you have a pointer to the log of this failure? I always have trouble with the autobuilder's web interface :/
May 27 16:47:04 <nitink> sgw: will do
May 27 16:47:06 <bluelightning> as in, finding stuff
May 27 16:48:21 <sgw> bluelightning: http://autobuilder.pokylinux.org:8010/builders/nightly-external/builds/134/steps/shell_20/logs/stdio, or do you need something else?
May 27 16:52:31 <bluelightning> qatomic_arm.h:361:35: error: output number 1 not directly addressable
May 27 16:52:35 <bluelightning> hmm
May 27 16:52:47 <bluelightning> presumably this is post-update to gcc 4.6.0
May 27 16:54:24 <sgw> bluelightning: yes
May 27 16:55:18 <bluelightning> well I'm not sure what that means, if the stuff that nitin is already working on doesn't fix it (not sure exactly which issue(s) he is looking at) then I will have to dig into it next week
May 27 16:57:39 <nitink> bluelightning: there is a fix for GCC 4.6.0 internal compiler error, which we were working around earlier. I am trying out the fix and see if helps or not
May 27 17:00:14 <sgw> bluelightning: thanks, I might dive into later today if the gcc fix does not address it.
May 27 17:00:24 <sgw> this is a potential blocker for M1
May 27 17:00:39 <nitink> sgw: while building  qt4-x11-free I am getting failure on flex
May 27 17:04:01 <nitink> RP__, sgw: good news: phil's fix does take care of ICE
May 27 17:04:54 <sgw> nitink: what's your flex failure, that's new
May 27 17:05:36 <RP__> nitink: can you package it up and submit it please?
May 27 17:05:37 <nitink> sgw: some rel_* symbols not found
May 27 17:05:48 <nitink> RP__: ok
May 27 17:06:04 <RP__> nitink: it might also be a good one to wave at the gcc people, you could talk to pb_ about getting that back upstream
May 27 17:06:08 <RP__> nitink: he's on #oe
May 27 17:07:22 <nitink> RP__: sure I will work with pb_
May 27 17:08:16 <nitink> sgw: flex may be my env issue
May 27 17:09:05 <nitink> sgw: I will need a build from scratch to get a clean env, too many things happening in my build tree
May 27 17:11:54 <sgw> If you have the patch I can also try a build here
May 27 17:18:28 <nitink> sgw: flex issue is gone now, it was related to my autoconf upgrade stuff
May 27 17:20:58 <sgw> Ok good.
May 27 17:22:17 <nitink> sgw: cleaning up the patch, will send you later
May 27 17:57:39 * nitink qt4-x11-free-4.7.3-r23.1 is taking long time to compile
May 27 17:59:59 <otavio> oe-core is broken
May 27 18:00:14 <otavio> it seems USE_PR_SERV needs to be properly handled
May 27 18:01:13 <nitink> sgw: qt4-x11-free-4.7.3-r23.1 compile succeeded
May 27 18:01:35 <otavio> ahh it fails because xmlrpc cannot be imported
May 27 18:01:41 <otavio> something missing somewhere?
May 27 18:02:23 <sgw> great!
May 27 18:02:28 <sgw> nitink: ^^^
May 27 18:06:43 <sgw> otavio: I will be starting a build of master here shortly (after M1 stuff)
May 27 18:07:02 <otavio> sgw: good
May 27 18:07:18 <otavio> sgw: here it fails to import xmlrpc so seems something is hardly broken
May 27 18:07:23 <otavio> sgw: or a missing depends
May 27 18:07:42 <otavio> ahah
May 27 18:07:49 <otavio> it seems to be xmlrpclib
May 27 18:07:51 <otavio> not xmlrpc
May 27 18:09:09 <otavio> ohh
May 27 18:09:30 <otavio> RP__: did you properly push bitbake changes for prserv? it seems this part is missing
May 27 18:11:46 <otavio> RP__: and USE_PR_SERV = "0" ought to be done in bitbake.conf by now
May 27 18:37:57 <otavio> gosh, this is confusing .. USE_PR_SERV is set to 0 but package classe doesnt see it
May 27 18:38:12 <egonzalez_ergio> dvhart: hi
May 27 19:03:18 <khem> hmmm bitbake seemsto be borking http://pastebin.com/cWfreqg5
May 27 19:46:51 <dvhart> heya egonzalez_ergio
May 27 19:47:38 <dvhart> egonzalez_ergio, how's the bluetooth work going?
May 27 19:52:34 <egonzalez_ergio> hey
May 27 19:52:36 <egonzalez_ergio> I'm here
May 27 19:52:39 <egonzalez_ergio> bop
May 27 19:52:42 <egonzalez_ergio> nop
May 27 19:53:10 <egonzalez_ergio> I'm tryed to modify yours files but don't compile the module
May 27 19:54:24 <egonzalez_ergio> simply ignore me new config
May 27 19:54:27 <egonzalez_ergio> my new
May 27 19:57:25 <egonzalez_ergio> In this way work, obviously: http://sastriawan.blogspot.com/2011/04/linux-kernel-modules-configuration-on.html
May 27 19:59:04 * nitink getting this error: http://pastebin.com/ndTf1hqM any clues ?
May 27 19:59:30 <zeddii> egonzalez_ergio, all of the above that you list there, they work here, I use them everyday. what branch is this on ?
May 27 20:01:38 <nitink> | ERROR: Connecting to PR service None:None failed: int() argument must be a string or a number, not 'NoneType'
May 27 20:01:38 <nitink> | ERROR: Function 'package_get_auto_pr' failed
May 27 20:04:53 <egonzalez_ergio> zeddii: I'm trying to do my distro. For now I want to add bluetooth kernel modules to cor-image-minimal
May 27 20:05:33 <JaMa|Off> also discussed on ML, but your error look a bit different then khem's and koen's
May 27 20:06:31 <zeddii> understood, but a defconfig or a config frag definitely work on bernard and master. I use them daily. is there somewhere I can see where what you tried
May 27 20:09:49 <nitink> JaMa|Off: right, I was checking any way to work around the error, may be I can revert the PRauto commit in my branch
May 27 20:13:37 <nitink> incandescant: any clues on above error ?
May 27 20:14:22 <nitink> maybe I need to recreate local.conf
May 27 20:14:50 * zeddii notes that dvhart didn't see my response before replying to the create a BSP email
May 27 20:15:01 <incandescant> nitink, afraid not
May 27 20:15:23 <incandescant> nitink, as JaMa|Off said that's a different issue to the one on the list
May 27 20:16:48 <nitink> incandescant: can I revert some commit locally to avoid the issue ?
May 27 20:18:44 <incandescant> nitink, I'd guess the PR server changes are the culprit
May 27 20:20:48 <nitink> incandescant: reverting the PR service commits, got me going :)
May 27 20:24:58 <incandescant> nitink, you should definitely file a bug to track your issue though ;-)
May 27 20:26:03 <nitink> incandescant: I have many of my patches in the tree, so not sure is it the problem with master tree or not
May 27 20:32:12 <incandescant> nitink, if you get a chance it'd be nice if you could verify
May 27 20:32:28 <nitink> invandescant: will do
May 27 20:34:20 <nitink> sgw: all the gettext patches will be mared like this, right? Upstream-Status: Inappropriate [licensing]
May 27 20:34:38 <sgw1> Ok
May 27 22:15:51 <RP__> fray: Are you arguing for or against adding that patch to gcc?
May 28 00:59:24 <mgross> bitbake grub (TARGET_ARCH=X86_64) returns ERROR: Nothing PROVIDES 'grub' ????
May 28 00:59:37 <mgross> how do debug?
May 28 00:59:58 <mgross> I know grub_0.97.bb is getting parsed
May 28 01:14:10 <nitink> mgross: I think you need meta-intel layer
May 28 01:17:36 <mgross> I'll give that a try.
May 28 01:18:00 <mgross> but I'm starting to look at the bitbake python and I want to know how I would aproach debugging this driectly?
May 28 01:18:49 <mgross> nitink: meta-intel-contrib ?
May 28 01:19:47 <mgross> got it.
May 28 01:19:57 <mgross> what branch should I try? bernard?
May 28 01:20:15 <nitink> mgross: http://git.pokylinux.org/cgit/cgit.cgi/meta-intel/
May 28 01:20:23 <nitink> master should be good
May 28 01:20:36 <nitink> and keep it inside poky.git
May 28 01:21:05 <nitink> and update your bblayers.conf to include that layer, and you can look at sugerbay machine, how it is using grub
May 28 01:21:27 <nitink> barnard: should be better branch
May 28 01:21:33 <nitink> and master would be latest one
May 28 01:21:57 <nitink> mgross: if you don't want latest stuff then go for bernard
May 28 01:24:10 <mgross> trying ...
May 28 01:25:04 <mgross> so why would this make grub show up?  I know its in the poky base tree.
May 28 01:25:16 <mgross> (still buildling BTW)
May 28 01:28:02 <mgross> hmm.  grub_1.98 is in the meta-intel/common/recipes-bsp
May 28 01:29:20 <mgross> the bb file for the grub2 recipie doesn't look different enough to explain the problem with the older version of grub not working.
May 28 01:30:05 <mgross> but its nice to see it building and not dumping a python stack any more.
May 28 01:32:47 <nitink> mgross: not sure why the one in poky.git is not working
May 28 01:33:11 <mgross> FWIW the one in poky works ok for i386.
May 28 01:33:33 <mgross> it just hates x86_64 target_arch
May 28 01:34:02 <mgross> I would like to know how to debug that issue though. Any debugging tips?
May 28 01:35:13 <mgross> found it!
May 28 01:36:01 <mgross> there is a bug in bitbake that fails to print out an execption message that gets raised in the grup_0.97.bb file.
May 28 01:36:14 <mgross> if not re.match('i.86.*-linux', host):
May 28 01:36:21 <mgross>         raise bb.parse.SkipPackage("incompatible with host %s" % host)
May 28 01:37:21 <mgross> line 28 of poky/meta/recipes-bsp/grub/grub_0.97.bb
May 28 01:46:20 <nitink> mgross: looks like that is old code before x86-64 was added
May 28 01:52:10 <mgross> yup.  now I'm digging into bitbake for why it can't report skipped recipies ;)
May 28 01:52:28 <mgross> thank you for getting me past the orriginal issue!!!
May 28 01:52:59 <nitink> mgross: np
**** ENDING LOGGING AT Sat May 28 02:59:57 2011

**** BEGIN LOGGING AT Sat May 28 02:59:57 2011
May 28 08:23:16 <JaMa|Off> moin, bitbake -b seems broken now :/
May 28 08:45:24 <JaMa> RP__: I've found the issue with debian.bbclass and allarch, do you have a sec?
May 28 09:43:24 <JaMa> RP__: added that info to bug #1075
**** ENDING LOGGING AT Sun May 29 02:59:58 2011

**** BEGIN LOGGING AT Sun May 29 02:59:58 2011
May 29 11:20:43 <dcordes> hi
**** BEGIN LOGGING AT Sun May 29 18:06:11 2011
May 30 02:17:49 <sgw1> jiajun: ping
May 30 02:17:59 <jiajun> sgw1: pong
**** ENDING LOGGING AT Mon May 30 02:59:59 2011

**** BEGIN LOGGING AT Mon May 30 02:59:59 2011
**** ENDING LOGGING AT Mon May 30 18:58:39 2011

**** BEGIN LOGGING AT Mon May 30 19:00:15 2011
May 30 19:07:52 <egonzalez_ergio> hi
May 30 19:08:24 <egonzalez_ergio> I have  aproblem with identification ofa  kernel module
May 30 19:08:42 <egonzalez_ergio> kernel-module-hci-usb
May 30 19:08:58 <egonzalez_ergio> this is btusb.ko?
**** ENDING LOGGING AT Mon May 30 20:11:13 2011

**** BEGIN LOGGING AT Mon May 30 20:12:15 2011
**** BEGIN LOGGING AT Tue May 31 07:34:15 2011
**** BEGIN LOGGING AT Tue May 31 07:48:14 2011
May 31 14:03:47 <RP__> zenlinux: FWIW you were on the right track with do_install but nativesdk is the wrong direction :)
May 31 14:05:48 <otavio> RP__: it seems I got it doing it right
May 31 14:06:05 <otavio> RP__: I am now testing the build off extensions using it
May 31 14:06:06 <RP__> otavio: cool
May 31 14:27:15 <otavio> RP__: now to use the tool, at the cross path, what var I use?
May 31 14:30:32 <jefferai> Hello there. I'm targeting a beagleboard and although I know that there are some precooked instructions for it on the wiki, I was hoping to get the experience of doing a full build, but I'm running into some issues, or quite possible simply things I don't quite understand
May 31 14:31:02 <jefferai> the first is that in my local.conf I have "MACHINE =?? "qemux86", which I understand to be the default; then later overridden with MACHINE ?= "beagleboard"
May 31 14:31:19 <jefferai> but when I run the build for sato it spits out information that makes it seem like it's building for x86
May 31 14:31:52 <otavio> Now I am stuck about calling the tool
May 31 14:31:57 <otavio> I did it as:
May 31 14:31:57 <otavio> NOTE: Calling: /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/bin/i586-oe-linux/chicken-install -debug -r slice:1.0
May 31 14:32:00 <otavio> sh: /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/bin/i586-oe-linux/chicken-install: No such file or directory
May 31 14:32:03 <otavio> mv: cannot stat `slice': No such file or directory
May 31 14:32:27 <otavio> the file /home/.../i586-oe-linux/chicken-install does exist
May 31 14:40:54 <jefferai> ah, here is the output:
May 31 14:40:55 <jefferai> TARGET_ARCH       = "i586"
May 31 14:40:55 <jefferai> TARGET_OS         = "linux"
May 31 14:40:55 <jefferai> MACHINE           = "qemux86"
May 31 14:41:25 <jefferai> so I'm not sure why the target arch is showing as i586 when I selected beagleboard as the machine
May 31 14:41:32 <jefferai> or in fact why qemux86 is showing up as the machine
May 31 14:43:04 <jefferai> ah, interesting - commenting out the "MACHINE ??= qemux86" line worked
May 31 14:43:19 <jefferai> but from the text, it looks like that should be a default only if nothing else is selected below that
May 31 15:10:37 <zenlinux> can anyone suggest to me a stable commit to use for building master?
May 31 15:10:57 <zenlinux> I tried rebasing my branch to master last night and it failed due to some license-related issues.
May 31 15:11:09 <zenlinux> I backed up to just before those commits and now it's complaining about the PR service being invalid
May 31 15:14:48 <otavio> zenlinux: 83ce96f44516c8a4a44c8c0140949256f8422014 works for me (oe-core)
May 31 15:15:37 <zenlinux> tnx otavio
May 31 15:20:13 <RP__> jefferai: Sounds like its not picking up that configuration
May 31 15:20:32 <RP__> jefferai: Maybe strace it and check which local.conf is being picked up?
May 31 15:20:55 <otavio> RP__: give me a tip ... when I want to use a cross tool, how I do to setup the LD_LIBRARY_PATH and like?
May 31 15:21:05 <otavio> RP__: I didn't find how it is done for gcc
May 31 15:21:19 <RP__> otavio: You shouldn't have to touch it
May 31 15:21:31 <otavio> RP__: just call the app?
May 31 15:22:21 <RP__> otavio: yes
May 31 15:22:31 <jefferai> RP__: if I remove that ??= bit, then my setting of beagleboard does get successfully picked up
May 31 15:23:17 <RP__> jefferai: hmm, that doesn't sound right...
May 31 15:23:25 <RP__> jefferai: could be a bug :/
May 31 15:23:31 <jefferai> yeah
May 31 15:23:37 <jefferai> it's ok, for now it's building beagleboard
May 31 15:23:41 <jefferai> but that brings me to my next question
May 31 15:23:46 <jefferai> so building these recipes gives me tons of packges
May 31 15:23:54 <jefferai> what I don't see from the documentation I've looked through so far
May 31 15:24:04 <jefferai> is how to turn all that into a distro that I can actually run
May 31 15:24:12 <RP__> jefferai: which kind of documentation are you looking for?
May 31 15:24:16 <jefferai> how I get from that build step to booting my beagleboard with it
May 31 15:24:47 <RP__> jefferai: "bitbake XXX" generates an image in deploy/images/ which you use on the device
May 31 15:24:54 <jefferai> oh
May 31 15:25:15 <jefferai> ok, then there's some other disconnect -- I thought that bitbake simply created various sets of packages
May 31 15:25:22 <RP__> It we can make the clearer somewhere please let us know where
May 31 15:25:25 <jefferai> so sato generates everything needed for sato; qt generates the qt libs; etc.
May 31 15:25:57 <RP__> jefferai: package targets just build packages, image targets build the packages and then combine them into an image
May 31 15:26:15 <RP__> jefferai: and yes, dependencies are handled
May 31 15:26:15 <jefferai> ah
May 31 15:29:13 <jefferai> RP__: okay, so I see that poky-image-sato is in meta-recipes-sato/images
May 31 15:30:01 <jefferai> but, I also see poky-image-clutter, poky-image-(base, core, directdisk, minimal, etc)
May 31 15:30:50 <jefferai> so if I wanted to have some subset of packages installed, would I e.g. use poky-image-sato as a base, and modify the defined necessary packages?
May 31 15:32:51 <jefferai> or would I create a new class?
May 31 15:33:48 <nitink> Good morning All !
May 31 15:38:23 <jefferai> basically it's not clear to me where you go and start customizing things to build the custom distribution you want; do I create classes that inherit from some other class, and then image recipes that use those classes? Do I have to modify tasks? If I modify recipes, do I need to create poky-image-(minimal, minimal-dev, base, core, directdisk, live, initramfs, etc.)?
May 31 15:39:03 <jefferai> I guess I can see how you could do it basing off of what's there, but I'd like to do things the "right way", for easier future upgrades if nothing else
May 31 15:39:47 <jefferai> (one reason I'm interested in this is if I e.g. end up targeting machines with older/lesser hardware than the beagleboard and need to strip things down quite a bit)
May 31 15:46:32 <RP__> jefferai: You can take an existing image definition and add/remove things, or copy it to your own image .bb file and make changes. This is documented in the reference manual?
May 31 15:48:16 <jefferai> RP__: yeah -- I see how to do it, just looking for the "right" way -- for instance, modifying an existing definition might be hard to upgrade from later. But -- would I be right in thinking that you can use e.g. IMAGE_FEATURES -= , not just IMAGE_FEATURES += ?
May 31 15:49:01 <RP__> jefferai: Currently we don't have a -= operator. You'd therefore normally come up with your own IMAGE_FEATURES line
May 31 15:49:13 <bluelightning> jefferai: re actually getting stuff onto your beagleboard, FYI there's README.hardware that contains some info on actually booting the new image
May 31 15:51:00 <bluelightning> jefferai: we are working on improving the documentation around customisation (well, I say we, it's mostly Scott R)
May 31 15:51:00 <jefferai> bluelightning: yep, saw that -- I just wanted to try doing it with my own image instead of using a pre-built one
May 31 15:51:21 <jefferai> but I've seen http://www.yoctoproject.org/download/bsp/texas-instruments-arm-cortex-a8-development-board-beagleboard
May 31 15:51:32 <jefferai> so I understand (I think!) how to actually get the image there once it's generated
May 31 15:51:42 <jefferai> I just wasn't clear on the process of generating custom images
May 31 15:51:47 <jefferai> but I think I'm getting an idea
May 31 15:52:08 <jefferai> there's just a lot of things that inherit from other recipes/definitions/tasks etc. and getting an idea of the flow takes a bit of getting used to
May 31 15:52:27 <jefferai> I dont' suppose it's possible to have an "overlay" of configuration inside build/conf ?
May 31 15:52:53 <RP__> jefferai: it is, any file in there will replace the core conf files
May 31 15:52:54 <jefferai> that way I don't have to keep track of what in the yocto bernard directory was originally there and what is mine
May 31 15:53:32 <RP__> jefferai: There is a pretty powerful concept of "layers" in use which contain customisations
May 31 15:53:40 <jefferai> that's good to hear
May 31 15:53:52 <jefferai> so inside conf, I would create a meta/ directory and then follow the directory structure?
May 31 15:55:10 <RP__> jefferai: I specifically mentioned conf files (and it applies to class files). For the .bb files and recipes themselves you'll need to create your own layer
May 31 15:55:45 <RP__> jefferai: Its not hard and there is documentation (for example the bsp guide has layer information in it)
May 31 15:55:58 <jefferai> ah, ok -- so build/conf overrides meta/conf, and build/classes overrides meta/classes ?
May 31 15:57:16 <RP__> jefferai: yes
May 31 15:58:47 <jefferai> looking in conf/layer.conf, it looks like to create a custom layer I would export LAYERDIR from my local.conf, and populate files in there?
May 31 16:03:14 <RP__> jefferai: Add an entry to conf/bblayers.conf pointing to somewhere with a layer.conf
May 31 16:03:29 <jefferai> ah, ok
May 31 16:22:15 <bluelightning> dvhart / tomz1: FYI I've found a problem with the way BBFILE_COLLECTIONS is being added to in meta-intel
May 31 16:22:59 <bluelightning> at least for me here bitbake does not detect e.g. crownbay in the list of collections; I'm guessing it's some kind of subtlety with "_append_crownbay +="
May 31 16:24:00 <tomz1> bluelightning: hmm, maybe I should just remove the _append_crownbay
May 31 16:24:27 <bluelightning> tomz1: perhaps, I'm not sure... I'd love to understand why it doesn't work
May 31 16:24:42 <bluelightning> I can see why you would want to do it that way
May 31 16:25:01 <tomz1> bluelightning: same here, but it seems to be causing problems for no good reason
May 31 16:25:45 <bluelightning> currently I think the only consequence is that files from those layers don't get any priority assigned
May 31 16:25:55 <tomz1> bluelightning: it worked for me, so I don't know how to reproduce at this point
May 31 16:26:49 <tomz1> bluelightning: anything to do with the recent priority fix e.g. being ignored
May 31 16:27:07 <bluelightning> BBFILE_COLLECTIONS doesn't affect the contents of BBFILES so you wouldn't notice any build issue unless you hit bug #1125, but that's due to some missing priority sorting anyway
May 31 16:30:18 <tomz1> bluelightning: ok, so can you file a new bug for the crownbay with info on reproducing and I'll look into it
May 31 16:31:57 <otavio> RP__: OK; it seems that I got it further but ..
May 31 16:31:58 <otavio> | NOTE: chicken_install: SRC_URI seems to be empty, assuming official Chicken egg
May 31 16:31:59 <otavio> | NOTE: Calling: i586-oe-linux-chicken-install -debug -r slice:1.0
May 31 16:31:59 <otavio> | sh: /home/otavio/hacking/el/tmp-eglibc-eglibc/sysroots/x86_64-linux/usr/bin/i586-oe-linux/i586-oe-linux-chicken-install: No such file or directory
May 31 16:32:01 <otavio> | ERROR: Function 'chicken-install failed to run' failed
May 31 16:32:49 <bluelightning> tomz1: actually thinking about it I know why it doesn't work... at the point we figure out collections (which is before the parsing stage) we don't know what MACHINE is, therefore the overrides haven't been applied
May 31 16:33:01 <otavio> RP__: any idea about what missing file can be?
May 31 16:34:27 <tomz1> bluelightning: ok, so we can't select based on machine at that point, so we have to just use the one in any case
May 31 16:34:41 <bluelightning> tomz1: I think so
May 31 16:35:03 <tomz1> bluelightning: ok, simple enough - I'll submit a patch to do that
May 31 16:35:15 <bluelightning> thanks
May 31 16:35:33 <tomz1> bluelightning: thanks for reporting it and pointing out the problem
May 31 19:48:56 <egonzalez_ergio> hi
May 31 19:50:14 <egonzalez_ergio> I have zlib in IMAGE_INSTALL
May 31 19:50:44 <egonzalez_ergio> when I make the image zlib compile ok but in do_rootfs
May 31 19:50:57 <egonzalez_ergio> | Processing zlib...
May 31 19:50:58 <egonzalez_ergio> | Unable to find package zlib!
May 31 19:51:21 <khem> egonzalez_ergio: IMAGE_INSTALL will take the package name not recipe name
May 31 19:52:05 <egonzalez_ergio> mmm
May 31 19:52:58 <egonzalez_ergio> this is teh recipe: meta/recipes-core/zlib/zlib_1.2.5.bb
May 31 19:53:22 <egonzalez_ergio> how I find package name?
May 31 19:53:43 <khem> egonzalez_ergio: look in the DEPLOY_DIR
May 31 19:53:50 <egonzalez_ergio> ok
May 31 19:56:10 <egonzalez_ergio> mmm
May 31 19:56:16 <egonzalez_ergio> [emiliano@emiliano deploy]$ find ./ -name *zlib*
May 31 19:56:18 <egonzalez_ergio> ./licenses/zlib
May 31 19:56:19 <egonzalez_ergio> ./licenses/zlib/zlib.h
May 31 19:56:21 <egonzalez_ergio> ./licenses/zlib-native
May 31 19:56:22 <egonzalez_ergio> ./licenses/zlib-native/zlib.h
May 31 19:56:24 <egonzalez_ergio> ./rpm/core2/python-zlib-2.6.6-nk1.4.core2.rpm
May 31 19:56:25 <egonzalez_ergio> ./rpm/core2/perl-module-compress-zlib-5.12.3-r0.core2.rpm
May 31 19:56:27 <egonzalez_ergio> ./rpm/core2/perl-module-io-compress-zlib-extra-5.12.3-r0.core2.rpm
May 31 19:56:28 <egonzalez_ergio> ./rpm/core2/perl-module-compress-raw-zlib-5.12.3-r0.core2.rpm
May 31 19:56:30 <egonzalez_ergio> ./rpm/core2/perl-module-io-compress-zlib-constants-5.12.3-r0.core2.rpm
May 31 19:56:31 <egonzalez_ergio> ./rpm/core2/perl-module-io-zlib-5.12.3-r0.core2.rpm
May 31 19:56:33 <egonzalez_ergio> ./rpm/atom_pc/kernel-module-zlib-deflate-2.6.37+git1+79669230fd82a3e7e254cf8b596a2388a4333e62_1+79d6188d99bdf63da9a0ba27c010792266e337f9-r18.atom_pc.rpm
May 31 19:56:34 <egonzalez_ergio> ./rpm/qemux86/kernel-module-zlib-deflate-2.6.37+git1+79669230fd82a3e7e254cf8b596a2388a4333e62_1+b2afed7ecd54918b73db7f30062aaaf02fdaba54-r18.qemux86.rpm
May 31 19:56:36 <egonzalez_ergio> ./rpm/i586/perl-module-compress-raw-zlib-5.12.3-r0.i586.rpm
May 31 19:56:37 <egonzalez_ergio> ./rpm/i586/perl-module-io-zlib-5.12.3-r0.i586.rpm
May 31 19:56:39 <egonzalez_ergio> ./rpm/i586/perl-module-compress-zlib-5.12.3-r0.i586.rpm
May 31 19:56:40 <egonzalez_ergio> ./rpm/i586/python-zlib-2.6.6-nk1.3.i586.rpm
May 31 19:56:42 <egonzalez_ergio> ./rpm/i586/perl-module-io-compress-zlib-extra-5.12.3-r0.i586.rpm
May 31 19:56:43 <egonzalez_ergio> ./rpm/i586/perl-module-io-compress-zlib-constants-5.12.3-r0.i586.rpm
May 31 19:56:52 <khem> Dont paste crap here
May 31 19:56:55 <khem> use pastebin
May 31 19:57:04 <egonzalez_ergio> oops
May 31 19:57:09 <egonzalez_ergio> true...
May 31 19:57:13 <egonzalez_ergio> excuseme
May 31 19:57:32 <khem> these channels are logged
May 31 19:57:39 <khem> keep them small
May 31 19:57:54 <egonzalez_ergio> http://pastebin.com/uQ0qMh0A
May 31 19:58:20 <egonzalez_ergio> there are not a zlib package
May 31 19:58:31 <khem> yes it did not get built
May 31 19:58:48 <khem> since there is no dependency on it
May 31 19:59:54 <egonzalez_ergio> http://pastebin.com/eJVzKge0
May 31 20:00:14 <egonzalez_ergio> zlib is created
May 31 20:02:26 <khem> do bitbake zlib
May 31 20:04:01 <egonzalez_ergio> http://pastebin.com/x53CBCch
May 31 20:04:15 <egonzalez_ergio> deploy]$ find ./ -name *zlib*  ->  same result
May 31 20:06:41 <egonzalez_ergio> I have ./tmp/sysroots/atom-pc/usr/include/zlib.h
May 31 20:06:48 <egonzalez_ergio> but not a zlib package!
May 31 20:11:09 <khem> hmm
May 31 20:12:46 <egonzalez_ergio> what is teh differnce about zlib and zlib-native?
May 31 20:26:50 <dvhart> egonzalez_ergio, -native is used by your build system, zlib is installed on the target
May 31 20:28:19 <egonzalez_ergio> then...is not necessary to unstall zlib in IMAGE_INSTALL?
May 31 20:29:18 <khem> egonzalez_ergio: if some package needs it then it will be pulled in automatically
May 31 20:29:42 <khem> egonzalez_ergio: if not and you still want it then you have to add it to IMAGE_INSTALL
May 31 20:33:32 <egonzalez_ergio> ok... I don't know if some package now needs zlib but I'm sure that a future programe (writed by me) will nedd zlib and I want to add now the library
May 31 20:49:57 <khem> egonzalez_ergio: if a future progam does then add zlib to its DEPENDS
May 31 20:50:22 <khem> and when you install your programs package on the device it will suck in zlib automagikally
May 31 20:50:31 <khem> as required runtime dependency
May 31 20:50:53 <khem> provided you have your feeds setup right
May 31 20:51:43 <egonzalez_ergio> txs
May 31 21:56:25 <RP__> zenlinux: How are base-passwd and base-passwd-cross different?
May 31 22:10:29 <zenlinux> RP__, was on the phone, back
May 31 22:11:41 <zenlinux> RP__, base-passwd-cross includes a default login.defs file and has to jump through hoops to get the default sysconfdir files into the sysroot
May 31 22:12:29 <RP__> zenlinux: I'm wondering if that would be better set as an option in the recipe which triggers the core to do the sysconfdir files
May 31 22:13:43 <zenlinux> RP__, also, base-passwd-cross needs the SSTATEPOSTINSTFUNCS workaround to make sure things work from sstate
May 31 22:13:53 <zenlinux> my opinion is that these are enough changes to keep the recipe separate
May 31 22:14:54 <RP__> zenlinux: This doesn't quite fit the meaning of "cross" :/
May 31 22:15:11 <RP__> cross things are things which are compiled to run on the build system but emit binaries for the target
May 31 22:15:56 <RP__> This is a passwd-base recipe with hacks to install in the target sysroot which is something very different
May 31 22:16:14 <zenlinux> sure, no disagreement there
May 31 22:17:09 <RP__> zenlinux: I'm not sure why the base-passwd recipe can't do these things in its sysroot task
May 31 22:17:10 <zenlinux> RP__, do you think the target sysroot changes could simply be a side effect of building the normal base-passwd recipe?
May 31 22:17:26 <RP__> zenlinux: I'm thinking it would then be clearer what's going on
May 31 22:17:48 <zenlinux> RP__, ok, I see your viewpoint. I can look into this
May 31 22:18:11 <RP__> zenlinux: We have gone to some lengths to keep the sysroot and target device in sync
May 31 22:18:28 <RP__> where there are differences, spelling it out clearly in the one target recipe seems a neater way to make the difference clear
May 31 22:34:58 * zenlinux -> afk for a bit
Jun 01 00:03:30 <egonzalez_ergio> hi
Jun 01 00:03:44 <egonzalez_ergio> there are somebody
Jun 01 00:03:46 <egonzalez_ergio> :-)
Jun 01 00:04:38 <egonzalez_ergio> I'm trying to compile a recipe that needs C++ compiler. What is it's DEPENDS?
Jun 01 00:17:57 <zenlinux> egonzalez_ergio, you can view a graphical dependency explorer with bitbake -g -u depexp <recipe name>
Jun 01 00:18:44 <zenlinux> unless you're asking what DEPENDS you need to add to a recipe to build a c++ project?
Jun 01 00:20:17 <zenlinux> in which case, I don't think you need to add anything special
Jun 01 00:23:41 <egonzalez_ergio> the recipe is mine. Im trying to add xerces and need c++
**** ENDING LOGGING AT Wed Jun 01 02:59:56 2011