**** BEGIN LOGGING AT Thu Jul 03 02:59:57 2008
Jul 03 03:18:47 <workaphobia> http://oe.linuxtogo.org/node/20/diff/609/610
Jul 03 03:19:05 <workaphobia> admist the awful misformatted page, notice the horrendous green background text:
Jul 03 03:19:15 <workaphobia> "NOTE!!! You must do the following two steps or bitbake will not find the bitbake.conf file! (message would be: "ERROR: Unable to open conf/bitbake.conf")  "
Jul 03 03:19:26 <workaphobia> Well, I have that error, and that page is lacking instructions
Jul 03 03:19:59 <workaphobia> I don't know why checking out and updating the .dev branch would magically fix bitbake or bbpath, but I tried it and it didn't work.
Jul 03 03:24:09 <workaphobia> what am I supposed to do to convince bitbake that a file exists?
Jul 03 03:45:55 <workaphobia> Ok, after digging through python source code for thirty minutes, there seems to be some environmental oddity where my bbpath is being ignored
Jul 03 03:46:14 <workaphobia> Still trying to figure out if it's my fault or bitbake's
Jul 03 03:54:20 <workaphobia> ...
Jul 03 03:54:21 <workaphobia> I hate my life.
Jul 03 03:54:47 <workaphobia> It's too late at night. Far too late if I'm making such an asinine mistake as forgetting to *export* the variables in my bashrc.
Jul 03 03:55:06 <workaphobia> And then proceed to spend an hour and a half debugging the problem, partly by digging through python code.
Jul 03 06:24:08 <hrw> morning
Jul 03 06:52:23 <czr_> mornink indeed
Jul 03 07:15:37 <mehtril> morning
Jul 03 08:35:43 <florian> good morning
Jul 03 09:01:22 <kiozen> morning!
Jul 03 09:01:29 <kiozen> I have a tiny question:
Jul 03 09:02:40 <kiozen> if do_configure failes, because the system includes are used instaed of the ones to cross compile..
Jul 03 09:03:04 <kiozen> what do I have to add to the *.bb file?
Jul 03 09:03:36 <kiozen> pleeease :)
Jul 03 09:07:15 <Julian_chu> system include? you mean it used absolute path ?
Jul 03 09:07:56 <kiozen> configure seems to test with /usr/inlcude instead with the includes from oe
Jul 03 09:08:40 <kiozen> this must be a trivial one, but I am a noob if it comes to cross compiling stuff
Jul 03 09:09:06 <kiozen> that is the message: ERROR: This autoconf log indicates errors, it looked at host includes.
Jul 03 09:11:31 <kiozen> this is caused by "CROSS COMPILE Badness:" in the configure log
Jul 03 09:17:34 <kiozen> hm, "inherit native" seems to do the trick. No clue why :)
Jul 03 09:18:31 <XorA> kiozen: that is almost certainly the wrong fix :-)
Jul 03 09:18:56 <XorA> kiozen: in these cases, you probably need to fix configure.in
Jul 03 09:19:26 <kiozen> XorA: what to look for in configure.in?
Jul 03 09:19:53 <XorA> a test which include /usr/include without using the CFLAGS correctly
Jul 03 09:20:01 <kiozen> ok
Jul 03 09:20:19 <XorA> sometime even a simple --with-blah = ${STAGING_INCDIR} in EXTRA_OECONF can fix it
Jul 03 09:20:31 <XorA> config.log is normally your friend
Jul 03 09:20:39 <XorA> its very detailed about failures
Jul 03 09:22:28 <kiozen> XorA: btw, what does "inherit native" do?
Jul 03 09:23:09 <XorA> kiozen: changes all the internal variable to build for your host machine
Jul 03 09:23:18 <XorA> kiozen: in that case /usr/include is valid
Jul 03 09:23:57 <kiozen> ah :)
Jul 03 10:44:39 <CIA-24> 03koen 07org.oe.dev * r197cf319... 10/ (3 files in 2 dirs): sqlite3: install headers during do_stage, fixing packaged-staging. From poky
Jul 03 11:05:09 <czr_> hmm. "Unable to handle kernel paging request at virtual address foo" is fun .. :-)
Jul 03 12:06:19 <kiozen> ok, finally I could bitbake latest gdal (1.5.2), how do I get the *bb file into oe? Should I send it as bug report?
Jul 03 12:06:53 <Crofton|work> kiozen, file a bug report
Jul 03 12:07:01 <kiozen> ok
Jul 03 12:12:00 <hrw> http://svn.o-hand.com/view/poky?rev=4799&view=rev if someone wants to build Maemo software with OE
Jul 03 12:13:01 <hrw> lunch time
Jul 03 12:17:06 <cdbot2> * * OE Bug 4407 has been created by oliver.eichler(AT)gmx.de
Jul 03 12:17:08 <cdbot2> * * update to gdal 1.5.2
Jul 03 12:17:10 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4407
Jul 03 14:06:16 <Crofton|work> is www.openembedded.org down?
Jul 03 14:06:36 <Crofton|work> is OE.mtn.bz2 mirrored anywhere
Jul 03 14:11:36 <Laibsch> ltg is at a load of 30 again
Jul 03 14:11:59 <Crofton|work> bother
Jul 03 14:13:14 <broonie> You could try just doing a from-scrach pull :)
Jul 03 14:13:27 <hrw> heh.. I am unable to draw few circles with same center point..
Jul 03 14:13:32 <Crofton|work> heh
Jul 03 14:13:40 <Crofton|work> broonie, that would take ages :)
Jul 03 14:16:39 <broonie> Crofton|work: ~8 hours on a 2GHz x86-64 last time I tried.
Jul 03 14:22:51 <CIA-24> 03crofton 07org.oe.dev * raf851f45... 10/ (4 files in 3 dirs): dsplink : Package sample programs and install them on Davinci images.
Jul 03 14:22:56 <CIA-24> 03mickeyl 07org.oe.dev * r00cf1e9e... 10/ (3 files in 3 dirs): frameworkd git fix typo in conf file
Jul 03 14:23:01 <CIA-24> 03koen 07org.oe.dev * rb43a21b3... 10/ (1 packages/gnash/gnash_0.8.3.bb): gnash: add 0.8.3 with an ugly, ugly hack to work around libtool problems
Jul 03 14:23:06 <CIA-24> 03koen 07org.oe.dev * r798e12bd... 10/ (3 files in 3 dirs): linux-omap2 git: add bootlogo for beagleboard
Jul 03 14:23:11 <CIA-24> 03koen 07org.oe.dev * r3b3faee3... 10/ (5 files in 4 dirs): dsplink: add -include linux/autoconf.h to the kernel cflags, obsoleting patches adding #includes for that
Jul 03 14:25:41 <Crofton|work> I wonder if we can move the OE.mtn.bz2 to amethyst ....
Jul 03 14:28:53 <CIA-24> 03koen 07org.oe.dev * rb6c0786a... 10/ (5 files in 4 dirs): linux-omap2 git: sync with sakomans tree and drop unused patches
Jul 03 14:29:38 <rwhitby> Crofton: http://downloads.openmoko.org/OE/snapshots/ from 25 May if that helps
Jul 03 14:48:29 <hrw> bye
Jul 03 14:55:05 <florian> http://www.linuxdevices.com/news/NS8827997755.html
Jul 03 14:55:36 <florian> xserver-kdrive-common sounds like OE or Poky
Jul 03 15:02:44 <CosmicPenguin> nice
Jul 03 15:07:21 <CIA-24> 03crofton 07org.oe.dev * ra5d35e3e... 10/ (3 files in 3 dirs): u-boot : Update SFF SDR board patch and bump git rev to current HEAD.
Jul 03 15:37:18 <CIA-24> 03koen 07org.oe.dev * r326382c0... 10/ (3 files in 3 dirs): oprofile: fix build with gcc 4.3
Jul 03 16:10:30 <cbrake> has anyone ever run into a problem where the OE patch operation tries to call perforce: http://pastebin.ca/1061413
Jul 03 16:10:50 <cbrake> helping a OE user debug a problem, and this one is very strange
Jul 03 16:11:41 <cbrake> all I can figure is there is some command in the users environment that is replacing a normal patch/quilt command and calls perforce instead
Jul 03 16:11:45 <cbrake> but having trouble finding it
Jul 03 16:13:27 <kergoth> cbrake:  pretty sure thats a gnu patch feature.
Jul 03 16:13:56 <kergoth>        -g num  or  --get=num
Jul 03 16:13:56 <kergoth>           This option controls patch's actions when a file is under RCS or SCCS control,  and
Jul 03 16:13:56 <kergoth>           does  not  exist or is read-only and matches the default version, or when a file is
Jul 03 16:13:56 <kergoth>           under ClearCase or Perforce control and does not exist.
Jul 03 16:13:58 <CosmicPenguin> export PATCH_GET=0
Jul 03 16:14:09 <kergoth> heh, there ya go, cp knows whats up
Jul 03 16:14:22 * CosmicPenguin has suffered from that affliction for quite some time now.... :)
Jul 03 16:14:30 <kergoth> think my manpath is borked, couldnt man patch on this box :P
Jul 03 16:15:16 <mrt2k7> hi, i've got a quite strange question....
Jul 03 16:16:03 <mrt2k7> i have problems with builds out of OE, the problem is my programs don't detect MMX, SSE etc. although they are listed in /proc/cpuinfo
Jul 03 16:16:35 <kergoth> if you're crosscompiling, why would you expect to be able to go by the /proc/cpuinfo info?
Jul 03 16:16:50 <mrt2k7> oh, i think i was unclear
Jul 03 16:17:03 <mrt2k7> i dont meant the cpuinfo on my build system
Jul 03 16:17:42 <mrt2k7> the resulting linux system obviously detects MMX etc. in its /proc/cpuinfo
Jul 03 16:17:56 <mrt2k7> but the user space programs, x264 in this case, doesn't find them
Jul 03 16:18:30 <mrt2k7> i build for x86-prescott
Jul 03 16:18:49 <mrt2k7> are such cpu extensions covered by the OE archs?
Jul 03 16:19:07 <CosmicPenguin> Are you saying the code isn't compiled with MMX instructions?
Jul 03 16:20:25 <mrt2k7> i'm really not an expert on this....silly question again:
Jul 03 16:21:05 <mrt2k7> is MMX support enabled at compile time, and is there MMX support on the build system for a certain cross-arch necessary?
Jul 03 16:21:59 <mrt2k7> or does this happen by adding some asm code to the program, and no local mmx unit would be necessary?
Jul 03 16:22:31 <mrt2k7> i'm just very unclear about where to find the switch for that
Jul 03 16:22:51 <CosmicPenguin> Generally, MMX is used in hand-tuned chunks in individual applications
Jul 03 16:22:57 <cbrake> CosmicPenguin: that works -- thanks!
Jul 03 16:23:08 <CosmicPenguin> the individual applications are responsible for detecting MMX and using it
Jul 03 16:23:10 <cbrake> CosmicPenguin: what triggers this, and why don't I see it on my workstation?
Jul 03 16:23:21 <kergoth> mrt2k7:  only -cross or -native packages are likely to gain anything from the build system.  most packages rely only on the target
Jul 03 16:23:59 <mrt2k7> thanks
Jul 03 16:24:11 <mrt2k7> i would assume i'm doing crossbuild, because of x86_64 -> 32
Jul 03 16:24:25 <mrt2k7> x86-prescott seems to be i686 basically
Jul 03 16:24:33 <CosmicPenguin> cbrake: I think it looks for the P4 environment variables and makes an assumption
Jul 03 16:24:46 <CosmicPenguin> cbrake: $P4PORT in particular 
Jul 03 16:25:01 <kergoth> imo that sort of crap belongs in quilt/patcher, not patch..
Jul 03 16:25:04 <kergoth> but thats gnu for you
Jul 03 16:25:34 <CosmicPenguin> that sortof crap doesn't belong anywhere - I'm smart enough to check out code before using it, thank you
Jul 03 16:25:53 <kergoth> hehe, true
Jul 03 16:27:12 <mrt2k7> what about a linux kernel with that:
Jul 03 16:27:22 <mrt2k7> > 3. 586/K5/5x86/6x86/6x86MX (M586)      in .config
Jul 03 16:27:41 <mrt2k7> could userspace programs use mmx etc. then?
Jul 03 16:27:52 <mrt2k7> i fear....no?
Jul 03 16:27:55 <CosmicPenguin> not unless they are compiled for it
Jul 03 16:28:30 <CosmicPenguin> MMX is a specific set of different opcodes - they just don't magically replace the standard opcodes
Jul 03 16:28:44 <mrt2k7> ok, so, a difference about that between a program and the kernel is not the deciding part...
Jul 03 16:28:56 <mrt2k7> i think ill try it with another app
Jul 03 16:28:59 <mrt2k7> mplayer or so
Jul 03 16:29:19 <kergoth> mplayer will still care about the features of the target, not your build machine :P
Jul 03 16:29:24 <kergoth> unles syou're building it natively
Jul 03 16:29:46 <mrt2k7> the target runs in a KVM vm
Jul 03 16:29:52 <mrt2k7> on the same machine ;)
Jul 03 16:30:08 <kergoth> the point is, crosscompiled apps should NEVER touch /proc
Jul 03 16:30:09 <kergoth> period
Jul 03 16:30:13 <mrt2k7> and the cpu the VM sees, has MMX
Jul 03 16:30:14 <kergoth> when crosscompiling, anyway
Jul 03 16:31:01 <CosmicPenguin> mrt2k7: I think what you're missing is that MMX isn't a switch you turn on -it has to be specifically and purposely written and compiled in
Jul 03 16:31:14 <mrt2k7> hm
Jul 03 16:31:31 <mrt2k7> i'll doublecheck that
Jul 03 17:36:51 <tharvey> trying to override TMPDIR from env doesn't seem to work - some things take it from env others take it from local.conf
Jul 03 17:58:28 <CIA-24> 03koen 07org.oe.dev * r1c739048... 10/ (4 files in 3 dirs): gst-ffmpeg: add 0.10.4, disabled by default
Jul 03 18:01:30 <CIA-24> 03mickeyl 07org.oe.dev * ra422dee5... 10/ (1 packages/freesmartphone/zhone_git.bb): zhone: uses distutils now
Jul 03 18:17:27 <mattaw> .e 
Jul 03 18:17:32 <mattaw> oops.
Jul 03 18:18:23 <mattaw> I have a SoC running inside a Virtex 2 fpga (Xilinx XUP board) which I am porting angstrom to
Jul 03 18:18:42 <mattaw> however it is a little difficult due to the wide variety of hardware you could have instantiated
Jul 03 18:24:26 <chris144> hi folks, long time, no speak :-)
Jul 03 18:25:21 <mattaw> that seems the norm in this channel :)
Jul 03 18:25:24 <Crofton> is there a good git mirror to pull meta-data from
Jul 03 18:25:38 <Crofton> accessible via http, I working with a guy who has firewall issues
Jul 03 18:26:26 <rkirti> u neednt use http neways...
Jul 03 18:26:37 <rkirti> oe metadate uses mtn if i m not wrong 
Jul 03 18:26:43 <rkirti> *metadata
Jul 03 18:27:49 <Crofton> mtn port is blocked
Jul 03 18:28:29 <Crofton> mattaw, that is an interesting project
Jul 03 18:28:31 <Crofton> I have a ml403
Jul 03 18:29:03 <mattaw> Crofton> noo, I hate that board :)
Jul 03 18:29:08 <rkirti> Crofton: oh ok..try http://oe.linuxtogo.org/snapshots/
Jul 03 18:29:19 <Crofton> the price was right :)
Jul 03 18:29:28 <mattaw> Crofton> I spent a long time on it with the GRLIB leon3 however it has only 4 DCM's in the FX Virtex4
Jul 03 18:29:32 <mattaw> and you need 5
Jul 03 18:29:52 <Crofton> I need to teach myself FPGA with it, when I get time
Jul 03 18:30:15 <mattaw> to run the ddr anyway :) It is a very good board. PS a piece of advice: don't lose the systemace cf card, it is special
Jul 03 18:30:56 <Crofton> lovely :)
Jul 03 18:31:06 <mattaw> crofton: however it is a good board if you are doing dsp and the onboard powerpc works fine
Jul 03 18:31:13 <Crofton> great
Jul 03 18:31:18 <Crofton> those are my needs :)
Jul 03 18:32:06 <mattaw> I just needed lots of logic and 5 DCMs
Jul 03 18:32:40 <Crofton> It's good to see the xlinix ppc people coming here
Jul 03 18:34:13 <mattaw> heh, I am working on SPARC v8 soc's but I do FPGA and ASICs
Jul 03 18:35:56 <mattaw> I have been able to build various leon3 configurations and upload linux builds into it. However the linux version is snapgear which reminds me of openzaurus, i.e. its rubber bands, baling twine and string 
Jul 03 18:36:22 <mattaw> openembedded solves so many evil problems with building a distribution
Jul 03 18:36:41 <Crofton|work> I know some guys messing with a 403
Jul 03 18:36:58 <Crofton|work> they were having trouble booting their hand made file system
Jul 03 18:37:10 <Crofton|work> I made a ml403 fs in OE and sent it to them
Jul 03 18:37:15 <Crofton|work> worked first time
Jul 03 18:37:24 <Crofton|work> well, the time after the untared it as root
Jul 03 18:37:51 <mattaw> indeed. OE is brilliant. I just need to convert the system to build for sparc glibc
Jul 03 18:38:07 <Crofton|work> tool chain areas are scary still :)
Jul 03 18:38:53 <Crofton|work> How can I use the OE fetchers with proxy servers?
Jul 03 18:39:21 <mattaw> ooh, a proxy? I have no idea
Jul 03 18:40:41 <Crofton|work> I'm hoping someone knows
Jul 03 18:40:46 <Crofton|work> I suppose I should rtfm
Jul 03 18:41:38 <mattaw> it isn't brilliant. I tried to find info on porting to another system however it has been a little hit and miss
Jul 03 18:42:17 <Crofton> yeah, we never have enough time for docs
Jul 03 18:42:29 <mattaw> what do you do?
Jul 03 18:43:22 <Crofton> I am a "consultant"
Jul 03 18:43:29 <Crofton> www.opensdr.com
Jul 03 18:43:45 <Crofton> that's a polite way of saying, I'll do anything for money
Jul 03 18:46:11 <mattaw> crofton: heh
Jul 03 18:46:42 <mattaw> I am a lecturer trying to come up with hardware software codesign who has a weird bent towards linux
Jul 03 18:47:48 <CosmicPenguin> Crofton: OE should respect http_proxy and such
Jul 03 18:47:55 <CosmicPenguin> Crofton: there are gotchas in GIT land
Jul 03 18:50:13 <kiozen> a noob needs more help :) what do I have to add to the bb file to tell bitbake to move some data from the package's share folder to /usr/share of the image?
Jul 03 18:50:44 <CIA-24> 03koen 07org.oe.dev * r421f0e4f... 10/ (1 packages/gstreamer/gst-ffmpeg_0.10.4.bb): gst-ffmpeg 0.10.4: fix src_uri
Jul 03 18:54:13 <Crofton|work> kiozen, look at some of the do_install methods in other bb files
Jul 03 18:54:34 <kiozen> ok
Jul 03 18:55:32 <mattaw> the patch file for the LEON3 2.6.21.1 kernel is pretty bit
Jul 03 19:07:27 <kiozen> Crofton|work: is do_install also used when building the rootfs folder? the image folder of the package has the data in /usr/share, it's just the rootfs missing it.
Jul 03 19:08:13 <Crofton> you need to get the data into an ipk
Jul 03 19:08:48 <Crofton> the rootfs is built from ipks
Jul 03 19:09:23 <Crofton|work> sorry I'm being vague, donig to many things at once right now
Jul 03 19:22:42 <Crofton|work> anyone know why I need to hit return when the boot process gets to the generate drop bear key message?
Jul 03 19:23:23 <kiozen> Crofton: right, it's not in the ipk, can you give me a quick hint where to define what's going into the ipk? 
Jul 03 19:24:10 <Crofton|work> FILES_${PN}_....
Jul 03 19:24:33 <kiozen> ah, ok I have seen that, thabks :)
Jul 03 19:56:48 <chris144> nite folks
Jul 03 20:13:18 <likewise> hello all
Jul 03 20:20:43 <Crofton> gm likewise 
Jul 03 20:21:56 <likewise> hi Crofton
Jul 03 20:27:54 <CIA-24> 03crofton 07org.oe.dev * r8c8d9512... 10/ (1 packages/linux/linux-davinci/davinci-sffsdr/defconfig): davinci-sffsdr : Update kernel defconfig.
Jul 03 20:35:37 <teamnoir> Question: I want to do the equivalent of "unset foo; export foo" in OE - that is, I want a particular variable to be unset in any inferior processes.  How do I accomplish that?
Jul 03 20:37:04 <kergoth> you'd have to do it in the shell function. bitbake syntax has no unset, only setting to an empty string
Jul 03 20:37:10 <kergoth> iirc anyway
Jul 03 20:38:10 <teamnoir> That's all I could see either.  "export", and there's a mention in bitbake about "unexport", but I don't immediately see how to use it.
Jul 03 21:16:41 <mattaw> right, got the angstrom kernel booting on the SoC. Now trying to include the rootfs
Jul 03 21:17:01 <mattaw> of course this would go quicker if I knew what the hell I was doing :)
Jul 03 21:18:06 <mattaw> coupled with knowing what an initrd and initramfs were, how they are created and how the image I am making works. Oh yes, add in how you pass the command line to the kernel to run it
Jul 03 21:23:08 <likewise> nite all
Jul 03 21:37:41 <mattaw> nearly there. Think I have got angstrom off the ground on the LEON3
Jul 03 21:37:48 <mattaw> all power to OpenEmbedded!
Jul 03 21:44:06 <cdbot2> * * OE Bug 4408 has been created by gwossum(AT)acm.org
Jul 03 21:44:08 <cdbot2> * * CMake installed in wrong place
Jul 03 21:44:10 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4408
Jul 03 22:22:40 <CIA-24> 03tmbinc 07org.oe.dreambox * rd793a159... 10/ (3 files in 2 dirs): madwifi-ng: add missing patches
Jul 03 22:22:44 <CIA-24> 03tmbinc 07org.oe.dreambox * rb070cb78... 10/ (7 files in 3 dirs): madwifi: backport other changes from .dev
Jul 03 22:24:53 * ant_ sees all libfoo-perl failing miserably...
Jul 03 22:52:32 <tharvey> ipkg list shows the module I'm trying to install, but ipkg install gives me 'cannot find package' - not sure how to troubleshoot this
Jul 03 22:54:12 <flo_lap> tharvey: it might be available but not for a compatible architecture
Jul 03 22:56:10 <tharvey> how is that determined by ipkg?  Basically I'm using an angstrom dist, but I want to point to my locally built packages instead of angstrom so I removed /etc/ipkg/ and added 'src local ftp://$myserver/$path-to-oe/build/tmp/deploy/glibc/ipk/$machine
Jul 03 22:56:33 <tharvey> then did an ipkg update and it pulled Packages from that dir... but nowhere in Packages it shows an architecture - did I setup my src wrong?
Jul 03 23:01:10 <ant_> tharvey: .../deploy/glibc/ipk ?
Jul 03 23:01:40 <flo_lap> by the architecture part in the filename and the Packages file
Jul 03 23:03:04 <tharvey> ok... makes sense - so the package I'm tring to install is Filename: kernel-module-mxc-gpios_2.6.22.6-r1_mx31btech.ipk
Jul 03 23:03:11 <flo_lap> tharvey: ah... yes, you need more feeds. there should be one cpu specific one and one architecture independent one in addition to this
Jul 03 23:03:20 <tharvey> so the architecture is mx31btech...
Jul 03 23:03:38 <tharvey> flo_lap, ok... then I am trying to simplify things too much
Jul 03 23:04:12 <flo_lap> tharvey: yep, only the very necessary bits are device specific (e.g. kernel)
Jul 03 23:04:54 <flo_lap> tharvey: What happens is that these might depend on another package which is not available what causes ipkg to ignore the package.
Jul 03 23:05:04 <flo_lap> tharvey: I agree the error message is bad
Jul 03 23:06:47 <tharvey> so I shouldn't 'rm -rf /etc/ipkg/*' I should edit each of those feeds and replace 'http://www.angstrom-distribution.org/feeds/2008/ipk/glibc' with 'ftp://$serverip/$oepath/build/tmp/deploy/glibc/ipk'
Jul 03 23:06:48 <tharvey> right?
Jul 03 23:08:04 <flo_lap> tharvey: right
Jul 03 23:10:12 <tharvey> angstrom has /etc/ipkg/arch.conf which has a bunch fo 'arch all 1' like statements - are those setting up priorities?  
Jul 03 23:11:22 <flo_lap> tharvey: exactly
Jul 03 23:11:34 * flo_lap wors longer than mickey|zzZZzz ;)
Jul 03 23:11:39 <flo_lap> eh works
Jul 03 23:11:52 <tharvey> so 'arch all 1' is lowest priority right?  higher number higher priority?
Jul 03 23:11:53 <mickey|zzZZzz> ;) g'night
Jul 03 23:12:32 <ant_> flo_lap: for your good sleep:  make: *** No rule to make target `/usr/lib/perl/5.8/Config.pm', needed by
Jul 03 23:12:32 <ant_> `Makefile'.  Stop.
Jul 03 23:12:32 <ant_> | FATAL: oe_runmake failed
Jul 03 23:13:18 <flo_lap> mickey|zzZZzz: good night
Jul 03 23:13:20 <ant_> flo_lap: I'm collecting other bizarre Alignment trap for you too...
Jul 03 23:13:28 <flo_lap> tharvey: yes
Jul 03 23:13:51 <tharvey> I guess whats confusing me is angstroms feed directory structure is very different from build/tmp/deploy/glibc/ipk
Jul 03 23:14:14 <flo_lap> ant_: ehhhh perl... which package is this?
Jul 03 23:14:36 <ant_> fI fear a *lot* of modules...
Jul 03 23:14:54 <ant_> oebug 4392
Jul 03 23:15:07 <ant_> staging problems?
Jul 03 23:17:38 <tharvey> for example /etc/ipkg/arch.conf contains 'arch all 1' yet there is no file in /etc/ipkg/*.conf that defines a src name of 'all'
Jul 03 23:18:09 <tharvey> same thing with 'arch armv5te 31' - there is no conf that describes  a src called 'armv5te'
Jul 03 23:18:48 <flo_lap> ant_: looks like perl pulls in a wrong path /usr is always bad
Jul 03 23:19:38 <flo_lap> tharvey: hrm, I don't know offhand where these are... 
Jul 03 23:20:50 <ant_> tharvey: all armv5te c7x0 i686 are subdirs of /ipk
Jul 03 23:21:01 <ant_> in my case
Jul 03 23:21:12 <flo_lap> tharvey: "all" that is... for armv5te it is likely that it is compatible but you do not need any packages with that arch but you could install them if you had additional ones
Jul 03 23:22:35 <ant_> prism-firmware, gpe-icons, etc
Jul 03 23:22:44 <tharvey> ant_, right those are subdirs of /ipk on my oe build system, but not on http://www.angstrom-distribution.org/feeds/2008/ipk - so I'm having trouble seeing how to map my local feeds to angstroms feeds
Jul 03 23:22:53 <tharvey> looks like I simply need to google some docs on ipkg configuration
Jul 03 23:22:59 <flo_lap> right, gpe-icons should be "all"
Jul 03 23:23:10 * flo_lap needs a bed
Jul 03 23:23:34 <flo_lap> tharvey: just keep in mind that the arch config only lists all possible
Jul 03 23:23:53 <flo_lap> while the feed configuration files usually only have the necessaty ones
Jul 03 23:24:05 <ant_> there is a file in contrib/angstrom/build_feeds.sh
Jul 03 23:24:07 <tharvey> flo_lap, oh, you mean arch.conf lists 'possible' feeds, which is why some don't actually exist - ok I understand
Jul 03 23:25:07 <flo_lap> tharvey: more or less... its even more than only the feeds. e.g. the same applies for installing single packages file by file
Jul 03 23:26:33 <flo_lap> tharvey: btw. you might get the same error message that the package could not be found if you try to install a package from your local filesystem using the wrong arch
Jul 03 23:27:15 <flo_lap> I relly need to get some sleep... back in ~9 hours
Jul 03 23:27:18 <flo_lap> good night
Jul 03 23:27:31 <ant_> urgh..1.27pm
Jul 03 23:27:37 <ant_> nite!
Jul 03 23:27:42 <tharvey> thx for the help
Jul 03 23:27:58 <flo_lap> tharvey: yw
Jul 03 23:27:59 <flo_lap> gn
**** ENDING LOGGING AT Fri Jul 04 02:59:57 2008