**** BEGIN LOGGING AT Fri May 15 02:59:58 2009
May 15 03:04:43 <kergoth> man, there are so many things i want to improve about bitbake and OpenEmbedded that i have no idea where to begin half the time
May 15 03:05:24 <kergoth> not that its bad, it's the best solution out there imo, just always room to improve
May 15 03:05:25 <kergoth> heh
May 15 03:07:40 <denix0> :)
May 15 03:11:54 <denix0> kergoth: ok, those changes seem to work: freeze.inc included after local.conf and freeze.inc creates weak assignment versions.conf files
May 15 03:12:42 <kergoth> okay, cool.  will have to do a bunch more test builds with it that way
May 15 03:12:42 <kergoth> thanks
May 15 03:13:01 <denix0> no problem, I'll keep testing as well
May 15 06:18:19 <Tartarus> heh
May 15 06:30:42 <rkirti> is conf/checksums.ini expected to have the checksum for every possible package ? and does it do a linear search in that file each time ?
May 15 06:38:49 <akheron> yes, but the search algorithm depends on ConfigParser implementation, I assume
May 15 06:39:22 <akheron> If it uses python dicts then there's a hashtable behind the scenes
May 15 06:41:09 <mckoan> good morning
May 15 06:51:59 <rkirti> akheron: ok. thanks
May 15 07:05:59 <akheron> rkirti: the search algorithm doesn't really matter, though, since the whole checksums.ini file is read in every time
May 15 07:07:48 <rkirti> akheron: ouch.
May 15 07:09:13 <akheron> in do_fetch
May 15 08:13:09 <ant_work> XorA: morning
May 15 08:14:09 <XorA> hey ant_work 
May 15 08:14:17 <ant_work> XorA: I almost finished kexec-tools_2.0.0. I adapred the patches.
May 15 08:14:44 <XorA> ant_work: heh and just as I fixed v1 :-)
May 15 08:15:02 <XorA> ant_work: BTW linux-kexecboot 2.6.24 is too old for the new toolchain
May 15 08:16:45 <ant_work> about this...kexec-static.patch seems not in therecipes
May 15 08:19:01 <XorA> ant_work: feel free to kill off orphoned patches
May 15 08:19:14 <ant_work> iirc size was 112kb
May 15 08:21:55 <ant_work> XorA: this did not apply, so I added -nostdinc. Necessary?
May 15 08:21:57 <ant_work> -PCFLAGS += $(call cc-option, -fnostdinc)
May 15 08:21:59 <ant_work> +PCFLAGS += $(call cc-option, -nostdinc)
May 15 08:22:37 <ant_work> (new purgatory/Makefile)
May 15 08:25:50 <XorA> ant_work: is likely I shall now abandon zaurus work for good, Im got a sheeva to play with
May 15 08:26:03 <ant_work> good luck ;)
May 15 08:26:26 <ant_work> I'll wait for 2nd generation hw
May 15 08:26:26 <XorA> I dont actually use the tosa, so unlike my previous zauruses it just sits on the desk turned off
May 15 08:31:18 <ant_work> XorA: you mean the devices renaming in recent kernels?
May 15 08:31:38 <ant_work> root= problem?
May 15 08:31:39 <XorA> ant_work: no, I mean linux 2.6.24 wont compile with gcc 4.3.3
May 15 08:31:53 <ant_work> ah, 'cause there is another issue...
May 15 08:32:15 <ant_work> using old kexecboot kernel and newest 2.6.29+ kernel
May 15 08:32:24 <ant_work> device names can differ
May 15 08:32:37 <XorA> for spitz?
May 15 08:32:54 <ant_work> http://www.hentges.net/irclogs/%23kexecboot/2009/May/20090513_kexecboot.log
May 15 08:33:52 <XorA> linux-rp has a hack to always make internal drive hda, its correct letter is hdc
May 15 08:34:02 <XorA> just find and restore that hack
May 15 08:43:12 <ant_work> XorA: pxa_cf_initorder_hack-r1 is already in SRC_URI
May 15 08:44:15 <XorA> ant_work: but does it still do what its supposed to
May 15 08:46:53 <XorA> ant_work: no its not
May 15 08:47:24 <ant_work> XorA: best is to ship kernels in pair
May 15 08:47:55 <XorA> ant_work: you need to do some work on 2.6.29+2.6.30 to pull in the needed patches like that that are not suitable for mainline
May 15 08:48:27 <ant_work> pavelm said most patches are not needed anymore 
May 15 08:48:44 <ant_work> I have yet to look in depth
May 15 09:03:17 <XorA> ant_work: well obviosuly the ide order one is :-)
May 15 09:03:27 <XorA> ant_work: but it will never go mainline
May 15 09:03:43 <XorA> ant_work: the only other way to fix the problem is to use device labels or UIDs
May 15 09:03:55 <XorA> then it doesnt matter what physical device is used
May 15 09:07:42 <zecke> RP: ping?
May 15 09:10:13 <XorA> ant_work: and start supporting tosa as well :-D
May 15 09:11:24 <ant_work> XorA: there are already Dmitry and Yuri :)
May 15 09:14:22 <ant_work> XorA: btw I can now read the partitions in nand. I have to minimize the includes and hope all builds small and static against klibc
May 15 09:15:25 <XorA> cool
May 15 09:15:27 <ant_work> there are tree locations to peek: 4+4+4 bytes (sys, ro,rw)
May 15 09:16:23 <ant_work> XorA: I 'm testing on SL-C860...other models have different address
May 15 09:16:30 <ant_work> I'll need confirmations ;-)
May 15 09:29:17 <pb___> hi ant_work 
May 15 09:29:22 <pb___> hi zecke 
May 15 09:31:07 <pb___> hi florian 
May 15 09:32:02 <florian> hi all
May 15 09:36:43 <hrw> morning
May 15 09:39:26 <florian> hi hrw 
May 15 09:49:13 <florian> hrw: What is the latest wisdom for emulating an N800 with qemu?
May 15 09:51:14 <hrw> florian: my blog posts is what I used. did not tried with other versions
May 15 09:51:37 <florian> hrw: ok
May 15 09:51:46 <hrw> florian: I basically ended n8x0 use. my n810 works now as music player when my daughter goes to sleep
May 15 09:52:11 <florian> :-)
May 15 09:54:09 <XorA> hrw: you should have used gta01 for that :-)
May 15 09:54:27 <hrw> XorA: gta01 do not stay for so long on battery
May 15 09:54:38 <hrw> XorA: and show me usable music player for it
May 15 10:12:52 <mckoan> I'm preparing a KaeilOS/OE presentation, is it correct to say that OE was initially create on February 2003 by Holger Schurig?
May 15 10:14:43 <mckoan> or would be better to keep it generic like "It was created by merging the achievements of OpenZaurus with contributions of projects like Familiar Linux"
May 15 10:15:10 <florian> Don't mention Familiar ;)
May 15 10:15:35 <mckoan> florian: are they so un-familiar ? :-D
May 15 10:16:00 <florian> mckoan: It needs to die... :)
May 15 10:20:37 <zecke> RP: do you remember why cache.py:sync is doing a deepcopy?
May 15 10:21:12 <XorA> Familiar is (tm) but a not a very pleasent bloke
May 15 10:21:19 <XorA> s/but/buy/
May 15 10:25:31 <hrw> mckoan: I do not know what would be about OE beginning
May 15 10:26:05 <hrw> mckoan: and OE was created by OZ hackers. Familiar joined much later
May 15 10:27:18 <mickey|zzZZzz> mckoan: OE was created by Chris Larson (overall architecture), Holger Schurig (first implementation), and Michael Lauer (first loads of packages and classes)
May 15 10:27:43 <florian> hi mickey|zzZZzz 
May 15 10:27:44 <mickey|zzZZzz> later, Familiar Linux hackers joined and brought additional sanity into the tools
May 15 10:27:51 <mickey|zzZZzz> plus adding lots of more infrastructure
May 15 10:27:53 <mickey|zzZZzz> morning 
May 15 10:28:03 <hrw> zzZ mickey
May 15 10:28:24 <pb___> mickey|zzZZzz: good morning
May 15 10:28:35 <mickey|zzZZzz> morning pb___ 
May 15 10:28:44 <florian> mickey|zzZZzz: I hope you had a good sleep yesterday... do you have the password for the gforge user that owns the lists?
May 15 10:29:11 <mickey|zzZZzz> florian: i have the master list password, if you mean that
May 15 10:29:27 <mickey|zzZZzz> not the password for the gforge unix user though
May 15 10:29:39 <florian> mickey|zzZZzz: who has this?
May 15 10:29:50 <mickey|zzZZzz> probably K**N
May 15 10:30:05 <florian> oh
May 15 10:30:19 <mickey|zzZZzz> he did most of the gforge setup didn't he?
May 15 10:30:39 <zecke> mickey|zzZZzz: python question: del array[index]
May 15 10:30:57 <zecke> mickey|zzZZzz: is actually removing the item index from the container? (and doing gc?)
May 15 10:31:14 <mickey|zzZZzz> zecke: removing the item from the container, gc only if this was the last reference
May 15 10:31:56 <zecke> mickey|zzZZzz: cache.py:sync is taking many many seconds...
May 15 10:32:08 <zecke> mickey|zzZZzz: mostly because a deepcopy... where I think a shallow copy can do...
May 15 10:32:53 <mickey|zzZZzz> i agree, it looks like a shallow copy could do here
May 15 10:33:04 <mickey|zzZZzz> worth a try
May 15 10:33:11 <mickey|zzZZzz> when things go havoc, it's not enough :)
May 15 10:35:12 <zecke> mickey|zzZZzz: it is mostly for not writing out everything...
May 15 10:35:26 <mickey|zzZZzz> bbiab, need to buy an intermediate sat receiver while waiting for the DM8000 to become widely available *sigh*
May 15 10:45:10 <hrw> XorA: I found why my gcc 4.3.3 builds were failing
May 15 10:45:20 <hrw> XorA: I had thumb enabled in local.conf ;(
May 15 11:05:31 <XorA> hrw: hehe
May 15 11:26:07 <CIA-35> 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * rafc463eeb8 10openembedded.git/recipes/llvm/ (3 files in 2 dirs): 
May 15 11:26:07 <CIA-35> llvm2.6-native: Revert SRCPV usage (its not appropriate here).
May 15 11:26:07 <CIA-35> * fixed the build patch (removed conflict markers)
May 15 11:26:07 <CIA-35> llvm2.6: Dito.
May 15 11:42:58 <zecke> RP: have you thought about multi threaded parsing?
May 15 11:43:10 <zecke> RP: or multithreaded cache building?
May 15 11:47:27 <CIA-35> 03Chris Larson <clarson@mvista.com> 07xora/angstrom-srcpv * ra515f55e61 10openembedded.git/conf/collections.inc: (log message trimmed)
May 15 11:47:27 <CIA-35> collections.inc: add collections to BBPATH, handle typos in COLLECTIONS, etc.
May 15 11:47:27 <CIA-35> - Alters BBPATH to include the newly unpacked collections, then automatically
May 15 11:47:27 <CIA-35> re-exec's bitbake with the new BBPATH to ensure the classes/.confs/etc from
May 15 11:47:27 <CIA-35> those collections are available to bitbake.
May 15 11:47:31 <CIA-35> - Handle typos in the COLLECTIONS variable by warning when glob returns nothing for a given
May 15 11:47:33 <CIA-35> item.
May 15 11:47:35 <CIA-35> 03Graeme Gregory <dp@xora.org.uk> 07xora/angstrom-srcpv * r3d7a9c867d 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv
May 15 11:47:38 <CIA-35> 03Robert Schuster <robertschuster@fsfe.org> 07xora/angstrom-srcpv * rafc463eeb8 10openembedded.git/recipes/llvm/ (3 files in 2 dirs): 
May 15 11:47:41 <CIA-35> llvm2.6-native: Revert SRCPV usage (its not appropriate here).
May 15 11:47:43 <CIA-35> * fixed the build patch (removed conflict markers)
May 15 11:47:45 <CIA-35> llvm2.6: Dito.
May 15 11:47:49 <CIA-35> 03Graeme Gregory <dp@xora.org.uk> 07xora/angstrom-srcpv * rb354a2b3d8 10openembedded.git/: Merge branch 'org.openembedded.dev' of git+ssh://git@git.openembedded.net/openembedded into xora/angstrom-srcpv
May 15 11:47:52 <CIA-35> 03Graeme Gregory <dp@xora.org.uk> 07xora/angstrom-srcpv * r44b2c047a4 10openembedded.git/recipes/llvm/ (2 files): llvm2.6_2.5+svnr20090511.bb,llvm2.6-native_2.5+svnr20090511.bb : SRCREV -> SRCPV
May 15 11:56:22 <CIA-35> 03Cliff Brake <cbrake@bec-systems.com> 07org.openembedded.dev * r1db790bfdc 10openembedded.git/docs/usermanual/chapters/getting_oe.xml: doc: change openembedded.net reference to openembedded.org
May 15 11:57:27 <zecke> anyone want to test two simple patches and send the result of "touch conf/local.conf; time bitbake -p minimal-image"?
May 15 11:58:00 <hrw> sure
May 15 11:59:04 <Crofton|work> frak, I just figured out the wiki.openembedded.net issue cbrake_away was talking to me about last night :)
May 15 12:03:17 <likewise> zecke: ping
May 15 12:03:32 <zecke> pong
May 15 12:04:26 <likewise> zecke: [13:49] <BET-frogger> likewise: OE's zecke-xgcc-cpp.patch doesn't work for gcc-4.3.2; they changed CROSS_COMPILING to CROSS_DIRECTORY_STRUCTURE,
May 15 12:05:03 <likewise> zecke: http://cgit.openembedded.org/cgit.cgi?url=openembedded/tree/recipes/gcc/gcc-4.3.2/zecke-no-host-includes.patch
May 15 12:05:10 <likewise> sorry wrong link
May 15 12:05:45 <likewise> zecke: probably good link, but BET mentions the wrong patch I think
May 15 12:07:19 <XorA> likewise: sheeva arrived thanks
May 15 12:09:16 <likewise> XorA: there still is an (obsolote) CD in my CD ROM player. I
May 15 12:09:34 <XorA> likewise: no problems, I replaced the OS with Angstrom after some cursing and swearing
May 15 12:09:43 <lisppaste7> zecke pasted "fasta?" at http://paste.lisp.org/display/80285
May 15 12:10:05 <likewise> XorA: u-boot swearing? Nand swearing?
May 15 12:10:16 <zecke> likewise: ah, so effectively the patch is useless?
May 15 12:10:25 <XorA> likewise: it wouldnt recognise my usb stick and the SDIO in kernel doesnt work for class 6 cards
May 15 12:10:47 <XorA> likewise: and OE is broken for making .ubi files :-)
May 15 12:10:56 <zecke> hrw: ^^^ could you try the above?
May 15 12:12:40 <hrw>  sure
May 15 12:12:50 <likewise> zecke: I think due to the #if(def?), yes, that's what's BET claims
May 15 12:13:25 <hrw> zecke: thats trunk or 1.8?
May 15 12:13:37 <zecke> hrw: trunk
May 15 12:13:41 <hrw> ok
May 15 12:15:42 <cbrake> anyone know what Bonsai and "OE Stats" are referred to on this page: http://wiki.openembedded.net/index.php/Community_Servers
May 15 12:15:52 <hrw> zecke: 'time bitbake -p minimal-image' before and after patch want?
May 15 12:16:11 <zecke> hrw: yes, and touch conf/local.conf before each run (want to have pure parsing..)
May 15 12:16:18 <hrw> cbrake: OE stats is tinderbox.oe.(org/net)
May 15 12:16:37 <hrw> zecke: ok, will try to keep machine idle during parsing
May 15 12:16:51 <zecke> cbrake: bonsai was a small django app for monotone in the spirit of bonsai.mozilla.org
May 15 12:17:02 <zecke> cbrake: with the single goal, when was which file changed, moved, deleted
May 15 12:17:15 <zecke> cbrake: specially the deleted part is something git can not easily answer
May 15 12:18:54 <cbrake> zecke: ok thanks, so that is not used anymore then
May 15 12:19:20 <zecke> cbrake: I think it is just broken :}
May 15 12:19:49 <cbrake> I'm going to delete http://wiki.openembedded.net/index.php/Community_Servers content and redirect to Infrastructure then
May 15 12:23:07 <florian> yes sounds like a good idea
May 15 12:24:18 <hrw> zecke: 1m slower with your patch, but this machine was not idle during test
May 15 12:29:03 <zecke> hrw: could you generate a comparable state?
May 15 12:50:03 <hrw> zecke: will try
May 15 12:50:15 <zecke> thanks
May 15 12:58:35 <Laibsch> Hi
May 15 13:01:17 <Laibsch> I'm trying to make my first push after the git transition, but "git push origin org.openembedded.dev" gets me "fatal: The remote end hung up unexpectedly".  "git pull" mostly works. .git/config is http://rafb.net/p/5oaY2Q31.html
May 15 13:01:43 <zecke> Laibsch: which protocol did you use?
May 15 13:02:21 <Laibsch> not sure, I followed http://wiki.openembedded.net/index.php/GitPhraseBook
May 15 13:02:28 <zecke> Laibsch: right, you want to push git+ssh :)
May 15 13:02:52 <Laibsch> change that in .git/config2, right?
May 15 13:02:59 <Laibsch> change that in .git/config, right?
May 15 13:03:01 <zecke> Laibsch: url = git+ssh://git@git.openembedded.net/openembedded
May 15 13:03:05 <hrw> zecke: 3m15s without, 3m8s with
May 15 13:03:07 <zecke> Laibsch: yes, for origin
May 15 13:03:10 <Laibsch> OK
May 15 13:03:11 <hrw> zecke: system was idle
May 15 13:03:48 <zecke> hrw: so, a bit faster... :}
May 15 13:03:59 <hrw> a bit
May 15 13:05:41 <Ojg> if i need libstdc++.so.6 in my oe system what bb recipe should i use to get the least overhead
May 15 13:05:52 <Ojg> *?
May 15 13:06:07 <hrw> why you need lib?
May 15 13:06:16 <hrw> I usually need apps in system not libs
May 15 13:09:16 <Ojg> well i have a c++ program i want to run on my system
May 15 13:12:33 <hrw> Ojg: add iperf to system? it use libstdc++ :)
May 15 13:13:28 <Ojg> hehe
May 15 13:16:52 <cbrake> Laibsch: based on your .git/config, you could also do: git push oe
May 15 13:17:24 <cbrake> Laibsch: git@git.openembedded.net == git+ssh://git@git.openembedded.net/openembedded
May 15 13:17:52 <Crofton|work> cbrake, how easy would it be to add google analytics to the website?
May 15 13:19:04 <cbrake> Crofton|work: pretty easy -- I use it for my site, and I think its pretty easy to share access to anyone with a gmail account
May 15 13:19:38 <Crofton|work> can you do so?
May 15 13:19:46 <Crofton|work> that would be cool data to know
May 15 13:21:09 <cbrake> Crofton|work: sure, I'll get something set up
May 15 13:21:19 <cbrake> Crofton|work: do you have a gmail address?
May 15 13:22:48 <Crofton|work> don't kill yourself over it
May 15 13:23:09 <Crofton|work> I'm just talking to some other guys and thought of it
May 15 13:25:42 <Crofton|work> We should buy this for OE!
May 15 13:25:43 <Crofton|work> http://74.125.95.132/search?q=cache:http%3A%2F%2Fcgi.ebay.co.uk%2Fws%2FeBayISAPI.dll%3FViewItem%26item%3D250424519490
May 15 13:25:48 <Laibsch> After adding ssh to the protocol, I can't pull any longer
May 15 13:27:28 <Laibsch> I'm being asked for the passphrase to my ~/.ssh/id_dsa, but after that it continues to ask me about the password for $user@git.openembedded.net
May 15 13:28:01 <Laibsch> I checked /home/git/authorized_keys on amethyst and I am listed there
May 15 13:28:06 <broonie> It's a 5 minute job to set up providing you can create a file in / on the web site.
May 15 13:28:16 <Laibsch> what am I doing wrong?
May 15 13:33:37 <CIA-35> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * rec5f45228f 10openembedded.git/ (conf/checksums.ini recipes/uim/uim.inc): uim: update SRC_URI to point to googlecode.com
May 15 13:33:59 <Laibsch> cbrake: Thank you.  Yours was the deciding hint
May 15 13:34:14 <Laibsch> I'm glad I can continue to pull without ssh
May 15 13:38:16 <XorA> Crofton|work: I already w4r3z3d that :-)
May 15 14:09:52 <CIA-35> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * r330665bd51 10openembedded.git/recipes/images/fso-paroli-image.bb: fso-paroli-image : don't ship udev-static-devices until it works
May 15 14:36:04 <CIA-35> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * r30c62fed75 10openembedded.git/recipes/efl1/ (edbus_svn.bb efreet_svn.bb): edbus efreet : More SONAME changes
May 15 14:39:13 <Laibsch> does an update to the GENTOO_MIRROR variable in conf/bitbake.conf (old URL is dead) require RFC on the ml?
May 15 14:39:46 <Tartarus> hm
May 15 14:40:03 <Tartarus> what're you changing it to?
May 15 14:40:24 <Laibsch> The new, correct value ;-)
May 15 14:40:32 <Tartarus> :P
May 15 14:40:33 <Laibsch> from 
May 15 14:41:03 <Crofton> Laibsch, better safe than sorry :)
May 15 14:41:20 <Crofton> you are touching a bitbake conf file
May 15 14:41:58 <Laibsch> I guess so
May 15 14:42:29 <Laibsch> But it's kind of an additional burden for these obvious housekeeping chores :-(
May 15 14:42:42 <Laibsch> old: http://distro.ibiblio.org/pub/linux/distributions/gentoo/distfiles
May 15 14:43:04 <Laibsch> whichis 404
May 15 14:43:08 <Laibsch> new: http://distfiles.gentoo.org/distfiles/
May 15 14:43:19 <Laibsch> makes housekeeping all the less fun
May 15 14:43:30 <Laibsch> I'll send an RFC :-(
May 15 14:43:47 <Tartarus> Nah, just do it
May 15 14:43:55 <Tartarus> That's a fairly obvious fix
May 15 14:44:02 <Tartarus> and it's not country-specific
May 15 14:45:35 <pb___> yeah, quite.  if the old URI doesn't work at all anymore then you can hardly make it wors.e
May 15 14:46:00 <Laibsch> Well, I know I can hardly make it worse
May 15 14:46:09 <Laibsch> But I guess policy is policy
May 15 14:46:22 <Laibsch> But that is kind of the dilemma I was thinking about myself
May 15 14:50:10 <Tartarus> Yeah, but it's not ment to be a straight-jacket
May 15 14:50:18 <Tartarus> Change it, then post the change for stable/2009
May 15 14:50:22 <Tartarus> it'll get an ack real quick
May 15 14:50:25 <Tartarus> and we can all move on :)
May 15 14:54:22 * XorA sorts his angstrom feeds
May 15 14:54:46 <XorA> Tartarus: i finally beat that sheeva into submission last night
May 15 15:00:18 <Tartarus> nice
May 15 15:00:55 <kergoth> morning
May 15 15:18:23 <Crofton|work> Laibsch, is the amount of time you spent complaining you could have done it
May 15 15:18:55 <Laibsch> nice comment, thank you
May 15 15:19:10 <Laibsch> Tell me where I was complaining?
May 15 15:19:34 <Laibsch> I think it makes sense to tread waters carefully after being absent for a while, no?
May 15 15:19:45 <Crofton|work> about submitting a patch over the gentoo issue
May 15 15:19:59 <Laibsch> I know what you are referring to
May 15 15:20:16 <Crofton|work> I'm in and out
May 15 15:20:44 <Crofton|work> of the channel
May 15 15:20:53 <Laibsch> sure
May 15 15:21:02 <Laibsch> I'm trying to tell you I wasn't complaining
May 15 15:21:07 <Crofton|work> np
May 15 15:21:16 <Crofton|work> it sort of sounded like it though :)
May 15 15:23:15 <royerfa> Hi, I am looking for the link to the website where you can automate the build of Angstrom for your target !
May 15 15:23:29 <royerfa> does anyone can send me this link please ?
May 15 15:23:51 <Crofton|work> www.openembedded.org?
May 15 15:24:00 <Crofton|work> www.angstrom-distribution.org?
May 15 15:26:58 <royerfa> Thanks but there was a webpage really handy where you can just select your packages and your target and the build is automated on the server and you can get the full filesystem as a tarball
May 15 15:27:10 <Crofton|work> ah
May 15 15:27:20 <Crofton|work> narcissus
May 15 15:27:26 <royerfa> yes
May 15 15:27:37 <pb___> morning kergoth 
May 15 15:27:42 <kergoth> morning
May 15 15:27:53 * kergoth needs to go back to bed
May 15 15:28:31 <Crofton|work> royerfa, http://amethyst.openembedded.net/~koen/narcissus/
May 15 15:35:17 <XorA> we have to find a new home for that
May 15 15:37:03 <ant_home> XorA: have you one mom?
May 15 15:37:21 <XorA> ant_home: I probably got the space and cpu power, but not the bandwidth
May 15 15:37:28 <ant_home> he he
May 15 15:37:43 <ant_home> in kexec-tools_2.0.0 there are more files
May 15 15:37:54 <ant_home> one of them fails to compile: crashdump
May 15 15:38:01 * XorA burns kexec to the ground
May 15 15:38:02 <ant_home> can I get rid off crashdump?
May 15 15:38:22 <ant_home> | kexec/crashdump-elf.c:46: error: '_SC_NPROCESSORS_CONF' undeclared (first use in this function)
May 15 15:38:51 * XorA has no idea what it does
May 15 15:39:23 <ant_home> crash + dump
May 15 15:40:57 <ant_home> I have to pay attentio to the effects of kexec-elf-rel-arm.c patch
May 15 15:41:10 <ant_home> -include <elf.h> 
May 15 15:41:22 <ant_home> +#include "../../../include/elf.h" 
May 15 15:46:20 <royerfa> I used bitbake to built the oe stack few weeks ago, I would like to build some specific package again with the -g switch and without being stripped. Is there a quick of doing that, because each time I am doing bitbake package It starts recompiling everything from the scratch (compiler, Glibc ....)
May 15 15:48:45 <kergoth> bitbake doesn't rebuild things on a whim.  they must have had their revisions bumped due to changes or something, or you wiped your tmp
May 15 15:49:03 <kergoth> or are building in a different dir, and hence with a different tmpdir (default tmpdir is ${TOPDIR}/tmp, and default topdir is $PWD)
May 15 16:03:25 <hrw> re
May 15 16:03:46 <kergoth> hey hrw
May 15 16:04:09 <eFfeM> yo
May 15 16:04:46 <hrw> kergoth: I have to look at your pushed changes and cherrypick some to stable/2009
May 15 16:05:21 * kergoth needs to find a good way to keep track of what he's pushed and what he hasn't
May 15 16:06:42 <hrw> kergoth: git format-patch and remove all pushed stuff
May 15 16:27:25 <royerfa> What do I need to change to disable the checker with bitbake 
May 15 16:27:41 <royerfa> I did a git pull and I shouldn't have done that ...
May 15 16:28:12 <royerfa> I need to do smt in sanity.conf but I don't know what to change with it
May 15 16:28:30 <royerfa> Error, DISTRO_PR has changed (.1 to .2) which means all packages need to rebuild.
May 15 16:29:23 <hrw> royerfa: angstrom config got changed recently in a way which require full rebuild
May 15 16:29:48 <hrw> royerfa: so use old metadata or remove tmp and rebuild
May 15 16:30:13 <royerfa> I would like to avoid recompiling all the staff
May 15 16:30:29 <hrw> so you need to go back with OE metadata
May 15 16:31:00 <royerfa> So do I need to change this sanity.conf ?
May 15 16:31:35 <hrw> no - you need to use git and checkout older metdata
May 15 16:32:25 <royerfa> Ah ... I don't how what is the command I should use :-(
May 15 16:32:33 <royerfa> I am not a git expert yet
May 15 16:33:35 <hrw> git checkout e0ea8fd0f401601b356b77dee159da641b0c83a9
May 15 16:33:41 <hrw> royerfa: thats the command
May 15 16:33:48 <hrw> or 'git reset --hard e0ea8fd0f401601b356b77dee159da641b0c83a9'
May 15 16:33:58 <royerfa> thank you a lot
May 15 16:36:39 <kergoth> hmm, our use of file:// isn't compliant with the rfc
May 15 16:40:18 <hrw> kergoth: what is wrong?
May 15 16:40:33 <kergoth> apparently you're supposed to do
May 15 16:40:38 <kergoth> file://<hostname>/<path>
May 15 16:40:44 <kergoth> where hostname can be the empty string or localhost
May 15 16:40:52 <kergoth> so file:///foo is actually a path of "foo" on localhost
May 15 16:41:02 <kergoth> file:////foo -> "/foo"
May 15 16:41:04 <kergoth> afaict
May 15 16:41:08 <kergoth> weird
May 15 16:41:17 <hrw> indeed
May 15 16:41:50 * kergoth was playing witht he use of the python urlparse module for our url bits, instead of our own crap
May 15 16:43:57 <hrw> cant we inherit from urlparse and adapt it for own use?
May 15 16:44:02 <Laibsch> sorry for the continiung git newbie questions, but "git format-patch" does nothing for me.  What am I missing?
May 15 16:44:12 <hrw> Laibsch: revision?
May 15 16:44:21 <Laibsch> revision of what?
May 15 16:44:23 <Laibsch> git?
May 15 16:44:25 <hrw> git format-patch -n -s REVISION
May 15 16:45:38 <Laibsch> thanks
May 15 16:45:44 <Laibsch> Maybe I am doing something wrong
May 15 16:45:48 <Laibsch> http://rafb.net/p/ruEUiZ16.html
May 15 16:46:03 <Laibsch> sorry
May 15 16:46:06 <Laibsch> I'm stupid ;-)
May 15 16:46:35 <Laibsch> "git format-patch -s --subject-prefix="PATCH][STABLE" -s d58018d42fbd256a48caf80b84a6e6fcdf69950a" returns me right to the command prompt, too
May 15 16:47:28 <hrw> d58018d42fbd256a48caf80b84a6e6fcdf69950a is HEAD?
May 15 16:50:01 <cbrake> Laibsch: git format-patch HEAD~x
May 15 16:50:11 <cbrake> Laibsch: where x is the # of patches you want to output
May 15 16:50:20 <cbrake> (something like that)
May 15 16:53:50 <Laibsch> yes, that revision is HEAD
May 15 16:53:58 <Laibsch> the change I want to commit eventually
May 15 16:54:09 <Laibsch> I'm 1 commit ahead of origin
May 15 16:55:16 <Laibsch> cbrake: Looking good
May 15 16:55:34 <Laibsch> How can I get git to export that to Thunderbird?
May 15 16:55:55 <hrw> Laibsch: "git format-patch origin..HEAD" will give all commits between you and upstream
May 15 16:56:02 <Laibsch> cool
May 15 16:56:33 <Laibsch> which mail agent do you guys use to send it to the ml?
May 15 16:58:46 <hrw> Laibsch: git send-email
May 15 17:02:34 <Laibsch> git: 'send-email' is not a git-command. See 'git --help'.
May 15 17:03:17 * Laibsch apt-cache search send-email
May 15 17:03:48 <Tartarus> Need a newer git
May 15 17:03:54 <Tartarus> use the one OE builds, that's what I do
May 15 17:03:54 <Laibsch> no
May 15 17:04:08 <Laibsch> need another git package ;-)
May 15 17:04:15 <Laibsch> git-email which I am installing right now
May 15 17:05:03 <Tartarus> hmm, i see :)
May 15 17:05:10 <hrw> Laibsch: aptitude install git-email
May 15 17:05:24 <Laibsch> yep, it's already running
May 15 17:05:27 <Laibsch> thanks
May 15 17:05:53 <rolleboy> im so happy, finally got the x11-image for kaeilos built for the pm623
May 15 17:06:07 <hrw> rolleboy: ronetix-pm9263?
May 15 17:06:11 <rolleboy> yes
May 15 17:06:19 <mckoan> rolleboy: good to know :-D
May 15 17:06:28 <rolleboy> long process... included changing from ubuntu to debian...
May 15 17:06:31 <hrw> rolleboy: what do you think about OE then?
May 15 17:06:33 <rolleboy> using the stable branch...
May 15 17:06:46 <rolleboy> and then building only in one thread, one prcoessor
May 15 17:07:13 <rolleboy> something must be wrong with the package build order, because any parallell build always gives me errors somewhere
May 15 17:07:19 <rolleboy> different places everytime
May 15 17:07:29 <hrw> strange
May 15 17:07:41 <hrw> I do multiple builds since it is possible
May 15 17:07:59 <hrw> and did such ones for ronetix-pm9263 too
May 15 17:08:04 <rolleboy> ok, maybe something with my machine setup... 
May 15 17:08:16 <rolleboy> or the fact that I use gcc 4.3?
May 15 17:08:23 <hrw> nope
May 15 17:08:26 <cbrake> rolleboy: parallel builds work well for me
May 15 17:08:30 <hrw> I use debian/sid
May 15 17:08:33 <Laibsch> hrw: would you be so kind to pastebin your config file for git send-email so that I can steal :-D
May 15 17:09:12 <CIA-35> 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * rba2ce3ddff 10openembedded.git/ (5 files in 3 dirs): kexec-tools_2.0.0: initial commit - kexec-tools_2.0.0 compiles just fine - kexec-tools-static_2.0.0 breaks during do_compile (against klibc) - setting DEFAULT_PREFERENCE = "-1"
May 15 17:09:38 <hrw> Laibsch: I have smtpserver smtpuser smtppass
May 15 17:09:51 <Laibsch> Oh, right, of course
May 15 17:09:52 <hrw> and smtpencryption=ssl
May 15 17:10:06 <Laibsch> After blanking those out :-)
May 15 17:10:18 <Laibsch> configure in .git/config?
May 15 17:10:24 <Laibsch> or elsewhere?
May 15 17:10:37 <hrw> in ~/.gitconfig I have
May 15 17:10:45 <Laibsch> Aha, I see
May 15 17:11:03 <Laibsch> You don't keep a copy of the mails you sent anywhere?
May 15 17:11:20 <hrw> nope
May 15 17:12:50 <mckoan> have a nice weekend
May 15 17:13:15 <Laibsch> hrw: SENDEMAIL.TO may be interesting for you
May 15 17:13:29 <Laibsch> to send to oe-devel ml by default
May 15 17:13:46 <Laibsch> There's a few other nices ones listed in the man page
May 15 17:16:08 <rolleboy> anyone knows what the default folder is for the cross-gcc to use for building apps with? I tried the one in /home/koan/devel/build/kaeilos/tmp/cross/armv5te/arm-kaeilos-linux-gnueabi/bin but when i compiled with that I could run the file on my host machine, and that doesnt seem right
May 15 17:16:59 <Tartarus> rolleboy, if you want a toolchain for use outside of OE, you want to build a meta-toolchain target and install the output from that
May 15 17:18:04 <rolleboy> aha ok thanks
May 15 17:18:28 <mckoan|away> rolleboy: # Steps to do:
May 15 17:18:28 <mckoan|away> # 1. export PATH=/home/koan/devel/build/kaeilos/tmp/cross/armv5te/bin/:$PATH
May 15 17:18:32 <mckoan|away> # 2. make
May 15 17:19:09 <rolleboy> ok.. thanks again mckoan for all your help with building the image
May 15 17:45:41 <hrw> have a nice weekend
May 15 17:53:53 <Laibsch> Is it possible to have DL_DIR on an NFS-mounted share?
May 15 17:54:04 <pb___> Yes, that should work fine.  I do that all the time
May 15 17:54:18 <Laibsch> Hm, seems to be hanging when I try it.
May 15 17:54:29 <pb___> That's odd.  Where does it hang?
May 15 17:54:43 <Laibsch> at the fetch task
May 15 17:54:56 <pb___> can you see what the specific process is that's stuck?
May 15 17:54:59 <pb___> e.g. with ps?
May 15 17:55:25 <Laibsch> I'll take a look in a minute
May 15 17:55:32 <Laibsch> Doing another build atm
May 15 17:57:13 <kergoth> wtf, my -c fetchall of this set of packages is trying to actually *build* libtool-native.
May 15 17:58:54 <Tartarus> -c fetchall? when did that happen, heh
May 15 18:02:31 <kergoth> been around for a while, its just fetch + a recrdeptask on fetch, afaik
May 15 18:03:08 <Tartarus> wish i knew about that before, heh, hacked up a recipe to do that at some point
May 15 18:03:15 <kergoth> heh
May 15 18:03:33 * Tartarus ^C's his current local build and does a -c fetchall
May 15 18:04:42 <kergoth> whee, got a .inc created that dumps a file containing a list of recipes + filespath files for each recipe where i had a successful task completion
May 15 18:04:47 <Tartarus> aw, not multi-threaded
May 15 18:04:55 <kergoth> now i can use that list to copy a set of packages & their deps into a new collection/overlay
May 15 18:39:02 <florian> re
May 15 18:40:47 <pb___> hi florian 
May 15 18:43:48 <florian> ~lart the tmpa910 for its assignment of a few irqs to a lot of gpios
May 15 18:43:48 * ibot holds the tmpa910 to the floor and spanks him with a cat-o-nine-tails for its assignment of a few irqs to a lot of gpios
May 15 18:53:46 <Laibsch> pb_: bitbake is hanging at "NOTE: Running task 463 of 479 (ID: 2, /home/leggewie/oe/openembedded.org/recipes/wget/wget_1.9.1.bb, do_fetch)", CPU load is below 5%, no progress for the last few minutes.  http://rafb.net/p/oABcbm76.html
May 15 18:54:26 <pb___> Laibsch: can you attach strace to process 25694 and see what it's doing?
May 15 18:55:16 <pb___> I guess you checked dmesg already for nfs warnings, right?
May 15 18:55:31 <Laibsch> actually, no
May 15 18:55:37 <Laibsch> [96192.132066] lockd: server rie not responding, still trying
May 15 18:55:42 <Laibsch> That may be a clue, thanks
May 15 18:55:44 <pb___> ah
May 15 18:55:50 <pb___> yeah, sounds like you lack lockd on the server
May 15 18:55:54 <kergoth> hmmm
May 15 18:56:17 <Laibsch> Oh, I remember with horror
May 15 18:56:40 <Laibsch> There's two nfs implementations, right.  One in userspace and one in kernelspace
May 15 18:56:52 <Laibsch> and both are very broken, just broken differently ;-)
May 15 18:57:07 <pb___> yeah, that's probably a fair assessment
May 15 18:57:08 <kergoth> pb___: i was just thinking, i bet we could safely change things so that the bbclasses that go into INHERIT, things that are common to all recipes, actually went into their own layer between the configuration metadata and the recipe itself.. either that, or they could actually become .inc's loaded at the bitbake.conf level.  either way, itd get it out of the recipe's metadata..
May 15 18:57:33 <pb___> the kernel one is, on average, a bit less broken than the userspace one but its breakage tends to fluctuate a fair bit depending on what exact versions you have
May 15 18:58:09 <pb___> kergoth: yah, I've thought about that from time to time but never dared to actually do it
May 15 18:58:37 <kergoth> trying to come up with more incremental improvements we can make, on our way to a theoretical oe-ng..
May 15 18:58:43 <kergoth> heh
May 15 18:59:04 <pb___> right, sounds like a good plan
May 15 18:59:25 <kergoth> baby steps :)  though, this is probably a pretty big baby
May 15 18:59:30 <pb___> Laibsch: anyway, if you can't mend lockd for any reason, you can mount the clients with "-o nolock"
May 15 18:59:50 <pb___> obviously locking won't work for you then, which will break some apps, but those apps will just be hanging at the moment so I guess you won't be that much worse off
May 15 19:00:44 <dfoley> does anyone know if something is broken with basic building in OE or bitbake ? All of a sudden, bitbake just basically does nothing when I'm trying to use the latest bitbake and OE.dev
May 15 19:00:57 <kergoth> "does nothing"?
May 15 19:01:03 <pb___> (in theory you will be a bit worse off, because you will swap an obvious hang for potential silent corruption if there's concurrency, but...)
May 15 19:01:03 <kergoth> you're going to need to provide more info than that
May 15 19:01:18 <dfoley> $ bitbake -s
May 15 19:01:18 <dfoley> NOTE: Parsing finished. 0 cached, 0 parsed, 0 skipped, 0 masked.
May 15 19:01:18 <dfoley> NOTE: Cache is clean, not saving.
May 15 19:01:26 <Crofton|work> wait, let me find my crystal ball :)
May 15 19:01:38 <pb___> dfoley: at a guess, you were outwitted by the renaming of packages to recipes
May 15 19:01:59 <pb___> I fell for this as well :-}
May 15 19:04:09 <Laibsch> pb_: thanks, nolock option works
May 15 19:04:19 <dfoley> oh boy, I knew about this too
May 15 19:04:24 <Laibsch> If I could only remember the bug that forced me to use nfs-kernel-server
May 15 19:04:33 <Laibsch> which, I think, does not have locking
May 15 19:04:51 <pb___> Laibsch: yes, it does have locking, you just need to start rpc.lockd
May 15 19:05:03 <Laibsch> Oh, does it?
May 15 19:05:10 <pb___> yes
May 15 19:05:12 <Laibsch> Well, then I'll see if I can enable it
May 15 19:05:28 <pb___> actually I think the user one is the one that lacks it.  the kernel server is much more feature-complete.
May 15 19:05:49 <Laibsch> I remember that a few years back I oscillated a few times between the two implementations of nfs because I would always fall into a very serious trap which made me install the other solution ;-)
May 15 19:05:57 <pb___> yeah, I've had that experience too
May 15 19:07:00 <pb___> weirdly, a few months ago, one of our FC1 machines started just suddenly locking up hard whenever we used nfs-kernel-server.
May 15 19:07:30 <pb___> it'd been working fine for years (literally, since about 2004) and the kernel hadn't changed.  never could figure out what was wrong, had to just switch to nfs-user-server.
May 15 19:07:34 <Laibsch> yes, I've experienced hard locks related to NFS :-(
May 15 19:07:43 <Laibsch> EXACTLY the same thing here
May 15 19:08:04 <Laibsch> It was bad because I was in Japan at the time, relying on file access on my home machine 
May 15 19:08:40 <pb___> but, we use nfs-kernel-server on all our other machines (including our main R&D fileserver) and it's fine there.
May 15 19:09:03 <Laibsch> At least once, it was related to bash/dash, though
May 15 19:09:12 <Laibsch> which did not make it more pleasant
May 15 19:09:17 <pb___> heh
May 15 19:11:38 <Laibsch> pb: sorry for the stupid question, but where do I enable lockd?
May 15 19:14:18 <pb___> Laibsch: sadly I think that depends on your distro, and maybe also on your kernel version
May 15 19:14:29 <pb___> in debian I think it's in either /etc/default/nfs-common or /etc/init.d/nfs-commo
May 15 19:14:30 <pb___> n
May 15 19:14:32 <Laibsch> obvious candidates?
May 15 19:14:47 <Laibsch> Yes, I already checked /etc/default
May 15 19:14:50 <pb___> I don't actually have nfs on this laptop so I can't check right now
May 15 19:14:54 <Laibsch> I'll continue to look around
May 15 19:14:57 <Laibsch> Thanks
May 15 19:15:24 <pb___> might get some clues from running "/etc/init.d/nfs-xxxxx restart" and see what it says
May 15 19:16:45 <Laibsch> Actually, I have a lockd process running
May 15 19:17:14 <Laibsch> Is that the one I want?  If so, why would the client think there is no locking?
May 15 19:20:06 <pb___> You need it on both the client and the server, I think.
May 15 19:20:10 <pb___> Which end are you looking at?
May 15 19:21:18 <Laibsch> I was checking /etc/default for the server
May 15 19:21:22 <Laibsch> Will check the client now
May 15 19:21:35 <kergoth> whee, this .inc is working.  dumps a list of 1) recipe filename, 2) __depends (the .inc's, etc, everything it included/inherited), 3) any instances of file:// files in FILESPATH, to feed into a script to populate a separate collection with a subset of the main collection
May 15 19:30:31 <Laibsch> ERROR: Multiple .bb files are due to be built which each provide virtual/libiconv (/home/leggewie/oe/openembedded.org/recipes/glibc/glibc_2.6.1.bb /home/leggewie/oe/openembedded.org/recipes/libiconv/libiconv_1.12.bb).
May 15 19:30:31 <Laibsch>  This usually means one provides something the other doesn't and should.
May 15 19:31:02 <Laibsch> Is that a serious error?  I vaguely remember something similar to this and it would b0rk tmp/ beyond repair
May 15 19:31:14 <Laibsch> I get this from "bitbake podget"
May 15 19:31:58 <Tartarus> hmm
May 15 19:32:02 <Tartarus> what DISTRO?
May 15 19:32:07 <Laibsch> minimal
May 15 19:32:13 <Tartarus> and do you have anything relevant in local.conf?
May 15 19:32:21 <Laibsch> nope
May 15 19:32:33 <Laibsch> Can you try to reproduce this??
May 15 19:33:01 <Tartarus> k
May 15 19:34:31 <Tartarus> MACHINE=?
May 15 19:34:40 <Laibsch> qemuarm
May 15 19:34:54 <Laibsch> please try to reproduce for something other than minimal
May 15 19:35:20 <Tartarus> i think this might be minimal specific
May 15 19:35:27 <Laibsch> could be
May 15 19:35:35 <Tartarus> since minimal does something different than the others for doing a uclibc distro
May 15 19:35:40 <Tartarus> which really needs fixing, sigh
May 15 19:37:39 <Crofton|work> heh
May 15 19:38:07 <Crofton|work> minimal needs to figure out what it is
May 15 19:39:01 <Tartarus> do see w/ minimal, trying angstrom
May 15 19:43:34 <Tartarus> yay, see w/ angstrom
May 15 19:43:46 <Tartarus> ah
May 15 19:43:47 <Tartarus> recipe bug
May 15 19:43:55 <Tartarus> RDEPENDS = "bash sed wget libiconv"
May 15 19:44:01 <Tartarus> not virtual/libiconv
May 15 19:45:36 <glima> hi, guys
May 15 19:47:10 <glima> can anyone, please, tell me where on the oe's git tree lies a sh4 target?
May 15 19:48:13 <Tartarus> l$ grep -El ARCH.*sh openembedded/conf/machine/*.conf
May 15 19:48:13 <Tartarus> openembedded/conf/machine/jornada6xx.conf
May 15 19:48:13 <Tartarus> openembedded/conf/machine/mtx-3.conf
May 15 19:48:13 <Tartarus> openembedded/conf/machine/titan.conf
May 15 19:48:27 <Tartarus> and mtx-3 is a false positive, heh
May 15 19:49:19 <glima> Tartarus: yes, i have looked at conf/machine dirs...
May 15 19:49:27 <glima> but no sh4 string found :(
May 15 19:49:58 <hrw> re
May 15 19:50:08 * hrw needs someone who use madwifi-ng in OE
May 15 19:52:33 <Tartarus> titan is sh4
May 15 19:54:51 <hrw> kergoth: -cfetchall probably builds git-native for you
May 15 19:54:57 <kergoth> figured
May 15 19:55:17 <glima> Tartarus: mmm, might fit
May 15 19:55:21 <glima> thanks, man
May 15 19:56:21 <Laibsch> Tartarus: What should we do about podget?
May 15 19:56:27 <Laibsch> This is an RDEPENDS line
May 15 19:56:36 <Laibsch> virtual/libiconv is not the right thing
May 15 19:56:45 <Laibsch> And angstrom is affected, too, btw
May 15 19:56:56 <Tartarus> Laibsch, er, ah right
May 15 19:57:02 <Tartarus> DEPENDS += virtual/libiconv
May 15 19:57:13 <Tartarus> and RDEPENDS should be set right automatically by the normal logic
May 15 19:57:18 <Laibsch> and move it out of RDEPENDS?
May 15 19:57:21 <Laibsch> OK
May 15 19:57:26 <Laibsch> Let's try that
May 15 19:57:33 <Tartarus> if it even needs a specific *DEPENDS
May 15 19:57:43 <Laibsch> Yes, who know
May 15 19:57:43 <Laibsch> s
May 15 19:57:57 <Laibsch> I'll just make above minimal change
May 15 20:02:55 <Laibsch> Do we publish the fingerprints for the servers somewhere?
May 15 20:08:12 <CIA-35> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r16d94b6b28 10openembedded.git/recipes/podget/podget_0.5.8.bb: 
May 15 20:08:12 <CIA-35> podget: libiconv in RDEPENDS is most certainly incorrect
May 15 20:08:12 <CIA-35> * moving libiconv out of RDEPENDS and virtual/libiconv into DEPENDS
May 15 20:30:52 <hrw> kergoth: with your freeze stuff I see re-parsing each time when I run bitbake...
May 15 20:31:21 <kergoth> hmmm, interesting
May 15 20:31:42 <kergoth> i bet it's the timestamp of the versions.conf file, i think the parser checks the stamp, not the content
May 15 20:32:07 <kergoth> will have to emit a temporary file and move it into place on buildcompleted if the files are different
May 15 20:32:12 <kergoth> i'll fix it, thanks for the report
May 15 20:32:15 * kergoth grumbles
May 15 20:32:46 <hrw> thx
May 15 20:33:57 * kergoth 'll also change it to be opt-in via a require/include from local.conf, since it changes default behavior
May 15 20:37:16 <hrw> ~kill madwifi
May 15 20:37:17 * ibot shoots a charged anti-photon gun at madwifi
May 15 20:56:04 * mwester thinks a charged anti-photon gun is too clean and painless a death for madwifi -- it needs to suffer and die a long, lingering death!
May 15 20:59:04 <hrw> and then die again
May 15 21:02:56 <hrw> bye
May 15 21:23:25 <ant_home> he..any *libc hacker around?
May 15 21:28:34 <Laibsch> Anybody else around who uses git send-email?  I've configured everything in ~/.gitconfig, yet when I actually want to send a mail I get "5.7.1 <openembedded-devel@lists.openembedded.org>: Recipient address rejected: Access denied".  Username and PW for the SMTP server are correct
May 15 21:29:35 <Crofton|work> is that the address you are subscribed to the list with?
May 15 21:29:45 <ant_home> :D
May 15 21:29:51 <Crofton|work> by now, most of the git people are off drinking :)
May 15 21:32:31 <Laibsch> I think I can only set the envelope-from and that is the address I am subscribed to the list with
May 15 21:32:46 <Laibsch> The From-Header cannot be changed AFAICS
May 15 21:32:49 <Tartarus> Laibsch, sounds like you don't have your smtp stuff setup right
May 15 21:32:57 <Laibsch> yes, it sounds like it
May 15 21:33:03 <Laibsch> but it's not true ;-)
May 15 21:33:19 <Laibsch> I double-checked and even turned off encryption
May 15 21:35:25 <ant_home> Tartarus: does this ring a bell?  kexec/crashdump-elf.c:46: error: '_SC_NPROCESSORS_CONF' undeclared (first use in this function)
May 15 21:35:40 <Tartarus> uclibc?
May 15 21:35:42 <ant_home> which header could I lack (klibc)?
May 15 21:35:47 <Tartarus> Ah
May 15 21:35:51 <ant_home> http://tinderbox.openembedded.net/public/logs/5254651.txt
May 15 21:35:51 <Tartarus> hack kexec
May 15 21:36:02 <ant_home> yep
May 15 21:36:17 <ant_home> kexec-tools_2.0.0 static against klibc
May 15 21:36:23 <Tartarus> Right
May 15 21:36:28 <ant_home> fails :/
May 15 21:36:29 <Tartarus> on klibc -D_SC_NPROCESSORS_CONF=1
May 15 21:36:36 <Tartarus> not _sc_nrprocesors_conf()
May 15 21:37:04 <ant_home> Tartarus: this crashdump was introduced with 2.0.0
May 15 21:37:10 <Tartarus> right
May 15 21:37:17 <Tartarus> I'm saying it's a broken program for klibc
May 15 21:37:22 <Tartarus> klibc doesn't provide that func
May 15 21:37:29 <Tartarus> neither, iirc, does or did uclibc at one point
May 15 21:37:34 <Tartarus> So just define that to 1
May 15 21:37:45 <Tartarus> rather than try and dynamically figure out the # of CPUs
May 15 21:37:58 <ant_home> he..for arm...almost actual
May 15 21:38:30 <ant_home> btw the patch I reproduced seems to kill non-arm archs...
May 15 21:38:39 <ant_home> some expert eye needed...help
May 15 21:40:09 <ant_home> http://cgit.openembedded.net/cgit.cgi?url=openembedded/commit/&id=ba2ce3ddff7692289d74a4017806b57a1681d3c8
May 15 21:54:37 <ant_home> Tartarus: ok, now a bit further...
May 15 21:54:39 <ant_home> http://tinderbox.openembedded.net/public/logs/5254745.txt
May 15 21:57:25 <pb___> Tartarus: isn't _SC_NPROCESSORS_CONF just an integer argument that you pass to sysconf()?
May 15 21:58:02 <pb___> I don't think it requires any support from the libc other than to define the constant; the logic should all be handled in the kernel, and as far as libc is concerned I wouldn't expect it to be different to any other sysconf.
May 15 21:58:04 <ant_home> kexec.h: extern unsigned long virt_to_phys(unsigned long addr);
May 15 21:58:14 <pb___> or did you mean that klibc doesn't have sysconf() at all?
May 15 21:58:40 <ant_home> memory.h: static inline unsigned long virt_to_phys(void *x)
May 15 21:58:40 <ant_home> {
May 15 21:58:40 <ant_home>         return __virt_to_phys((unsigned long)(x));
May 15 21:58:40 <ant_home> }
May 15 21:59:15 <ant_home> so..error: previous definition of 'virt_to_phys' was here
May 15 22:00:19 <ant_home> pb___: I just set it to 1
May 15 22:03:05 <Tartarus> pb___, i could be mis-remembering, yeah
May 15 22:03:51 <florian> hi mickeyl 
May 15 22:08:59 <mickeyl> cheers lfo
May 15 22:09:33 <mickeyl> err
May 15 22:09:37 <mickeyl> flo, that is
May 15 22:32:46 <ant_home> hm..okay... the -nostdinc was a bad idea...
May 15 22:43:51 <mickeyl> you got mail :)
May 15 22:49:11 <florian> everyone?
May 15 22:50:47 <mickeyl> hopefully
May 15 22:51:03 <mickeyl> subscribing oe-devel should be mandatory for everyone working on OE
May 15 22:51:08 <mickeyl> else you miss all the goodies...
May 15 22:51:59 <florian> :-)
May 15 22:52:27 <florian> "Dr's Lis Newsletter"? ;)
May 15 22:52:38 <florian> hrm no, wrong account 
May 15 22:54:08 <mickeyl> hahaha
May 15 22:54:11 <mickeyl> no details, please :D
May 15 22:54:21 <mickeyl> anyways, g'night
May 15 22:54:55 <florian> *g*
May 15 22:54:59 <florian> mickey|zzZZzz: good night
**** ENDING LOGGING AT Sat May 16 02:59:57 2009