**** BEGIN LOGGING AT Thu May 28 02:59:58 2009
May 28 03:33:56 <kitno> guys- i am building a new .bb file
May 28 03:34:09 <kitno> and have some problems with the dependencies
May 28 03:34:31 <kitno> Missing or unbuildable dependency chain was: ['fusb', 'sane']
May 28 03:34:39 <kitno> fusb is my app
May 28 03:34:57 <kitno> but sane builds and is installed
May 28 03:35:23 <kitno> my prog also uses libcurl, and i put curl in the depends and it works
May 28 03:37:44 <kitno> does it need to have a -dev package to work?
May 28 04:22:50 <ppafin> Why flac is broken? I tried to build it with my gumstix, no luck.
May 28 04:40:07 <cdbot2> * * OE Bug 5131 has been created by dbaryshkov(AT)gmail.com
May 28 04:40:09 <cdbot2> * * linux-kexecboot-2.6.24-autobuild
May 28 04:40:11 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=5131
May 28 06:29:11 <mckoan> good morning
May 28 06:39:14 <aanishn> my build is failing at module-init-tools-cross_3.2.2.bb, when I check the config.log of the package I can see --build=i686-linux --host=i686-linux --target=arm-oe-linux-gnueabi
May 28 06:39:19 <aanishn> while configure --help says host= should be arm-oe-linux-gnueabi, is the error in my configuration
May 28 06:41:32 <rkirti_> aanishn: what machine are you building for ? and what distro ?
May 28 06:45:33 <aanishn> I created a small distro conf from minimal.conf, max is the same. machine is beagleboard
May 28 07:03:03 <recalcati_oe> morning
May 28 07:04:45 <Goddchen> hi everybody :)
May 28 07:05:52 <Goddchen> i'm experiencing quite some difficulties in building an image for avr32 with openembedded, is this the correct channel to call for HELP? :)
May 28 07:50:03 <CIA-73> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r7664c56425 10openembedded.git/recipes/xorg-xserver/xserver-xorg_1.6.1.bb: xserver xorg 1.6.1: fix sysroot regression by applying the same patch as 1.5.x
May 28 07:50:13 <CIA-73> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r3c4e35bd43 10openembedded.git/ (2 files in 2 dirs): xf86-input-keyboard: update to 1.3.2
May 28 08:00:12 <recalcati_oe> I've pulled from stable/2009 and now I'm compiling beagleboard-demo-image . 
May 28 08:06:12 <Goddchen> i'm experiencing quite some difficulties in building an image for avr32 with openembedded, is this the correct channel to call for HELP? :)
May 28 08:06:24 <pb__> NekoXP: no, it shouldn't
May 28 08:10:36 <CIA-73> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r40e3fb133a 10openembedded.git/recipes/linux/ (linux-rp.inc linux.inc): 
May 28 08:10:36 <CIA-73> linux(-rp).inc: Quirk for udev greater or equal 141
May 28 08:10:36 <CIA-73> * opt-in, distros can set UDEV_GE_141 = 1 to get the quirks applied
May 28 08:10:36 <CIA-73> * currently unsets CONFIG_SYSFS_DEPRECATED* per udev README
May 28 08:12:42 <CIA-73> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r45c663e9f6 10openembedded.git/conf/distro/include/angstrom-2008-preferred-versions.inc: angstrom 2009.X: some more preferred versions
May 28 08:12:42 <CIA-73> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * re2883ac3ce 10openembedded.git/recipes/devicekit/devicekit_003.bb: devicekit: add 003
May 28 08:24:33 <Goddchen> is avr32 target working anyways?
May 28 08:35:22 <pb__> Goddchen: if you're having specific problems, feel free to say what they are and maybe someone can help you with them.
May 28 08:39:03 <ant_work> pb__: morning
May 28 08:48:51 <pb__> hi ant_work 
May 28 08:48:53 <pb__> hi florian 
May 28 08:54:11 <florian> hi all
May 28 08:55:24 <CIA-73> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r194567e13a 10openembedded.git/recipes/xorg-proto/xproto-native_7.0.15.bb: xproto-native 7.0.15: depends on util-macros-native
May 28 08:59:54 <ant_work> florian: do you know any hacker around to help with kexec-tools_2.0.0 klibc-static ?
May 28 09:00:06 <ant_work> I felt asleep last night checking headers...
May 28 09:00:17 <ant_work> but I don't use any IDE...
May 28 09:00:31 <ant_work> just console / Midnight Commander
May 28 09:00:50 <ant_work> stuff is just too big :)
May 28 09:01:13 <florian> ant_work: hum well... ask for a hacker with time :-}
May 28 09:01:35 * florian is at work now... it might take some time. kexec is new for me
May 28 09:02:02 <ant_work> I tried to follow the steps taken by thesing porting old recipe
May 28 09:02:15 <ant_work> but the Makefiles changed a lot
May 28 09:02:40 <ant_work> I guess some paths could be wrong
May 28 09:03:08 <ant_work> the good news is the patches for arm are already in :)
May 28 09:03:19 <ant_work> upstream
May 28 09:03:37 <ant_work> we are still using a strange recipe...not the official sources
May 28 09:04:26 <ant_work> (kexec-tools_1.101)
May 28 09:04:48 <ant_work> fun is in the readme it claims to be 2.0 :)
May 28 09:06:25 <ant_work> florian: second good news is, the 'normal' kexec-tools_2.0.0 compiles just fine. We have problems just with the klibc-static version
May 28 09:07:31 <ant_work> kexec-tools_2.0.0 has now DEFAULT_PREFERENCE = "-1"...just need testers
May 28 09:09:00 <rkirti|zZzz> I am building a gtk variant and my configure fails with a 'gtk-update-icon-cache' not found error ..Isnt it suffficient to inherit the gtk-icon-cache class in the recipe?
May 28 09:14:21 <florian> rkirti|zZzz: Sounds like a missing dependency on the native package.
May 28 09:15:20 <florian> I don't know offhand but its likely that gtk-icon-cache is provided by gtk+-native or somethign like this.
May 28 09:21:51 <XorA> morning
May 28 09:27:06 <jipi> join #oe
May 28 09:27:55 <pb_> florian: hrm, it seems that the infra-red dust removal thing that film scanners do is incompatible with regular black & white stock.  that's a shame.
May 28 09:29:05 <pb_> apparently you have to use chromogenic film for that to work.  I wonder how much harder that is to develop by hand.
May 28 09:29:14 <florian> pb_: that's nasty ibdeed... didn't know this. 
May 28 09:30:33 <pb_> florian: apparently the dust removal works because the dyes in chromogenic film are transparent to infra-red.  so, they shine an IR light through the frame, and any areas that are obscured must be due to dust.
May 28 09:31:04 <pb_> but, the silver crystals that you get with the older b&w processes aren't IR-transparent, so I guess the scanner would think that the entire image was dust.  that'd be no good.
May 28 09:32:18 <florian> yeah... that might be a problem. 
May 28 09:33:00 <pb_> you can buy chromogenic black-and-white film but it needs to be developed using the C-41 process (ie same as for colour film) which I've never done.
May 28 09:33:03 * pb_ goes to read about it
May 28 09:34:53 <florian> That's more effort and has some more requirements about temperature iirc
May 28 09:36:08 <pb_> yeah, that's what I'd heard as well
May 28 09:39:01 <pb_> of course, I could just send it off to a lab, but that'd be no fun.  maybe I'd be best off just giving up on the dust removal and then I can go on using my favourite hp5.
May 28 09:40:47 <Goddchen> http://nopaste.info/5401ee5705.html
May 28 09:40:57 <pb_> a scanner like http://www.jessops.com/online.store/categories/Printers%20and%20Scanners/Scanners/products/Plustek/OpticFilm%207300%20Film%20Scanner-66948/Show.html looks like it would do the business but I wonder whether it works with linux.
May 28 09:41:03 <Goddchen> i'm trying to build an image for avr32 and get that error
May 28 09:41:30 <Goddchen> why is he trying to build glibc? it should be using uclibc? or is the trying to build glibc to build crosscompiler?
May 28 09:42:01 <pb_> yeah, avr is only supported in uclibc
May 28 09:42:20 <pb_> how did you select uclibc in your configuration?
May 28 09:45:39 <florian> pb_: I wonder if cleaning the film before scanning is a good idea. There is some special eqipment to do so... 
May 28 09:46:09 <pb_> yah, I wondered about that.  "special equipment" sounds awfully as though it might be expensive though :-}
May 28 09:47:20 <florian> no that was quite simple... its ages ago i have worked with films and enlarger :-}
May 28 09:54:26 * Goddchen is back, hopefully with a better server connection now
May 28 09:54:37 <Goddchen> did anyone reply to my previos question?
May 28 09:54:45 <pb_> <pb_> yeah, avr is only supported in uclibc
May 28 09:54:45 <pb_> <pb_> how did you select uclibc in your configuration?
May 28 09:55:41 <Goddchen> mom
May 28 09:56:16 <Goddchen> i used the local.conf_sample provided by oe and put the following values in it (according to avr32linux.org wiki)
May 28 09:56:33 <Goddchen> TARGET_OS = "linux-uclibc"
May 28 09:56:33 <Goddchen> MACHINE = "atngw100"
May 28 09:56:33 <Goddchen> DISTRO = "angstrom-2008.1"
May 28 09:56:33 <Goddchen> ANGSTROM_MODE = "uclibc"
May 28 09:57:25 <pb_> that looks like it should be fine.
May 28 09:57:33 <pb_> if you "bitbake uclibc" explicitly, does that work?
May 28 09:57:40 <Goddchen> let me try...
May 28 09:58:18 <Goddchen> hm
May 28 09:58:19 <Goddchen> NOTE: Cache is clean, not saving.
May 28 09:58:19 <Goddchen> ERROR: Nothing PROVIDES 'uclibc'
May 28 09:58:56 <pb_> hah, that's no good
May 28 09:59:05 <Goddchen> i'm in directory stuff/build and i have exported BBPATH to point to stuff/build and stuff/openembedded
May 28 09:59:23 <pb_> try building one of the uclibc.bb files directly with 'bitbake -b'
May 28 10:00:44 <Goddchen> like this:  bitbake -b /home/swk/osgi/openembedded/stuff/openembedded/recipes/uclibc/uclibc_0.9.30.1.bb?
May 28 10:00:48 <pb_> right
May 28 10:01:17 <Goddchen> http://nopaste.info/3f87c764ff.html
May 28 10:02:39 <pb_> hm, crazy
May 28 10:02:45 <pb_> bbiab, gotta go to a meeting now
May 28 10:05:09 <florian> Goddchen: remove the cache directory... this forces it to parse again. 
May 28 10:11:14 <Goddchen> damn it, disconnected again
May 28 10:11:26 <Goddchen> did you write something? ;)
May 28 10:13:31 <florian> <florian> Goddchen: remove the cache directory... this forces it to parse again. 
May 28 10:20:40 * Goddchen changed irc port, hopefully better connection now...
May 28 10:20:44 <Goddchen> what's the status?
May 28 10:21:17 <Goddchen> i think there must be some error in my environment configuration since i can't do "bitbake uclibc"?
May 28 10:25:45 <hrw> morning
May 28 10:26:49 <florian> Goddchen: yes somethign is wrong. remove the cache directory... this forces it to parse again. 
May 28 10:32:41 <Goddchen> when i run bitbake -D -D -D uclibc it sais:
May 28 10:32:56 <Goddchen> DEBUG: skipping /home/swk/osgi/openembedded/stuff/openembedded/recipes/uclibc/uclibc-initial_svn.bb
May 28 10:33:01 <Goddchen> and many more lines like this one
May 28 10:40:51 <Goddchen> so why is bitbake skipping to use the uclibc files?
May 28 10:58:20 <hrw> it is ANGSTROMLIBC = "uclibc" not ANGSTROM_MODE
May 28 11:00:55 <pb_> ah right, crazy angstrom
May 28 11:04:20 <pb_> Goddchen: I guess the wiki you are reading must be out of date.
May 28 11:13:07 <ant_work> !purge internet
May 28 11:13:19 <ant_work> pb_: oh..bad..doesn't work ;)
May 28 11:13:29 <pb_> ant_work: doh
May 28 11:14:48 <ant_work> pb_: there are tons of superceeded infos in the web
May 28 11:15:04 <ant_work> that's already a problem *today*
May 28 11:15:10 <ant_work> imagine in 10 yrs!
May 28 11:15:17 <pb_> yeah, indeed
May 28 11:15:42 <pb_> not that it's unique to the web, of course: in olden days we had books with out of date information :-)
May 28 11:16:06 <ant_work> I fear Google's cache will last longer than stone ;)
May 28 11:16:16 <booxter> just filter info by date and use good sources :)
May 28 11:16:21 <pb_> ant_work: yah, probably
May 28 11:17:57 <pb_> booxter: well, I guess the problem in this case is knowing what are "good sources".  it isn't entirely unreasonable for someone trying to do an avr32 build to assume that avr32linux.org is a trustworthy source.
May 28 11:18:02 <ant_work> pb_: soon the noun 'beagle' will not be associate to a dog anymore..(you know, frequency analysys, blah, blah..)
May 28 11:19:09 <pb_> ant_work: that'd be amusing, though I'm not sure the beagle is actually that widespread outside embedded circles.
May 28 11:19:30 <pb_> as of today, anyway, the beagleboard doesn't seem to show up anywhere in the top ten hits for "beagle"
May 28 11:20:03 <ant_work> btw...
May 28 11:20:19 <hrw> and we had beagle device in OE few years ago..
May 28 11:20:22 <ant_work> beagle beats sheeva 13.200.000 vs. 257.00 hit :)
May 28 11:20:30 <hrw> before beagleboard appeared
May 28 11:22:00 <pb_> ant_work: ah, but, google says that sheeva "... possesses more than enough power to destroy any opponent unfortunate enough to cross her path"
May 28 11:22:16 <pb_> compared to that, the beagle seems lame
May 28 11:23:04 <ant_work> pb_: if we try in hindy Sheeva will probaby win
May 28 11:23:10 <ant_work> hindi?
May 28 11:23:27 <pb_> hindi, yah
May 28 11:24:08 <booxter> ;-)
May 28 11:24:42 <booxter> I'm atheist, I choose beagle! :D
May 28 11:27:57 <ant_work> pb_: Shiva wins
May 28 11:28:24 <hrw> ~curse gta01 for crappy usb charging
May 28 11:28:25 <ibot> May the fleas of a thousand camels infest your most sensitive regions, gta01 for crappy usb charging !
May 28 11:28:35 <pb_> ant_work: ah right, yeah, that'd make sense
May 28 11:28:46 <hrw> not charged after one night connect to usb hub
May 28 11:29:14 <pb_> switched off, or active?
May 28 11:29:50 <hrw> off
May 28 11:29:59 <pb_> iirc, the gta01 does have an issuette in that it basically won't charge if you leave it switched on at the bootloader screen, because it needs about as much current to run the cpu as it draws from the usb bus so there isn't any left over for the battery.  but, if it was off, it should be fine.
May 28 11:30:22 <pb_> i've never had a problem charging mine like that, I don't think.
May 28 11:30:32 <hrw> anyway I have battery charger for its batteries somewhere
May 28 11:30:46 <ant_work> hrw: you reminds me we have similar issue on Zaurus: won't recharge if AC is branched during suspend...not only USB!
May 28 11:30:48 <pb_> though, I guess I usually charge from inside linux with it on. 
May 28 11:31:15 <pb_> ant_work: oh yeah, I remember that.  is that just a kernel bug or is there some underlying limitation?
May 28 11:31:22 <ant_work> bug
May 28 11:31:31 <pb_> righto
May 28 11:31:41 <ant_work> indices pointing to RP :)
May 28 11:31:51 <ant_work> (pavelm, Eric Miao)
May 28 11:32:46 <ant_work> I suppose power management is a bad beast on every hw implementation..that's my experience
May 28 11:33:04 <ant_work> with servers it's a breeze...full throttle !
May 28 11:34:06 * ant_work is thinking now to replace the office-server with a Fujitsu Primergy TX120 S2
May 28 11:38:10 <ant_work> take this:
May 28 11:38:14 <ant_work> [13:37]	<ser>	the google summer of code project to build a nav app for android has started from defining a new binary format to store osm data
May 28 11:38:16 <ant_work> [13:37]	<ser>	what is your opinion about it? do you think there is a need of such new format?
May 28 11:42:53 <pb_> yeah, power management in general does suck pretty badly in linux
May 28 11:45:08 <pb_> that primergy sounds quite neat.  27dB noise level would be nice :-)
May 28 11:45:14 <pb_> I think our proliants idle at something like 70dB
May 28 11:45:45 <ant_work> he..prices (bare, no-disks shuld be around 550 Euro)
May 28 11:46:42 <ant_work> still  find it for >1000 and noise >47db...http://www.monclick.it/schede/fujitsu/T1202S0002IT/primergy-tx120-s2.htm
May 28 11:46:54 <ant_work> better wait a bit...
May 28 11:50:56 <ant_work> pb_: perhaps they measured without SAS disks :)
May 28 11:51:13 <ant_work> wrt SAS, I'd get the 10.000rpm
May 28 11:52:27 <ant_work> 15.000 cannot be whispered
May 28 11:53:34 <pb_> yeah, I guess they probably used SATA 7200rpm if they were interested in quiet and low power
May 28 11:54:31 <ant_work> can you say anything about how fiable SAS disks are vs. old good SCSI?
May 28 11:54:50 <ant_work> still Ultra2Wide here
May 28 11:55:14 <ant_work> I'm a bit perplexed by the 2.5'' size
May 28 11:55:22 <ant_work> still, seems the future
May 28 11:56:12 <pb_> yeah, personally I am not thrilled about SAS either.  the capacities are still so small (due to the 2.5" form factor) that you end up needing an unfeasibly large number of drives.
May 28 11:56:51 <hrw> sas are only 2.5"?
May 28 11:57:03 * hrw -> food
May 28 11:57:16 <ant_work> well, 73GB raid0 would suffice here *today*
May 28 11:57:22 <pb_> I don't think there's any reason you couldn't make a 3.5" SAS drive, but I've never seen one.
May 28 11:57:59 <ant_work> I think the new SSD are 2.5''
May 28 11:58:11 <pb_> ant_work: ah, sas would probably be okay for you.  we have somewhere around 8TB in total of raid1 array (i.e. something like 16TB of drives) and it would take far too many drives to build that with 2.5" disks.
May 28 11:58:41 <ant_work> pb_urgh..raid1
May 28 11:58:52 <ant_work> just mirror
May 28 11:59:15 <ant_work> the small TX120 can have up to 4 in the fromt bay..sounds nice
May 28 11:59:28 <pb_> yeah, I would like to move it to raid0+1 (or 1+0) but the prospect of rebuilding the array is not a pretty one.
May 28 11:59:46 <pb_> the amount of downtime it would require just to copy the data from one set of disks to another is quite large.
May 28 12:00:04 <ant_work> I can only imagine moving such a stream of data...
May 28 12:00:33 <pb_> well, it's not actually quite that bad because the 8TB is split over several different servers.
May 28 12:00:47 <pb_> I think the biggest single array we actually have is 2TB.
May 28 12:03:58 <Goddchen1> hi
May 28 12:04:14 <Goddchen1> switched notebook
May 28 12:04:51 <Goddchen1> pb__ are you there?
May 28 12:05:03 <pb_> hello
May 28 12:05:30 <Goddchen1> hey
May 28 12:05:44 <Goddchen1> sry for my crappy connection last time, hopefully it's better this time
May 28 12:06:14 <Goddchen1> did you have any suggestion for me last time?
May 28 12:06:57 <pb_> hrw pointed out that ANGSTROM_MODE was renamed to ANGSTROMLIBC
May 28 12:07:01 <pb_> did you make that change to your local.conf?
May 28 12:07:11 <Goddchen1> no, let me try
May 28 12:08:03 <Goddchen1> ANGSTROMLIBC="uclibc"
May 28 12:08:03 <Goddchen1> right?
May 28 12:08:15 <pb_> yeah, I think so
May 28 12:08:59 <Goddchen1> ok, rebuilding cache... i did "bitbake uclibc"
May 28 12:13:30 <Goddchen1> hey it does "something"... :)
May 28 12:13:49 <pb_> very good
May 28 12:14:02 <pb_> might be worth asking the avr32linux.org people to update the reference to that variable in their instructions
May 28 12:14:43 <Goddchen1> when i did "bitbake -D -D -D uclibc" an hour ago, i saw line like "skipping ...uclibc.x.bb", how is that possible? that's the reason why it said "nothing provides uclibc"
May 28 12:16:12 <Goddchen1> is it possible that ANGSTORMLIBC was the cause of that?
May 28 12:16:26 <pb_> yeah
May 28 12:16:55 <pb_> I don't know exactly what ANGSTROMLIBC does; the internal machinations of angstrom are pretty mysterious to me.  but it's certainly possible that it could have had this effect.
May 28 12:17:24 <pb_> all the uclibc.bb files will disable themselves if TARGET_OS ends up being set to a value they don't like the look of, see the __anonymous function in uclibc.inc
May 28 12:17:49 <pb_> I suspect that angstrom probably generates TARGET_OS based on ANGSTROMLIBC, though that's just a guess.  you'd have to check the angstrom conf files to find out for sure.
May 28 12:18:03 <Goddchen2> compiling binutils... :)
May 28 12:18:15 <pb_> or you could ask the h4x0rs in #angstrom
May 28 12:18:23 <Goddchen2> btw, my final goal is to run a java app on that system, do you think that is possible?
May 28 12:18:42 <pb_> yeah, I can't see why not. 
May 28 12:18:55 <pb_> I've no idea what the jvm situation is like on avr32 but I imagine it should be possible to make something run.
May 28 12:18:58 <Goddchen2> i tried with buildroot, but the jamvm buildroot build for avr32 does not fully support threads :(
May 28 12:24:08 <Goddchen2> when i do "bitbake uclibc", what exactly does it build? do i get a rootfs of some kind out of that?
May 28 12:30:02 <Goddchen3> grrrr i hate wifi at university
May 28 12:37:27 <kitno> guys- having a problem writing my own .bb that uses another lib
May 28 12:37:46 <kitno> it says: Missing or unbuildable dependency chain was: ['fusb', 'sane']
May 28 12:37:53 <kitno> fusb is my program
May 28 12:38:20 <kitno> i have libsane built and it is installed in the image
May 28 12:38:52 <XorA> kitno: show us you .bb on pastebin
May 28 12:39:05 <kitno> ok
May 28 12:41:24 <hrw> ANGSTROMLIBC enables to switch between glibc/eglibc/uclibc in simple way
May 28 12:43:06 <kitno> XorA, http://pastebin.ca/1437700
May 28 12:43:20 <kitno> its an old .bb i am trying to forward port
May 28 12:43:30 <kitno> and add sane
May 28 12:44:42 <kitno> so maybe i am doing something wrong
May 28 12:44:51 <pb_> kitno: do you actually have a sane.bb in your recipes directory?
May 28 12:44:51 <kitno> s/maybe/probably/
May 28 12:44:59 <kitno> pb_, yes
May 28 12:45:02 <kitno> well
May 28 12:45:09 <kitno> i have a sane-backends
May 28 12:45:17 <kitno> which has PACKAGE = 'libsane'
May 28 12:45:17 <pb_> sane-backends isn't good enough
May 28 12:45:28 <pb_> if you put 'sane' in DEPENDS then you need to have a .bb file named "sane.bb"
May 28 12:45:39 <pb_> or, conversely, if your bb is sane-backends.bb then you need to put 'sane-backends' in DEPENDS
May 28 12:46:13 <kitno> ahh- per our conversation yesterday, i thought it looked for lib[whatever] in all the bb files PACKAGE statements
May 28 12:46:19 <kitno> i misunderstood
May 28 12:46:35 <pb_> ah, no, that was a different thing.
May 28 12:46:47 <pb_> DEPENDS is just a list of .bb files that need to be built before this one
May 28 12:47:15 <pb_> so, in this case, if you change it from sane to sane-backends then I expect it will work
May 28 12:48:43 <pb_> kitno: by the way, apropos the scanning thing we were talking about yesterday, do you happen to know how well the plustek film scanners (7500i and so on) are supported under linux?
May 28 12:49:04 <kitno> pb_, not at all i think
May 28 12:49:10 <kitno> see the list here:
May 28 12:49:10 <pb_> drat, that's what I suspected
May 28 12:49:20 <kitno> http://www.sane-project.org/sane-supported-devices.html
May 28 12:49:23 <pb_> thanks
May 28 12:49:44 <kitno> AFAIK- the ones with the best support are nikon LS-xxxx
May 28 12:50:02 <kitno> and some cheaper flatbeds with a TPU will work
May 28 12:53:01 <kitno> there has recently been some discussion about the LS-50, IIRC
May 28 12:54:43 <kitno> pb_, that worked, just need the right incantation :)
May 28 12:57:57 <pb_> righto, I'll have a look at the nikon ones.  the plustek looks like a nice unit on paper (7200dpi optical resolution, allegedly, and it does have the ir-channel for dust removal although I'm not sure that will work for me).  plus, it's pretty cheap.  but, if I have to run it under windows, that'd be a bit of a negative.
May 28 13:09:48 <kitno> unfortunately, film scanning is one of sane's weaker points, but you might look at vuescan
May 28 13:11:43 <ant_work> pb_: if you fall to $MS Whine you'd try Artscan 
May 28 13:14:01 <kitno> artscan or artiscan
May 28 13:14:40 <ant_work> he.. art-scan exactly
May 28 13:15:59 <kitno> is that a brand of scanner?
May 28 13:16:25 <CIA-73> 03Julien 'Ainulindale' Cassignol <ainulindale@gmail.com> 07shr/import * r89099a8edf 10openembedded.git/recipes/e17/e-wm_svn.bb: 
May 28 13:16:25 <CIA-73> e-wm: Removed OVERRIDE for SHR. Patch has been applied.
May 28 13:16:25 <CIA-73> Signed-off-by: Julien 'Ainulindale' Cassignol <ainulindale@gmail.com>
May 28 13:18:11 <ant_work> pb_: http://www.scanhelp.com/288int/artscan/panorama.pdf
May 28 13:19:13 <zerum> anyone knows what recipe generates the /etc/sysconfig/bluetooth file?
May 28 13:19:31 <ant_work> your fingers...
May 28 13:20:25 <ant_work> look at blueprobe
May 28 13:23:55 <zerum> blueprobe, lemme see..
May 28 13:25:00 <CIA-73> 03Stanislav Brabec <utx@penguin.cz> 07org.openembedded.dev * rb6cc6c1814 10openembedded.git/ (conf/checksums.ini recipes/man-pages/man-pages_3.21.bb): man-pages: Update to version 3.21.
May 28 13:35:21 <zerum> ant_work: thank you, I found it in /etc/init.d/bluetooth (duh). The hx4700 section may need some changes, as the hciattach tool searches for the script in /lib/firmware
May 28 13:37:51 <ant_work> zerum: btw I had to hack the initscript on start) stop) and add it the rfcomm bind/release. Serial just did not show automatically
May 28 13:38:03 <ant_work> this was months ago
May 28 13:41:20 <pb_> I think the idea was that the application software (i.e. gpe-bluetooth or whatever) is responsible for setting up rfcomm.
May 28 13:41:36 <pb_> iirc, the bluetooth initscript was only supposed to launch the base daemons and do whatever was needed to configure the hci.
May 28 13:41:51 <zerum> well, the gpebluetooth just runs /etc/bluetooth/hciattach
May 28 13:42:47 <zerum> which in turn runs /etc/sysconfig/bluetooth to get environment variables, then execute /sbin/hciattach
May 28 13:42:56 <pb_> yeah, that's for starting the hci
May 28 13:43:17 <pb_> rfcomm isn't really supposed to be done at that level
May 28 13:43:44 <zerum> well, I finally managed to get bluetooth working on the 4700 again
May 28 13:43:54 <pb_> I guess you could put an rfcomm bind in there if you wanted, it wouldn't really do any harm, but it'd be better to have it dealt with at the application layer.
May 28 13:43:59 <zerum> but it required a few patches to blues-utils
May 28 13:48:26 <zerum> so, would this patch be interesting to openembeded? Where do I discuss it?
May 28 13:48:46 <pb_> probably best to post it to the mailing list in the first instance.
May 28 13:48:54 <zerum> right
May 28 13:48:57 <pb_> or, alternatively, send it to the upstream bluez dudes and see what they say.
May 28 13:49:07 <zerum> perhaps it would be better
May 28 13:49:08 <pb_> if it lands in bluez upstream then obviously oe will get it automatically in due course
May 28 13:49:26 <zerum> because I believe there's a serious bug with their texas() routines
May 28 13:49:40 <pb_> right, that does sound like it would be best discussed with upstream.
May 28 13:49:52 <pb_> what version of bluez are you using now - did you upgrade to 4.40, or are you still on 3.36?
May 28 13:50:04 <zerum> still on 3.36
May 28 13:50:11 <zerum> but the texas is unchanged on 4.40
May 28 13:50:18 <pb_> righto
May 28 13:51:05 <pb_> anyway, yeah, bluez upstream and/or hx4700-port mailing list sounds like the best place for that kind of issue.
May 28 13:51:23 <pb_> I don't expect the oe list has any particular texas chipset expertise.
May 28 13:51:38 <zerum> yes, of course
May 28 13:52:32 <zerum> I was away from a long time, the last hx4700 port mailing list that I know of was from handhelds.org
May 28 13:54:20 <pb_> yeah, I've been rather out of touch with the hx4700 as well.  I don't know what the current mailing list situation is with that.
May 28 14:22:24 <NekoXP_> pb_ 12h48 churning, I didn't quit it last night :D
May 28 14:22:32 <NekoXP_> so what do I do about this, it's pretty strange... 
May 28 14:29:18 <pb_> dunno, what does "ps" say it's doing?
May 28 14:31:11 <NekoXP_> it says it's soaking up an entire processor
May 28 14:31:13 <ant_work> zerum: iirc now gpe-bluetooth have been superceeded bu gnome-bluetooth (with a nasty comment in commit)
May 28 14:31:29 <NekoXP_> the log if I kill it says a lot of umm
May 28 14:31:37 <zerum> hm
May 28 14:31:56 <NekoXP_> found /oe/tmp/deploy/eglibc/ipk/armv7-a/*.ipkk in Packages but mtime differs - re-reading
May 28 14:32:01 <zerum> ant_work: can you help me with a link? :)
May 28 14:32:01 <NekoXP_> and then Lost field license, LGPL
May 28 14:32:25 <NekoXP_> it does that a hell of a lot of times
May 28 14:32:33 <ant_work> zerum: http://cgit.openembedded.net/cgit.cgi/openembedded/commit/?id=2419aee437204314ad6c00cf2b264a4d6646044a
May 28 14:33:05 <zerum> nasty indeed! :)
May 28 14:33:11 <zerum> well, gotta try that
May 28 14:33:37 <ant_work> zerum: btw s/tried to do/did/
May 28 14:33:42 <ant_work> with a bit hacking
May 28 14:34:41 <ant_work> zerum: in the meanwhile you could stumble in hal/dbus issues..good luck
May 28 14:34:42 <zerum> I don't even want to think about Opie status on bluetooth
May 28 14:35:09 <zerum> and consider I'm using the stable/2009 branch
May 28 14:35:10 <zerum> heh
May 28 14:35:30 <pb_> NekoXP_: that's very weird, I've never heard of that before
May 28 14:35:52 <hrw> zerum: opie and bluetooth... I assume that it is just totally broken
May 28 14:35:53 <NekoXP_> now I stop it and restart it this morning it's working >.<
May 28 14:36:10 <NekoXP_> it did base-image and console-image is running and making my disk fire like mad
May 28 14:36:22 <NekoXP_> 30 seconds and it'll do x11-image... hang on :D
May 28 14:37:16 <CIA-73> 03Stanislav Brabec <utx@penguin.cz> 07org.openembedded.dev * re4cf294ccd 10openembedded.git/recipes/gpe-login/ (files/no-deprecated-sysfs.patch gpe-login_0.95.bb): gpe-login: Do not depends on kernel with CONFIG_SYSFS_DEPRECATED*=y.
May 28 14:38:01 <NekoXP_> anyway regardless.... this is the start of freescale imx515 support
May 28 14:38:27 <NekoXP_> how I go about the git tree mentioned in the docs? so I can push this up somehow
May 28 14:38:35 <hrw> NekoXP_: how much time it took for you to add support?
May 28 14:38:50 <NekoXP_> about 2 weeks on and off trying to resolve weirdness with gcc and so on
May 28 14:39:01 <NekoXP_> actually editing files and not watching builds... about 30 minutes
May 28 14:39:07 <hrw> NekoXP_: i.mx31 is armv7a like omap3?
May 28 14:39:12 <NekoXP_> yes
May 28 14:39:17 <hrw> s/31/51
May 28 14:39:18 <NekoXP_> 51
May 28 14:39:37 <pb_> ant_work: yah, it looks like gnome-bluetooth does include most of gpe-bluetooth's functionality.  I don't know to what extent it's actually a dropin replacement and to what extent that commit is just general angstrom craziness.
May 28 14:39:37 <NekoXP_> but it doesn't build with the stable/2009 branch
May 28 14:39:39 <CIA-73> 03Stanislav Brabec <utx@penguin.cz> 07org.openembedded.dev * r6de1fd8368 10openembedded.git/recipes/man-pages/man-pages_2.79.bb: man-pages: Removed man-pages_2.79.bb.
May 28 14:40:00 <hrw> NekoXP_: what is missing?
May 28 14:41:15 <NekoXP_> I don't know. but the compiler chosen by default doesn't build the kernel, the arch flags are wrong, beagle is built around some codesourcery kernel.. there is a lot of crap in there I had to hack around to even get it to build, and pb_ came up with the pn_glibc arch flags thing to let glibc build the right locales for angstrom
May 28 14:41:52 <hrw> NekoXP_: i.mx51 kernel is not buildable with plain gcc?
May 28 14:42:37 <NekoXP_> it builds with gcc 4.3.3 with armv7-a as an -march but not the one that bitbake picked out for me without forcing a prefered version for some reason
May 28 14:43:04 <NekoXP_> lots of stupid "processor target does not support cpsid i" errors
May 28 14:43:09 <hrw> probably some missing stuff in machine config or angstrom config
May 28 14:43:14 <NekoXP_> which basically meant it was building for arm4
May 28 14:43:42 <NekoXP_> there's not much "missing" considered I copied the beagle support and just changed a few names and tried to build
May 28 14:43:57 <NekoXP_> my local.conf is a nightmare now :)
May 28 14:44:08 <hrw> NekoXP_: speaking of review/merge. use git-send-email to send patchset to ML
May 28 14:44:13 <NekoXP_> ok
May 28 14:44:45 <NekoXP_> before that I am going to find my cigarettes which have mysteriously vanished since I went to sleep last night
May 28 14:45:02 <hrw> NekoXP_: use --no-chain-reply-to
May 28 14:45:35 <NekoXP_> ok
May 28 14:45:49 <NekoXP_> its basically not much more than the kernel stuff and machine description, so.
May 28 14:46:20 <NekoXP_> but that's worth going in. we might have a couple other developers in the next few weeks cleaning it up but right now.. I am the only guy with these boards to test
May 28 14:48:04 <hrw> NekoXP_: you work for Genesi?
May 28 14:48:29 <NekoXP_> yep
May 28 14:49:47 <hrw> NekoXP_: so the fun question - will MorphOS migrate to arm7?
May 28 14:50:02 <NekoXP_> we haven't even broached the subject
May 28 14:50:44 <NekoXP_> in any case it would cost money and we're piling it into something else
May 28 14:51:11 <hrw> NekoXP_: any plans to sell i.mx51 kits for affordable price?
May 28 14:52:05 <NekoXP_> no because they're not affordable but its not long until the efika mx is released... we have all the sample boards, sent to developers.. firmware needs a brush up..
May 28 14:53:08 <NekoXP_> we'd rather sell real consumer-level devices than weirdo development kits :D
May 28 14:53:48 <hrw> ;)
May 28 14:53:57 <hrw> 750$ for efika mx dev 
May 28 14:54:07 <NekoXP_> did bill mention that on morphzone or so?
May 28 14:54:15 <NekoXP_> because it wasn't on his blog
May 28 14:54:32 <hrw> I just googled
May 28 14:54:53 <hrw> 'efika mx' gave me genesi website -> online shop -> price
May 28 14:55:24 <NekoXP_> oh THAT :)
May 28 14:55:39 <NekoXP_> well this is a soft tooled initial production sample
May 28 14:55:56 <NekoXP_> it is actually far, far more than just that board.. you're looking at the netbook pcb
May 28 14:56:12 <NekoXP_> there's a screen and a wireless and a camera and..
May 28 14:56:31 <hrw> I knoiw
May 28 14:56:39 <woglinde> hi hrw
May 28 14:56:50 <NekoXP_> very low volume so it cost us a lot :)
May 28 14:57:07 <NekoXP_> if anyone is really desperate for it then $750 is good value
May 28 14:57:18 <hrw> thebohemian: ping
May 28 14:57:52 <NekoXP_> the open client board and case design aren't done yet but they will be. and that will become the mx developer edition later.
May 28 14:58:54 <NekoXP_> hmn x11-image still takes forever
May 28 14:59:01 <NekoXP_> 17 minutes now
May 28 14:59:16 <NekoXP_> oh well at least I have base- and console-
May 28 15:00:43 <NekoXP_> what does R mean in ps?
May 28 15:01:05 <NekoXP_> running?
May 28 15:01:15 <NekoXP_> sorry what does R+ mean? :D
May 28 15:01:48 <NekoXP_> there is no explanation for the + in man ps
May 28 15:01:58 <hrw> NekoXP_: 'man ps' see + here
May 28 15:02:10 <hrw>        +    is in the foreground process group
May 28 15:02:25 <NekoXP_> ah so.. actually running and not just in the queue
May 28 15:05:58 <pb_> no, the linux tools don't distinguish between 'runnable' and 'actually running'.
May 28 15:06:09 <pb_> there's no equivalent to the "O" state that you get with solaris for example
May 28 15:06:10 <NekoXP_> ook
May 28 15:06:21 <NekoXP_> bah :D
May 28 15:06:25 <pb_> which is a bit sad, but there you are
May 28 15:07:15 <pb_> I'm not sure if this is just a deficiency in ps and top, or if it's a limitation of the data that the kernel provides.  I guess probably the latter but I don't know for sure.
May 28 15:07:37 <NekoXP_> wow that sucks. my microwave destroys my wireless connection.
May 28 15:07:44 <NekoXP_> I think I need a new microwave >.<
May 28 15:07:56 <pb_> heh.  do you get this strange, warm feeling when you stand in front of it?
May 28 15:08:06 <woglinde> he pb
May 28 15:08:27 <NekoXP_> and I thought the headaches were just caffeine withdrawl!
May 28 15:08:38 <pb_> yo woglinde 
May 28 15:09:45 <woglinde> hi elena
May 28 15:12:12 <ant_work> woglinde: hey
May 28 15:12:38 <woglinde> jo ant
May 28 15:14:13 <ant_work> woglinde: do you think you'll have some time in these days?
May 28 15:14:36 <ant_work> struggling against kexec-tools klibc static here..
May 28 15:14:54 <ant_work> Makefile changed and I'm a bit lost
May 28 15:17:04 <woglinde> ant nope
May 28 15:17:21 <ant_work> I'll try with uclibc..sound easier :)
May 28 15:22:32 <NekoXP_> what is opkg-cl anyway?
May 28 15:24:17 <hrw> opkg is package manager
May 28 15:24:26 <hrw> opkg-cl is cli app
May 28 15:25:38 <NekoXP_> hmm with -DD bitbake asks me a question about /etc/localtime
May 28 15:25:59 <NekoXP_> if I didn't run with debug would it not ask the question interactively and as such just "hang"?
May 28 15:26:21 <pb_> probably, yeah
May 28 15:26:40 <pb_> that definitely sounds like a bug if it's asking you those kinds of things
May 28 15:27:10 <NekoXP_> answering the default answer seems to have stalled it, too
May 28 15:27:18 <pb_> doh
May 28 15:27:42 <NekoXP_> and if I quit bitbake, opkg-cl still takes 100% of one of my CPUs
May 28 15:30:18 <ant_work> bbl
May 28 15:33:01 <NekoXP_> hmm curious
May 28 15:33:21 <NekoXP_> if I answer N to the question (which is the default), if I ctrl-c bitbake then I get N<enter> on my terminal
May 28 15:33:25 <NekoXP_> is it not receiving the response?
May 28 15:34:01 <NekoXP_> 100% cpu could mean it is incessantly polling the terminal
May 28 15:41:31 <pb_> sounds like it.  might need to use strace to find out what it's actually doing.
May 28 15:46:25 <DJWillis> NekoXP_: I have seen that self same bug/issue with BitBake/OPKG-CL. In my case it was a package complaining about overwriting a controled file and hung on the Y/N.
May 28 15:46:58 <NekoXP_> yep
May 28 15:47:42 <NekoXP_> tzdata is complaining that /etc/localtime is provided by me or a script - or in the package from the maintainer, and asks me what to do, and doesn't want a response :D
May 28 15:47:46 <NekoXP_> so
May 28 15:47:49 <NekoXP_> strace it is
May 28 15:48:00 <CIA-73> 03Sebastian Spaeth <Sebastian@SSpaeth.de> 07fso/milestone5.5 * r085a88ae15 10openembedded.git/recipes/ (calc/calc_0.0.1.bb calc/calc_git.bb intone/intone_svn.bb): 
May 28 15:48:00 <CIA-73> new recipes calc and intone
May 28 15:48:00 <CIA-73> callc is an efl based calculator
May 28 15:48:00 <CIA-73> intone is an mplayer front end
May 28 15:48:00 <CIA-73> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * r09c463a4f7 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs : new version of calc and intone
May 28 15:48:04 <CIA-73> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * r9b3a026c22 10openembedded.git/recipes/ode/ode_0.11.1.bb: ode : add version 0.11.1
May 28 15:48:13 <DJWillis> I did have a test case that would replecate it somewhere but not sure if I still do.
May 28 15:48:47 <DJWillis> NekoXP_: it seems to come about if the BB is broken in so much as it can't handle state questions with the defaults passed in.
May 28 15:48:58 <NekoXP_> shouldn't there be an option somewhere that states "use te defaults if there are any questions"?
May 28 15:49:05 <NekoXP_> so it just accepts it and carries on?
May 28 15:49:27 <NekoXP_> I'll tell you what strace says it's doing in about 2 minutes :D
May 28 15:50:25 <DJWillis> NekoXP_: yep, one would think so, my test case was to install a GTK+ theme and update systems gtkrc from within that BB. That causes the fault with the " is provided by me or a script - or in the package from the maintainer" issue.
May 28 15:50:42 <DJWillis> NekoXP_: be interested in the output, off home now so away for a few hours.
May 28 15:56:07 <NekoXP_> argh
May 28 15:56:16 <NekoXP_> strace stopped tracing because a child was spawned
May 28 15:56:31 <NekoXP_> shit maybe it's BB_NUM_THREADS causing it?
May 28 15:59:45 <booxter> what should -dev packages generally contain? can I place some datadir stuff that is also needed for compilation?
May 28 16:01:11 <pb_> -dev packages are meant to contain all the files that are only needed for development, rather than for normal runtime operation
May 28 16:01:12 <Ainulindale> dev should be stuff useful for development purposes with the package you're shipping if I'm not mistaken
May 28 16:01:27 <pb_> if that includes data files then yes, you can ship them in -dev
May 28 16:04:01 <florian> hi tardyp 
May 28 16:04:32 <tardyp> hi
May 28 16:04:40 <woglinde> hi florian
May 28 16:06:06 <florian> hi woglinde 
May 28 16:06:48 <tardyp> florian, remember me? I was the original writer of gpe-conf...
May 28 16:07:19 <florian> tardyp: yes sure I do - haven't seen you for quite a while. how are you?
May 28 16:07:35 <CIA-73> 03Julien 'Ainulindale' Cassignol <ainulindale@gmail.com> 07shr/import * r9a572b4dd8 10openembedded.git/recipes/notifier/notifier_0.2.bb: notifier: Fixed wrong S.
May 28 16:08:09 <tardyp> yes. I was recruted in Freescale part because of my implication in GPE.
May 28 16:08:27 <florian> tardyp: oh cool
May 28 16:09:30 <tardyp> now, I'm freescale is going to layoff my team...
May 28 16:09:51 <florian> oh... oops, that's less cool
May 28 16:10:11 <tardyp> yep. Time to find new oportunities.
May 28 16:10:40 <tardyp> For now I have more time to look at oe.
May 28 16:10:50 <florian> that's good... 
May 28 16:11:11 <tardyp> to see if I can run this on freescale boards I have
May 28 16:11:19 * florian is going to please OE with some Freescale hardware in near future :)
May 28 16:11:56 <tardyp> what hw?
May 28 16:12:05 <florian> tardyp: Some of them should be supported already.
May 28 16:12:27 <tardyp> I can see mx31ads recipes.
May 28 16:12:35 <florian> tardyp: A TX27 board... should have a i.MX27 
May 28 16:12:37 <tardyp> I dont know which kernel it uses
May 28 16:14:43 <tardyp> hum I did not know TX27. sound great!
May 28 16:15:31 <tardyp> florian, did you manage to earn your life with oe?
May 28 16:16:16 <florian> tardyp: http://www.karo-electronics.de/index.php?id=354&L=1
May 28 16:16:31 <NekoXP_> hmn hmnhmnhmn
May 28 16:17:25 <florian> tardyp: no... I use OE quite frequently but its not really the business.
May 28 16:17:37 <NekoXP_> guys, how do I tell bitbake to stop trying to ask me interactive questions
May 28 16:18:02 <woglinde> nekpxp?????
May 28 16:18:13 <woglinde> which function should this be?
May 28 16:18:26 <woglinde> dou you mean bitbake shell?
May 28 16:18:34 <NekoXP_> bitbake x11-image
May 28 16:18:35 <woglinde> invoked with bitbake -i?
May 28 16:18:38 <tardyp> florian, which company you work for?
May 28 16:18:42 <NekoXP_> it gets to tzdata and asks this:
May 28 16:18:52 <woglinde> nekoxp what is bitbake asking you?
May 28 16:19:09 <florian> tardyp: http://www.kernelconcepts.de/en/
May 28 16:19:11 <NekoXP_> http://www.pastebin.ca/1438036
May 28 16:19:12 <NekoXP_> this
May 28 16:19:26 <NekoXP_>  no matter what you tell, it just hangs and opkg-cl soaks 100% cpu
May 28 16:20:08 <|AbsyntH|> <tardyp> to see if I can run this on freescale boards I have  <= i'm tring to build oe for mpc8343e for install an os on a zywall board 
May 28 16:20:21 <woglinde> nekoxp aeh?
May 28 16:20:30 <|AbsyntH|> but the mpc8343 is not jet supported
May 28 16:20:35 <NekoXP_> bitbake -DD x11-image is all I ran
May 28 16:20:37 <woglinde> nekoxp why the hell you are overwriting your system settings?
May 28 16:20:44 <NekoXP_> I'm not
May 28 16:20:46 <woglinde> your HOST
May 28 16:20:49 <NekoXP_> bitbake asks me this
May 28 16:20:53 <|AbsyntH|> *yet
May 28 16:20:59 <NekoXP_> it means in the root filesystem
May 28 16:21:07 <woglinde> nekoxp are you running bitbake as root?
May 28 16:21:07 <NekoXP_>  as in /oe/tmp/rootfs
May 28 16:21:10 <NekoXP_> no
May 28 16:21:19 <tardyp> |AbsyntH| I actually work in freescale arm branch, not powerpc..
May 28 16:21:26 <NekoXP_>  /etc/localtime is already in there before it extracts tzdata.ipk
May 28 16:21:34 <NekoXP_> so it asks to resolve the conflict
May 28 16:21:35 <woglinde> nekoxp yes
May 28 16:21:42 <woglinde> hm
May 28 16:21:50 <woglinde> so eglibc is broken in this case
May 28 16:22:01 <NekoXP_> could it really be broken?
May 28 16:22:06 <woglinde> and its not bitbake
May 28 16:22:08 <woglinde> its opkg
May 28 16:22:10 <NekoXP_> why would eglibc matter here?
May 28 16:22:13 <NekoXP_> opkg is running natively
May 28 16:22:25 <NekoXP_> on suse 11.1 glibc 2.7 or whatever it is
May 28 16:22:40 <woglinde> because this file is handled by both packages tzdata and eglibc
May 28 16:22:50 <NekoXP_> you know
May 28 16:22:54 <woglinde> and only one package should do it in this case
May 28 16:22:58 <NekoXP_> as buggy as that may be that eglibc handles it
May 28 16:23:11 <NekoXP_> the real bug here is that bitbake HANGS when it comes up against it
May 28 16:23:26 <NekoXP_> someone obviously coded something to say "you have two of these, which one?" and then the result is ignored
May 28 16:23:38 <NekoXP_> also: if you don't have debug enabled it never asks and just waits forever
May 28 16:23:54 <NekoXP_> bitbake is broken, fixing eglibc is a workaround of a symptom, not the underlying problem :D
May 28 16:23:56 <tardyp> Hey; I'm compiling angstrom, and it seems that still a lot of packages dont like PARALLEL_MAKE = "-j 4"
May 28 16:24:05 <tardyp> I modified oe_runmake to do something like:
May 28 16:24:11 <tardyp> ${MAKE} ${EXTRA_OEMAKE} "$@" || ${MAKE} ${EXTRA_OEMAKE} -j 1 "$@" ||die "oe_runmake failed"
May 28 16:24:14 <woglinde> NekoXP nope it is not bitbakes error
May 28 16:24:18 <tardyp> shouldn't this behavior be the default?
May 28 16:24:25 <tardyp> rather than overwritting PARRALLEL_MAKE in each .bb?
May 28 16:24:26 <woglinde> its eglibc error
May 28 16:25:02 <pb_> tardyp: well, you can make it the default in local.conf if you like
May 28 16:25:19 <woglinde> trady grep the recipes there are enough examples how to disable it for the package
May 28 16:25:41 <woglinde> and dont know what you are compiling
May 28 16:25:55 <tardyp> I want -j4 for all package, and -J1 if this fails.
May 28 16:25:55 <woglinde> I never saw yet a package broke on it
May 28 16:26:32 <tardyp> compiling angstrom-2008.1 for mx31ads
May 28 16:26:39 <tardyp> it first fails on m4
May 28 16:26:48 <woglinde> ?????
May 28 16:27:13 <woglinde> m4 native?
May 28 16:27:16 <tardyp> yes
May 28 16:27:22 <woglinde> never saw this failing
May 28 16:27:36 <woglinde> so maybee something strange on your side
May 28 16:27:52 <tardyp> I have a fresh install of ubuntu 9
May 28 16:27:56 <tardyp> 9.04
May 28 16:27:56 <woglinde> maybee a hardware issue?
May 28 16:28:29 <florian> or dash vs. bash?
May 28 16:28:50 <woglinde> hm
May 28 16:28:53 <woglinde> right
May 28 16:28:59 <woglinde> that could be
May 28 16:29:11 <woglinde> link /bin/sh to bash
May 28 16:30:26 <tardyp> good idea
May 28 16:30:39 <tardyp> I still re-run to send you the exact error
May 28 16:31:53 <|AbsyntH|> tardyp, look at this http://wiki.openembedded.net/index.php/Gcc_issues_in_Intrepid_and_later
May 28 16:31:58 <NekoXP_> woglinde, I think you're not understanding the problem here
May 28 16:32:12 <NekoXP_> 1) yes, eglibc is in error for doing /etc/localtime
May 28 16:32:24 <NekoXP_> but 2) bitbake knows there is a conflict and fails to resolve it when asking the user
May 28 16:32:28 <NekoXP_> and hangs
May 28 16:32:32 <NekoXP_> indefinitely with 100% cpu
May 28 16:34:23 <woglinde> why should bitbake fix outputs from opkg?
May 28 16:35:08 <NekoXP_> woglinde, someone obviously decided it should, or it would not ask
May 28 16:35:33 <NekoXP_> bitbake - or whatever tool it's spawning that asks - should handle the resolution properly
May 28 16:35:35 <NekoXP_> and it doesn't
May 28 16:35:58 <NekoXP_> maybe this is a bug in opkg-cl but it's definitely not a problem with eglibc just because it has ONE file conflicting with another package
May 28 16:36:16 <pb_> yeah, agreed, opkg-cl is clearly broken in this case
May 28 16:36:43 <pb_> it's hard to say whether bitbake is also to blame without doing more debugging.
May 28 16:36:50 <florian> Yes I have seen this soem time ago too... seems to happen with eglibc only for some reason.
May 28 16:37:31 <woglinde> florian eglibc shouldnt mess with tzdata
May 28 16:37:33 <NekoXP_> is there some eglibc configure flag to stop it handling tzdata
May 28 16:38:16 * pb_ go home now
May 28 16:38:17 <pb_> later all
May 28 16:38:25 <NekoXP_> if I can futz my local.conf to work around it that will be fine
May 28 16:38:35 <NekoXP_> I really want this bug to stay in stable/2009 so someone can fix it properly
May 28 16:38:51 * florian too, bbl
May 28 16:38:54 <NekoXP_> opkg-cl not accepting input on questions is stupid, and hanging unless bitbake is on double debug is stupid
May 28 16:39:21 <NekoXP_> is there some way I can inject something to a process' stdin using /proc/<pid> ?
May 28 16:40:20 <NekoXP_> I just want to see if it's basically opkg-cl waiting for input but bitbake is not hooking up the response
May 28 16:40:37 <NekoXP_> it is obviously just printing the result from opkg-cl as if it was an error and not passing the response back
May 28 16:42:46 <tardyp> http://pastie.org/492845
May 28 16:43:12 <tardyp> I think the most important line is:
May 28 16:43:14 <tardyp> | make: INTERNAL: Exiting with 3 jobserver tokens available; should be 4!
May 28 16:46:03 <tardyp> ok. it seems that dash was the failure..
May 28 16:46:20 <NekoXP_> echo N >/proc/blah/fd/0 should work right?
May 28 16:46:54 <zerum> gah, I need a break
May 28 16:47:11 <zerum> just went outside for lunch and saw a car with a "HCI 4700" licence plate...
May 28 16:48:16 <NekoXP_> also does anyone know of some kind of.. athena widget set which magically uses gtk or qt as underlying toolkit?
May 28 16:48:27 <NekoXP_> I am only trying to get around the fact that libXaw stuff looks ugly as sin :D
May 28 16:52:59 <NekoXP_> gah injecting a response doesn't make any difference
May 28 16:57:48 <CIA-73> 03Stanislav Brabec <utx@penguin.cz> 07org.openembedded.dev * r19741f0075 10openembedded.git/recipes/xorg-lib/libx11_1.1.4.bb: libx11-1.1.4: Prevent crash of makekeys (backport from 1.1.5).
May 28 17:04:25 <NekoXP_> okay how can I make it so that tzdata is not required, force it not to build/install and just rely on eglibc?
May 28 17:04:48 <NekoXP_> would adding PROVIDES_pn_eglibc = "tzdata" work?
May 28 17:22:06 <cdbot2> * * OE Bug 5133 has been created by matt(AT)genesi-usa.com
May 28 17:22:07 <cdbot2> * * bitbake xorg-image hangs when opkg-cl  asks for input (eglibc, angstrom)
May 28 17:22:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=5133
May 28 17:29:18 <pb__> NekoXP_: something like that, or ASSUME_PROVIDED += "tzdata"
May 28 17:29:33 <NekoXP_> ok
May 28 17:30:37 <NekoXP_> hmm where did the openmotif package go from recipes?
May 28 17:33:11 <pb__> did we ever have an openmotif one?
May 28 17:33:17 <pb__> lesstif is there, is that what you were thinking of?
May 28 17:33:52 <NekoXP_> no
May 28 17:33:57 <NekoXP_> I really need openmotif :D
May 28 17:34:06 <NekoXP_> it was there.. back in the dark ages
May 28 17:34:20 <pb__> heh, sucks to be you
May 28 17:34:32 <pb__> still, if it was there, you should be able to dig it out of the git history
May 28 17:34:33 <NekoXP_> the build tracker still lists it but, nothing ever got built in recent memory :]
May 28 17:34:44 <booxter> does that have some sense: FILES_qt4-embedded-sql4 = "sql other_real_layout_paths..."?
May 28 17:35:07 <NekoXP_> pb_, how? :D
May 28 17:35:08 <booxter> that's what I can see in the current qt4.inc implementation (if I read it correctly...)
May 28 17:36:00 <booxter> I mean this stuff: http://pastebin.com/m98416c7
May 28 17:36:29 <NekoXP_> http://apps.sourceforge.net/trac/thinstation/browser/ThinStation/trunk/recipes/openmotif/openmotif_2.3.2.bb?rev=627
May 28 17:36:40 <NekoXP_> I suppose I can steal this. good old thinstation...
May 28 17:36:58 <booxter> or possibly I just don't know Python at all :)
May 28 17:40:16 <pb__> booxter: that does sound a bit weird, but... this is qt, so you need to recalibrate your idea of normality at the door.
May 28 17:40:53 <booxter> pb__: ;] That's not qt, that's the recipe ;)
May 28 17:43:49 <pb__> NekoXP_: hm, I don't have openmotif even in my packages trees from 2005 and 2006
May 28 17:44:05 <NekoXP_> no problem I think I was thinking of the thinstation tree after all :D
May 28 17:44:08 <pb__> and I can't find any trace of it in the logs either.  seems like it must have been airbrushed from history by some shadowy government agency
May 28 17:44:12 <pb__> ah, or that
May 28 17:44:13 <pb__> heh
May 28 17:44:22 <NekoXP_> copied it into the overlay and poked at it to stop it building with weird configure flags :D
May 28 17:45:27 <NekoXP_> hmm or not. what are the oe flags for this
May 28 17:45:34 <NekoXP_> HOST_ARCH and TARGET_ARCH?
May 28 17:46:14 <NekoXP_> oh sod it I should be using OE_EXTRA stuff anyway
May 28 17:53:33 <florian> re
May 28 17:53:59 <NekoXP_> oh wow this is so exciting somehow... I think I need to go take a chill pill
May 28 18:06:16 <NekoXP_> hmm
May 28 18:06:34 <NekoXP_> checking for /usr/X/include/X11/X.h... configure: error: cannot check for file existence when cross compiling
May 28 18:06:42 <NekoXP_> this is odd, why is it even looking in /usr/X ?
May 28 18:08:42 <NekoXP_> http://www.motifzone.net/forum/viewtopic.php?f=4&t=3389 looks like nobody knows how to fix it either :/
May 28 18:10:44 <Tartarus> patch configure ?
May 28 18:17:16 <NekoXP_> Tartarus, yep just did
May 28 18:17:24 <NekoXP_> ridiculous moronic openmotif :]
May 28 18:18:07 <NekoXP_> I was hoping there'd be a patchset someone came up with that fixed all the problems but it looks liek I have to go do it by hand :D
May 28 18:18:49 <NekoXP_> grah except autoreconf regenerates it all
May 28 18:19:22 <florian> no... you can provide the result in a site file
May 28 18:19:57 <NekoXP_> it does a stupid check for cross_compiling = yes that I need to remove
May 28 18:46:51 <NekoXP_> okay guys I really need some help here.. on fixing autoconf m4 stuff :(
May 28 18:46:58 <NekoXP_> florian, what was this site thing?
May 28 18:47:59 <NekoXP_> I don't think I can override the variable there since it uses the flag to derive a tuple for building etc.
May 28 18:55:57 <NekoXP_> I can't even find where the damn thing is
May 28 18:57:58 <florian> NekoXP_: 
May 28 18:58:21 <florian> NekoXP_: look at the contrib/site-files
May 28 18:58:35 <NekoXP_> I saw those. I meant the part of aclocal that has that error message in
May 28 18:58:47 <NekoXP_> I hate it when stuff is magically generated from other files which are not present in the tree
May 28 18:58:59 <NekoXP_> die autoconf die :((
May 28 18:59:01 <florian> NekoXP_: you need to find the variable name in the log and guess the right result
May 28 18:59:37 <NekoXP_> I want to hack it then, since changing that didn't work
May 28 18:59:52 <NekoXP_> it does multiple checks for cross_compiling across the board
May 28 19:00:22 <NekoXP_> I could force the set of the variable it sets after that but I don't think it would not check for cross_compiling = yes first
May 28 19:03:12 <NekoXP_> ac_cv_file__user_X_include_X11_X_h = no is what it should be
May 28 19:03:32 <NekoXP_> and ac_cv_file__user_X11R6_include_X11_X_h = no 
May 28 19:03:34 <NekoXP_> we'll see I guess
May 28 19:04:37 <NekoXP_> so where do I set these and make them?
May 28 19:07:59 <NekoXP_> do I just make an /oe/overlay/site/openmotif and add them there and have them picked up or?
May 28 19:14:36 <florian> NekoXP_: ... append to a good file in the site directory
May 28 19:14:51 <florian> forget about contrib... my bad
May 28 19:16:53 <NekoXP_> florian, I really don't want to modify my oe tree, can I just copy it into my overlay and have it magically pick it up?
May 28 19:18:16 <florian> NekoXP_: hmm.. i havn't tried this with site files yet. but i guess so, yes
May 28 19:18:49 <NekoXP_> it worked
May 28 19:19:07 <NekoXP_> configure: loading site script /oe/overlay/site/arm-linux
May 28 19:19:15 <NekoXP_> how do I make it load a custom site script?
May 28 19:20:04 <NekoXP_> there was a site.conf once upon a time but it's not in my current openembedded/conf dir
May 28 19:21:54 <NekoXP_> okay the hack worked but... now it says configure: error: C compiler cannot create executables
May 28 19:21:56 <NekoXP_> *argh*
May 28 19:23:00 <sweetlilmre> anyone got a fix for guile-native? "configure.in:795: error: possibly undefined macro: AM_GNU_GETTEXT" (latest pull)
May 28 19:23:24 <NekoXP_> in function _start undefined reference to __libc_start_main
May 28 19:23:29 <NekoXP_> etc. etc.
May 28 19:23:45 <NekoXP_> so I guess it is not picking up the correct libc directory from staging?
May 28 19:25:35 <NekoXP_> in which case how do I "fix" that
May 28 19:38:18 <sweetlilmre> guile-native-1.8.5 recepie is missing a gettext-native dependency
May 28 19:44:31 <woglinde> sweetlilmre hm are you sure or is it only missing inherit gettext?
May 28 19:46:25 <sweetlilmre> woglinde: I am not sure at all, I just added gettext as a dep (after seeing a similar fix in the commit log for e2fsprogs) and it worked
May 28 19:47:39 <woglinde> sweetlilmre inherit gettext looks for USE_LOCALE and sets configure and deps accodringly
May 28 19:48:01 <woglinde> but maybee guile uses the crappy gnome automacros which alaways turn on nls
May 28 19:48:11 <woglinde> autotoolsmacro
May 28 19:48:24 <sweetlilmre> as in AM_GNU_GETTEXT ?
May 28 19:48:33 <woglinde> nope
May 28 19:48:35 <woglinde> thats okay
May 28 19:49:10 <sweetlilmre> woglinde: ah, sorry I am not really too clued up on this stuff at all. that was the error I was getting, missing AM_GNU_GETTEXT
May 28 19:49:13 <sweetlilmre> so I assumed
May 28 19:49:34 <DJWillis> Quick stupid question, is there a neat way to do a symlink from a to b in a package without using a pkg_postinst script.
May 28 19:50:16 <woglinde> pmount suffered the same porblem
May 28 19:51:17 <woglinde> ah okay the gnome-nls.m4 is okay
May 28 19:51:22 <woglinde> but the root of evil
May 28 19:51:24 <woglinde> is AM_GLIB_GNU_GETTEXT
May 28 19:52:53 <sweetlilmre> woglinde: one day I will understand all this :)
May 28 19:53:24 <woglinde> *g*
May 28 19:56:13 <NekoXP_> arghhhhh
May 28 19:56:28 <NekoXP_> florian, pb_ anyone got an idea on how I can stop tzdata from being installed
May 28 19:56:50 <florian> NekoXP_: yes... comment out the dependency in gpe-conf :-)
May 28 19:57:09 <NekoXP_> bahhhh :(
May 28 19:57:11 <florian> In fact it would be better to check where the file it conflicts with is from.
May 28 19:57:48 <NekoXP_> it's probably eglibc for definite...
May 28 19:58:17 <florian> Either something provides the same - then it needs to be marked to do this at packaging level or packaging needs to be fixed.
May 28 19:58:40 <NekoXP_> so how do I stop it from packaging that file?
May 28 19:58:48 <NekoXP_> without listing every file to be packaged and not including it?
May 28 19:59:02 <florian> Which file is this?
May 28 19:59:07 <NekoXP_>  /etc/localtime
May 28 19:59:38 <NekoXP_> at the first instance. opkg-cl returns a question and bitbake won't let me give an answer so opkg-cl hangs with 100% CPU
May 28 19:59:48 <NekoXP_> and if I ctrl-c bitbake it doesn't clean opkg-cl up so it just sits there
May 28 20:03:09 <florian> hmm... depends on the masks that pull it in.
May 28 20:03:35 <florian> iirc there was a magic to exclude fieles... it was dicuseed at least
May 28 20:04:43 <NekoXP_> okay then
May 28 20:04:48 <NekoXP_> here's the question 
May 28 20:04:55 <florian> NekoXP_: what about the following: make it a separate package 
May 28 20:05:06 <NekoXP_> how do I set -force-defaults to okpg-cl? is there something that I can pass the args to?
May 28 20:05:27 <florian> isn't this the default in oe?
May 28 20:05:41 <NekoXP_> it can't be or it would never ask the question
May 28 20:06:04 <florian> imho that's a bug
May 28 20:06:04 <NekoXP_> it should be in rootfs_ipk.bbclass right?
May 28 20:07:39 <NekoXP_> looking for a variable I can change....
May 28 20:07:45 <NekoXP_> IPKGCONF_TARGET looks good
May 28 20:09:38 <NekoXP_> ah crap I will just edit the bbclass directly
May 28 20:15:29 <NekoXP_> florian, adding -force-defaults made it work
May 28 20:15:40 <NekoXP_> xorg-image is done :D
May 28 20:16:29 <NekoXP_> bug 5133 is where I am reporting all this
May 28 20:20:07 <florian> good point... -force-defaults needs to get in - interactive isn't.
May 28 20:25:44 <NekoXP_> being interactive is a good thing since it finds problems like this :D
May 28 20:26:01 <NekoXP_> eglibc shouldn't be making etc/localtime and nobody would have noticed otherwise
May 28 20:26:22 <NekoXP_> what really should be fixed is.. fixing the interactivity so that it responds to interaction
May 28 20:33:49 <NekoXP_> silly dumb question.. how do I get the angstrom build to include the sdk.. gcc and suchlike?
May 28 20:34:04 <NekoXP_> so I can go right into it and build a native package for openmotif or something? :D
May 28 20:34:38 <NekoXP_> there must be some package or task I can simply add to angstrom_extra_install and have it puill in the whole bucketload
May 28 20:35:11 <NekoXP_> task-native-sdk perhaps?
May 28 20:42:14 <florian> NekoXP_: If you want to build _on_ your device task-native-sdk is what you want.
May 28 20:42:26 <NekoXP_> aha okay
May 28 20:42:30 <NekoXP_> so I just add this to?
May 28 20:42:44 * kergoth ponders a revamp of the whole "stamp" concept
May 28 20:42:46 <NekoXP_> I mean task-native-sdk is basically just an ipkg?
May 28 20:43:21 <woglinde> hi kergoth
May 28 20:43:28 <kergoth> hey
May 28 20:43:30 <florian> yes right... in fact one with soe dependencies
May 28 20:43:39 <florian> hi kergoth 
May 28 20:43:50 <florian> kergoth: with a database?
May 28 20:43:54 <NekoXP_> excellent
May 28 20:44:49 <kergoth> florian:  i was toying with the idea of attaching a snippet of python to a task via a variable flag that would be evaluated to determine whether the task should be run.  the default could just be an os.path.exists(stamp).  you could use it to only run do_fetch *at all* if we actually need something to be fetched, but it would still satisfy the task dependency for tasks that dep on fetch
May 28 20:45:09 <kergoth> do_package could only run if we actually need to emit some packages.
May 28 20:45:14 <kergoth> or whatever
May 28 20:45:38 * kergoth 's just throwing ideas around again
May 28 20:46:18 <NekoXP_> running python per task has a huge overhead compared to stamps though doesn't it? :D
May 28 20:46:19 <florian> I get the idea.... need to think about how much we'd gain with it.
May 28 20:47:51 <kergoth> it probably wouldnt be *terribly* difficult to implement a proof of concept
May 28 20:47:55 <kergoth> i think i'll add it to my todo
May 28 20:47:58 <kergoth> try it out, see how it behaves
May 28 20:48:01 <kergoth> might not be worth the trouble
May 28 20:48:11 <kergoth> but worth toying with, i think
May 28 20:49:55 <kergoth> i also think we need to better define the context in which our inline python snippets are run
May 28 20:50:07 <NekoXP_> grahh firefox doesn't build for the same reason openmotif doesn't
May 28 20:50:13 <kergoth> for example, iirc os is pre-imported, and 'd' is the current datastore, but that isnt written down anywhere to my knowledge
May 28 20:50:14 <NekoXP_> libidl says c compiler cannot create executables
May 28 20:53:04 <jimsheldon> does anyone know why qt4/files/0003-no-tools.patch exists?  it removes src_tools_moc src_tools_rcc src_tools_uic from SRC_SUBDIRS in the Qt embedded build
May 28 20:58:12 <NekoXP_> --libdir is set fine for configure though so why wouldn't it be able to find it?
May 28 20:58:24 <NekoXP_> maybe it's linking with something other than libc... libgcc maybe? :(
May 28 20:59:29 <NekoXP_> but the missing symbols are called from /oe/tmp/staging/armv7-blah/usr/lib/crt1.o so it has the right dir
May 28 21:00:21 <kergoth> florian: was thinking that revamping stamps would make it substantially easier to improve the way packaged staging works
May 28 21:03:24 <NekoXP_> should I have libgcc in my staging ?
May 28 21:08:58 <booxter> I got these "sh: rm: command not found" when something is installed to staging. Is it only mine problem?
May 28 21:09:23 <booxter> though all works ok, but such warning messages are not a good sign
May 28 21:11:52 <Jay7> booxter: it's common thing
May 28 21:12:02 <Jay7> but seems harmless (I hope)
May 28 21:12:09 <ant__> Jay7: hey
May 28 21:12:14 <Jay7> it happens while rebuilding package afaik
May 28 21:12:17 <Jay7> ant__: morning :)
May 28 21:12:26 <ant__> Jay7: I just discovered Ihar == booxter :P
May 28 21:12:35 <Jay7> he :)
May 28 21:13:19 <booxter> ant__: yeap. was it a secret you tried to uncover all days long? ;)))
May 28 21:13:58 <ant__> It smells you could just help us with kexec-tools-klibc-static...
May 28 21:14:08 <Jay7> ant__: some peoples discussing hardware modding of zauruses on hpc.ru :)
May 28 21:14:31 <Jay7> first idea was replace Z's board with gumstix some :)
May 28 21:14:36 <ant__> he..I have to compile UTF-8 locales, then :)
May 28 21:16:22 <ant__> Jay7: koen is pressing with kexecboot updates...
May 28 21:16:32 <Jay7> yeah..
May 28 21:16:44 <Jay7> ant__: what kind of updates he needed?
May 28 21:16:59 <ant__> I suppose the uImage thing
May 28 21:17:08 <Jay7> uImage is kexec thing..
May 28 21:17:31 <ant__> yea, but in the meanwhile we could add an hack
May 28 21:17:41 <Jay7> well.. I hope I'll be free from monday :)
May 28 21:18:09 <ant__> it looks like you'll need an IDE to follow all that includes...
May 28 21:18:37 <ant__> I can't get a picture yet...
May 28 21:19:46 <ant__> second thing, the previous/actual recipe emits ton of warnings...
May 28 21:20:01 <ant__> still happens to work
May 28 21:20:10 <ant__> bravo thesing!
May 28 21:20:49 <NekoXP_> okay gcc-cross-sdk is busted
May 28 21:21:12 <NekoXP_> checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
May 28 21:27:13 <NekoXP_> gcc guys say 'this is not a bug' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
May 28 21:27:20 <NekoXP_> I want to kill bunnies now
May 28 21:34:05 <ant__> Jay7: try to fix the ICON and the DEFAULT bits...I'll insist for help with static
May 28 21:34:20 <ant__> ah..mtdparts reads...
May 28 21:34:34 <ant__> *readings
May 28 21:34:39 <Jay7> ant__: I'll finish refactoring and fix all bugs and bring lost features back :)
May 28 21:34:59 <ant__> pls add mtdparts nand read for Z
May 28 21:34:59 <Jay7> I have full list of problems :)
May 28 21:35:05 <Jay7> this is next thing :)
May 28 21:35:26 <Jay7> It is required for me to switch to kexecboot
May 28 21:36:16 <ant__> about uImage..well you know the hack...just read uImage and cut the header
May 28 21:36:48 <Jay7> ant__: then I should write it back before pass to kexec call
May 28 21:37:16 <ant__> better is add it to kexec-tools, no discussion :)
May 28 21:37:57 <Jay7> well.. I'll see :)
May 28 21:38:13 <Jay7> I'll look even :)
May 28 21:38:42 <ant__> I'll bother people in the meanwhile :))
May 28 21:38:59 <Jay7> ant__ <- bother-man :)
May 28 21:39:09 <ant__> he...
May 28 21:39:37 <mickey|bbiab> florian: are you using gitosis on git.ltg?
May 28 21:40:25 <ant__> Jay7: tyhesing disappeared, florian is full of work, woglinde is busy...next candidate could be Khem...missing too
May 28 21:40:48 <ant__> (they will hate me)
May 28 21:40:48 * florian is still alive
May 28 21:41:07 <florian> mickey|bbiab: no
May 28 21:41:08 <Jay7> heh..
May 28 21:41:11 <Jay7> busy days
May 28 21:41:14 <florian> somewhat
May 28 21:41:21 <Jay7> we should search fresh blood :)
May 28 21:46:43 <kergoth> hmmmm
May 28 21:55:24 * kergoth thinks
May 28 21:57:51 <booxter> wanna fresh blood? just kill someone
May 28 22:00:33 * Jay7 is looking around :)
May 28 22:01:51 <booxter> Jay7: noone?:)
May 28 22:02:15 <Jay7> all are known already ;)
May 28 22:02:55 <Jay7> my Tosa is now a bit closer..
May 28 22:03:02 <Jay7> ~2000 km left :)
May 28 22:05:04 <ant__> Jay7: flameman is back
May 28 22:05:19 <ant__> another candidate :)
May 28 22:08:30 <woglinde> good nite
May 28 22:08:55 * florian doesn't get the reason why oe selects linux 2.6.17 even if 2.6.28 has a raised default preference
May 28 22:08:59 <florian> woglinde: gn
May 28 22:11:09 <booxter> florian: maybe your machine is not in supported list?
May 28 22:13:30 <Crofton|work> florian, COMPATIBLE_MACHINE?
May 28 22:14:31 <NekoXP_> hmn nnanaaggghhgggh
May 28 22:14:35 * NekoXP_ kicks OE
May 28 22:14:36 <booxter> yeap, that's what I meant
May 28 22:15:12 <Crofton|work> booxter, I thought so :)
May 28 22:15:35 <ant__> brb
May 28 22:15:35 <NekoXP_> what could be wrong if certain packages do not build because they say "compiler cannot create executables" with config.log showing crt1.o not finding symbols for __libc_start et al.?
May 28 22:15:52 <NekoXP_> I thought it was just my custom openmotif but libidl does it as a dependency for firefox too
May 28 22:17:22 <florian> booxter, Crofton|work: gnaaa right
May 28 22:18:25 * florian should get some sleep
May 28 22:18:59 * Jay7 -> sleep
May 28 22:20:37 <NekoXP_> you sleep when you're dead :D
May 28 22:24:49 <Crofton|work> florian, its happened to me :)
May 28 22:25:44 <florian> hmm no... looking at the 2.6.28 recipe the preferences shoudl do the trick... 
May 28 22:26:08 <florian> there is nothing such as COMPATIBLE_MACHINE set in there
May 28 22:26:09 <NekoXP_> nobody got a clue about cannot create executables?
May 28 22:26:11 <NekoXP_> :(
May 28 22:26:44 <florian> NekoXP_: sounds like a fundamental problem with the toolchain
May 28 22:27:53 <booxter> florian: what machine?
May 28 22:29:24 <florian> booxter: a new one... but look at linux_2.6.28.bb
May 28 22:30:33 <booxter> florian: is it really virtual/linux package? or maybe just linux-headers?
May 28 22:30:33 <NekoXP_> florian, what kind of fundamental problem? :D
May 28 22:31:20 <booxter> florian: I don't have linux-2.6.17 at all
May 28 22:31:51 <NekoXP_> florian, what are you making a new kernel for may I ask? :)
May 28 22:32:02 <florian> NekoXP_: Karo TX27
May 28 22:32:13 <florian> booxter: virtual/linux
May 28 22:32:26 <NekoXP_> oooh that's a wonderful little processor :D
May 28 22:32:28 <NekoXP_> have one here
May 28 22:32:51 <booxter> florian: so - where have you found 2.6.17 linux package?:)(
May 28 22:33:13 <booxter> there is no such recipe in the tree
May 28 22:34:32 <florian> booxter: that's in a little overlay... 
May 28 22:34:54 <florian> looks like this is the issue here
May 28 22:35:25 <florian> the overlay is preferred and it seems to prefer any bb from the overlay even ofer a preferred in the main tree
May 28 22:35:36 * florian doesn't think this is clever
May 28 22:36:43 <booxter> florian: you can avoid specifying overlay priorities
May 28 22:37:08 <booxter> then it will use the newest possible version I think
May 28 22:37:12 <florian> yes might be a good idea
May 28 22:37:55 <booxter> and then if you really need to use older recipe version from overlay then specify PREFERRED_VERSION_packagename = "X.X.X"
May 28 22:48:59 <kergoth> florian: pretty sure overlay priorities are only used to resolve ambiguity in the case of multiple recipes providing the preferred version.  in the absence of a preferred version, it will use the higher version from a lower priority collection over a lowe version in a higher priority collection
May 28 22:53:28 <booxter> kergoth: it won't
May 28 22:53:59 <kergoth> either it does, or it's broken.
May 28 22:54:02 <kergoth> it's that simple
May 28 22:54:29 <booxter> if my overlay has higher priority then oe builds the highest version from that overlay not from all the known recipes
May 28 22:54:42 <booxter> at least that's how it worked a month ago
May 28 22:56:41 <kergoth> hrmph, thats counterintuitive imo
May 28 22:57:06 <pb__> i think that's broken, not just counterintuitive.
May 28 22:57:14 * florian agrees
May 28 22:57:29 <booxter> kergoth: sometimes it's not. sometimes I really need older version. but generally it's really odd
May 28 22:57:41 <kergoth> the original intent was for collection priority to only be used to resolve ambiguity, but it seems it does more than that now
May 28 22:57:41 <pb__> kergoth: I'm pretty sure the collections code, as first designed at least, worked the way you described.
May 28 22:57:55 <kergoth> didn't you write the original version? i thought i was remembering correctly
May 28 22:58:13 <pb__> yeah, I did, but it was a while ago
May 28 22:58:56 <pb__> I don't think it was ever the intent that a high priority overlay would completely mask newer versions from a lower priority collection; that's what PREFERRED_VERSION is for.
May 28 22:59:50 <kergoth> yep.  if you're too lazy to manually set preferred versions for that overlay, then exclude the overlay with the newer versions, use a freeze script to emit your preferred versions, then add it back
May 28 22:59:58 <kergoth> heh
May 28 22:59:58 <pb__> though, possibly, the overlay code pre-dated PREFERRED_VERSION, in which case it might have seemed like a good idea for the version in the highest priority overlay to be definitive I suppose
May 28 23:00:06 <kergoth> ah, true
May 28 23:00:13 <pb__> I don't really remember anymore.
May 28 23:00:28 <pb__> plus, of course, the code has probably been changed since I wrote it in any case :-}
May 28 23:00:41 <pb__> sadly the bitbake manual is silent on what the intended behaviour is
May 28 23:03:23 <booxter> there is no bitbake manual, really ;)))
May 28 23:03:29 <pb__> sure there is
May 28 23:03:31 <kergoth> of course there is
May 28 23:03:44 <booxter> that's a piece of old crap, not very usefull
May 28 23:03:46 <kergoth> its just it really only covers the syntax thoroughly, not so much behavior
May 28 23:04:01 <kergoth> it's still quite accurate for it covers, booxter 
May 28 23:04:24 <kergoth> also, you're talking to the two of us who wrote the "piece of old crap" :P
May 28 23:04:31 <pb__> booxter: well, your corrections or constructive criticism are welcome
May 28 23:04:44 <booxter> kergoth: I like to piss the right men ;)
May 28 23:04:46 <pb__> your abuse is, perhaps, not quite so welcome
May 28 23:05:22 <booxter> pb__: don't think I want to abuse someone. I'm not. Sorry if I said something crappy :-\
May 28 23:06:56 <booxter> if you're interested, for me, the bad thing is that there is no place where I can find info on different oe functions/tasks/classes... I know it's not a bitbake manual problem but - that's a field where OE has a bad docs coverage (or I just missed the proper doc)
May 28 23:07:14 <kergoth> the openembedded user manual is the place for that, not bitbake
May 28 23:07:21 <kergoth> if you're going to complain, and least complain about the right document
May 28 23:07:24 <kergoth> s/and/at/
May 28 23:08:20 <kergoth> the bitbake manual is missing a lot about the behavior of bitbake, the apis of the bb python module, implementation details, expectations for python tasks and python snippets, how the shell scripts are emitted, etc, but that doesn't sound like it's what you're looking for
May 28 23:12:01 <booxter> btw can anyone explain why on the earth should I have specific number of spaces for my python populate_package_append() function? If there are no 8 spaces at the beginning then it complains on wrong indentation (seems that it occures after "merging" the main and custom _append functions). How should I know what the magic is?
May 28 23:12:53 <booxter> so, 4 spaces doesn't work, but 8 are. I spent an hour to find the reason :-\
May 28 23:13:36 <kergoth> python expects consistent indentation, so you have to be indented the same as the function you're appending to.  check the definition of populate_packages in the bbclass
May 28 23:13:43 <kergoth> thatd be something bitbake should really be smarter about
May 28 23:15:15 <RP> It is :/
May 28 23:16:36 <booxter> kergoth: either bitbake should indent it the right way, or we should have a code style guide
May 28 23:19:01 * kergoth cranks up some Yeah, Yeah, Yeahs and hacks on src_distribute
May 28 23:21:39 <pb__> kergoth: the more I think about that overlay thing, the more convinced I am that it was intentional for older versions in higher priority overlays to beat newer versions in lower priority collections.
May 28 23:22:34 <pb__> I don't remember whether that's because we didn't have PREFERRED_VERSION then, or just because it seemed unreasonable to expect overlay users to freeze their current versions of everything as PREFERRED, just in case some crazy h4x0r checked in a newer version upstream.
May 28 23:23:59 <kergoth> ah, i stand corrected then.  still seems a bit hokey, but *shrug*
May 28 23:24:40 <pb__> I think the idea was that, if I've gone to the trouble of making a modified version of package foo, I probably do want my modifications irrespective of what other versions have appeared upstream in the meantime
May 28 23:25:40 <pb__> and, I guess, I felt that it was easy enough to pull new .bbs from the upstream repo into the overlay if you did want to incorporate them
May 28 23:26:19 <kergoth> aye, makes a certain amount of sense, though i could argue the other direction too
May 28 23:26:31 <pb__> not to say that's necessarily the optimum workflow, but I think it was what fitted best with the project I was working on at the time
May 28 23:26:54 <pb__> nowadays, particularly given freeze.inc, the answer might be different if I was doing it again
May 28 23:28:03 <ant__> he...for kernel then you have DEFAULT_PREFERENCE and MACHINE_KERNEL_PR to combine too
May 28 23:28:17 * kergoth thinks
May 28 23:28:43 <kergoth> RP: ever play with the idea of using a python snippet in a flag instead of directly checking stamp existence, to determine if a task needs to be run?
May 28 23:30:15 <NekoXP_> guys how do I extract a cpio archive to somewhere other than the current directory? :/
May 28 23:30:32 <kergoth> good question, check the man page? :)
May 28 23:30:46 <NekoXP_> the man page is useless, as is the info page it refers to :D
May 28 23:31:03 <NekoXP_> also --help is no good and google doesn't give me anything except "you can copy an entire directory using cpio! cool isn't it???"
May 28 23:31:59 <NekoXP_> grah y'know what.. never mind
May 28 23:32:00 <NekoXP_> I can hack this
May 28 23:36:57 <pb__> ant__: heh, I still think MACHINE_KERNEL_PR is just a bad idea and should never have happened
May 28 23:39:35 <pb__> NekoXP_: I don't think you can change the output directory for cpio.  afaik, it can only extract to stdout, or to the cwd.
May 28 23:39:49 <NekoXP_> that's fair enough. I hacked around it like thinstation did :D
May 28 23:39:57 <NekoXP_> now I have a weird issue though
May 28 23:40:13 <NekoXP_> ERROR: QA Issue: No GNU_HASH in the elf binary: '/some/secret/binary' :)
May 28 23:40:33 <NekoXP_> I don't care about GNU_HASH how do I turn QA off for this package
May 28 23:41:43 <pb__> that usually means that your secret binary isn't getting ${LDFLAGS} included in its final link.
May 28 23:41:58 <pb__> not sure how you turn qa off per-package, other than redefining do_package_qa() as an empty method
May 28 23:42:14 <NekoXP_> the binary works on the target system even without it, so.. I don't care
May 28 23:42:23 <Crofton|work> someone posted that recently
May 28 23:42:26 <pb__> oh, looks like there's an INSANE_SKIP thing you can set
May 28 23:42:31 <NekoXP_> http://groups.google.com/group/beagleboard/msg/9139591e9a2d8d8d
May 28 23:42:35 <pb__>        if bb.data.getVar('INSANE_SKIP_' + package, d, True):
May 28 23:42:35 <pb__>             bb.note("package %s skipped" % package)
May 28 23:42:35 <pb__>             continue
May 28 23:42:35 <Crofton|work> yeah, that sounds about right
May 28 23:42:56 <NekoXP_> http://article.gmane.org/gmane.comp.handhelds.openembedded.scm/15296 <-- like this?
May 28 23:43:30 <pb__> yeah, that sort of thing
May 28 23:44:06 <cdbot2> * * OE Bug 5134 has been created by quickx(AT)hotmail.com
May 28 23:44:08 <cdbot2> * * Build Errors for AT91Bootstrap + u-boot
May 28 23:44:10 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=5134
May 28 23:44:20 <pb__> it doesn't matter what value you set the variable to, anything will do as the right hand side.
May 28 23:45:31 <NekoXP_> it worked that's awesome
May 28 23:45:43 <NekoXP_> now I'm just hitting these dumb crt1.o errors
May 28 23:45:56 <NekoXP_> I thought it was motif but libidl does it as a dependency of firefox
May 28 23:46:19 <pb__> what errors are those?
May 28 23:46:31 <pb__> crt1.o is part of glibc, you should certainly have it in staging somewhere
May 28 23:46:43 <NekoXP_> for config.log it checks if the compiler can generate executables
May 28 23:47:05 <NekoXP_> and I get an error for it that says basically, in crt1.o, the following symbols could not be found... __libc_start, __libc_exit, etc.
May 28 23:47:24 <NekoXP_> which is weird because crt1.o is in /usr/lib in staging, right next to ... libc.so
May 28 23:47:36 <pb__> that is rather weird.  sounds like it must be using the wrong compiler, or the wrong cflags.
May 28 23:47:46 * pb__ zz now
May 28 23:47:47 <pb__> night all
May 28 23:47:50 <NekoXP_> the same cflags as 6000 other tasks built fine with though?
May 28 23:48:38 <NekoXP_> it's a linker error. but the linker flags are fine.
May 28 23:57:11 <ant__> good night
May 28 23:57:14 <NekoXP_> how do I set the architecture of a package inside a recipe
May 28 23:57:32 <NekoXP_> I got a bunch of precompiled arm stuff and if I make a recipe normally it builds it for i686-linux
May 28 23:58:45 <NekoXP_> ARCH=arm would do right?
May 29 00:05:52 <booxter> NekoXP_: what recipe?
May 29 00:06:30 <NekoXP_> custom recipe
May 29 00:06:39 <NekoXP_> it's a tarball from a partner with a lot of files in
May 29 00:06:59 <NekoXP_> no compiling to do.. just put it in the right place in install/ et voila
May 29 00:07:51 <booxter> NekoXP_: by default packages are built for your target arch (I think), unless they inherit native or sdk
May 29 00:08:18 <NekoXP_> hm ok
May 29 02:53:08 <CIA-73> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * rbe52905547 10openembedded.git/recipes/ode/ode_0.11.1.bb: ode : add version 0.11.1
May 29 02:53:09 <CIA-73> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * r855287929b 10openembedded.git/conf/distro/include/sane-srcrevs.inc: sane-srcrevs: remove paroli
May 29 02:53:09 <CIA-73> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * rfd76aaa8c7 10openembedded.git/: Merge branch 'fso/milestone5.5' of git@git.openembedded.org:openembedded into fso/milestone5.5
May 29 02:54:30 <CIA-73> 03Angus Ainslie <nytowl@openmoko.org> 07fso/milestone5.5 * rf3fde07319 10openembedded.git/conf/checksums.ini: checksums.ini : add ode 0.11.1
**** ENDING LOGGING AT Fri May 29 02:59:57 2009