**** BEGIN LOGGING AT Tue Aug 24 02:59:57 2010
Aug 24 03:04:43 <khem> Crofton|work: I think it treats it as file
Aug 24 03:04:49 <khem> I mean single fie
Aug 24 03:04:53 <khem> file
Aug 24 03:05:41 <khem> Crofton|work: are you in bay area ?
Aug 24 03:18:33 <porcoesphino> hey, anyone around to answer a stupid question I should probably know the answer to?
Aug 24 03:19:11 <khem> ask
Aug 24 03:19:14 <porcoesphino> I am making an image and the package-dev tarball doesn't seem to be getting installed.
Aug 24 03:19:31 <khem> package-dev ?
Aug 24 03:19:44 <khem> do you mean dev packages are not installed ?
Aug 24 03:19:53 <porcoesphino> yeah
Aug 24 03:20:00 <porcoesphino> package was a placeholder
Aug 24 03:20:17 <porcoesphino> more specifically, the opencv libraries are not being installed
Aug 24 03:20:22 <Crofton|work> khem, I was, but just got home
Aug 24 03:20:27 <khem> only packages which have dependencies 
Aug 24 03:20:31 <khem> will be added
Aug 24 03:20:47 <porcoesphino> but opencv-dev is not something that seems to like being added to the image
Aug 24 03:20:49 <Crofton|work> khem, it should copy entire directory
Aug 24 03:20:51 <khem> Crofton|work: oh. wud have been good to meet up in person
Aug 24 03:20:55 <Crofton|work> it certainly did at one point
Aug 24 03:21:02 <khem> Crofton|work: did it work that way before ?
Aug 24 03:21:02 <Crofton|work> yeah, but I was swamped
Aug 24 03:21:08 <Crofton|work> I'll be back though
Aug 24 03:21:10 <Crofton|work> not sure when
Aug 24 03:21:28 <khem> let me know I andy and you can meet :)
Aug 24 03:21:35 <khem> that will be US OEDEM :)
Aug 24 03:22:06 <porcoesphino> khem. I'm doing: DEPENDS += "opencv", IMAGE_INSTALL += "opencv". Should I be doing something else?
Aug 24 03:22:29 <khem> yes
Aug 24 03:22:36 <porcoesphino> dammit >< :P
Aug 24 03:22:37 <khem> IMAGE_INSTALL += "opencv-dev"
Aug 24 03:22:43 <porcoesphino> ha
Aug 24 03:22:54 <porcoesphino> but the depends is fine?
Aug 24 03:23:13 <khem> where are you adding depends
Aug 24 03:23:38 <porcoesphino> hmm...
Aug 24 03:23:58 <porcoesphino> in the same recipe, just above my addition to IMAGE_INSTALL
Aug 24 03:24:14 <porcoesphino> wait a sec.. I'll what is it paste bin? it.
Aug 24 03:24:24 <Crofton|work> heh, still sort of on left coast time
Aug 24 03:24:27 <khem> you dont need that
Aug 24 03:24:28 <Crofton|work> bedtime
Aug 24 03:24:36 <porcoesphino> ha
Aug 24 03:24:36 <khem> Crofton|work: gn
Aug 24 03:24:39 <porcoesphino> nice to know :P
Aug 24 03:32:13 <porcoesphino> khem: this is what I do now. Anything odd in there? http://pastebin.com/tBTg7hmj
Aug 24 03:32:54 <porcoesphino> it was working fairly well when opencv-dev was missing and I had MY_PACKAGES also included in the DEPENDS +=
Aug 24 03:33:36 <porcoesphino> it's building the runqueue now, so it looks like it's all good, but any pointers on stupid things I'm doing is always appreciated :P
Aug 24 04:18:36 <porcoesphino> alright..
Aug 24 04:18:58 <porcoesphino> so, opencv splits up into packages based on each lib file
Aug 24 04:19:17 <porcoesphino> I can do: opkg install libopencv-highgui2.1
Aug 24 04:19:39 <porcoesphino> but I can't do IMAGE_INSTALL += "libopencv-highgui2.1"
Aug 24 04:19:43 <porcoesphino> why's this?
Aug 24 04:22:19 <porcoesphino> and thanks for that before khem. It worked well for opencv-dev
Aug 24 04:30:58 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r7be4d74e1b 10openembedded.git/recipes/openmoko-3rdparty/om-neon_svn.bb: 
Aug 24 04:30:58 <CIA-2> om-neon: bump PR to rebuild .edj
Aug 24 04:30:58 <CIA-2> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Aug 24 05:00:41 <porcoesphino> Hmm... it looks like it was RDEPENDS
Aug 24 05:00:42 <porcoesphino> cheers
Aug 24 05:25:08 <likewise> gm
Aug 24 05:26:10 <ka6sox-work> morning
Aug 24 05:36:59 <Noor> eFfeM_work: Hi
Aug 24 05:37:38 <Noor> eFfeM_work: yesterday you asked me to submit one patch of uicmoc4-native recipe
Aug 24 05:37:56 <Noor> does Patch 1/2 and Patch 2/2 work
Aug 24 05:38:11 <Noor> do I have to sumbit both patches in one email?
Aug 24 05:42:07 <likewise> Noor: it's still a bit early, so be patient :-)
Aug 24 05:51:50 <Noor> OK. Thanks likewise 
Aug 24 06:04:14 <likewise> bbiab
Aug 24 06:15:35 <eFfeM_work> gm
Aug 24 06:16:29 <eFfeM_work> Noor: haven't tested the uicmoc4-native patches, but as they are related and have the same subject line I'd say it should be one patch that patches boht files
Aug 24 06:17:05 <eFfeM_work> (& hi likewise; you're on early)
Aug 24 06:20:57 <Noor> so when PATCH n/m option is used
Aug 24 06:21:15 <eFfeM_work> Noor: don't understand your question
Aug 24 06:21:48 <eFfeM_work> btw out of curiosity: where fahad and you live ?
Aug 24 06:22:04 <Noor> I mean I saw some email with subject [Patch 1/3] and [Patch 2/3]
Aug 24 06:22:13 <Noor> In Pakistan
Aug 24 06:22:15 <Noor> :)
Aug 24 06:22:28 <Noor> and where are u from
Aug 24 06:22:32 <eFfeM_work> netherlands
Aug 24 06:22:44 <Noor> ahan
Aug 24 06:23:17 <eFfeM_work> patch 1/2 is if it is a set of mildly related patches (e.g. because they are too big alone or still make sense separately)
Aug 24 06:23:44 <Noor> OK
Aug 24 06:24:02 <eFfeM_work> this happens if there is an order needed but the binding is weak; I'ev also seen it if someone just send unrelated patches
Aug 24 06:24:05 <Noor> and if some thing is not sesible in seperate patches then it should be in one email
Aug 24 06:24:19 <eFfeM_work> btw so you are probably a few hrs ahead of us; i'm at gmt+2
Aug 24 06:24:33 <Noor> we are GMT + 5
Aug 24 06:27:54 <eFfeM_work> khem, (if you are still awake & online): were you able to reproduce the 4.4.4 problem?
Aug 24 06:33:13 <Noor> eFfeM_work: just sent u an email for review
Aug 24 06:33:21 <eFfeM_work> ok
Aug 24 06:33:43 <Noor> the combined patched will look like this or you want something else
Aug 24 06:46:31 <eFfeM_work> the inc_pr one is fine 
Aug 24 06:47:00 <Noor> is there any way of emiiting patches in one file from format-patch
Aug 24 06:47:15 <Noor> i used --stdout option and redirected output to a file
Aug 24 06:47:24 <Noor> is there any other way
Aug 24 06:48:17 <eFfeM_work> don't know what you mean; I just make changes in both files, then do a git add, then a git commit ; then git format-patch -1
Aug 24 06:48:29 <eFfeM_work> that will generate a file 0001-.....
Aug 24 06:48:37 <eFfeM_work> which can then be send by git send-email
Aug 24 06:48:54 <Noor> OK
Aug 24 07:24:00 <dv> gays, I have problem with mkfs.jffs2 in OE
Aug 24 07:24:11 <dv> it gets SIGABRT
Aug 24 07:26:59 <hrw> hi
Aug 24 08:09:14 <fahad_usman> morning eFfeM_work
Aug 24 08:09:23 <eFfeM_work> hi fahad
Aug 24 08:11:10 <fahad_usman> remember i was having problem with target recipes
Aug 24 08:11:26 <fahad_usman> i was getting some assembler error
Aug 24 08:11:33 <fahad_usman> i finally resolved it
Aug 24 08:12:43 <fahad_usman> i chenged the MACHINE = "om-gta01"
Aug 24 08:12:53 <fahad_usman> instead of MACHINE = "beagleboard"
Aug 24 08:13:37 <eFfeM_work> hm, this is strange, seems you have a toolchain issue; om-gta01 perhaps uses a different compiler
Aug 24 08:14:55 <fahad_usman> and if i change the machine backe to beaglegboard, i start getting the same error again
Aug 24 08:15:36 <JaMa|GoNe> isn't beaglebord armv7 while gta01 is armv4?
Aug 24 08:15:42 <fahad_usman> so, should i continue working with om-gta01?
Aug 24 08:16:01 <fahad_usman> beagleboard is arm v7, not sure about om-gta01
Aug 24 08:16:14 <eFfeM_work> that is an option, but in the end it is probably better to rebuild from scratch
Aug 24 08:16:20 <eFfeM_work> (e.g. during lunch or overnight)
Aug 24 08:17:20 <eFfeM_work> i have not seen issues with asm errors for beagleboard
Aug 24 08:17:33 <soltys> fahad_usman: om-gta01 is armv4t afair
Aug 24 08:17:44 <JaMa|GoNe> yes it is
Aug 24 08:20:24 <fahad_usman> the error i get is 
Aug 24 08:20:25 <fahad_usman> NOTE: Running task 381 of 539 (ID: 9, /home/fahad/systemBuilder/oe-git/openembedded/recipes/lemon/lemon_3.5.4.bb, do_compile) ERROR: function do_compile failed ERROR: log data follows (/home/fahad/systemBuilder/oe-git/build/tmp/work/armv7a-angstrom-linux-gnueabi/lemon-3.5.4-r0/temp/log.do_compile.518) | Assembler messages: | Fatal error: Invalid -march= option: `armv7-a' NOTE: Task failed: /home/fahad/systemBuilder/oe-git/build/tmp/
Aug 24 08:34:15 <florian> good morning
Aug 24 08:38:39 <eFfeM_work> fahad_usman: your armv7 toolchain is broken, if you want to keep using beagleboard as target, rebuild !
Aug 24 08:49:55 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rfc5b0d4eb8 10openembedded.git/recipes/linux/ (linux/spitz/defconfig linux_git.bb): 
Aug 24 08:49:55 <CIA-2> linux-git: upgrade SRCREV to 2.6.32-rc2
Aug 24 08:49:55 <CIA-2> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Aug 24 08:50:06 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r6e2f24717f 10openembedded.git/recipes/linux/linux-openmoko-2.6.34_git.bb: 
Aug 24 08:50:06 <CIA-2> linux-openmoko-2.6.32: upgrade to 2.6.32.5
Aug 24 08:50:06 <CIA-2> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Aug 24 10:52:55 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r2fd903f4f6 10openembedded.git/conf/machine/hawkboard.conf: hawkboard: tweak ubifs params
Aug 24 11:21:18 <Jin^eLD> huhu
Aug 24 12:42:14 <GNUtoo|laptop> hi, I want to do the equivalent of that for a machine:
Aug 24 12:42:47 <GNUtoo|laptop> GTK_IM_MODULE=xim all_gtk_apps
Aug 24 12:42:57 <GNUtoo|laptop> in what config file should I set that
Aug 24 12:43:07 <GNUtoo|laptop> my device has an hardware keyboard
Aug 24 13:41:23 <Crofton|work> has the DRC_URI behavior for file changed?
Aug 24 13:41:48 <Crofton|work> used to be if you gave it a directory, the contents of the directory where copied in
Aug 24 14:55:03 <Crofton|work> kergoth_, 
Aug 24 14:55:08 <Crofton|work> the line in question
Aug 24 14:55:20 <Crofton|work> SRC_URI = "file:///home/balister/src/git/linux-omap-2.6-export \
Aug 24 14:58:27 <khem> Crofton|work: it seems you can also use srctree for what you are trying
Aug 24 14:59:54 * kergoth_ tests
Aug 24 15:00:19 <hrw> Jin^eLD: alive?
Aug 24 15:00:30 <Jin^eLD> yes
Aug 24 15:00:36 <hrw> Jin^eLD: where do you live?
Aug 24 15:00:37 <Jin^eLD> hi
Aug 24 15:00:40 <Jin^eLD> Austria, Vienna
Aug 24 15:01:12 <hrw> Jin^eLD: postcode?
Aug 24 15:01:18 <Jin^eLD> 1040
Aug 24 15:01:23 <Jin^eLD> but well, Vienna is tiny anyway
Aug 24 15:01:46 <Jin^eLD> or are you checking mail service .pl -> .at?
Aug 24 15:02:44 <hrw> Jin^eLD: that APP Primer which you want is packed in large packs. 6 cans of 1st + 12 cans of hardener
Aug 24 15:03:02 <Jin^eLD> oh crap..
Aug 24 15:03:06 <hrw> Jin^eLD: so ~10 kg package
Aug 24 15:03:21 <Jin^eLD> so they don't sell it in smaller amounts?
Aug 24 15:03:36 <Jin^eLD> actually I was hoping that they could point you to local resellers
Aug 24 15:03:43 <hrw> Jin^eLD: not directly, but will call them
Aug 24 15:04:24 <Jin^eLD> at least I think that in .pl one should be able to easily buy this brand in a local store
Aug 24 15:06:58 <hrw> you have a luck - there is local shop which has APP products
Aug 24 15:07:18 <Crofton|work> kergoth_, I swear it used to work :)
Aug 24 15:07:30 <Crofton|work> I triple checked my spelling
Aug 24 15:07:45 <kergoth_> i know it did, at one point
Aug 24 15:08:16 <Crofton|work> yeah
Aug 24 15:08:26 <Crofton|work> it is from a bb file that "used" to work
Aug 24 15:08:31 <Crofton|work> brb
Aug 24 15:12:27 <GNUtoo|laptop> hi, does someone knows how to add that in oe:
Aug 24 15:12:35 <GNUtoo|laptop> GTK_IM_MODULE=xim
Aug 24 15:13:04 <GNUtoo|laptop> where should I put that or something with the same effect
Aug 24 15:13:05 <GNUtoo|laptop> ?
Aug 24 15:15:32 <Jin^eLD> hrw: cool! :)
Aug 24 15:16:08 <Jin^eLD> hrw: in austria it's very difficult to get such things, because only stores for "professional use" have that kind of stuff, and there it's extremely expensive
Aug 24 15:16:44 <GNUtoo|laptop> Jin^eLD, ?
Aug 24 15:16:56 <GNUtoo|laptop> jtag?
Aug 24 15:17:12 <Jin^eLD> GNUtoo|laptop: no, car paint stuff :))
Aug 24 15:17:19 <GNUtoo|laptop> ah ok
Aug 24 15:17:38 <GNUtoo|laptop> lol....I'm too much computer/free software/embedded oriented
Aug 24 15:17:45 <Jin^eLD> hehe
Aug 24 15:21:57 <hrw> Jin^eLD: does it have to be app?
Aug 24 15:22:52 <Jin^eLD> hrw: well, the brands that I can get here are like twice or three times expensive
Aug 24 15:23:08 <hrw> Jin^eLD: bad luck. local shop does not sell that kind of APP products ;(
Aug 24 15:23:30 <Jin^eLD> in .pl there is also Novol which should be OK, but I did work with this APP primer and I know it's good, no idea about the other ones..
Aug 24 15:24:11 <hrw> ;(
Aug 24 15:25:30 <Crofton|work> lunch
Aug 24 15:25:47 <Jin^eLD> :(
Aug 24 15:31:22 <zub> hi
Aug 24 15:31:48 <zub> got a guestion about patchwork... looking at some of my patches that are rotting there, I see two things I submitted patches for were fixed independently
Aug 24 15:31:55 <zub> what should I set in patchwork then?
Aug 24 15:34:18 <hrw> applied, archived
Aug 24 15:35:34 <zub> well, the change is in OE, but it's not from my patch
Aug 24 15:35:55 <hrw> so superseded,archived
Aug 24 15:36:02 <zub> ok, thanks
Aug 24 16:00:01 <kergoth_> hmm, forgot about that bug
Aug 24 16:00:16 <kergoth_> try to bitbake foo when foo is in ASSUME_PROVIDED, it hangs after the runqueue generation, rather than exiting
Aug 24 16:22:52 <eFfeM> hi
Aug 24 16:23:01 <GNUtoo|laptop> hi
Aug 24 16:23:20 <eFfeM> khem did you by any chance manage to reproduce the problem, or is more info needed ?
Aug 24 16:24:11 <kergoth_> grr
Aug 24 16:26:56 <pb_> kergoth_: quite
Aug 24 16:29:33 <CIA-2> 03Noor Ahsan <noor_ahsan@mentor.com> 07org.openembedded.dev * rf36fb215be 10openembedded.git/recipes/sgml-common/sgml-common-native_0.6.3.bb: (log message trimmed)
Aug 24 16:29:33 <CIA-2> sgml-common-native: Convert to new style staging, remove do_stage()
Aug 24 16:29:33 <CIA-2> * Converted do_stage to do_install
Aug 24 16:29:33 <CIA-2> * Replaced ${STAGING_BINDIR_NATIVE} with ${D}${bindir}, ${sysconfdir} with ${D}${sysconfdir}, ${STAGING_DATADIR} with ${D}${datadir}.
Aug 24 16:29:33 <CIA-2> * Updated install-catalog script. it had hard coded reference to ${sysconfdir}. Changed it to ${D}${sysconfdir}.
Aug 24 16:29:33 <CIA-2> * Used SYSROOT_PREPROCESS_FUNCS to add a function sgml_common_native_mangle.
Aug 24 16:29:34 <CIA-2> * Write new function sgml_common_native_mangle function.
Aug 24 16:29:44 <CIA-2> 03Noor Ahsan <noor_ahsan@mentor.com> 07org.openembedded.dev * r167ad00f38 10openembedded.git/recipes/sgml-common/sgml-common-native_0.6.3.bb: 
Aug 24 16:29:44 <CIA-2> sgml-common-native: Run oe-stylize.py and updated the recipe accordingly
Aug 24 16:29:44 <CIA-2> * Run oe-stylize.py on the recipe and updated the recipe according to the output of oe-stylize.py
Aug 24 16:29:44 <CIA-2> * Remove FILESDIR variable
Aug 24 16:29:44 <CIA-2> Signed-off-by: Noor Ahsan <noor_ahsan@mentor.com>
Aug 24 16:51:45 <Crofton> how does srctree work ....
Aug 24 17:02:29 <kergoth_> if the recipe in question doesn't use BBCLASSEXTEND, and has no -native/-cross/etc, or you only inherit srctree in one variant, then its safe to just point S=/path/to/sourcetree and SRC_URI=""
Aug 24 17:02:45 <kergoth_> the danger is that tasks of multiple variants could run in the same source tree, interleaved
Aug 24 17:02:50 <kergoth_> so srctree merges the tasks
Aug 24 17:03:05 <kergoth_> you only need srctree if that's an actual danger for you
Aug 24 17:03:11 <kergoth_> otherwise you can just set S/SRC_URI and go
Aug 24 17:03:19 <kergoth_> but thats the concept :)
Aug 24 17:06:31 <Crofton|work> ah
Aug 24 17:06:32 <Crofton|work> heh
Aug 24 17:06:55 <Crofton|work> cbrake, examlples lackes the SRC_URI
Aug 24 17:12:39 <cbrake> Crofton|work: must not need them :-)
Aug 24 17:13:08 <cbrake> Crofton|work: in srctree.bbclass: SRC_URI = ""
Aug 24 17:13:29 <Crofton|work> yes, but how do the recipes know where the source is?
Aug 24 17:13:52 <cbrake> the source is assumed to be the same location as the *.bb?
Aug 24 17:13:55 <cbrake> Crofton|work: looking ...
Aug 24 17:13:59 <Crofton|work> ah
Aug 24 17:14:07 <Crofton|work> I am using the full path
Aug 24 17:14:17 <cbrake> Crofton|work: yes: S = "${FILE_DIRNAME}"
Aug 24 17:14:37 <cbrake> Crofton|work: so basically, the location of your source needs to be in the bbpath
Aug 24 17:14:59 <cbrake> Crofton|work: there may be some way to point srctree at a directory outside bbpath, but I have not tried that
Aug 24 17:15:06 <Crofton|work> hopefully S="/full/path/to/source" works ....
Aug 24 17:15:07 <kergoth_> hm?
Aug 24 17:15:10 <kergoth_> just point S at the path
Aug 24 17:15:16 <kergoth_> it only defaults to the dir the recipe is in
Aug 24 17:15:16 <kergoth_> yeah
Aug 24 17:15:18 <Crofton|work> we'll know
Aug 24 17:15:19 <kergoth_> that'll work fine
Aug 24 17:15:24 <Crofton|work> I had to kill of tmp :(
Aug 24 17:15:44 <kergoth_> also, bbpath isn't how bitbake finds recipes, anyway :P
Aug 24 17:16:15 <cbrake> kergoth_: its not?
Aug 24 17:16:25 <kergoth_> no.
Aug 24 17:16:32 <kergoth_> recipes are found using BBFILES, the way they always have been
Aug 24 17:16:47 <kergoth_> bbpath is only used for require/include and locating classes and config files and the like
Aug 24 17:16:57 <cbrake> kergoth_: ahh, yes -- BBPATH is only for conf, etc
Aug 24 17:17:02 <kergoth_> yep
Aug 24 17:17:12 <cbrake> ok, thanks for the clarification
Aug 24 17:17:27 <kergoth_> now whats really biting me in the ass is upstream git repositories with crappy tags making GITVER useless
Aug 24 17:17:43 <kergoth_> seeing the ref relative to 'cvs-readonly' is not particularly useful for a PV
Aug 24 17:18:15 <cbrake> kergoth_: nod, would it help to have an option to only used annotated tags?
Aug 24 17:18:28 <kergoth_> not particularly, in this case that tag is annotated
Aug 24 17:18:32 <kergoth_> which is fucking stupid if you ask me, but..
Aug 24 17:18:35 <cbrake> kergoth_: :-(
Aug 24 17:18:42 <kergoth_> and git descirbe can't accept a list of refs to consider or a pattern or anything
Aug 24 17:18:44 <kergoth_> its all or nothing
Aug 24 17:18:48 <kergoth_> grr
Aug 24 17:37:12 <dv>  I have troubles with mkfs.jffs2 build by OE. it gets SIGABRT while creating image. somebody know anything about it?
Aug 24 17:48:00 <likewise> dv: how can we reproduce your problem?
Aug 24 17:52:04 <likewise> eFfeM: good evening
Aug 24 17:55:10 <eFfeM> hi likewise, how are you doing? you were online early this morning 
Aug 24 17:57:52 <likewise> eFfeM: expected an early delivery (>= 6h30) and had trouble sleeping already, so I got up early indeed.
Aug 24 17:58:24 <eFfeM> ah ok, not used to see you so early :-)
Aug 24 17:58:37 <likewise> eFfeM: many cleanup proposals from you recently, seems you are doing the dirty work in OE... cleaning up the left-over mess.
Aug 24 18:00:39 <eFfeM> yup,although not everyone appreciates it :-( guess those are the people with a large attic or shed to store everything eventually someone somewhere might use. Then again most responses are positive :-)
Aug 24 18:14:36 <dv> dear likewise, you can build linux for sam91 using OE and see when you're making "bitbake base-image" you'll get the errors
Aug 24 18:17:30 <likewise> dv: what is your host system, and what other options should be in the local.conf?
Aug 24 18:19:32 <dv> host system is Mandriva 2010 pp, I already succesfully build a jffs2 image for powerpc440 ml507 before. but for AT91SAM - can't
Aug 24 18:19:55 <dv> local.conf have IMAGE_FSTYPES = "jffs2 tar.bz2"
Aug 24 18:20:05 <dv> MACHINE ?= "at91sam9m10g45ek"
Aug 24 18:20:53 <dv> in short words, I did everithyng recommended in http://www.at91.com/linux4sam/bin/view/Linux4SAM/OpenEmbeddedAngstromBuild#Getting_OpenEmbedded
Aug 24 18:21:30 <dv> if I switch jffs2 off - everything is ok. but I need to have jffs2 as root filesystem
Aug 24 18:21:36 <Crofton|work> khem, ping
Aug 24 18:21:48 <kergoth_> argh
Aug 24 18:22:57 <CIA-2> 03Stefan Schmidt <stefan@datenfreihafen.org> 07org.openembedded.dev * rbdf185ef3f 10openembedded.git/recipes/linux/linux-omap-hah_2.6.31.bb: linux-omap-hah_2.6.31: Add kernel recipe for bug20
Aug 24 18:23:08 <CIA-2> 03Stefan Schmidt <stefan@buglabs.net> 07org.openembedded.dev * r5e939bfffe 10openembedded.git/conf/machine/bug20.conf: bug20.conf: Remove note about kernel not in OE yet
Aug 24 18:23:40 <kergoth_> m4 git requires gperf to build? what the hell?
Aug 24 18:29:24 <likewise> dv: could you run git log -n1 in your OpenEmbedded checkout?
Aug 24 18:30:07 <likewise> kergoth_: what distro?
Aug 24 18:30:36 <dv> commit b78fc95424b5f0fb28246e8c61bb8b4d6a9d733a
Aug 24 18:30:37 <kergoth_> distro?
Aug 24 18:30:38 <dv> Author: Henning Heinold <h.heinold@tarent.de>
Aug 24 18:30:39 <dv> Date:   Mon Jul 12 13:29:16 2010 +0200
Aug 24 18:30:49 <kergoth_> no, i'm saying m4 upstream git requires gperf to build, and there's no option to disable it
Aug 24 18:30:58 <dv> and 5 more strings
Aug 24 18:31:07 <kergoth_> not oe's m4 :)
Aug 24 18:34:11 <likewise> kergoth_: ah :-)
Aug 24 18:42:06 <likewise> dv: that is a non-default OpenEmbedded setting, you probably extracted the tar file over the OpenEmbedded GIT checkout?
Aug 24 18:42:29 <likewise> dv: "For demo root filesystems available in the GettingStarted page, we used the following commit ID : a646269c2ada7691d8a7f7455ba4528c7cca3483 . The stable/2009 branch should be stable enough to be able to build using those instructions even with a more recent HEAD for this branch. "
Aug 24 18:42:52 <likewise> dv: did you check that specific checkout with the given tar file?
Aug 24 18:42:52 <dv> yes, I'm using additional .bb files from SAM91.com
Aug 24 18:43:14 <likewise> dv: ok, that explains why the MACHINE is not present in OE.
Aug 24 18:43:41 <dv> no, thay (SAM91) have special settings and recipes to build some SAM-specific kernel patches and GUI enviroment
Aug 24 18:43:54 <likewise> dv: is there someone who made those modifications/add-ons who you can ask? I'ld like to help you, but not with something that is out of my reach (out of OE).
Aug 24 18:44:27 <likewise> dv: if I spend time looking for the bug, I want to be able to fix it. Otherwise, it's time wasted for me.
Aug 24 18:45:01 <dv> they have no irc ior any other messangers. and my question is just about mkfs.jffs2 that gts SIGABRT somehow
Aug 24 18:45:59 <likewise> dv: there must be something (very?) specific why it doesn't work with you, as JFFS2 is quite commonly used in OE.
Aug 24 18:46:20 <likewise> dv: the keywords in are "just" and "somehow" :-)
Aug 24 18:46:26 <dv> I'm surprized too!
Aug 24 18:46:44 <GNUtoo|laptop> does someone know where I should ask for the integration of something like that in oe or SHR:
Aug 24 18:46:52 <GNUtoo|laptop> GTK_IM_MODULE=xim
Aug 24 18:47:00 <GNUtoo|laptop> should I send a mail?
Aug 24 18:48:51 <dv> likewise, it gets some patches for jffs2 from openzaurus
Aug 24 18:50:00 <dv> and
Aug 24 18:50:03 <dv> EXTRA_IMAGECMD_jffs2 = "--pad --little-endian --eraseblock=0x20000 -n"
Aug 24 18:59:24 <eFfeM> should .so file end up in a package ? if so which one? the regular one or e.g. a -dev package ?
Aug 24 19:03:56 <dv> eFfeM, is your question for me?
Aug 24 19:07:07 <likewise> eFfeM: regular
Aug 24 19:19:38 <eFfeM> dv, no, likewise, thanks 
Aug 24 19:19:48 <eFfeM> i thought they would be picked up automatically
Aug 24 19:26:40 <likewise> eFfeM: nope, DEPENDS on .so packages are picked up automatically. 
Aug 24 19:36:00 <khem> gm
Aug 24 19:42:29 <khem> hmmm one common issue when converting do_staging to new sysrooted style staging is that sometimes recipes installed a tool in cross bindir in do_staging
Aug 24 19:42:55 <khem> but now its hard to make that possible as the sysroot for cross and target packages are different
Aug 24 19:43:14 <khem> so one can not put it in do_install or something like that 
Aug 24 19:43:26 <khem> has anyone found a solution for this issue
Aug 24 19:43:44 <khem> e.g. one can look into do_stage of wxwidgets/wxbase_2.8.9.bb
Aug 24 19:44:30 <khem> ln -sf ${STAGING_LIBDIR}/wx/config/${TARGET_PREFIX}base-ansi-release-2.8 ${STAGING_BINDIR_CROSS}/wx-config
Aug 24 19:44:44 <khem> how would one achieve that in new staging
Aug 24 19:45:19 <khem> I wish we could generate target cross and build-host specific ipks from single recipe 
Aug 24 19:45:57 <khem> well BBCLASSEXTEND is for build-host specific 
Aug 24 19:46:32 <khem> I feel that having a new cross recipe for creating that symlink only is an overkill
Aug 24 19:48:14 <kergoth_> non-cross recipes shouldn't be installing in cross.
Aug 24 19:54:29 <Crofton|work> srctree + linux.inc fight
Aug 24 19:54:30 <likewise> khem: wx-config runs on the build host, but generates output for the target, I presume?
Aug 24 19:54:34 <Crofton|work> over the defconfig
Aug 24 19:54:48 <likewise> Crofton|work: who wins?
Aug 24 19:54:48 <Crofton|work> linux.inc really wants it to end up in ${WROK}
Aug 24 19:54:55 <Crofton|work> not me
Aug 24 19:55:05 <likewise> Crofton|work: hmm sounds like oe.
Aug 24 19:55:18 <likewise> we never win
Aug 24 19:56:47 <khem> likewise: yes
Aug 24 19:56:49 <RP__> khem: STAGING_BINDIR_CROSS is part of the target sysroot in poky iirc
Aug 24 19:57:13 <khem> RP__: ok and does it do the right think when staged
Aug 24 19:58:09 <khem> RP: I see that its pointing to right staging area
Aug 24 19:59:03 <RP__> khem: I think I handled it in binconfig.bbclass in the end
Aug 24 19:59:03 <khem> my question is will it install it correctly if I do something like do_install_append(){ ln -sf ${STAGING_LIBDIR}/wx/config/${TARGET_PREFIX}base-ansi-release-2.8 ${STAGING_BINDIR_CROSS}/wx-config}
Aug 24 19:59:32 <khem> RP: OK prolly I need to inherit that in the recipe then
Aug 24 19:59:41 <RP__> khem: Create ${D}${bindir}/wx-config and binconfig.bbclass should pick it up
Aug 24 20:00:04 <RP__> Grr, that class is searching ${S}
Aug 24 20:00:19 <khem> RP: ${D}${bindir}/wx-config would be for target isnt it
Aug 24 20:00:44 <RP__> khem: Right, I was thinking binconfig.bbclass would then notice it though
Aug 24 20:00:48 <khem> alright the symlink does not matter as long as it points to right script
Aug 24 20:01:03 <khem> RP__: ok
Aug 24 20:01:10 <khem> I think we need to solve this problem 
Aug 24 20:01:14 <RP__> khem: Look at the libtool recipes in Poky
Aug 24 20:01:51 <RP__> Those show an example of creating BINDIR_CROSS scripts
Aug 24 20:02:04 <RP__> I think it would be good to find a nicer way
Aug 24 20:02:23 <RP__> e.g. Listing scripts that should be symlinked to the crossscripts directory in a new cariable?
Aug 24 20:02:26 <RP__> variable
Aug 24 20:03:42 <khem> RP__: you mean SYSROOT_PREPROCESS_FUNCS var
Aug 24 20:04:25 <khem> hmmm thats one way ok
Aug 24 20:05:25 <khem> I think synlinking two staging areas is not good. a copy of its own is better
Aug 24 20:06:30 <RP__> khem: Remember that in poky, STAGING_BINDIR_CROSS is STAGING_BINDIR/crossscripts 
Aug 24 20:06:55 <RP__> so the symlink would just be ../foo
Aug 24 20:07:05 <RP__> but poky does run separate copies I think at the moment
Aug 24 20:07:35 <khem> why did you change its meaning ?
Aug 24 20:07:41 <khem> to STAGING_BINDIR/crossscripts
Aug 24 20:08:03 <khem> in OE it points to where cross tools are living which is semantically correct
Aug 24 20:08:27 * khem needs food 
Aug 24 21:23:40 <ant_> khem: heh..found another nest of wasps like klibc recipe?
Aug 24 21:29:09 <khem> ant_: OE has much more yes
Aug 25 02:01:18 <jessie> hi there, i having issue build the angstrom-gnome-image, in particular the networkmanger is failing do_configure due to an inability to locate iptables.  I have checked and the iptables package is being built.  I was wondering if anyone has recently built the angstrom-gnome-image and had any similar problems?
**** ENDING LOGGING AT Wed Aug 25 02:59:57 2010