**** BEGIN LOGGING AT Fri Jun 19 02:59:58 2009
Jun 19 05:04:22 <CIA-2> 03Rolf Leggewie <oe-devel@rolf.leggewie.biz> 07org.openembedded.dev * r036881b909 10openembedded.git/ (conf/checksums.ini recipes/ruby/ruby.inc): 
Jun 19 05:04:22 <CIA-2> ruby: introduce SHRT_VER to follow recent restructuring of upstream FTP server
Jun 19 05:04:22 <CIA-2> * update SRC_URI and checksums.ini
Jun 19 05:51:36 <recalcati_oe> morning
Jun 19 06:29:45 <CIA-2> 03Sebastian Krzyszkowiak <seba.dos1@gmail.com> 07shr/import * r720a9f1409 10openembedded.git/recipes/freesmartphone/ (frameworkd/frameworkd frameworkd_git.bb): 
Jun 19 06:29:45 <CIA-2> frameworkd: fix incorrect name in initscript
Jun 19 06:29:45 <CIA-2> Signed-off-by: Klaus Kurzmann <mok@fluxnetz.de>
Jun 19 07:12:14 <eFfeM> ok, removed my temp dir as DISTRO_PR was bumped and now I have the dreaded e2fsprogs problem again
Jun 19 07:13:15 <eFfeM> I'm more than happy to debug this, but I would need some suggestions/support as I am no good in neither python nor the build system
Jun 19 07:37:45 <recalcati_oe> eFfeM: do you know a scientific way to know how much ram is really available in a linux embedded system. the simple free or cat /proc/meminfo are not enough, for example they can show 1MB free, but I can malloc and use upto 25MB   ?
Jun 19 07:52:52 <pb___> recalcati_oe: there isn't really any way to determine that.  the kernel doesn't expose that information to processes.
Jun 19 08:00:44 <eFfeM> recalcati_oe: if you have swap then it also depends on your swap space
Jun 19 08:01:21 <eFfeM> but you never can't tell up to the byte even if there is no swap as allocation goes by pages
Jun 19 08:02:17 <eFfeM> also the size of the data chunk that you malloc will have effect (small sizes might allow to alloc more as they are less vulnerable to fragmentation
Jun 19 08:04:08 <eFfeM> rebooting
Jun 19 08:05:08 <Longfield> morning
Jun 19 08:06:21 <Longfield> is anyone here familiar with cmake in OE ?
Jun 19 08:09:10 <Goddchen> i'm having trouble to boot my angstrom image (created with oe, console-image) in qemu, everything seems to be fine, except i don't get a login shell
Jun 19 08:09:13 <Goddchen> i'm having trouble to boot my angstrom image (created with oe, console-image) in qemu, everything seems to be fine, except i don't get a login shell
Jun 19 08:09:17 <Goddchen> whoops
Jun 19 08:09:23 <Goddchen> http://goddchen.pastebin.com/m525b2e93
Jun 19 08:09:25 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rfab2a49c1a 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev
Jun 19 08:09:35 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r029db62688 10openembedded.git/conf/checksums.ini: checksums: add some more checksums
Jun 19 08:09:36 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r31d6afe558 10openembedded.git/recipes/dvsdk/ (ti-dmai.inc ti-dmai_svn.bb): 
Jun 19 08:09:36 <CIA-2> ti-dmai: bump SRCREV and fix path to cross-compiler
Jun 19 08:09:36 <CIA-2> * calling compiler with their full path is bogus anyway
Jun 19 08:36:16 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * r9b90a9c715 10openembedded.git/recipes/linux/ (linux-2.6.29/tqm8540/defconfig linux_2.6.29.bb): 
Jun 19 08:36:16 <CIA-2> linux-2.6.29: add a default kernel for tqm8540
Jun 19 08:36:16 <CIA-2> Now a correct commit, sorry for the previous attempt.
Jun 19 08:36:16 <CIA-2> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Jun 19 09:13:38 <Longfield> I have an svn fetch packages, and even if I remove all the needed files, bitbake does not fetch the sources anymore ...
Jun 19 09:14:13 <pb_> which files exactly did you remove?
Jun 19 09:19:14 <Longfield> DL_DIR/svn rep and all svn.rep.packages files in DL_DIR
Jun 19 09:20:09 <Longfield> pb_: and I also removed the work rep for the recipe
Jun 19 09:20:21 <pb_> and the tarball and its md5 file?
Jun 19 09:20:46 <Longfield> pb_: yeah, that's what I meant with svn.rep.packes files
Jun 19 09:21:06 <pb_> okay, so what exactly happens when you run bitbake?
Jun 19 09:21:11 <woglinde> hi
Jun 19 09:21:16 <pb_> is it trying to unpack a nonexistent tarball?
Jun 19 09:21:20 <Longfield> bitbake directly starts at do_configure (which fails because of no source files ....)
Jun 19 09:21:28 <woglinde> !ping florian
Jun 19 09:21:29 <cdbot2> pong
Jun 19 09:21:31 <pb_> oh, right.  did you delete the stamps?
Jun 19 09:21:41 <Longfield> stamps ?
Jun 19 09:21:43 <pb_> yes
Jun 19 09:21:43 <woglinde> hi longfield
Jun 19 09:21:49 <Longfield> hi woglinde
Jun 19 09:22:01 <pb_> they're in the tmp/stamps directory
Jun 19 09:22:12 <pb_> if you blow away the WORKDIR, which it sounds like you did, you need to remove the stamps as well.
Jun 19 09:22:19 <woglinde> *g*
Jun 19 09:22:20 <woglinde> yes
Jun 19 09:22:20 <Longfield> ok, let's remove the stamps
Jun 19 09:22:28 <pb_> the easiest way to do that is just to use "bitbake -c clean", which will remove both the stamps and the workdir in one go.
Jun 19 09:22:44 * Longfield takes notice
Jun 19 09:22:58 <woglinde> hm why the hack cygwin dont ship qt yet
Jun 19 09:25:03 <woglinde> hm okay the ship qt3
Jun 19 09:25:07 <woglinde> but not 4
Jun 19 09:26:45 <woglinde> he florian
Jun 19 09:29:11 <Longfield> thx _pb, it now fetches and I have the sources back in place
Jun 19 09:33:12 <pb_> very good
Jun 19 09:33:18 <pb_> florian_kc: good morning
Jun 19 09:34:21 <wyzzopt991> autoghost.pl
Jun 19 09:35:01 <woglinde> ???
Jun 19 09:37:44 <pb_> that seems to be a popular comment in this channel nowadays
Jun 19 09:39:23 <Laibsch> pb_: did the gpe-image boot for you?
Jun 19 09:39:37 <Laibsch> I get a similar result as for the opie-image
Jun 19 09:39:42 <Laibsch> no GUI
Jun 19 09:39:45 <pb_> Laibsch: sort of.  I got as far as the login screen, but the touchpanel didn't work and I didn't get any fonts either.
Jun 19 09:39:58 <Laibsch> same kind of message: init respawning too fast
Jun 19 09:40:03 <pb_> the touchpanel thing was probably my qemu misconfiguration, I'm not sure what you're meant to do to have it emulate a touchscreen
Jun 19 09:40:22 <pb_> or, indeed, what touchscreen driver would be appropriate on i386
Jun 19 09:40:27 <Laibsch> alright, let's take a closer look one of these days
Jun 19 09:40:29 <RP> pb_: usb wacom driver
Jun 19 09:40:37 <pb_> fonts is obviously a micro-image problem, just a missing package I expect
Jun 19 09:40:47 <Laibsch> pb_: try poky-qemu
Jun 19 09:40:49 <pb_> RP: ah right, thanks
Jun 19 09:41:05 <Laibsch> with it, I can at least boot poky images correctly
Jun 19 09:41:18 <pb_> Laibsch: but I didn't get the "respawning too fast" thing.  remind me what distro you were using?
Jun 19 09:41:21 <RP> pb_: For x86 I've had success with the vmmouse xorg driver too
Jun 19 09:41:41 <Laibsch> pb_ minimal
Jun 19 09:47:32 <pb_> Laibsch: I guess that might be the difference.  I haven't tried that one.
Jun 19 09:56:17 <woglinde> hi laibsch
Jun 19 09:56:35 * Laibsch winkt zurück
Jun 19 10:24:03 <woglinde> lunch
Jun 19 10:25:43 <pb_> no thanks, it's a bit early
Jun 19 10:26:47 <florian> :-)
Jun 19 10:27:12 <pb_> hm, this esdi controller really doesn't want to cooperate
Jun 19 10:27:16 * pb_ gives it a stern look
Jun 19 10:28:46 <florian> hmm... yes there was a time harddisk controllers were really hard to make work properly. :)
Jun 19 10:30:15 <pb_> yeah, it's all coming back to me
Jun 19 10:30:26 <CIA-2> 03rpurdie * r1180 10/ (10 files in 6 dirs): Merge the BBCLASSEXTEND code from Poky. This allows once recipe to provide mutliple targets (e.g. -native and -sdk) and has been discussed on the OE mailing list
Jun 19 10:31:41 <pb_> florian: by the way, did you ever get a response from the rest of the oe board about this membership voting business?
Jun 19 10:33:44 <CIA-2> 03Stanislav Brabec <utx@penguin.cz> 07org.openembedded.dev * r32336c5325 10openembedded.git/recipes/angstrom/angstrom-x11-base-depends.bb: angstrom-x11-base-depends: Bump PR to get new XSERVER for spitz and akita.
Jun 19 10:37:44 <florian> pb_: zecke replied... but its I guess I need to go ahead myself again. 
Jun 19 10:38:42 <florian> But we are making progress. We get a bank account which is supposed to be free of charges.
Jun 19 10:43:38 <pb_> florian: very good
Jun 19 11:10:00 <Goddchen> hi, seems like my INIT doesn't work (compile console-image for qemuarm machine). it just hangs
Jun 19 11:10:31 <Goddchen> when passing "init=/bin/sh" to boot parameters i end up in sh but of course nothing is initialized
Jun 19 11:12:29 <woglinde> re
Jun 19 11:12:35 <Goddchen> wb
Jun 19 11:13:09 <pb_> Goddchen: what happens if you try to run /sbin/init by hand?
Jun 19 11:13:37 <Goddchen> Usage: init 0123456SsQqAaBbCcUu
Jun 19 11:13:56 <Goddchen> and when i run it with any number i get:
Jun 19 11:13:59 <pb_> ok, very good.  how about "exec /sbin/init"?
Jun 19 11:14:13 <Goddchen> # /sbin/init 1
Jun 19 11:14:13 <Goddchen> init: timeout opening/writing control channel /dev/initctl
Jun 19 11:14:38 <Goddchen> oh, with exec it works
Jun 19 11:14:49 <Goddchen> but same as calling it directly from the boot process, it just hangs
Jun 19 11:15:12 <pb_> does it do anything at all before it hangs?
Jun 19 11:15:13 <Goddchen> http://goddchen.pastebin.com/m4cbb4ad3
Jun 19 11:15:36 <pb_> oh right
Jun 19 11:15:50 <pb_> well, that's not a problem with init itself, it's getting much further than that
Jun 19 11:15:59 <pb_> it sounds like your startup scripts are just broken
Jun 19 11:16:17 <Goddchen> i didn't touch them
Jun 19 11:16:38 <pb_> sure, I didn't mean that you personally had broken them.
Jun 19 11:16:46 <pb_> but, it appears that whatever your distro is shipping doesn't work.
Jun 19 11:16:54 <Goddchen> angstrom
Jun 19 11:17:09 <Goddchen> actually i use "angstrom-2008.1"
Jun 19 11:17:20 <pb_> might be best to ask in #angstrom, I think this is where their h4x0rs hang out
Jun 19 11:17:34 <pb_> I don't know anything about how the angstrom boot process is meant to work
Jun 19 11:17:43 <Goddchen> i did this morning and a few minutes ago, without any answers ;)
Jun 19 11:17:48 <Goddchen> hm ok
Jun 19 11:17:50 <Goddchen> i understand
Jun 19 11:18:00 <pb_> or try their mailing list, perhaps
Jun 19 11:19:01 <Goddchen> bw, another question:
Jun 19 11:19:19 <Goddchen> when i mount the rootfs rw from the beginning via boot parameter i get the message "No space left on device"
Jun 19 11:19:48 <Goddchen> which is of course correct, because the image file only holds the data and to free space, is this normal behaviour?
Jun 19 11:19:49 <pb_> that sounds like your filesystem is just full.  what do "df" and "df -i" say?
Jun 19 11:20:29 <Goddchen> hehe it sais df: /proc/mounts: No such file or directory
Jun 19 11:20:32 <pb_> heh
Jun 19 11:20:50 <pb_> mount p /proc -t proc
Jun 19 11:21:22 <Goddchen> oh, actually there is some free space
Jun 19 11:21:34 <Goddchen> dev/root                65367     25009     37082  40% /
Jun 19 11:21:46 <pb_> but, as to whether the filesystem is meant to have any free space or not, that again is really a question for angstrom.  I would have expected that there would be some but it depends what their intended usage for those images is.
Jun 19 11:23:25 <RP> Does anyone see a problem with bitbake trunk requiring python 2.6?
Jun 19 11:23:53 <pb_> no, not really.  what's the feature in 2.6 that you want to use?
Jun 19 11:24:36 <woglinde> hm?
Jun 19 11:24:41 <woglinde> transition to 3.0?
Jun 19 11:24:49 <RP> pb_: self.timeout buried in the SocketServer
Jun 19 11:25:12 <Goddchen> hm hopefully somebody in #angstrom will read my question...
Jun 19 11:25:17 <RP> pb_: We used to do it by overriding the get_request() call back for 2.5 but its a horrible hack which broke for 2.6
Jun 19 11:25:33 <RP> and they've added an intereface to do what we need now
Jun 19 11:26:12 <pb_> fair enough.  so long as 2.6 is in most of the common distros, which I think it is, that sounds fine.
Jun 19 11:26:33 <pb_> obviously it'd be a bit sad if people had to build python from source, or install g3nt00 or something in order to run bitbake
Jun 19 11:27:06 <RP> pb_: indeed, By the time trunk is useful for people I suspect 2.6 shouldn't be an issue
Jun 19 11:28:01 <pb_> righto
Jun 19 11:28:07 <pb_> yeah, might as well go ahead and do it as far as I'm concerned
Jun 19 11:30:16 <RP> I'd better send an email about it I guess
Jun 19 11:38:05 <woglinde> hm lenny hasnt python 2.6
Jun 19 11:40:21 <gremlin[it]> hi all 
Jun 19 11:40:40 <gremlin[it]> finally i got a EBVBeagle on my hands ;) 
Jun 19 11:41:46 <woglinde> hi gremlin
Jun 19 11:41:53 <gremlin[it]> hi woglinde 
Jun 19 11:42:05 <woglinde> whats better on ebv?
Jun 19 11:42:49 <gremlin[it]> basically it's a kit ... beagle + cables + usb hub + usb eth + power adapters 
Jun 19 11:43:19 <gremlin[it]> but i just notice it have the "old" power control chip respect to DigiKey Beagle C2 
Jun 19 12:32:12 <woglinde> hi gnutoo
Jun 19 12:32:27 <Gnutoo> woglinde, hi
Jun 19 12:32:41 <Gnutoo> woglinde, I'll eat and be back soon
Jun 19 12:47:38 <Gnutoo> I'm back
Jun 19 12:47:45 <woglinde> re gnutoo
Jun 19 12:49:48 <Gnutoo> mmm...| install: cannot stat `arch/mips/brcm-boards/bcm947xx/compressed/piggy': No such file or directory  ...but which piggy is it?
Jun 19 12:50:38 <Gnutoo> piggy.gz ? or piggy.o ?
Jun 19 12:50:44 <Gnutoo> I bet it's the gz part
Jun 19 12:50:50 <Gnutoo> strange
Jun 19 12:51:37 <woglinde> *g*
Jun 19 12:51:45 <woglinde> bcm *suckz*
Jun 19 12:51:47 <woglinde> *g*
Jun 19 12:52:10 <Gnutoo> yes but it's 2.6.30 kenrel
Jun 19 12:52:20 <Gnutoo> not proprietary 2.4 
Jun 19 12:53:07 <Gnutoo> and I've only a wrt54gs v4 as router for playing with(my main router is an x86 one)
Jun 19 12:54:51 <woglinde> gnutoo was only a joke
Jun 19 12:54:59 <Gnutoo> ok lol
Jun 19 12:55:01 <woglinde> the problem should be easily fixable
Jun 19 12:56:04 <Gnutoo> I'm looking in it now...but I didn't spot the joke because yesterday someone told someone else not to buy broadcom based router in #openwrt because they sucked...
Jun 19 12:58:54 <Gnutoo> maybe it's because I use lzma
Jun 19 13:04:36 <Gnutoo> I'll try something...
Jun 19 13:04:37 <woglinde> yeah
Jun 19 13:04:44 <woglinde> lzma is to new
Jun 19 13:06:14 <Gnutoo> no I bet it's the machine or distro config
Jun 19 13:06:26 <Gnutoo> because I use a 2.6 kernel and should use a 2.4
Jun 19 13:08:08 <Gnutoo> ah no it's not that
Jun 19 13:08:27 <Gnutoo> but it does strange things like make dep that is for a 2.4 kernel
Jun 19 13:08:34 <hrw> morning
Jun 19 13:08:38 <Gnutoo> hi
Jun 19 13:09:41 <Ainulindale> Would anybody know why libsdl-x11 configure is patched with that? http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/libsdl/files/configure_tweak.patch?h=shr/import
Jun 19 13:09:44 <Ainulindale> No apparent reason
Jun 19 13:10:35 <Ainulindale> It's not possible to enable alsa with that patch
Jun 19 13:10:41 <Gnutoo> I bet the commit log gives no indications
Jun 19 13:10:47 <woglinde> hi hrw
Jun 19 13:11:08 <Ainulindale> Gnutoo: Well if it did I wouldn't ask, would I? :-)
Jun 19 13:11:24 <Gnutoo> ok
Jun 19 13:11:43 <Gnutoo> that why I said that "I bet that"
Jun 19 13:12:00 <Ainulindale> It does some stuff which is necessary, then for alsa removes a bunch of directives and in the end does enable_alsa=no
Jun 19 13:12:04 <Ainulindale> So the configure thing is of no use
Jun 19 13:12:32 <Gnutoo> mmm the kenrel configuration seems much more longer now...maybe it was my kernel config
Jun 19 13:12:39 <woglinde> Ainulindale its time to update to sdl 1.2.13 anyway
Jun 19 13:14:32 <Ainulindale> Well yeah but meanwhile ... :-)
Jun 19 13:14:53 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r1e538fcb15 10openembedded.git/recipes/dvsdk/gstreamer-ti_svn.bb: gstreamer-ti: fix build with non-external toolchains
Jun 19 13:14:58 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rb25b3f4965 10openembedded.git/ (72 files in 4 dirs): 
Jun 19 13:14:58 <CIA-2> linux-omap-pm git: start syncing with linux-omap non-pm
Jun 19 13:14:58 <CIA-2> * also add dvsdk defines to omap3.inc
Jun 19 13:14:58 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r8b4c4053b8 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev
Jun 19 13:15:01 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r1549dbbad7 10openembedded.git/recipes/geoclue/ (files/gtk-doc.make geoclue_git.bb): geoclue: update to 0.11.1 + git
Jun 19 13:17:30 <CIA-2> 03Jeremy Lainé <jeremy.laine@m4x.org> 07org.openembedded.dev * rde37408939 10openembedded.git/: Merge branch 'org.openembedded.dev' of ssh://git@git.openembedded.net/openembedded into org.openembedded.dev
Jun 19 13:17:41 <CIA-2> 03Jeremy Lainé <jeremy.laine@m4x.org> 07org.openembedded.dev * r804c811516 10openembedded.git/recipes/glibc/ (glibc_2.7.bb glibc_2.9.bb): glibc_2.[79].bb: remove extra quote from SRC_URI for powerpc
Jun 19 13:30:57 <woglinde> hm plam released some source code
Jun 19 13:32:14 <woglinde> and most of the patches are taken from oe because they use oe
Jun 19 13:32:33 <CIA-2> 03Philip Balister <philip@balister.org> 07org.openembedded.dev * r617f8b6d64 10openembedded.git/ (conf/checksums.ini recipes/fann/fann_2.0.0.bb): 
Jun 19 13:32:33 <CIA-2> fann-2.0.0 : Add recipe for Fast Artificial Neural Network Library.
Jun 19 13:32:33 <CIA-2> This recipe stages the headers into /usr/include. This matches the Debian
Jun 19 13:32:33 <CIA-2> way, but not the Fedora way. Some adjustments will be needed for packages
Jun 19 13:32:33 <CIA-2> that use fann by including <fann/fann.h>
Jun 19 13:32:37 <CIA-2> Motivation provided by Elvis Dowson. Thanks!
Jun 19 13:32:48 <Crofton> hmm
Jun 19 13:33:03 <Crofton> I was hoping a blank line would stop cia from picking up the explanation
Jun 19 13:33:05 <Crofton> oh well
Jun 19 13:34:22 <woglinde> its okay
Jun 19 13:44:15 <Gnutoo> mmm I have: * zImage        - Compressed kernel image (arch/arm/boot/zImage)
Jun 19 13:44:47 <Gnutoo> make: *** No rule to make target `zImage'.  Stop.
Jun 19 13:45:12 <Gnutoo> oups I made ARCH=arm....lol
Jun 19 13:45:18 <Gnutoo> I was used to do that...
Jun 19 13:59:38 <woglinde>  zImage was removed for x86
Jun 19 14:25:43 <hrw> the good news: flyers are in print
Jun 19 14:26:02 <hrw> the bad news: may not be ready for LT first day
Jun 19 14:26:33 <hrw> I wonder when our zaurus guys will switch to 2.6.30 to get lzma compressed kernels
Jun 19 14:37:08 <woglinde> hrw hm maybe florian can print something for the first day
Jun 19 14:37:43 <hrw> I will know on monday how things are
Jun 19 14:39:43 <florian> hrw: I can print some, can you send me the latest version?
Jun 19 14:44:14 <hrw> florian: http://linuxtogo.org/~mickeyl/misc/OE-Flyer.pdf
Jun 19 14:44:45 <hrw> btw:  http://opensource.palm.com/packages.html
Jun 19 14:47:12 <hrw> bye
Jun 19 15:04:32 <Gnutoo> hi, no-one is responding in #openwrt...I bet I'll have to wait for knowing safe memory locations to load the kernel and to know how to load it and execute with pmon
Jun 19 15:05:13 <Gnutoo> there are the command load and boot but I'd like to be shure before using them
Jun 19 15:05:20 <kergoth> morning
Jun 19 15:05:29 <pb_> yo kergoth
Jun 19 15:05:44 <kergoth> hey pb_ 
Jun 19 15:06:11 <Gnutoo> because it seems to be different from uboot and the documentation isn't great
Jun 19 15:08:25 <woglinde> jo kergoth
Jun 19 15:09:05 <kergoth> damn, i should fix this patch resolver stuff, it isn't correctly using TERMCMD to spawn a shell if a patch has rejects
Jun 19 15:09:07 <kergoth> hrm
Jun 19 15:12:26 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r19cf11e6aa 10openembedded.git/recipes/linux/ (97 files in 12 dirs): linux-omap-pm: add .6.29 recipe so the git one can move to 2.6.30
Jun 19 15:12:35 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r3e80dbd5bb 10openembedded.git/: Merge branch 'org.openembedded.dev' of git@git.openembedded.org:openembedded into org.openembedded.dev
Jun 19 15:14:21 <pb_> kergoth: I never did manage to figure out how to apply the git stash by hand, by the way.  ended up just reverting the files to a non-conflicting state and doing "git stash apply".
Jun 19 15:14:23 <pb_> all rather weird
Jun 19 15:14:30 <kergoth> damn, that's really weird indeed
Jun 19 15:15:08 <pb_> yeah, oh well
Jun 19 15:15:37 <pb_> on another topic, do you remember which .bb file it is that creates the static nodes in /dev?
Jun 19 15:15:52 <pb_> I'm getting a pile of them in my micro-image that I don't want, but I can't remember where they come from :-}
Jun 19 15:18:16 <kergoth> hrm.. 
Jun 19 15:18:28 <pb_> doh, what, why is iphone-rootfs providing libc-for-gcc?!
Jun 19 15:18:45 <kergoth> haha
Jun 19 15:19:16 <pb_> all of a sudden bitbake is deciding to download all this crazy iphone stuff.
Jun 19 15:19:23 <kergoth> pb_: looks like initscripts both depends and rdepends on makedevs, that looks promising.
Jun 19 15:19:31 <pb_> kergoth: aha, thanks
Jun 19 15:20:01 <kergoth> should probably split some of that up :)
Jun 19 15:20:07 <kergoth> i wonder if anyone's messed with upstart in OpenEmbedded
Jun 19 15:21:01 <pb_> yeah, the situation with the startup scripts is a bit of a mess at the moment.  I'd like to get rid of sysvinit from micro-image but I've never quite dared to do that because it also ships a pile of important-looking startup bits.
Jun 19 15:21:13 <pb_> also, the division of responsibility between sysvinit and initscripts is a bit vague
Jun 19 15:21:48 <kergoth> indeed
Jun 19 15:21:49 <pb_> upstart does sound quite cute but I've never actually used it.
Jun 19 15:21:57 <kergoth> me neither
Jun 19 15:22:17 <kergoth> we may end up having to delve into that mess at mv, due to lsb stuff
Jun 19 15:22:30 <pb_> the other one I keep meaning to look at is the busybox init.  don't really know anything about that either, although it scares me a bit.
Jun 19 15:22:51 <kergoth> busybox init has no runlevels ,right?
Jun 19 15:22:59 <pb_> I think that's right
Jun 19 15:23:23 <pb_> which, to be fair, is probably ok for 90% of embedded systems anyway.
Jun 19 15:23:38 <pb_> and probably at least 75% of desktops, come to that.
Jun 19 15:24:09 <woglinde> kergoth palm
Jun 19 15:24:12 <XorA> runlevels only work if you have some way to switch them :-)
Jun 19 15:24:14 <woglinde> has upstart
Jun 19 15:24:20 <pH5> upstart 0.3.8 is from march 2007, doesn't seem like there was any recent activity in oe.dev
Jun 19 15:24:36 <kergoth> woglinde: yeah i saw that.. wonder if they'd make what they've done there available :)
Jun 19 15:24:38 <woglinde> but I believe the succers will not share the .bb with us
Jun 19 15:24:43 * kergoth doubts it
Jun 19 15:24:45 * kergoth nods
Jun 19 15:25:07 <XorA> I looked up upstart for OM, but like all OM tasks I was never left in peace long enough to make it work
Jun 19 15:25:43 * kergoth chuckles
Jun 19 15:25:46 <XorA> wasted my time doing a .bb for qtopia-phone instead
Jun 19 15:25:47 <pH5> http://opensource.palm.com/packages.html lists upstart and palms modifications
Jun 19 15:25:58 <woglinde> ph5 yes
Jun 19 15:26:02 <woglinde> but not the .bb
Jun 19 15:26:05 <pb_> doh, after all this drama with esdi controllers, I suddenly realised that the drive I've been trying to connect is not the one I wanted anyway.
Jun 19 15:26:08 <pb_> ~fishslap me
Jun 19 15:26:24 <woglinde> pb *g*
Jun 19 15:26:27 <Gnutoo> pH5, wow thanks
Jun 19 15:26:48 <Gnutoo> pH5, are you from palm?
Jun 19 15:28:01 <kergoth> pH5: interesting, no build scripts or metadata, but the source is still helpful :)
Jun 19 15:28:02 <kergoth> hmm
Jun 19 15:28:10 * kergoth gets caffeine
Jun 19 15:28:11 <pH5> Gnutoo: hehe, no. I just read laforge's blog.
Jun 19 15:28:28 <Gnutoo> ah ok becuase I wondered how much freedom you get with that phone
Jun 19 15:28:47 <Gnutoo> I should write on the mailing list for asking about...
Jun 19 15:29:27 <eut> hello
Jun 19 15:29:41 <kergoth> “I am rather like a mosquito in a nudist camp; I know what I want to do, but I don’t know where to begin.” - Stephen Bayne
Jun 19 15:30:12 <eut> is there a way for me to define some extra commands i want to be run in do_stage() while still having bitbake run the default?
Jun 19 15:30:49 <kergoth> eut: from a recipe, yes — do_stage_append, or define a do_stage and call the class's do_stage from it.  i.e. do_stage() { mystuff; autotools_do_stage }
Jun 19 15:31:01 <eut> ah great
Jun 19 15:31:02 <eut> thanks
Jun 19 15:32:02 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * r3165281acd 10openembedded.git/recipes/u-boot/ (10 files): 
Jun 19 15:32:02 <CIA-2> u-boot: drop PACKAGE_ARCH from individual recipes
Jun 19 15:32:02 <CIA-2> As PACKAGE_ARCH is now set in main u-boot file, drop it from all recipes.
Jun 19 15:32:02 <CIA-2> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Jun 19 15:32:04 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * ra7f82b5da8 10openembedded.git/recipes/u-boot/u-boot.inc: 
Jun 19 15:32:07 <CIA-2> u-boot: set PACKAGE_ARCH to MACHINE_ARCH in .inc
Jun 19 15:32:09 <CIA-2> u-boot should be generated on per-machine base. Set PACKAGE_ARCH in .inc
Jun 19 15:32:11 <CIA-2> file so all u-boot's inherit it.
Jun 19 15:32:13 <CIA-2> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Jun 19 15:32:15 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * rbb103dc3d8 10openembedded.git/recipes/u-boot/ (u-boot_2009.01.bb u-boot_2009.06.bb): 
Jun 19 15:32:18 <CIA-2> u-boot: upgrade at91sam9g20ek from 2009.01 to 2009.06
Jun 19 15:32:20 <CIA-2> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Jun 19 15:32:22 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * rb0feb8aed2 10openembedded.git/: Merge branch 'org.openembedded.dev' of git://git.openembedded.org/openembedded into org.openembedded.dev
Jun 19 15:32:25 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * rdc858e127b 10openembedded.git/recipes/lowpan-tools/lowpan-tools_git.bb: 
Jun 19 15:32:32 <CIA-2> lowpan-tools: bump git srcrev
Jun 19 15:32:34 <CIA-2> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Jun 19 15:35:57 <eut> kergoth, i'm getting 'autotools_do_stage command not found'
Jun 19 15:36:24 <kergoth> erm, s/do_stage/stage_all/;  i forgot that autotools doesn't provide you a stage task at all.
Jun 19 15:36:28 <kergoth> base provides an empty one
Jun 19 15:36:40 <kergoth> so you dont need to call a stage at all, or append, just define yours :P
Jun 19 15:36:57 <kergoth> or call autotools_stage_all to automatically stage your headers and libraries if you use autotools
Jun 19 15:37:31 <eut> i essentially just want to tack on 3 oe_libinstall lines because the package provides some libs
Jun 19 15:38:11 <woglinde> eut hm?
Jun 19 15:38:21 <woglinde> isnt autotools doing it for you?
Jun 19 15:38:47 <eut> other packages depend on those libs and the system doesnt seem to find them unless i add the oe_libinstall lines
Jun 19 15:38:55 <kergoth> autotools doesn't provide a useful stage method unless you're native or inherit autotools_stage
Jun 19 15:39:23 <kergoth> eut: just make a stage method that calls autotools_stage_all, and see if that fixes it.  if not you can always do it manually :)
Jun 19 15:39:32 <eut> heh ok
Jun 19 15:39:44 <eut> for now i will try inheriting autotools_stage :]
Jun 19 15:39:48 <kergoth> :)
Jun 19 15:40:23 <eut> arg.. could not inherit from autotools_stage.bbclass while parsing....
Jun 19 15:40:55 <kergoth> er, what's the error?
Jun 19 15:41:22 <kergoth> all autotools_stage does is inherits autotools and gives you a do_stage that calls autotools_stage_all, shouldtn be anything to fail
Jun 19 15:41:27 <eut> ERROR: Could not inherit file classes/autotools_stage.bbclass while parsing package.bb
Jun 19 15:41:37 <kergoth> no, there's almost certainly messages above that.
Jun 19 15:41:41 <kergoth> WHY didn't it inherit it?
Jun 19 15:42:02 <eut> NOTE: Handling BitBake files: | (4977/4978) [99 %]ERROR: Could not inherit....
Jun 19 15:42:25 <eut> *trying autotools_stage_install*
Jun 19 15:42:26 <kergoth> well, dunno what to tell you.  classes/autotools_stage.bbclass exists in upstream OpenEmbedded and works just fine for other recipes
Jun 19 15:42:33 <kergoth> it's autotools_stage_all.
Jun 19 15:42:58 <kergoth> ERROR: Task /home/clarson/oe/projects/oe-recipe_sanity/collections/oe/recipes/shasum/shasum-native.bb (do_recipe_sanity) has circular dependency on /home/clarson/oe/projects/oe-recipe_sanity/collections/oe/recipes/stage-manager/stagemanager-native_0.0.1.bb (do_recipe_sanity)
Jun 19 15:43:00 <kergoth> what the hell
Jun 19 15:44:39 <kergoth> shasum-native's DEPENDS is *empty*
Jun 19 15:44:43 <kergoth> so how is that a circular dep?
Jun 19 15:44:45 * kergoth grumbles
Jun 19 15:46:08 <RP> kergoth: You can have task level dependencies and other subtle details
Jun 19 15:46:26 <kergoth> yeah, i know, but i dont have any of those on the task it just errored on.
Jun 19 15:46:46 <RP> We really need better error debugging
Jun 19 15:46:58 <kergoth> just a recrdeptask on itself to run it on the deps, thats it
Jun 19 15:46:59 * kergoth nods
Jun 19 15:47:19 <RP> kergoth: it could be the recrdeptask
Jun 19 15:47:34 <RP> iirc you have to have a two tasks and play games with that :(
Jun 19 15:47:58 <RP> Somewhere bitbake need to be taught not to insert a self dependency
Jun 19 15:49:12 <kergoth> ahhh
Jun 19 15:49:20 <kergoth> but this has worked in the past
Jun 19 15:49:23 <kergoth> I've run it before
Jun 19 15:49:27 <kergoth> hrmph
Jun 19 15:50:46 <woglinde> *g*
Jun 19 15:56:10 <eut> kergoth, autotools_stage_all inside of do_stage() {} worked
Jun 19 15:56:19 <eut> :]
Jun 19 15:56:25 <eut> thanks for the help
Jun 19 16:01:02 * kergoth scratches head
Jun 19 16:02:16 <kergoth> what the hell do you mean task do_recipe_sanity_all doesn't exist for task-boot ,i just fucking created the task
Jun 19 16:02:19 * kergoth thinks
Jun 19 16:02:59 <Crofton> heh
Jun 19 16:03:22 <kergoth> aha, rogue copy of the class floating around in BBPATH
Jun 19 16:03:24 <kergoth> i hate it when that happens
Jun 19 16:04:21 <woglinde> *g*
Jun 19 16:06:04 <keesj> any clue what PSG_MODULE is in a configure.ac ?
Jun 19 16:06:26 <kergoth> check the macros in aclocal.m4
Jun 19 16:12:25 <kergoth> whee, NOTE: gcc-cross 4.3.3 r4.1: recipe_sanity: native or cross recipe with non-empty PACKAGES
Jun 19 16:12:28 <kergoth> minor thing, but what the heck
Jun 19 16:12:38 <pb_> very good
Jun 19 16:12:53 <Tartarus> libgcc, iirc
Jun 19 16:12:58 <Tartarus> that's all just wierd, heh
Jun 19 16:13:52 <pb_> kergoth: I was wondering whether it'd be possible to teach kergoth_sanity to detect that situation that cropped up on the mailing list the other day, where you have two variables which will collide when the left hand sides are expanded.
Jun 19 16:14:06 <pb_> i.e. the RDEPENDS_${PN} vs RDEPENDS_foo thing
Jun 19 16:14:34 <kergoth> hmm, good question, i'll try adding it
Jun 19 16:15:02 <CIA-2> 03Chris Larson <clarson@mvista.com> 07org.openembedded.dev * r5c66c828be 10openembedded.git/classes/recipe_sanity.bbclass: 
Jun 19 16:15:02 <CIA-2> recipe_sanity: add check for PACKAGES in native/cross and split to recipe_sanity_all.
Jun 19 16:15:02 <CIA-2> Signed-off-by: Chris Larson <clarson@mvista.com>
Jun 19 16:16:59 * kergoth thinks
Jun 19 16:17:06 <pb_> uh-oh
Jun 19 16:17:09 <kergoth> :)
Jun 19 16:21:14 <woglinde> okay
Jun 19 16:21:18 <woglinde> time to heading home
Jun 19 16:21:23 <woglinde> good bye till later
Jun 19 16:23:34 * kergoth might have to do something rather twisted to accomplish this.. hmm
Jun 19 16:36:21 * kergoth chuckles as he hijacks bb.build.data_smart.DataSmart.renameVar
Jun 19 16:37:51 <prpplague> kergoth: make sure you check that there are no babies in the back seat
Jun 19 16:38:14 * kergoth really needs to spend more quality time with zecke's parsing patchset
Jun 19 16:38:36 <prpplague> kergoth: red lobster and a movie?
Jun 19 16:38:56 * prpplague jokes with kergoth 
Jun 19 16:39:43 <kergoth> hehe
Jun 19 16:44:56 <Tartarus> Fucking hell I hate opkg.  Today is the day I get "Could not obtain administrative lock" errors for fun on some recipes but not others
Jun 19 16:45:06 <Tartarus> (meta-toolchain* yes, images no)
Jun 19 16:45:27 <prpplague> Tartarus: hehe
Jun 19 16:45:33 <kergoth> fun fun
Jun 19 17:05:55 <hoj> dumbq: is there a bitbake way to show which packages are installed?
Jun 19 17:06:02 <kergoth> "installed"?
Jun 19 17:08:15 <hoj> that doesn't seem to be a bitbake flag ..
Jun 19 17:08:27 <kergoth> what do you mean by installed?
Jun 19 17:09:27 <hoj> package has passed the do_install phase.   Or maybe that state info is not kept (like rpm does)
Jun 19 17:09:47 <kergoth> uh
Jun 19 17:09:51 <kergoth> do_install is just used to create packages
Jun 19 17:09:54 <kergoth> that's all
Jun 19 17:09:58 <kergoth> it doesn't install into an image or something
Jun 19 17:10:10 <kergoth> image recipes take the packages emitted by the other recipes and use them to create an image
Jun 19 17:10:19 <kergoth> the fact that a recipe happens to have had do_install run is meaningless.
Jun 19 17:10:25 <kergoth> and will tell you absolutely nothing
Jun 19 17:12:11 <hoj> hm.   Where is the order of operations done, for ex: doing '-c patch' knows that do_unpack has to be done first, right?
Jun 19 17:15:44 <kergoth> any .inc/.bbclass/.bb can add tasks and define their dependencies
Jun 19 17:15:49 <kergoth> in that particular case, base.bbclass does it
Jun 19 17:17:21 <kergoth> pb___: 
Jun 19 17:17:22 <kergoth> NOTE: Running task 1 of 1 (ID: 0, /home/clarson/oe/projects/recipe_sanity/collections/user-collections/test.bb, do_recipe_sanity)
Jun 19 17:17:23 <kergoth> NOTE: test-1.0: recipe_sanity: Rename of RDEPENDS_${PN} to RDEPENDS_test overwrote oldvalue test2 with new value test1.
Jun 19 17:17:23 <kergoth> NOTE: Tasks Summary: Attempted 1 tasks of which 0 didn't need to be rerun and 0 failed.
Jun 19 17:17:25 <hoj> ok.     Thanks kergoth
Jun 19 17:23:44 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * r7b60863bdf 10openembedded.git/recipes/glibc/ (4 files in 2 dirs): 
Jun 19 17:23:44 <CIA-2> glibc-2.9: fix builds for arm-oabi
Jun 19 17:23:44 <CIA-2> Signed-off-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
Jun 19 17:23:55 <CIA-2> 03Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> 07org.openembedded.dev * r05b8e9043d 10openembedded.git/: Merge commit 'origin/org.openembedded.dev' into org.openembedded.dev
Jun 19 17:29:51 <pb___> kergoth: very good
Jun 19 17:30:18 * pb___ stabs debian
Jun 19 17:30:21 <kergoth> i replaced bb.data.data_smart.DataSmart.renameVar with my own function that calls the original.  nasty, nasty hook
Jun 19 17:30:23 <kergoth> but it works :P
Jun 19 17:30:30 <pb___> seems that the initramfs maker no longer bothers to start lvm before trying to mount /
Jun 19 17:30:37 <pb___> heh, right
Jun 19 17:31:35 <kergoth> discovered something i can do thats kind of fun.  since i keep a reference to the config datastore around, i can set things in there that are actually global to all recipes :)
Jun 19 17:32:02 <kergoth> course, that doesn't apply to tasks, since they're forked off
Jun 19 17:37:00 <kergoth> pb___: i think the applying the stash thing has to do with the fact that the stash stores not just the changes to the working copy, but also the index.  the stash commit is actually a merge commit, with one of its parents being the index bits
Jun 19 17:37:26 * kergoth was curious
Jun 19 17:45:50 <kergoth> pb___: found the details on diffs of merge commits: see git help diff-tree, under COMBINED DIFF FORMAT. that's the format its giving you, and it was specifically designed to not be applyable with patch
Jun 19 17:46:17 * kergoth thinks given that, its probably more trouble than its worth trying to apply it manually :)
Jun 19 17:47:12 <pb___> yeah, quite
Jun 19 17:48:38 <kergoth> nice, this caught one of those bugs you wanted to check for, in a task-base :)
Jun 19 17:48:45 <kergoth> 208:NOTE: openssh-4.6p1: recipe_sanity: Rename of FILES_${PN}-dbg to FILES_openssh-dbg overwrote oldvalue  ${bindir}/.debug ${libdir}exec/.debug" with new value ${bindir}/.debug ${sbindir}/.debug ${libexecdir}/.debug ${libdir}/.debug ${base_bindir}/.debug ${base_sbindir}/.debug ${base_libdir}/.debug ${libdir}/${PN}/.debug ${libdir}/matchbox-panel/.debug.
Jun 19 17:54:05 <Tartarus> Hmm
Jun 19 17:54:13 <Tartarus> Is there a technical steering committee yet?
Jun 19 17:55:06 <oof> is there a way to set the desired revision of a package?
Jun 19 17:55:34 <kergoth> oof: you mean like PR?
Jun 19 17:55:40 <kergoth> which is set in thousands of the recipes?
Jun 19 17:56:26 * Tartarus thinks no, and saves this as a draft for when there is (PR/INC_PR rules)
Jun 19 17:57:17 <kergoth> hmm, i should see if mv is fine with me pushing my abiversion bits, at least to the list for discussion.  it's really rather messy at the moment, but it does work.
Jun 19 17:57:17 <oof> doh, stupid question :p
Jun 19 18:03:53 <kergoth> http://kergoth.pastey.net/116308
Jun 19 18:04:45 <kergoth> two of these bugs alone in a task-base
Jun 19 18:11:55 <pb___> heh, right
Jun 19 18:12:33 <pb___> the glibc-dev one is particularly amusing because the assignment to RPROVIDES_glibc-dev in the bbclass file is actually wrong, it's just being overwritten with the correct value by lucky chance
Jun 19 18:14:00 <kergoth> hehe
Jun 19 18:14:02 <pb___> the openssh one is just weird, what's matchbox-panel doing in there?!
Jun 19 18:14:39 <kergoth> dunno, the recipe is appending the former bits, which are obviously broken
Jun 19 18:14:45 <kergoth> there's a mismatched ", and obviously wrong paths
Jun 19 18:15:18 <Gnutoo> hi,I'd like to try my micro-base-image...what should I do to tftpboot the image via cfe/pmon?
Jun 19 18:15:29 <pb___> Tartarus: no, the TSC seems to be bottlenecked on the current e.V. administrative problems
Jun 19 18:15:30 <kergoth> pb___: that's the default from bitbake.conf
Jun 19 18:15:41 <pb___> it is a bit frustrating
Jun 19 18:15:46 <Tartarus> yeah, crap
Jun 19 18:15:51 <kergoth> so again a broken value being overwritten by a more correct one, though i dont know why matchbox-panel is in bitbake.conf, that seems bad
Jun 19 18:16:00 <Crofton|work> we need a German speaker to look over the statutes
Jun 19 18:16:45 <Gnutoo> pb___, what's the problem with openssh? there is a updated recipe in tree but it's not extensively tested
Jun 19 18:17:11 <kergoth> just a minor issue with the package specific vars, harmless right now, but a candidate for cleanup
Jun 19 18:17:56 <Gnutoo> ok...by the way the updated recipe is PREFERRED_VERSION="-1" because I was too afraid of breaking something and didn't test it extensively
Jun 19 18:18:37 <Gnutoo> (I only tested the ssh command)
Jun 19 18:19:51 <Crofton> http://ev.kde.org/getinvolved/members.php
Jun 19 18:20:05 <Crofton> excellent, now I know how to read the statutes :)
Jun 19 18:20:20 <Crofton> since oe's are basically a copy of the kde statutes
Jun 19 18:20:37 <Gnutoo> I'll try the boot command and I hope that it won't erase the flash
Jun 19 18:20:53 <Gnutoo> (because the flash is maped into memory...)
Jun 19 18:23:47 <likewise_> Crofton: at least 80% of the active members most vote other than "abstain" within two weeks! (<= my dead lock scenario)
Jun 19 18:24:16 <likewise_> I cannot believe KDE makes that happen either - so I must be misreading  it
Jun 19 18:24:27 <Crofton|work> well, we need only vote in people who will take the responsibilty seriously
Jun 19 18:24:32 <pH5> likewise_: 20% have to vote
Jun 19 18:25:07 <Gnutoo> ok
Jun 19 18:25:42 <Gnutoo> but the traduction is needed no?
Jun 19 18:25:51 <Gnutoo> s/traduction/translation
Jun 19 18:26:08 <oof> what does the oe_libinstall's -C option do?
Jun 19 18:26:26 <Crofton> pH5, http://ev.kde.org/rules/online_voting.php covers that
Jun 19 18:26:34 <Crofton> I've sent a summary to the member list
Jun 19 18:26:55 <Crofton> hopefully, we can adopt the kde policies to get some clarity to the process
Jun 19 18:27:08 <Crofton> everyone typing +1 is unmanagable
Jun 19 18:27:57 <likewise_> pH5: ah yes, >= 20% have to vote other than abstention. 
Jun 19 18:28:13 <likewise_> s/>=/>/
Jun 19 18:28:19 <pH5> Crofton: that sounds very reasonable
Jun 19 18:28:27 <Crofton> we do need to impress on people that members need to keep up with things
Jun 19 18:28:41 <Crofton> or, move to the inactive class
Jun 19 18:29:02 <likewise_> and we should get rid of the forced assembly, if we can
Jun 19 18:29:17 <Crofton> I kind of like the idea ....
Jun 19 18:29:35 <Crofton> I'm not sure how practical it is
Jun 19 18:29:38 <Crofton> and we may have done so
Jun 19 18:29:57 <likewise_> I mean we have very good committers who we cannot expect to fly over to the other side of the world every two years
Jun 19 18:30:04 <Crofton> excuse me, Extraordinary members :)
Jun 19 18:30:15 <likewise_> :-)
Jun 19 18:30:20 <Crofton> I know
Jun 19 18:30:28 <Crofton> I'm sure kde has similar issues
Jun 19 18:31:57 <Crofton> basically, it looks like you become an Extraordinary member if you suport the organization, but do not want to vote and attend meetings
Jun 19 18:32:16 <Crofton> the immediate problem is membership and voting
Jun 19 18:32:29 <Crofton> hopefully, people agree with copying what kde does
Jun 19 18:33:29 <Gnutoo> ok
Jun 19 18:43:23 <kergoth> damn there are a fuckload of missing or unbuildable dependency chains in a world build
Jun 19 18:46:06 <CIA-2> 03Chris Larson <clarson@mvista.com> 07org.openembedded.dev * rabacaf4743 10openembedded.git/classes/recipe_sanity.bbclass: 
Jun 19 18:46:06 <CIA-2> recipe_sanity.bbclass: add check to handle bugs wrt var expansions in var names.
Jun 19 18:46:06 <CIA-2> Signed-off-by: Chris Larson <clarson@mvista.com>
Jun 19 18:48:04 <oof> ok another question that may be sorta dumb... i'm trying to install a lib and some headers with a bb recpie work/arm.../package/install/ looks pefect but package/image doesnt... image/ doesnt have the libs nor the headers that are in install/
Jun 19 18:48:13 <kergoth> yes
Jun 19 18:48:20 <kergoth> files are moved from image to the install dirs in the packaging phases
Jun 19 18:49:18 <oof> doh... :/
Jun 19 18:49:24 <oof> thanks
Jun 19 18:49:51 <oof> hey, got it worksing
Jun 19 18:49:55 <oof> working*
Jun 19 18:49:57 <oof> wonderful
Jun 19 18:50:20 <mdavey|work> A specific package is failing to download from gitorious.org when running bitbake.  Any suggestions for a workaround?
Jun 19 18:55:49 <oof> mdavey|work: if you intend to check out the sources with git it first tries to grab from some mirrors... it takes a while for them to time out before actually using git to check the sources out
Jun 19 19:01:00 <CIA-2> 03Holger Schurig <hs4233@mail.mn-solutions.de> 07org.openembedded.dev * r4ba9366117 10openembedded.git/recipes/glibc/ (glibc-2.3.5+cvs/etc/ld.so.conf glibc_2.3.5+cvs20050627.bb): 
Jun 19 19:01:00 <CIA-2> glibc: fix "extract" and "munge"/"configure" for ancient glibc 2.3.5+cvs
Jun 19 19:01:00 <CIA-2> * ld.so.conf was specified, but missing
Jun 19 19:01:00 <CIA-2> * syntax error in *.bb file: missing "}"
Jun 19 19:03:18 <mdavey|work> oof: It takes ages to fail, when it does, it says conenction failed and always the same IP: 87.238.52.168
Jun 19 19:03:54 <Crofton> mdavey|work, try pulilng with git manuaully
Jun 19 19:04:10 <Crofton> I do not think the recipe is broken
Jun 19 19:04:11 <mdavey|work> git pull?  with any other args?
Jun 19 19:04:16 <Crofton> do you have firewall issues?
Jun 19 19:04:24 <Crofton> git clone most likely
Jun 19 19:05:02 <mdavey|work> maybe.  I am behind a firewall and on gentoo emerge doesn't work because the port isn't allowed by the firewall.
Jun 19 19:05:16 <Crofton> this is a clue!
Jun 19 19:05:22 <mdavey|work> git pull successfully gets its update
Jun 19 19:05:27 <mdavey|work> s
Jun 19 19:05:33 <Crofton> if git clone does not work, you have a problem
Jun 19 19:05:41 <Crofton> maybe the specific port
Jun 19 19:05:48 <Crofton> git over http versus other way
Jun 19 19:05:53 <Crofton> I think ........
Jun 19 19:05:53 <mdavey|work> git clone has worked for me in the past. I already have a repo.
Jun 19 19:06:02 <Crofton> for the specific url?
Jun 19 19:06:12 <mdavey|work> maybe.
Jun 19 19:06:20 <kergoth> (read: no)
Jun 19 19:07:06 * kergoth thinks about having recipe_sanity warn when LICENSE hasn't been set to something other than unknown
Jun 19 19:08:12 <mdavey|work> so is there a way to manually download this specific thing (what is the correct name for things that bitbake fetches - source packages?)
Jun 19 19:08:31 <mdavey|work> or to tell bitbake to use an HTTP proxy?
Jun 19 19:09:00 <kergoth> http_proxy just like wget
Jun 19 19:09:11 <CIA-2> 03Holger Schurig <hs4233@mail.mn-solutions.de> 07org.openembedded.dev * rf090fe6b95 10openembedded.git/recipes/glibc/glibc-2.3.5+cvs/etc/ld.so.conf: 
Jun 19 19:09:11 <CIA-2> glibc: move missing ld.so.conf into correct directory
Jun 19 19:09:11 <CIA-2> my previous patch was erraneous (Thou shalt not develop on one box and
Jun 19 19:09:11 <CIA-2> commit on another box ...)
Jun 19 19:09:14 * kergoth isn't sure if the git fetcher obeys it, off the top of his head, htough
Jun 19 19:15:46 <CIA-2> 03Chris Larson <clarson@mvista.com> 07org.openembedded.dev * r01c214c0d1 10openembedded.git/classes/recipe_sanity.bbclass: 
Jun 19 19:15:46 <CIA-2> recipe_sanity.bbclass: add checks for missing/default variables
Jun 19 19:15:46 <CIA-2> By default, for now, it just checks for LICENSE being left as default when
Jun 19 19:15:46 <CIA-2> SRC_URI is set, and an empty DESCRIPTION, which freaks out the packaging
Jun 19 19:15:46 <CIA-2> classes.
Jun 19 19:15:48 <CIA-2> Signed-off-by: Chris Larson <clarson@mvista.com>
Jun 19 19:16:42 * kergoth tries to think of other things that might be useful to be told about
Jun 19 19:17:07 <pb___> RDEPENDS/RPROVIDES without a specified subpackage?
Jun 19 19:17:29 <pb___> that's almost never the right thing to do, though I guess there are some occasions when it might be
Jun 19 19:17:41 <kergoth> elaborate?
Jun 19 19:17:50 <kergoth> oh, without the _ bit
Jun 19 19:17:53 <kergoth> yeah, thats bad...
Jun 19 19:17:53 <pb___> right
Jun 19 19:17:57 <kergoth> very bad
Jun 19 19:18:30 <pb___> turns out that update-rc.d.bbclass had been getting that wrong forever
Jun 19 19:18:34 <kergoth> ugh
Jun 19 19:18:37 * kergoth adds that
Jun 19 19:18:56 <cbrake> Crofton: I agree with likewise_ -- I don't like required participation in physical meetings 
Jun 19 19:19:21 <Crofton> cbrake, this is the least of our problems atm :)
Jun 19 19:19:26 <Crofton> I kind of think we took it out
Jun 19 19:19:41 <Crofton> of course, you could host a meeting in OH
Jun 19 19:19:54 <cbrake> Crofton: I also think voting participation requirements should be low.  As I tried to state before, paticipation in OE comes and goes.
Jun 19 19:20:29 <Crofton> that is why we have the extraordinary members
Jun 19 19:20:37 <Crofton> and 20% quorom :)
Jun 19 19:20:57 <pb___> cbrake: there isn't anything in the statutes that actually obliges you to attend a meeting.  indeed, there's provision for both appointing proxies and determining when the meeting is quorate, both of which would be unnecessary if everybody had to attend, so I guess the expectation is that not everyone will.
Jun 19 19:21:01 <Crofton> I think the kde guys have all these issues
Jun 19 19:22:54 <cbrake> ok, sounds good
Jun 19 19:23:11 <cbrake> so I guess we need to get voting infrastructure in place
Jun 19 19:23:21 <Crofton> yep
Jun 19 19:25:10 <florian> re
Jun 19 19:25:14 <pb___> florian: good evening
Jun 19 19:25:36 <kergoth> NOTE: dropbear-0.51: recipe_sanity: RPROVIDES should not be set, but is set to 'ssh sshd'
Jun 19 19:25:38 * kergoth chuckles
Jun 19 19:25:48 <pb___> heh
Jun 19 19:26:42 <pb___> it's funny how many of the most commonly used packages have these kinds of gross errors
Jun 19 19:27:23 <CIA-2> 03Phil Blundell <philb@gnu.org> 07org.openembedded.dev * r91cdbe63a7 10openembedded.git/conf/distro/micro-uclibc.conf: micro-uclibc: avoid selection of crazy iphone stuff as provider for iconv
Jun 19 19:28:04 <kergoth> yes, yes it is
Jun 19 19:28:27 <kergoth> also, lots of if it isnt broke, dont fix it, mindset.  very little cleanup or changes to modern ways of doing things happening
Jun 19 19:28:59 <Crofton> heck, lots of us are afraid to touch stuff that lots of people depend on
Jun 19 19:29:04 <kergoth> true
Jun 19 19:29:19 <kergoth> trying to clean up autotools, I'm still nowhere near done with it
Jun 19 19:29:26 <pb___> kergoth: yeah.  there are two sides to that, though: I find it as frustrating as the next man when someone breaks a package that was working perfectly well in the interests of "cleanup"
Jun 19 19:29:29 <kergoth> if i look at it funny, some random package nobody's touched in a year breaks
Jun 19 19:29:37 <kergoth> true
Jun 19 19:30:28 <kergoth> I've lately been mulling over the possibility of avoiding the autoreconf generations of stuff when not necessary.  lots of our packages would build fine with their existing stuff if we override LIBTOOL=${LIBTOOL} on the make line and dep on libtool-cross :)
Jun 19 19:33:20 <CIA-2> 03Chris Larson <clarson@mvista.com> 07org.openembedded.dev * rdf7ddd8fea 10openembedded.git/classes/recipe_sanity.bbclass: 
Jun 19 19:33:20 <CIA-2> recipe_sanity.bbclass: add checks for "bad" vars like RDEPENDS/RPROVIDES.
Jun 19 19:33:20 <CIA-2> Signed-off-by: Chris Larson <clarson@mvista.com>
Jun 19 19:36:39 <kergoth> weird
Jun 19 19:36:44 <kergoth> native.bbclass sets RPROVIDES = "${PN}"
Jun 19 19:37:34 <kergoth> maybe that's to handle -native classes that RDEPENDS on it, due to including their main packages.. but i expect there's a better way to handle that particular situation, like using DEPENDS :P
Jun 19 19:49:04 <CIA-2> 03Chris Larson <clarson@mvista.com> 07org.openembedded.dev * r715ccad5fe 10openembedded.git/classes/recipe_sanity.bbclass: 
Jun 19 19:49:04 <CIA-2> recipe_sanity.bbclass: only check RPROVIDES/RDEPENDS in target recipes.
Jun 19 19:49:04 <CIA-2> Signed-off-by: Chris Larson <clarson@mvista.com>
Jun 19 19:53:40 <mdavey|work> kergoth: I think you are right - git/bitbake doesn't obey http_proxy
Jun 19 20:30:27 <keesj> hmm it's autoconf that pulls the aclocal.m4  some somewhere else while my package has a aclocal in autoconf/aclocal.m4
Jun 19 20:30:41 <keesj> that one contains the PSG_MODULE macro
Jun 19 20:31:54 <woglinde> re
Jun 19 20:32:06 <woglinde> right
Jun 19 20:32:17 <woglinde> aclocal.m4 is generated
Jun 19 20:32:47 <kergoth> pb___: you happen to know if anyone's looked at moving subpkg metadata into the staging packages, so rdeps from shlibs are retained when the staging packages are used?
Jun 19 20:32:55 * kergoth ponders
Jun 19 20:34:07 <pb___> kergoth: not that I know of, but that sounds like a good idea
Jun 19 20:34:26 <kergoth> k, just checking, i'll add it to my todo then
Jun 19 20:34:29 <kergoth> thanks
Jun 19 20:51:34 <pb___> ok, cool
Jun 19 20:53:28 <keesj> but if it already exist in that other directory? (when I unpack libtar there is a autoconf/aclocal.m4 in there)
Jun 19 21:03:15 <Tartarus> pb___, isn't micro-uclibc doing LIBC=uclibc ?
Jun 19 21:03:27 <Tartarus> That should have kept it from pulling in crazy libiconv and such
Jun 19 21:04:36 <Tartarus> pb___, ah-ha, micro/micro-uclibc are using PREFERRED_LIBC not LIBC and that's wrong :)
Jun 19 21:05:25 <Tartarus> micro is working only because sane-toolchain.inc has LIBC ?= glibc
Jun 19 21:12:26 <khem> Tartarus: looking at sane-toolchain, TARGET_FPU_armv6 ?= "hard" that does not seem correct to me
Jun 19 21:13:33 <khem> I think none of arms should have hard floating  point as default 
Jun 19 21:13:54 <Tartarus> Not sure
Jun 19 21:14:02 <Tartarus> I know n810 is v6-hard
Jun 19 21:14:17 <Tartarus> Not 100% sure about the i.mx31pdk
Jun 19 21:14:42 <khem> because the calling convention will also change for floating points if we use fpu=hard
Jun 19 21:15:02 <CIA-2> 03Dieter Thimm <dthimm@gmx.de> 07org.openembedded.dev * r4229c71182 10openembedded.git/ (4 files in 3 dirs): This is the Boardfile, defconfig, Kerneldiff and adapted bb file for the new tx25 ka-ro Board.
Jun 19 21:15:03 <CIA-2> 03Florian Boor <florian.boor@kernelconcepts.de> 07org.openembedded.dev * r7e4b03d130 10openembedded.git/recipes/linux/linux_2.6.30.bb: linux: Use 2.6.30 for the TX25
Jun 19 21:15:05 <khem> We want to have a gcc which uses soft-floating point calling conventions and utilize VFP if it can
Jun 19 21:18:53 <khem> -mfloat-abi=softfp -mfpu=vfp is what we should use
Jun 19 21:19:31 <khem> mx31, does it have a FPU 
Jun 19 21:19:46 <CIA-2> 03Florian Boor <florian.boor@kernelconcepts.de> 07org.openembedded.dev * r1f4f1ed2f1 10openembedded.git/recipes/zbar/zbar_0.8.bb: zbar: New recipe for zbar barcode decoder.
Jun 19 21:20:01 <khem> we should configure gcc with --with-float=softfp
Jun 19 21:20:02 <khem> --with-fpu=vfp
Jun 19 21:20:12 <Tartarus> Is that a v6-wide thing?
Jun 19 21:20:19 <khem> yes
Jun 19 21:20:21 <keesj> I have something like this s -mfpu=vfp -mfp=vfp  -mfloat-abi=softfp (v6)
Jun 19 21:20:36 <Tartarus> ok
Jun 19 21:21:01 <khem> Tartarus: if an implementation is misisng vfp then you wont use -mfpu=vfp 
Jun 19 21:21:02 <pb___> Tartarus: mm, I've never been convinced about sane-toolchain.inc as a concept.  a lot of the stuff in there isn't really toolchain related and seems to be of dubious sanity.
Jun 19 21:21:23 <Tartarus> pb___, it's not bad, it's getting better, but yeah.
Jun 19 21:21:29 <Tartarus> never the less, micro* has a bug :)
Jun 19 21:21:30 <Tartarus> posted on the ml
Jun 19 21:22:23 <pb___> Tartarus: what's ${LIBC} actually used by?  just sane-toolchain.inc, or something else?
Jun 19 21:22:44 <Crofton|work> shouldn't that go to the micro distro list?
Jun 19 21:23:11 <Tartarus> pb___, LIBC is used by everyone, to key off what LIBC they're using
Jun 19 21:23:27 <Tartarus> You shouldn't actually need a separate conf for uclibc vs glibc
Jun 19 21:24:03 <khem> Will these angstrom-libc.inc files be removed ? they seem like same as sane-toolchain stuff
Jun 19 21:24:14 <pb___> Tartarus: okay, fair enough.  that PREFERRED_LIBC thing does look pretty bogus.
Jun 19 21:24:29 <Tartarus> khem, yes, as a cleanup someone could cleanup sane-toolchain-foo a little more and kill off the angstrom versions
Jun 19 21:24:40 <khem> k
Jun 19 21:25:47 <florian> There is a list for micro distro?
Jun 19 21:25:59 * Crofton|work is just being an ass
Jun 19 21:26:44 <pb___> Tartarus: though, I do wonder whether having a global variable for the selected libc is a very wholesome idea.  What sorts of things are conditional on it?
Jun 19 21:27:12 <Tartarus> pb___, I did bring it up on the ml :)
Jun 19 21:27:21 <Tartarus> But, it brings in conf/distro/include/${LIBC}.inc
Jun 19 21:27:36 <Tartarus> That sets the various preferred providers and adds libc-uclibc/glibc as an override
Jun 19 21:27:58 <Tartarus> So we can finally fix the uclibc overrides that aren't always turned on (see gcc*.inc)
Jun 19 21:27:59 <pb___> yeah, I gathered that.  But I thought you were saying that the variable was actually inspected by other packages as well.
Jun 19 21:29:02 <Tartarus> The variable is only used by confs, but the overrides can/should be used
Jun 19 21:29:05 <pb___> if it's just used for selecting which conf/ bits to include then that's fine, I just wasn't very keen on the idea of packages doing "if ${LIBC} == uclibc then..." kind of stuff.
Jun 19 21:29:11 <Tartarus> been swamped with other work and haven't done the override cleanups
Jun 19 21:29:45 <Tartarus> pb___, testing LIBC, no, but testing the new override is i think a good thing
Jun 19 21:29:57 <Tartarus> having to do 2 cases to catch uclibc sucks
Jun 19 21:30:05 <Tartarus> And isn't always possible (see gcc and NLS stuff)
Jun 19 21:30:41 <pb___> yeah, I suppose.  it'd be nice to do that stuff with autoconf, but I guess life is a bit too short.
Jun 19 21:33:20 <khem> interesting when doing do_package_write of --with-float=softfp
Jun 19 21:33:29 <khem> e2fsprogs-libs_1.41.5.bb 
Jun 19 21:33:39 <khem> wrong paste
Jun 19 21:34:14 <khem> when doing do_package_write of e2fsprogs-libs_1.41.5.bb is looking for util-linux-ng-2.15-r3/install/e2fsprogs-libs-dbg
Jun 19 21:35:14 <pb___> yeah, that's a famous bug
Jun 19 21:35:31 <khem> its looking to package a file from util-linux into e2fsprogs-libs 
Jun 19 21:35:31 <khem> oh ok
Jun 19 21:36:08 <khem> looks like there is a variable thats not updated well in parallel build
Jun 19 21:37:22 <Crofton|work> florian, did you see my email to the members list?
Jun 19 21:38:22 <khem> Crofton|work: what is a member list ?
Jun 19 21:38:52 <pb___> Tartarus: I've made that LIBC change in my local tree.  I'll try a fresh build overnight and check it in tomorrow if all is well.
Jun 19 21:40:19 <Crofton|work> the ev member list
Jun 19 21:40:33 <Crofton|work> we are working through procedural issues atm
Jun 19 21:40:36 <Crofton|work> painfully slowly
Jun 19 21:40:51 <Gnutoo> hi, why previous 2.4.30 kernel for wrt54 is compressed in lzma?
Jun 19 21:41:01 <Gnutoo> is pmon/cfe capable of booting that?
Jun 19 21:41:17 <florian> Crofton|work: yes... basically I agree but in my opinion the process is too complex. But we should just go through the process for now. So we list all new mwmbers and start voting,
Jun 19 21:41:39 <khem> Crofton|work: can you enlist me too ?
Jun 19 21:41:42 <Crofton|work> well, i think we need good structure
Jun 19 21:42:02 <Crofton|work> khem, as soon as we figure out how to do it properly :)
Jun 19 21:42:13 <Crofton|work> I think the kde system shoudl work well
Jun 19 21:42:26 <Crofton|work> we just need to work out how to handle things efficiently
Jun 19 21:42:39 <Crofton|work> we are sort of headless at the moment
Jun 19 21:43:54 <Crofton|work> http://ev.kde.org/workinggroups/
Jun 19 21:44:10 <Crofton|work> I like the phrase "working group" better than "committee" also
Jun 19 21:46:31 <Crofton|work> khem, a little more info is here http://wiki.openembedded.net/index.php/Organization
Jun 19 21:47:12 <pb___> hm, oh dear, build failed in coreutils-native
Jun 19 21:47:30 <pb___> I wonder if that's some fallout from the LIBC thing or just random breakage
Jun 19 21:47:32 * pb___ dinner time now
Jun 19 21:47:48 * Crofton|work notes it is way past pb___ 's dinner time
Jun 19 21:48:09 <Crofton|work> or should be ...
Jun 19 21:49:59 <khem> Gnutoo: lzma is probably a suitable choice for the wrt54 project
Jun 19 21:50:17 <Gnutoo> yes but how do I boot that?
Jun 19 21:50:26 <Gnutoo> I have access to pmon/cfe via serial
Jun 19 21:50:33 <Gnutoo> and I've tftp+NFS server setup
Jun 19 21:52:02 <khem> CFE should be able to understand lzma compressed image
Jun 19 21:53:46 <Gnutoo> ok thanks a lot...I think I have to find how  now...
Jun 19 21:54:27 <Gnutoo> I had some responses from #openwrt....<Bartman007> Gnutoo: pmon/cfe runs an lzma-loader stub we place before the kernel. that loader then decompresses the kernel and execs it.
Jun 19 21:54:51 <Gnutoo> so basically it's like any compressed kernel
Jun 19 21:56:49 <khem> yeah I would think so
Jun 19 21:56:53 <woglinde> hi khem
Jun 19 21:57:01 <khem> woglinde: hello
Jun 19 21:59:30 <Gnutoo> mmm...the bootloader seem stopped here: http://pastebin.com/m6ec1b3e3
Jun 19 22:00:09 <Gnutoo> woglinde, hi
Jun 19 22:00:22 <woglinde> re gnutto
Jun 19 22:02:21 <khem> Gnutoo: is ur kernel tftp'ed correctly 
Jun 19 22:02:52 <Gnutoo> what do you mean exactly? I think it hang during tftp transfert...I'll retry
Jun 19 22:04:57 <Gnutoo> maybe I should use srecord
Jun 19 22:06:18 <khem> whats wrong with tftp do you have your server setup correctly 
Jun 19 22:07:03 <Gnutoo> maybe I'll try downloading from the server from another client
Jun 19 22:12:21 * denix0 is away: I'm not here
Jun 19 22:21:25 <pb___> ah, out of disk space
Jun 19 22:21:26 <pb___> heh
Jun 19 22:22:00 * pb___ deletes some opie trees
Jun 19 22:24:58 * khem is also out of disk space
Jun 19 22:29:40 <Gnutoo> mmm...seems that my setup is correct: Could not load 168.0.0.2:wrt-kernel-2.6.30.lzma: Not an ELF-format executable
Jun 19 22:30:06 * Gnutoo has plenty of disk space...for now(I bought a 2x500GB = 1TB for my laptop)
Jun 19 22:43:17 <Gnutoo> khem, still doesn't work...even srecord doesn't 
Jun 19 22:43:30 <Gnutoo> and my desktop computer could tftpget the kernel
Jun 19 22:43:48 <Gnutoo> I tried both type of network cables
Jun 19 22:44:08 <Gnutoo> the router has a correct ip and can ping my laptop
Jun 19 22:45:23 <khem> Gnutoo: you should find out how CFE loads and runs kernel 
Jun 19 22:45:41 <Gnutoo> ok 
Jun 19 22:45:43 <Gnutoo> thanks a
Jun 19 22:45:46 <Gnutoo> s/a//
Jun 19 22:45:59 <Gnutoo> it runs from flash
Jun 19 22:46:25 <Gnutoo> but I don't want to touch flash before knowing the partitions that I can touch
Jun 19 22:47:08 <Gnutoo> and if the kerenl is too bit will it override a partition?
Jun 19 23:14:50 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * rdfc9b3d6f7 10openembedded.git/recipes/meta/meta-toolchain.bb: meta-toolchain: Use ${layout_base_libdir} not usr/lib for opkg.
Jun 19 23:19:07 <kergoth> anyone here successfully produced a rootfs_rpm based image?
Jun 19 23:19:11 <kergoth> I'm having a hell of a time
Jun 19 23:23:29 <woglinde> kergoth hrw is the only one I know who tried rpm
Jun 19 23:23:50 <kergoth> hrw|gone: boo
Jun 19 23:23:52 * kergoth rolls eyes
Jun 19 23:32:25 * Tartarus runs into and fixes another little issue with layout_prefix / layout_exec_prefix / layout_base_prefix being different
Jun 19 23:35:33 <kergoth> damnit yum
Jun 19 23:35:36 * kergoth grr
Jun 19 23:35:37 <sakoman> hmmm . . . ERROR: QA Issue with dhcp-server: No GNU_HASH in the elf binary
Jun 19 23:35:51 <sakoman> just me or do others see this too?
Jun 19 23:37:58 <Tartarus> Sigh, time to make all the gcc's use INC_PR
Jun 19 23:45:12 <kergoth> argghh
Jun 19 23:45:18 <kergoth> yum hates me.
Jun 19 23:45:30 <khem> apt is better 
Jun 19 23:56:34 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * rbe7846117e 10openembedded.git/recipes/gcc/ (5 files): gcc-3.4.4: Switch to INC_PR
Jun 19 23:56:34 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r781df6069c 10openembedded.git/recipes/gcc/ (4 files): gcc-4.1.2: Switch to INC_PR
Jun 19 23:56:35 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r36d5d93bf4 10openembedded.git/recipes/gcc/ (4 files): gcc-3.4.3: Switch to INC_PR
Jun 19 23:56:36 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r82ca98eff8 10openembedded.git/recipes/gcc/ (4 files): gcc-4.1.0: Switch to INC_PR
Jun 19 23:56:39 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r073b1af549 10openembedded.git/recipes/gcc/ (4 files): gcc-3.3.4: Use INC_PR
Jun 19 23:56:42 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * raf245faf6d 10openembedded.git/recipes/gcc/ (4 files): gcc-4.3.1: Switch to INC_PR
Jun 19 23:56:45 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r6f012276b3 10openembedded.git/recipes/gcc/ (4 files): gcc-4.2.2: Switch to INC_PR
Jun 19 23:56:52 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r9ee3d21325 10openembedded.git/recipes/gcc/ (4 files): gcc-4.3.2: Switch to INC_PR
Jun 19 23:56:55 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r793b86cc83 10openembedded.git/recipes/gcc/ (4 files): gcc-4.4.0: Switch to INC_PR
Jun 19 23:56:58 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r598ee434ef 10openembedded.git/recipes/gcc/ (4 files): 
Jun 19 23:57:01 <CIA-2> gcc-package-sdk.inc: ${layout_base_bindir} is not the path to where the real binary is.
Jun 19 23:57:03 <CIA-2> The binary will always be two levels back, and it will always be in ${bindir}
Jun 19 23:57:05 <CIA-2> as that's what we pass to configure, so basename that to find the right
Jun 19 23:57:07 <CIA-2> directory name. Bump INC_PR in gcc-canadian-sdk 4.2.4,
Jun 19 23:57:09 <CIA-2> gcc-cross-sdk 4.2.4/4.3.3/4.4.0
Jun 19 23:57:13 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r8d1f74b25a 10openembedded.git/recipes/gcc/ (4 files): gcc-4.1.1: Switch to INC_PR
Jun 19 23:57:18 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r0ccf91c95b 10openembedded.git/recipes/gcc/ (4 files): gcc-4.2.3: Switch to INC_PR
Jun 20 00:20:37 <Tartarus> more spam, sorry :)
Jun 20 00:20:45 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r867b91643b 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.14.90.0.7.bb binutils_2.14.90.0.7.bb): binutils-2.14.90.0.7: Switch to INC_PR
Jun 20 00:20:46 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r90515bc834 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.16.91.0.6.bb binutils_2.16.91.0.6.bb): binutils-2.16.91.0.6: Switch to INC_PR
Jun 20 00:20:47 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r7ea0d46f10 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.15.94.0.1.bb binutils_2.15.94.0.1.bb): binutils-2.15.94.0.1: Switch to INC_PR
Jun 20 00:20:48 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r467626ffc8 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.16.91.0.7.bb binutils_2.16.91.0.7.bb): binutils-2.16.91.0.7: Switch to INC_PR
Jun 20 00:20:51 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * rc528566fbc 10openembedded.git/recipes/binutils/binutils-cross-sdk.inc: 
Jun 20 00:20:54 <CIA-2> binutils-cross-sdk: ${layout_base_bindir} is not the path to where the real binary is.
Jun 20 00:20:56 <CIA-2> The binary will always be two levels back, and it will always be in ${bindir}
Jun 20 00:20:58 <CIA-2> as that's what we pass to configure, so basename that to find the right
Jun 20 00:21:00 <CIA-2> directory name
Jun 20 00:21:02 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * re0f4953d78 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.14.90.0.6.bb binutils_2.14.90.0.6.bb): binutils-2.14.90.0.6: Switch to INC_PR
Jun 20 00:21:05 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * rc69f12b8ea 10openembedded.git/recipes/binutils/ (3 files): binutils-2.18.50.0.7: Switch to INC_PR
Jun 20 00:21:08 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r4b69ea8dbc 10openembedded.git/recipes/binutils/ (3 files): binutils-2.19.1: Switch to INC_PR
Jun 20 00:21:13 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * rde6775aaa9 10openembedded.git/recipes/binutils/ (3 files): binutils-2.18: Switch to INC_PR
Jun 20 00:21:16 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * ra84d0f48e6 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_2.17.50.0.12.bb binutils_2.17.50.0.12.bb): binutils-2.17.50.0.12: Switch to INC_PR
Jun 20 00:21:19 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r5d1ef29327 10openembedded.git/recipes/binutils/ (3 files): binutils-2.19.51.0.3: Switch to INC_PR
Jun 20 00:21:24 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * r6fefecfed9 10openembedded.git/recipes/binutils/ (3 files): binutils-2.19: Switch to INC_PR
Jun 20 00:21:27 <CIA-2> 03Tom Rini <trini@embeddedalley.com> 07org.openembedded.dev * rb52781c95e 10openembedded.git/recipes/binutils/ (binutils-cross-sdk_cvs.bb binutils_cvs.bb): binutils-cvs: Switch to INC_PR
**** ENDING LOGGING AT Sat Jun 20 02:59:57 2009