**** BEGIN LOGGING AT Mon May 23 02:59:58 2011
May 23 05:57:56 <sanket> can any suggest some lightweighted webbrowser.... which can smoothly work on 250 Mhz processor....
May 23 06:04:36 <grg> sanket, you're generally out of luck
May 23 06:04:39 <mrj10> lynx!
May 23 06:05:06 <grg> graphical browser options include: netsurf.
May 23 06:05:15 <grg> netsurf does not do javascript
May 23 06:05:16 <sanket> lynx is a text base webbrowser....
May 23 06:05:50 <grg> sanket, if you have gfx acceleration and lots of ram, your life will be much easier
May 23 06:06:04 <grg> otherwise its mission impossible
May 23 06:06:40 <grg> phones and tablets which include browsers are much more powerful and often struggle with bigger websites
May 23 06:07:05 <sanket> I have tried some Midori webbrowser... but still the performance is not upto the mark.... I m compiling this browsers for MIPS.....'
May 23 06:07:34 <grg> i have a 400MHz mipsel, 128mb ram and have had no luck finding a nice usable browser
May 23 06:07:49 <grg> they all suck on these resources, for various reasons
May 23 06:08:26 <grg> i got firefox building some time ago, and it worked much faster than expected. But still not usable without much patience
May 23 06:09:39 <mrj10> maybe chrome?
May 23 06:10:00 <grg> no
May 23 06:10:21 <grg> the resources required to load modern websites are too great
May 23 06:16:15 <mrj10> well yeah
May 23 06:16:21 <mrj10> it's not going to be great on that hardware
May 23 06:16:26 <mrj10> no matter what you do
May 23 06:16:32 <mrj10> but it may suck less than the alternatives
May 23 06:18:23 <ka6sox-away> I use elinks but thats not graphical...and less and less is text based :(
May 23 06:19:05 <grg> web developers have been conspiring against embedded devices for a long time
May 23 06:19:33 * grg shakes his fist at javascript
May 23 06:19:55 <grg> HTML4.0 ought to be enough for anyone, right...?
May 23 06:21:04 <ka6sox-away> grg, that goes along with 640kB ought to be enough for anyone.
May 23 06:23:41 <grg> :)
May 23 06:44:51 <CcSsNET> grg, dillo
May 23 06:44:58 <CcSsNET> limited yes. but fast
May 23 06:54:07 <grg> CcSsNET, dillo doesn't do javascript. So its in the same category as netsurf. Fast, but ultimately useless for the web of today.
May 23 07:01:00 <CIA-10> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rc0c5bbaa3c 10openembedded.git/recipes/avahi/mango-lassi_git.bb: 
May 23 07:01:00 <CIA-10> mango-lassi: switch to Svens version
May 23 07:01:00 <CIA-10> From #systemd:
May 23 07:19:26 <mckoan> good morning
May 23 07:24:26 <CIA-10> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r804cec0ea9 10openembedded.git/recipes/qt4/ (qt-4.7.3.inc qt-4.7.3/0001-wsegl2-support.patch): 
May 23 07:24:26 <CIA-10> qt 4.7.3: update powervr code to work with recent (1.6) powervr SDKs
May 23 07:24:26 <CIA-10> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 23 09:05:18 <CIA-10> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * raae5b51e4a 10openembedded.git/recipes/qt4/qt-4.7.3.inc: 
May 23 09:05:18 <CIA-10> qt4: fix typo in SRC_URI
May 23 09:05:18 <CIA-10> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 23 10:07:04 <sanket> I had builded x11-image using oe having Angstrom distribution.... I want to change the Splash Image .... vll it be possible? and how to?
May 23 11:30:34 <eFfeM_work> should I be able to run a statically linked uclibc exe on a system that is for the rest build with eglibc ?
May 23 11:36:48 <pb_> yes
May 23 11:49:27 <eFfeM_work> pb_: hm, I get a segfault at address 0 (trying a statically linked helloworld). this is with a tree pulled a few months ago
May 23 11:49:55 <pb_> I wouldn't be massively surprised if static linking is just plain broken with uclibc./
May 23 11:50:19 <pb_> Why are you trying to do that, out of interest?
May 23 11:53:33 <eFfeM_work> well, I moved from eglibc to uclibc (on ppc) to see how much space I save, but when I boot that image I get a kernel panic, attempting to kill init
May 23 11:53:53 <eFfeM_work> so reverted to the eglibc image and tried a statically linked exe to see if that part works
May 23 11:54:48 <pb_> ah, I see
May 23 11:54:49 <eFfeM_work> btw there is quite some saving, eglibc is about 1 M, uclibc is 670 k or so, but libm saves massively
May 23 11:55:14 <pb_> maybe better to try booting with eglibc and then chrooting into a uclibc tree, rather than introducing the extra variable of static linking
May 23 11:55:31 <eFfeM_work> maybe update to git head or oe-core before I try agian, saw quite some uclibc patches from khem
May 23 11:55:38 <eFfeM_work> can try that too
May 23 11:55:48 <pb_> yeah, or that
May 23 11:56:06 <pb_> uclibc didn't even compile for me last time I tried so I can't easily check for myself whether static bins work or not.
May 23 11:56:33 <pb_> but yes, you're right, uclibc is significantly smaller that (e)glibc
May 23 11:58:42 <zecke> hrw: ping
May 23 11:58:51 <pb_> hi zecke
May 23 11:59:08 <eFfeM_work> chrooting leads to a segfault on the chroot cmd
May 23 11:59:40 <zecke> pb_: hi, how are you? your first months in the new job have passed?
May 23 12:00:06 <pb_> eFfeM_work: okay, so it sounds as though uclibc is just generically broken
May 23 12:00:28 <pb_> zecke: yes, thanks.  it'll be four months tomorrow in fact.
May 23 12:00:38 <pb_> all going well so far :-)
May 23 12:00:41 <eFfeM_work> pb_: guess so, will try with git head, but probably not today
May 23 12:01:32 <eFfeM_work> too much work and too little time
May 23 12:01:41 <pb_> righto
May 23 12:12:12 <Crofton> pb_, games are core :)
May 23 12:12:46 <GNUtoo> about games....where should I add games like:
May 23 12:12:51 <GNUtoo> *wesnoth
May 23 12:12:55 <GNUtoo> *wordwarvi
May 23 12:12:56 <GNUtoo> etc...
May 23 12:12:59 <GNUtoo> not poky games
May 23 12:13:08 <GNUtoo> in oe-core
May 23 12:13:20 <GNUtoo> will there be a game layer
May 23 12:13:48 <Crofton> the games layer :)
May 23 12:13:56 * Crofton is at the beach
May 23 12:14:12 <GNUtoo> ah there is a game layer now
May 23 12:14:13 <GNUtoo> ok
May 23 12:14:25 <Crofton> I don't know
May 23 12:14:35 <Crofton> I am just being silly :)
May 23 12:14:59 <GNUtoo> ah ok
May 23 13:45:51 <pb_> hi mickey|
May 23 13:51:15 <cbrake> pb_: Hi Phil.  Someone mentioned you have a micro distro git layer somewhere?
May 23 13:51:28 <pb_> hi cliff
May 23 13:51:29 <cbrake> pb_: I would like to add that to the weekly changelog if it makes sense 
May 23 13:52:34 <pb_> yes, it's currently at git://pbcl.net/git/meta-micro, but I was planning to move it to be hosted at oe.org in the nearish future
May 23 13:52:59 <CIA-10> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rf4a0659a00 10openembedded.git/recipes/x-load/x-load_git.bb: 
May 23 13:52:59 <CIA-10> x-load git: bump SRCREV
May 23 13:52:59 <CIA-10> tested on beagleboard/angstrom
May 23 13:53:09 <CIA-10> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r1b18fbc058 10openembedded.git/recipes/avahi/mango-lassi_git.bb: 
May 23 13:53:09 <CIA-10> mango-lassi: add missing xtst to DEPENDS
May 23 13:53:09 <CIA-10> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 23 13:53:12 <pb_> what do you need to do to add it to the changelog: do you just pull from the repo and inspect the output from "git log"?
May 23 13:53:28 <cbrake> pb_: yes
May 23 13:53:43 <pb_> ok, cool.  well, you are very welcome to start doing that.  I'll let you know if/when the url changes.
May 23 13:53:43 <cbrake> pb_: do you want me to set up the repo on git.oe.org now?
May 23 13:53:52 <pb_> actually, yeah, let's do that
May 23 13:53:59 <pb_> I guess now is as good a time as any to move it
May 23 13:54:13 <cbrake> pb_: ok, I'll set up the repo unless you want to
May 23 13:54:44 <pb_> please go ahead
May 23 13:59:13 <cbrake> pb_: http://cgit.openembedded.org/cgit.cgi/meta-micro/
May 23 13:59:28 <pb_> rock
May 23 13:59:29 <pb_> thanks
May 23 13:59:33 <cbrake> pb_: you should have push access.  I assume you want to keep this layer the "pull model"?
May 23 13:59:50 <pb_> yes, please
May 23 14:02:05 <CIA-10> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r9665a28fc6 10openembedded.git/recipes/avahi/avahi-ui_0.6.30.bb: 
May 23 14:02:05 <CIA-10> avahi-ui 0.6.30: improve packaging some more
May 23 14:02:05 <CIA-10> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 23 14:05:20 <CIA-10> 03Andreas Oberritter <obi@opendreambox.org> 07master * r063c182297 10openembedded.git/classes/kernel.bbclass: 
May 23 14:05:20 <CIA-10> kernel.bbclass: pass KERNEL_VERSION through legitimize_package_name
May 23 14:05:20 <CIA-10> - KERNEL_VERSION may contain characters unsuitable for package
May 23 14:09:16 <CIA-10> 03Andreas Oberritter <obi@opendreambox.org> 07master * rb527db8025 10openembedded.git/lib/oe/unpack.py: 
May 23 14:09:16 <CIA-10> lib/oe/unpack.py: unpack rar archives
May 23 14:09:16 <CIA-10> Signed-off-by: Andreas Oberritter <obi@opendreambox.org>
May 23 14:09:37 <mdpoole> Is there a good way to find out which recipe generated an .opkg?
May 23 14:10:17 <pb_> look at the OE: field in the control file
May 23 14:11:02 <CIA-10> 03Andreas Oberritter <obi@opendreambox.org> 07master * re178452958 10openembedded.git/classes/kernel.bbclass: (log message trimmed)
May 23 14:11:02 <CIA-10> kernel.bbclass: pass AR, NM and OBJCOPY to make
May 23 14:11:02 <CIA-10> - Fixes build with certain vendor-supplied Montavista kernels.
May 23 14:12:17 <mdpoole> pb_: Thanks!  That did the trick.
May 23 14:24:13 <pb_> hi kergoth
May 23 14:27:04 <cbrake> can someone point me to meta-slugos?
May 23 14:28:27 <pb_> git://github.com/kraj/meta-slugos.git apparently
May 23 14:28:45 <pb_> also git://github.com/kraj/meta-nslu2.git
May 23 14:28:50 <pb_> (for the nslu2 machine layer)
May 23 14:30:40 <kergoth> hmm, do we have a wiki page just listing all the known available layers, yet? we should make one, if not
May 23 14:30:45 * kergoth yawns
May 23 14:30:51 <pb_> not afaik
May 23 14:30:53 <pb_> good idea though
May 23 14:31:13 <pb_> meta-metadata :-}
May 23 14:32:58 <kergoth> hehe
May 23 14:33:14 * cbrake is swimming in layers ...
May 23 14:36:43 <cbrake> http://git.yoctoproject.org/ has a bunch more layers ...
May 23 14:43:54 * mwester-laptop needs to figure out the layer thing...
May 23 14:48:15 <pb_> cbrake: do you have any idea what keeps going wrong with the oe-core repo?  it seems to break any time anybody touches anything git-related on melo.
May 23 14:49:00 <cbrake> pb_: is it broke now?
May 23 14:49:05 <pb_> yeah
May 23 14:49:10 <cbrake> pb_: I just pushed some git changes
May 23 14:49:11 <pb_> I suspect it broke when you added meta-micro
May 23 14:49:55 <cbrake> pb_: I'll look at it
May 23 14:50:01 <pb_> ok, thanks
May 23 14:50:08 <pb_> I don't have my ssh key with me right now so I can't look myself
May 23 14:50:43 <pb_> see http://lists.linuxtogo.org/pipermail/openembedded-core/2011-May/003009.html for the complaint
May 23 15:03:25 <cbrake> RP__: oe-core git is fixed.  I also fixed the root cause of the problem.
May 23 15:10:54 <pb_> cbrake: excellent, thanks
May 23 16:04:13 <kergoth> does anyone else think it'd be useful to have a tool to inspect a tmpdir and tell you about the build?
May 23 16:04:26 <kergoth> these images were built, these recipes, these tasks failed, whatever..
May 23 16:04:29 <kergoth> after the fact
May 23 16:05:04 <kergoth> not everyone saves a full build log -- speaking of which, we need to start emitting one '
May 23 16:17:14 <GNUtoo> kergoth, or maybe we could have a general logging system
May 23 16:17:21 <GNUtoo> something like an integrated tee
May 23 16:17:22 <kergoth> not sure what you mean by that.
May 23 16:17:30 <kergoth> current bitbake already uses the python logging module
May 23 16:17:35 <GNUtoo> basically I do that everytime:
May 23 16:17:36 <GNUtoo> screen
May 23 16:17:37 <kergoth> adding a global log is like 2 lines of code
May 23 16:17:44 <GNUtoo> bitbake foo-image;bitbake bar thing
May 23 16:17:53 <GNUtoo> and then I detach
May 23 16:17:56 <GNUtoo> and reattach
May 23 16:18:05 <GNUtoo> and I don't know what failled
May 23 16:18:08 <GNUtoo> and what succeded
May 23 16:18:38 <kergoth> that depends on what bitbake UI you use, also
May 23 16:18:44 <GNUtoo> ah?
May 23 16:18:51 <GNUtoo> I use the console ui
May 23 16:18:54 <GNUtoo> bitbake foo-image
May 23 16:18:57 <kergoth> the gtk one lets you go back and look at the state of all the tasks, and copy the log files of each, etc
May 23 16:19:03 <GNUtoo> ah ok
May 23 16:19:10 <GNUtoo> I work trough ssh
May 23 16:19:17 <kergoth> but, i do think we need an automatic always emitted log of your full bitbake build
May 23 16:19:24 <GNUtoo> and I always forgett to tee the bitbake output
May 23 16:19:29 * kergoth nods
May 23 16:19:30 <GNUtoo> yes
May 23 16:25:26 <ka6sox-away> kergoth, I do, for stats.
May 23 16:55:14 <RP__> cbrake: thanks very much!
May 23 16:56:27 <RP__> kergoth: Ideally we need to separate out the console log levels from the main logging levels but I'd love to see a log file of the console
May 23 17:21:37 <kergoth> _ctypes.o: ELF file data encoding is not little endian -- anyone run into this one?
May 23 17:21:44 <kergoth> python build, powerpc machine
May 23 17:25:14 <RP__> kergoth: oecore or not?
May 23 17:25:24 <RP__> We had some ctypes fixes in there recently...
May 23 17:26:45 <kergoth> not
May 23 17:26:51 * kergoth checks the oe-core log
May 23 17:29:50 <kergoth> looks like the recent changes there were for 3rd party stuff, while the issue i'm hitting is with building of the c extensions in python itself
May 23 17:37:59 <RP__> kergoth: fair enough, I just wondered if it was related
May 23 17:45:27 <khem> RP__: in oecore libelf is provided by elfutils but elfutils do not build for uclibc due to its glibc'ism but gcc 4.5 needs libelf to build itself
May 23 17:45:46 <khem> for target it does not build for uclibc since it requires elfutils
May 23 17:46:11 <khem> in classic oe there is a separate recipe for libelf
May 23 17:46:51 <khem> I wonder if we should either provide a virtual/libelf 
May 23 18:36:11 <EricFromFlorida> hello.  Can someone advise me on my bitbake recipe?  What is the fundamental different between work directory which end up under overo... and ones that end up under armv7a...  I created my own recipe and the deliverable ended up under armv7a and I was wondering why and what for?
May 23 18:40:09 <kergoth> recipes are flagged as either arch specific or machine specific.
May 23 18:40:18 <kergoth> this is done to support building for multiple target machines in a single tmpdir
May 23 18:41:16 <EricFromFlorida> i see.... so is arm... an architecture specific target?
May 23 18:41:28 <EricFromFlorida> and overo-... a machine specific target?
May 23 18:54:47 <T0mW> Couple of years ago, I wasted a lot of time with OE until I stumbled upon the fact that I was using the unstable branch (monotone days).  Now that I'm starting a new project, what branch should I use that is "stable"?
May 23 18:55:36 <zecke> T0mW: you might want to take a look at Yocto/Poky for something very stable.
May 23 18:55:54 <kergoth> erm, wrong button
May 23 18:56:15 <kergoth> i was going to say yocto/poky is indeed a good option, or you could use the maintenance branch of oe, which is the latest oe release + some backported fixes
May 23 18:56:24 <kergoth> sadly oe-core isn't anywhere near ready for primetime yet
May 23 18:57:15 <T0mW> ha, not that stable.  With monotone there were many branches, I don't see anything but the "master" branch.  What I'd like to avoid is developing using bleedin' edge recipies that change hourly (unstable branch)
May 23 18:58:21 <jconnolly> is there a TSC or yocto-based timeline for oe-core readiness kergoth ?
May 23 18:58:28 <jconnolly> just curious
May 23 18:58:43 <T0mW> I've now got two projects to fill filesystems for.  One has a large LCD, the other doesn't.
May 23 18:59:35 <T0mW> kergoth: "remotes/origin/2011.03-maintenance" ??
May 23 18:59:53 <kergoth> T0mW: there's master, and there's the maintainance branch. there's also the 'testing' tag, which is a weekly snapshot with recorded information about what machines/distros were successfully built with it
May 23 18:59:54 <kergoth> yeah
May 23 19:00:38 <T0mW> kergoth: thank you, Chris.
May 23 19:00:46 <kergoth> np
May 23 19:01:03 <kergoth> do check out yocto/poky though, its a much much smaller repository, focused on a stable minimal subset of metadata of oe
May 23 19:01:12 <kergoth> (which is what oe-core will be for both projects in the future)
May 23 19:03:20 <foerster> kergoth: did you happen to see the picture i linked on here last week for my first OE based product?
May 23 19:03:29 <kergoth> foerster: nope
May 23 19:03:39 <foerster> http://erafx.com/tmp/LZPS_FD2_1.jpg
May 23 19:03:47 <foerster> http://erafx.com/tmp/LZPS_FD2_2.jpg
May 23 19:04:11 <foerster> Just the front panel touch screen is OE.  super-loop/rtos on other boards inside.
May 23 19:04:14 <T0mW> kergoth: seen that and played with it, it was interesting.  
May 23 19:04:44 <kergoth> foerster: nice. definitely a use case i haven't seen before
May 23 19:04:58 <foerster> and one shot of the front panel in action: http://erafx.com/tmp/LZPS_FD2_0.jpg
May 23 19:05:24 <foerster> I forgot my camera when I was at the factory 2 weeks ago, and my droid takes lousy pictures.
May 23 19:07:15 <ka6sox-away> foerster, nice
May 23 19:07:46 <foerster> ka6sox-away: thanks ;)  Feels good to finally get it released.
May 23 19:07:51 <kergoth> foerster: congrats :)
May 23 19:07:58 <foerster> kergoth: thanks
May 23 19:08:07 <foerster> first 5 units to ship this Friday
May 23 19:08:15 <kergoth> nice
May 23 19:08:57 <kergoth> working on sort of meta-products, i don't get to see anything *tangible* go out the door anymore. selling something oe based for other people to use to make *their* products, a bit more meta, detached from the real devices :)
May 23 19:09:11 <kergoth> its always a nice feeling to actually get a product out the door
May 23 19:09:20 <foerster> FYI - that's a "static transfer switch", typically used in high end datacenters.  
May 23 19:09:21 <kergoth> more so with something physical for some reason, at least for me
May 23 19:09:41 <foerster> Yea, it's nice to be able to see it, touch it, and experience it working on real hardware :)
May 23 19:09:50 <kergoth> indeed
May 23 19:16:17 <foerster> kergoth: cairo (graphics lib) at work: http://www.erafx.com/tmp/waveform.png
May 23 19:17:01 * foerster is done spamming :)
May 23 20:49:55 <EricFromFlorida> which variable in a recipe would target a working directory for overo... or armv7a... ?
May 23 20:52:04 <JaMa> not sure what you mean, but maybe you want PACKAGE_ARCH
May 23 20:53:38 <mdpoole> that was my guess as well, but I couldn't find documentation for what PACKAGE_ARCH is supposed to do
May 23 20:53:56 <mdpoole> (I just looked at some of the TI-specific recipes)
May 23 20:54:58 <kergoth> i already explained this earlier.
May 23 20:55:30 <kergoth> recipes can be marked as being machine specific. this is necessary to facilitate builds of multiple machines in a single build directory.
May 23 20:55:42 <kergoth> if your recipe will run on any device, you don't need to touch PACKAGE_ARCH at all
May 23 20:59:05 <JaMa> or you can set PACKAGE_ARCH = "all" if the package isn't even architecture specific (like theme files)
May 23 20:59:24 <JaMa> to keep only one build for all machines/architectures in build directory
May 23 21:00:08 <kergoth> good point
May 23 21:01:03 <kergoth> and of course this affects the architecture on the binary packages emitted, which allows a single opkg package feed to work for multiple devices as well, not just for builds
May 23 21:07:10 <CIA-10> 03Stanislav Brabec <utx@penguin.cz> 07master * r49af496ad1 10openembedded.git/recipes/crda/crda_1.1.1.bb: 
May 23 21:07:10 <CIA-10> crda: Fix build by disabling of make environment overrides.
May 23 21:07:10 <CIA-10> Signed-off-by: Stanislav Brabec <utx@penguin.cz>
May 23 21:07:20 <CIA-10> 03Stanislav Brabec <utx@penguin.cz> 07master * r6c8afcfada 10openembedded.git/recipes/crda/crda_1.1.1.bb: 
May 23 21:07:20 <CIA-10> crda: Upgrade regulatory database to 2011.04.28.
May 23 21:07:20 <CIA-10> Signed-off-by: Stanislav Brabec <utx@penguin.cz>
May 23 21:14:46 <ka6sox-away> khem ping?
May 23 21:50:22 <hbeck> anyone know offhand if there's an OE python recipe that provides contents similar to python-support package (/usr/bin/dh_pysupport, /usr/sbin/update-python-modules) ?
May 23 21:52:00 <EricFromFlorida> I found it ;)  PACKAGE_ARCH = "${MACHINE_ARCH}"  
May 23 21:52:14 <EricFromFlorida> Thanks for the educational tour :))
May 23 21:57:13 <CIA-10> 03Stanislav Brabec <utx@penguin.cz> 07master * r627af4c7a0 10openembedded.git/recipes/gnome/gnome-desktop.inc: 
May 23 21:57:13 <CIA-10> gnome-desktop: Disable doc build - XSL processing depends on /usr/share/xml and needs work to be independent on host system.
May 23 21:57:13 <CIA-10> Signed-off-by: Stanislav Brabec <utx@penguin.cz>
May 23 22:08:08 <CIA-10> 03Stanislav Brabec <utx@penguin.cz> 07master * r5a32c2a86b 10openembedded.git/recipes/navit/navit_svn.bb: 
May 23 22:08:08 <CIA-10> mavit-svn: Upgrade to SVN snapshot 4495. Changed SVN URI to http (https does not work).
May 23 22:08:08 <CIA-10> Signed-off-by: Stanislav Brabec <utx@penguin.cz>
May 23 22:22:53 <CIA-10> 03Stanislav Brabec <utx@penguin.cz> 07master * r880742f207 10openembedded.git/recipes/bluez/ (2 files in 2 dirs): 
May 23 22:22:53 <CIA-10> bluez-hcidump: Fix declaration clash (remove definition of ntoh64() already present in bluetooth.h).
May 23 22:22:53 <CIA-10> Signed-off-by: Stanislav Brabec <utx@penguin.cz>
May 23 22:41:04 <CIA-10> 03Stanislav Brabec <utx@penguin.cz> 07master * r6b89af6c12 10openembedded.git/recipes/balsa/balsa_2.4.7.bb: 
May 23 22:41:04 <CIA-10> balsa: Fix DEPENDS. Disable doc build - XSL processing is dependent on host system installation.
May 23 22:41:04 <CIA-10> Signed-off-by: Stanislav Brabec <utx@penguin.cz>
May 23 22:58:38 <CIA-10> 03Stanislav Brabec <utx@penguin.cz> 07master * r1efeba2486 10openembedded.git/recipes/mumpot/mumpot_0.4.bb: 
May 23 22:58:39 <CIA-10> mumpot: Upgrade to version 0.6.
May 23 22:58:39 <CIA-10> Signed-off-by: Stanislav Brabec <utx@penguin.cz>
May 23 23:08:24 <hbeck> ugh.
May 23 23:08:56 <hbeck> what's the purpose behind having 65+ python- packages?
May 23 23:09:02 <hbeck> 2.6.6 recipe
May 23 23:23:34 <kergoth> high granularity is usually preferred, to keep image sizes down
May 23 23:23:43 <kergoth> while retaining flexibility
May 23 23:48:26 <Chat6394> hello
May 23 23:54:44 <dexxor> Hello
May 23 23:55:07 <dexxor> has anybody looking at developing an embedded routing platform?
May 23 23:55:14 <dexxor> like a cisco type device?
May 23 23:57:26 <dexxor> or even mikrotik?
May 23 23:57:59 <dexxor> currently looking for developors to look into dev a industrial M2M device
May 24 00:04:25 <ka6sox-away> dexxor, ya, but its not simple to compete with them.
May 24 00:40:43 <dexxor> ka6sox nothing to compete in the commercial space, but loads of oppertunity in the industrial space
May 24 00:41:30 <ka6sox-home> dexxor, true
May 24 00:41:50 <ka6sox-home> industrial is a new space....
May 24 00:56:46 <dexxor> I have found the hardware - just need some direction on the software side - need some serious development
May 24 01:02:39 <grg> dexxor, where abouts in oz are you?
May 24 01:02:46 <grg> (i'm in Adelaide)
May 24 01:04:21 <ka6sox-home> git server and wiki are offline for the next 3-4hrs.
May 24 01:04:29 <ka6sox-home> maintainence window.
**** ENDING LOGGING AT Tue May 24 01:08:22 2011

**** BEGIN LOGGING AT Tue May 24 05:32:15 2011
May 24 06:36:27 <mckoan> good morning
May 24 06:42:40 <ka6sox-farfarawa> morning still waiting to see my first push of the day...to make sure git is back up.
May 24 06:49:13 <ka6sox-farfarawa> normally I see JaMa or Koen push something by now.
May 24 07:13:26 <tasslehoff> I believe the time has come to create my own machine. What I want to do for now is to make it exactly like the beagleboard, except that I will add patches for my own board in the linux kernel. Any advice how to attack this?
May 24 07:17:38 <ka6sox-farfarawa> I wish someone would try to push something...that way I can go to bed.
May 24 07:24:30 <tasslehoff> looks pretty much like I just need to create a machine file, make sure my board is supported in the linux-recipe, and add a machine folder with my defconfig. Sound about right?
May 24 07:24:48 <ka6sox-farfarawa> any other day and there would be 10 pushes...but since I'm waiting now...nothing.
May 24 07:28:39 <JaMa> ka6sox-farfarawa: :) sorry I was on meeting so nothing to push yet
May 24 07:28:58 <ka6sox-farfarawa> JaMa, understood...
May 24 07:29:15 <JaMa> ka6sox-farfarawa: push to oe-core-contrib in few sec
May 24 07:29:35 <ka6sox-farfarawa> we did some work last night while you slept so I'm waiting still I'm sure its working for me to sign off for the night.
May 24 07:29:49 <ka6sox-farfarawa> JaMa, thanks.
May 24 07:29:51 <JaMa> yup read your announcement
May 24 07:30:22 <ka6sox-farfarawa> good...dunno if these things get read or not.
May 24 07:31:16 * JaMa admits to forget what he read and doing git pull --rebase in in the morning when it was down :)
May 24 07:31:54 <ka6sox-farfarawa> whoops...well it should be back up now.
May 24 07:32:05 <ka6sox-farfarawa> as of 0703z
May 24 07:43:00 <JaMa> ka6sox-farfarawa: both pushes worked for me fine, thanks!
May 24 07:44:11 <ka6sox-farfarawa> JaMa, thanks....not I can sleep.
May 24 07:44:24 <JaMa> gnight
May 24 08:39:55 <XorA> morning
May 24 08:40:22 <JaMa> morning
May 24 08:42:00 <CIA-10> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r878a4755f0 10openembedded.git/recipes/freesmartphone/ (4 files): 
May 24 08:42:01 <CIA-10> freesmartphone: bump SRCREVs
May 24 08:42:01 <CIA-10> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
May 24 08:44:15 <mckoan> XorA, JaMa : good morning
May 24 08:44:56 <XorA> hey hey mckoan hows it going
May 24 08:45:04 <XorA> and Jama
May 24 09:26:46 <eFfeM_work> can I stash the same file in two packages (generated from the same recipe) ?
May 24 09:28:34 <JaMa> afaik no and they would cause conflict for package manager on target
May 24 09:29:26 <eFfeM_work> thought that too, actually the packages should most likely not be there at the same time
May 24 09:29:30 <pb_> eFfem_work: you can copy it, obviously, and there's nothing to prevent the two copies going into separate PACKAGES
May 24 09:29:42 <eFfeM_work> sure
May 24 09:31:07 <eFfeM_work> I was peeking at the watchdog recipe, this provides two exe's: watchdog and wd_keepalive, but obviously you only need one prog to feed the dog, so it seemed nice to split into two but both would need watchdog.conf
May 24 09:31:26 <eFfeM_work> let's check what debian does
May 24 09:31:50 <pb_> debian usually deals with that by putting the .conf file in a package of its own, which the other two depend on
May 24 09:32:05 <pb_> I don't know what it does in this specific case though, certainly worth taking a look
May 24 09:33:44 <ant_work> pb_: hey, I have a question about removing unneeded files before packaging
May 24 09:34:24 <ant_work> one recipe uses linux headers (klibc) and I had to remove the .install and ..install.cmd files 
May 24 09:34:58 <ant_work> ideally make headers_install should remove those, isn't
May 24 09:35:27 <eFfeM_work> debian squeeze for ppc has both images in one package
May 24 09:35:35 <eFfeM_work> they are small
May 24 10:18:07 <CIA-10> 03Holger Hans Peter Freyther <zecke@selfish.org> 07master * r8f1d7a1b3c 10openembedded.git/recipes/dvnixload/dvnixload_0.2.6.bb: 
May 24 10:18:07 <CIA-10> dvnixload: The directory structure was changed upstream, update.
May 24 10:18:07 <CIA-10> The file moved to http://www.hugovil.com/repository/dvnixload/dvnixload-0.2.6.tar.gz
May 24 10:47:31 <pb_> hi mickey|office
May 24 10:52:31 <mickey|office> good morning pb_ 
May 24 10:58:44 <zecke> hi all
May 24 10:59:12 <pb_> hail zecke
May 24 11:01:32 <mickey|office> hi z.
May 24 11:45:10 <XorA> if MeeGo is the unstoppable force, is Yocto the immovable object :-D
May 24 11:54:28 <zecke> how to debug the git fetcher nowadays?
May 24 11:54:41 <zecke> i happily kill the underlying git process and nobody cares.
May 24 11:55:42 <CIA-10> 03Martin Jansa <Martin.Jansa@gmail.com> 07master * r27d866075b 10openembedded.git/recipes/freesmartphone/fso-specs_git.bb: 
May 24 11:55:42 <CIA-10> fso-specs: older SRCREV because HEAD causes libfreesmartphone-glib to fail
May 24 11:55:42 <CIA-10> * doesn't like <annotation> in <signal>
May 24 12:00:19 <zecke> and where is the diff between fetcher fetcher2?
May 24 12:06:26 <zecke> it is really a bad mess.. incredible
May 24 12:08:13 <pb_> yeah, I am a bit baffled by the fetch2 thing as well
May 24 12:08:18 <pb_> I don't know what's going on there, it does seem weird
May 24 12:11:42 <zecke> ah... apparently bitbake was waiting for a lock. i wonder if this was always so hard to debug.
May 24 12:12:29 <zecke> pb_: "bitbake: copy bb.fetch to bb.fetch2 as initial code base for fetcher overhaul". not very specific.
May 24 12:13:33 <zecke> no idea what to do about it. :(
May 24 12:16:19 <zecke> ha, no I am tricked into a recursion. the log file asks me to look into itself. :)
May 24 12:16:50 <XorA> zecke: Ive seen that one :-D
May 24 12:17:18 <XorA> was fixed by adding FAKEROOT="" to local.conf
May 24 12:17:54 <zecke> XorA: To be fair.. it is oe-core, it is triggered by validate_branches of a kernel I try to add
May 24 12:18:56 * XorA is too busy writing kernel code for oe-core
May 24 12:19:22 <pb_> oe-core is part of the kernel now?  eleet
May 24 12:19:30 <pb_> I guess that was a natural progression.
May 24 12:20:39 <florian> :-)
May 24 12:20:41 <XorA> well didnt someone write a dbus kmod, once that happened everythin can go in kernel :-D
May 24 12:20:53 <CIA-10> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r0be0c1e97a 10openembedded.git/recipes/gnome/gnome-bluetooth_2.32.0.bb: 
May 24 12:20:53 <CIA-10> gnome-bluetooth 2.32.0: package gconf files
May 24 12:20:53 <CIA-10> Signed-off-by: Koen Kooi <koen@openembedded.org>
May 24 12:29:39 <ant_work> well
May 24 12:29:55 <ant_work> I see many of you guys are peeking with oe-core
May 24 12:30:14 <ant_work> who will declare the bitrot of classic oe?
May 24 12:30:25 <ant_work> when? after next release, isn't?
May 24 12:31:59 <ant_work> to me, it looks probable many machines will be dropped
May 24 12:32:01 <XorA> ant_work: AFAIK there is no more releases of oe.dev
May 24 12:32:11 <ant_work> one in June?
May 24 12:32:42 <XorA> maybe I misremember but I thought the .03 release was the last
May 24 12:32:57 <ant_work> can't remember too
May 24 12:33:19 <XorA> next release should be oe-core released
May 24 12:34:20 <pb_> it probably is true that many machines will be dropped unless someone merges them into a layer that can be used with oe-core.
May 24 12:34:23 <XorA> ant_work: get those zaurures to meta-oe :-)
May 24 12:34:38 <ant_work> with remote/external BSP layers?
May 24 12:34:48 <pb_> that shouldn't be terribly hard, though, so I don't think it is a big obstacle.
May 24 12:34:50 <ant_work> (was for the previous sentence?)
May 24 12:35:27 <XorA> not sure I ever saw the TSC rule on the structure of machine layers, but Ive been working on non OE projects
May 24 12:35:54 <pb_> afaik, the tsc hasn't published any guidance on that, except to say that machines don't belong in oe-core.
May 24 12:35:59 <ant_work> I only read about qemu and atom/omap
May 24 12:36:41 <pb_> putting them in meta-oe might well be fine.  you could create an external bsp layer, but if it's only going to have one or two files in then that might be overkill.
May 24 12:36:56 <pb_> or, perhaps, a shared layer for a bunch of machines would make sense as well.
May 24 12:37:10 <ant_work> in fact we are talking about meta-handhelds
May 24 12:37:42 <pb_> yeah, that sounds like a fine idea to me
May 24 12:37:48 <ant_work> but those doesn't share the kernel, so it would be a bit complicate
May 24 12:38:02 <ant_work> ipaq are behind iirc
May 24 12:38:15 <bluelightning> XorA: I thought you didn't want old machines in meta-oe...
May 24 12:38:19 <ant_work> we shall really have some example
May 24 12:38:47 <XorA> bluelightning: I personally dont want them unless someone supports them
May 24 12:38:54 <ant_work> where the layer is hosted is ininfluent atm
May 24 12:38:55 <pb_> there's no reason you couldn't have multiple kernels in meta-handhelds, I guess
May 24 12:39:02 <bluelightning> XorA: define "support"
May 24 12:39:15 <XorA> bluelightning: no drive by dumping
May 24 12:39:48 <bluelightning> most of the machines I proposed for meta-handheld were not drive-by dumped
May 24 12:39:56 <bluelightning> some may have bitrotted, but that's not the same thing
May 24 12:41:20 <ant_work> pb_: I still have to study how linux-yocto does configure and build the kernel. Seems there is a modular approach
May 24 12:42:04 <ant_work> honestly, kernel config is soo moving target that any ambition of hardcoded knowledge is futile
May 24 12:42:14 <ynezz> :)
May 24 12:43:15 <pb_> yeah, might be worth looking at what yocto does.
May 24 12:43:25 <XorA> bluelightning: see above where I said I havent been paying much attention lately
May 24 12:44:51 <ant_work> XorA: maybe we should do a meta-pxa layer. This is rather well supported upstream.
May 24 12:45:02 <ant_work> still
May 24 12:45:18 <ynezz> first time I hear about gerrit, looks really nice http://labs.qt.nokia.com/2011/05/23/gerrit-joined-the-qt-creator-project/
May 24 12:45:29 <ynezz> maybe replacement for patches/bugzilla? :D
May 24 12:46:09 <foerster> ynezz: I've started my company using gerrit recently
May 24 12:46:15 <foerster> so far, so good
May 24 12:46:32 <bluelightning> if it takes away some of the manual nature of patchwork then all the better...
May 24 12:46:35 <ynezz> yea, I could imagine that
May 24 12:46:58 <ynezz> foerster: yea, I could imagine that
May 24 12:47:05 <ant_work> ynezz: maybe you missed today's msgs on LAKML about patchwork ;)
May 24 12:48:17 <ynezz> I read lakml with grep (just search for patches/platforms I'm interested in), so I missed it for sure :)
May 24 12:48:31 <ant_work> "Linux ARM kernel on patchwork"
May 24 12:58:17 <pb_> I guess meta-pxa would be a reasonable plan too, but a more generic meta-handhelds sounds like it would probably be more valuable.
May 24 12:58:50 <ant_work> ok, let's have the strongARM on board ;)
May 24 12:59:04 <ant_work> I forgot collie...
May 24 12:59:07 <pb_> heh.  well, I was thinking more of platforms like s3c2410, but I guess strongarm too
May 24 13:01:32 <pb_> I guess the easiest way for you to get started with that would be to set up a meta-handhelds repo on github or some such, and then (if you want) we can import it to oe.org once your workflow has settled down a bit.
May 24 13:02:40 <hrw> I think that only devices which have users/devs should be converted
May 24 13:02:54 <hrw> so progear will die for example
May 24 13:03:30 <bluelightning> pb_: that's what I plan to do, unless ant_work wants to beat me to it ;)
May 24 13:03:37 <hrw> as I do not plan to boot it again - maybe will drop it one day to 'electronic wastebasket' during cleaning basement
May 24 13:04:58 <bluelightning> I see looking at LAKML, hx4700 has had some recent work ... excellent
May 24 13:05:14 <bluelightning> one less in the 2.6.21-hh box
May 24 13:05:59 <hrw> I would say that 2.6.21-hh box is same as electronic wastebasket
May 24 13:06:23 <hrw> nhk15 should die too - 2.6.20 kernel only and mainline is not usable on it
May 24 13:06:39 <bluelightning> hrw: well, 2.6.21-hh does still work, but keeping it working is an effort
May 24 13:07:10 <hrw> bluelightning: 2.4.18-crapix was also working but we got rid of it
May 24 13:07:27 <bluelightning> yes well embedix was full of fail
May 24 13:07:32 <hrw> I really wonder how many of hp5xxx are still operational
May 24 13:07:45 <bluelightning> I still have all of mine
May 24 13:07:57 <bluelightning> been a while since I tested the ones with soldered in batteries though
May 24 13:08:00 <hrw> bluelightning: at work I have people which had hands in embeddix...
May 24 13:08:18 * XorA lends hrw an axe
May 24 13:08:33 <hrw> bluelightning: I still have c760, nhk15, progear, nokia770 but they are not used and rather will not be
May 24 13:08:47 <bluelightning> there was a good reason for excising (or should I say exorcising) embedix, as it required a boatload of 2.4 stuff to keep it going
May 24 13:09:46 <ant_work> and gcc3
May 24 13:10:00 <hrw> ant_work: 2.95
May 24 13:10:11 <ant_work> omg
May 24 13:10:39 <ant_work> away, away
May 24 13:10:44 * XorA still remembers the days when you used to have about 5 different versions of gcc/egcc just to get on with work
May 24 13:11:08 <XorA> egcs
May 24 13:11:58 <bluelightning> I don't know much about progear or nhk15, but nokia770 suffers from lack of open source drivers... c760 should still be usable though
May 24 13:12:13 <ant_work> c760 shines
May 24 13:12:39 <ant_work> don't pretend to work on it, though ;)
May 24 13:13:08 <hrw> ant_work: my c760 would love new battery - but it costs more then c760 value
May 24 13:13:12 <bluelightning> well I can only hope to test the devices I have, c760 isn't one of them
May 24 13:13:26 <ant_work> I would love a corgi-kernel battery driver...
May 24 13:13:37 <hrw> it is like with trabant from ddr - you can multiple value by putting one banana inside
May 24 13:13:39 <ant_work> I'm jalous spitz and tosa have...
May 24 13:14:18 <bluelightning> hrw: hahaha
May 24 13:14:29 <ant_work> hrw: if it's not for paperhold I can send you a battery I received
May 24 13:14:36 <CIA-10> 03Denis Carikli <GNUtoo@no-log.org> 07org.openembedded.dev * reefe2cf9d9 10openembedded.git/conf/machine/bug20.conf: 
May 24 13:14:37 <CIA-10> bug20.conf: override the omap3 kernel PR and bump PR
May 24 13:14:37 <CIA-10> The bug20 uses a different kernel than the one defined in omap3.inc
May 24 13:14:40 <hrw> ant_work: do not do it
May 24 13:14:47 <ant_work> :P
May 24 13:15:09 <hrw> ant_work: but I still have spare leather case for c760
May 24 13:15:38 * bluelightning should really catalog his devices
May 24 13:15:38 <ant_work> I think I'll donate my Sharp matherial totheir Museum soon...
May 24 13:15:59 <hrw> bluelightning: so do I - just to track what I have and who has it now
May 24 13:16:10 <ant_work> I even received a luxury leathe case for poodle
May 24 13:16:33 <bluelightning> I have a growing collection in the office now too, they just seem to accumulate
May 24 13:17:11 <ynezz> it's handy, adds more space for the dust :p
May 24 13:17:23 <bluelightning> heh
May 24 13:18:31 <ant_work> unfortunately those small devices suffered gpe/opie twilight
May 24 13:20:32 <ant_work> but successfully booting a console image from serial with kernel debug is still nice, maybe I'm perverted... :P
May 24 13:21:35 <bluelightning> ant_work: I'm at least trying to keep opie going... ;)
May 24 13:22:01 <ant_work> yea, you earned lot of karma for this
May 24 13:22:09 <bluelightning> next version will at least fix the bluetooth evility
May 24 13:22:21 <anarsoul> bluelightning: linux-h1940-2.6.1x can be removed aswel
May 24 13:22:48 * anarsoul still need to send oe patches for h1940 and rx1950 kernels
May 24 13:22:57 <ant_work> bluelightning: as you have seen there is a jungle of overrides to eradicate too...
May 24 13:23:18 <anarsoul> btw, I really doubt that someone's using -hh kernels nowadays
May 24 13:23:44 <ant_work> question is: should we keep all as it is now in oe-dev? Doing some more cleanings?
May 24 13:23:59 <bluelightning> anarsoul: well, with some machines there is no alternative, and it does work
May 24 13:24:30 <bluelightning> anarsoul: thanks for getting h1940 and rx1950 out of that hole though :)
May 24 13:24:48 <anarsoul> bluelightning: no pb, it was fun for me :)
May 24 13:25:07 <bluelightning> anarsoul: any plans to do any other devices? ;)
May 24 13:25:30 <GNUtoo> hi
May 24 13:25:32 <GNUtoo> what's that:
May 24 13:25:36 <GNUtoo> http://cgit.openembedded.org/cgit.cgi/openembedded/log/?h=org.openmbedded.dev
May 24 13:25:42 <GNUtoo> a typo I guess
May 24 13:26:27 <anarsoul> bluelightning: well, I had plans about rx3xxx, but can't find them here
May 24 13:26:52 <bluelightning> anarsoul: you mean you have trouble acquiring a device?
May 24 13:28:11 <anarsoul> hm, there's rx3715 on local forum for 60 usd, I'll think about buying it :)
May 24 13:34:43 * XorA needs to work out how to run OE on his zx spectrum
May 24 13:34:59 <XorA> or maybe the QL
May 24 13:35:36 <florian> XorA: You might want to start with building for these devices ;-) 
May 24 13:38:42 <anarsoul> XorA: you still own sinclair QL? :)
May 24 13:40:11 <hrw> collie had 200MHz or more?
May 24 13:42:27 <anarsoul> hrw: according to wikipedia, 206mhz, http://en.wikipedia.org/wiki/Sharp_Zaurus
May 24 13:43:19 <hrw> tx
May 24 13:43:28 <XorA> anarsoul: I only just bpought it a week ago
May 24 13:43:45 <anarsoul> ah
May 24 13:44:58 <XorA> anarsoul: I had some of the spectrums for years, but i never had a QL
May 24 13:45:22 <pb_> maybe you should invest in a C5 as well :-)
May 24 13:45:23 <hrw> XorA: own sam coupe?
May 24 13:45:44 <XorA> hrw: no, they are so bloody rare :-(
May 24 13:46:03 <hrw> XorA: Pentagon, Scorpion, Evolution?
May 24 13:46:25 <XorA> hrw: I need to appeal to my eastern european friends to find me them :-D
May 24 13:46:34 <hrw> XorA: or you just limit yourself to UK ones?
May 24 13:46:54 <XorA> hrw: Id love to get hold of a pentagon or two
May 24 13:47:01 <anarsoul> :)
May 24 13:47:04 <XorA> hrw: there is a polish clone I beleive as well?
May 24 13:47:38 <hrw> XorA: ofcourse
May 24 13:47:46 <hrw> XorA: Elwro 800 Junior
May 24 13:48:05 <hrw> show me CEE country without ZX Spectrum clone ;D
May 24 13:48:43 <hrw> I never used z80 based computers anyway.
May 24 13:48:45 * bluelightning started with the BBC micro
May 24 13:49:02 <bluelightning> 6502 ftw
May 24 13:49:03 <anarsoul> hrw: why? z80 is soooooo niiiice :)
May 24 13:49:08 <hrw> except one "micro"controller during study which we programmed in asm
May 24 13:49:13 <pb_> right, big ups to 6502
May 24 13:49:17 <hrw> anarsoul: 6502 uber alles!
May 24 13:49:37 * XorA was never a fan of 6502
May 24 13:50:07 <hrw> you used z80 thats why
May 24 13:50:16 <XorA> hrw: I had an Acorn Electron as well
May 24 13:50:33 <hrw> A B C D E H L and something more. how it could be sane?
May 24 13:50:53 <XorA> you forgot F :-D
May 24 13:51:52 <anarsoul> also IX, IY, I and R
May 24 13:51:52 <XorA> hrw: if you can get a Elwro cheap and some method of getting it in my hands, I can find some $$$ :-D
May 24 13:52:27 <XorA> and the bug that gives 16bit address on IO was nice
May 24 13:52:43 <XorA> without that ZX would never have happened
May 24 13:53:10 <anarsoul> XorA: hm, I was sure that there're instructions to address 16bit ports
May 24 13:53:34 <XorA> anarsoul: not officially, but a bug loaded the B register onto the address bug incorrectly
May 24 13:53:52 <XorA> bus
May 24 13:54:22 <XorA> LD BC,#1234, IN C would actually do 16bit not 8 bit like it was supposed to
May 24 13:54:46 <hrw> XorA: elwro != cheap nowadays
May 24 13:54:58 <hrw> XorA: they are rare 
May 24 13:55:16 <XorA> hrw: same as the other machine in UK then, they are not even particularly rare, but going for insane prices on ebay
May 24 13:56:15 * XorA likes having the divIDE these days, its sweet to have a modern CF card in a 30 year old machine
May 24 13:56:48 <hrw> D:
May 24 13:57:20 <XorA> of course all spectrum programs ever written fit on one CF :-D
May 24 13:57:53 <anarsoul> heh
May 24 13:58:08 <XorA> anarsoul: you have QL?
May 24 13:58:17 <anarsoul> XorA: nope
May 24 13:58:26 * XorA needs to find an actual use for it
May 24 13:58:39 <anarsoul> only 128kb clone of spectrum covered with a dust :)
May 24 13:58:48 <XorA> hehe
May 24 13:59:16 <XorA> I have zx81, spectrum 48k, spectrum 48k+, +2, 3x +2A, +3, QL
May 24 13:59:50 <anarsoul> well, then you can open a small museum :)
May 24 14:00:14 <XorA> zx80 goes for insane price as does sam coupe
May 24 14:01:06 <XorA> and I need to locate a 128k toaster machine
May 24 14:02:05 <hrw> XorA: no timex 2048/2068?
May 24 14:04:22 <XorA> hrw: they were not actually officialy sold in UK so again rare
May 24 14:05:52 <hrw> XorA: was there zx spectrum 16k?
May 24 14:08:00 <XorA> hrw: yes, original one was 16k
May 24 14:08:07 <hrw> want one?
May 24 14:08:30 <hrw> 500pln ~= 130 GBP
May 24 14:09:20 <hrw> sam coupe for 1600 pln ~= 370 GBP 
May 24 14:13:29 <XorA> ouch on both those prices
May 24 14:13:55 <XorA> I think Im just not retro enough :-D
May 24 14:19:17 <hrw> ;D
May 24 14:42:59 <GNUtoo> XorA, maybe there are emulators tough
May 24 14:43:11 <GNUtoo> not sure if they are in oe or under what license
May 24 14:43:26 <kergoth> morning
May 24 14:43:36 <XorA> GNUtoo: thare are hundreds of emulators, and a few GPL ones
May 24 14:43:51 <GNUtoo> ok
May 24 14:43:53 <zecke> crap.. it is really not my day.. i wonder when output was replaced with just providing (0|1) as result for operations. :(
May 24 14:44:08 <XorA> GNUtoo: I am working on a project where I fit my beagleXM inside a 48k zx casing and use an IO extended for keyboard
May 24 14:44:28 <GNUtoo> lol ok
May 24 14:45:22 <GNUtoo> is there the code of spacewars somewhere btw?
May 24 14:45:32 <XorA> no idea
May 24 14:46:49 <GNUtoo> you can't be more retro than spacewars
May 24 14:49:22 <zecke> kergoth: http://pastebin.ca/2068444, what do you think? right now it detects that data is None and then takes the md5 sum of it which raises an exception
May 24 14:49:38 <kergoth> zecke: i got bit by that too
May 24 14:49:53 <kergoth> either that error should be fatal, or we need to continue, clearly there's a mismatch between what it says and what it does
May 24 14:49:56 <kergoth> either its fatal or not.. 
May 24 14:50:15 <kergoth> might want to check with RP, but that looks sane to me
May 24 14:50:42 <kergoth> though, i wonder if anything will choke on not finding the hash for that task. hopefully not :)
May 24 14:50:46 <kergoth> otherwise we could just hash ""
May 24 14:51:47 <zecke> kergoth: yeah, probably bb.fatal. right now it failed on -cclean as I fucked up my metadata
May 24 14:52:17 <kergoth> there are valid cases for having an empty task, but on the other hand its not difficult to create ane mpty task in the metadata
May 24 14:52:35 * kergoth shrugs
May 24 14:55:38 <zecke> make it fatal. better than throwing an exception.
May 24 15:00:41 <zecke> who is the pull-maintainer for oe-core?
May 24 15:02:23 <JaMa|Off> zecke: RP
May 24 15:55:04 <zecke> one more stupid question.. if I have a native package that needs to know the name of the toolchain.. where should I put TARGET_ARCH in the ${PN}?
May 24 15:59:57 <ka6sox-sleep> well..I didn't see my name taken in Vain here so I assume things are working okay.
May 24 16:00:44 * bluelightning shakes fist at ka6sox-sleep
May 24 16:00:55 <bluelightning> (just kidding ;)
May 24 16:10:57 <ka6sox-sleep> bluelightning, sometimes when I wake up I see my nick in like 3-4 channels being used I know I'm in trouble.
May 24 16:11:21 <ka6sox-sleep> the best days are when I wake up and see it not mentioned anywhere.
May 24 16:11:53 <bluelightning> heh
May 24 16:11:56 <bluelightning> no news is good news
May 24 16:12:05 <ka6sox-sleep> in my case...true
May 24 16:12:12 <ka6sox-sleep> morning mwester-laptop 
May 24 16:12:40 <mwester-laptop> Salutations!
May 24 16:12:49 * mwester-laptop is trying to catch up on 2+ weeks of OE-related email...
May 24 16:12:59 <ka6sox-sleep> mwester-laptop, good luck.
May 24 16:13:19 <mwester-laptop> :)
May 24 16:13:29 <ka6sox-sleep> mwester-laptop, is imitron ready to make images?
May 24 16:13:59 <mwester-laptop> Should be, but based on the original OE repo.  (Not on the new one that Khem put together using layers and OE-core)
May 24 16:14:43 <mwester-laptop> I kicked off a build last week when I had a chance to SSH in for a while; it built ok.
May 24 16:15:00 <ka6sox-sleep> okay great...I need an image for a FatSlug.
May 24 16:15:12 <ka6sox-sleep> well..this one is Obese actually.
May 24 16:15:46 <mwester-laptop> I see a thread from a couple weeks ago where Khem is wondering what GIT infrastructure the SlugOS folks have... I think the answer is pretty much none.  I'll have to consider that a bit; I was hoping that we could stay on the OE servers.
May 24 16:16:21 <ka6sox-sleep> mwester-laptop, I have a git server for you already...just will put your key in ther.
May 24 16:16:53 <mwester-laptop> Anyway, I'm just going to try to catch up today, and perhaps I can get those new repos downloaded if my current (flakey) internet connection stays up.  (I'm in an RV far from home!)
May 24 16:17:10 <ka6sox-sleep> np...
May 24 16:17:22 <ka6sox-sleep> mwester-laptop, which target did you build for last time?
May 24 16:17:29 <ka6sox-sleep> slugOS BE/LE?
May 24 16:17:34 <mwester-laptop> Both.
May 24 16:17:44 <mwester-laptop> Khem has been keeping BE working.
May 24 16:18:00 <ka6sox-sleep> okay, I"d like to use the LE one...for a test of this ObeseSlug.
May 24 16:18:03 <mwester-laptop> (requires toolchain expertise far far beyond my skills.)
May 24 16:18:15 <mwester-laptop> LE works great; that's what I've been booting.
May 24 16:18:32 <mwester-laptop> Oh - gotta run! Later.
May 24 16:18:38 <ka6sox-sleep> laters.
May 24 16:34:41 <Jay7> wow.. some ZX fans here :)
May 24 16:34:55 <Jay7> zaurus and zx fans even :)
May 24 16:35:00 * Jay7 is backreading the log :)
May 24 17:00:41 <khem> mwester-laptop: hey
May 24 17:01:06 <khem> mwester-laptop: I have got slugos-image working for both le/be using both eglibc/uclibc on the new repo
May 24 17:24:49 <zecke> Crofton: ping?
May 24 17:27:30 <Crofton> pong
May 24 17:27:38 * Crofton is at the beach though
May 24 17:27:54 <zecke> ah nice
May 24 18:33:27 <GNUtoo> hi, I've problems with udev, it blocks my boot somehow
May 24 18:33:31 <GNUtoo> how to debug it?
May 24 18:33:45 <GNUtoo> I've tried bootchart but it didn't last long enough
May 24 18:37:51 <GNUtoo> basically it goes in /var/log/ by default
May 24 18:38:02 <GNUtoo> which obviously get mounted over by tmpfs
May 24 18:38:17 <GNUtoo> I've done an /etc/bootchart.conf file, no luck
May 24 18:38:32 <GNUtoo> I'll check my busybox defconfig
May 24 18:39:15 <florian> re
May 24 18:44:32 <GNUtoo> hmmm I do not see bootchart in defconfig
May 24 18:44:33 <GNUtoo> strange
May 24 18:44:37 <GNUtoo> but I have it on target
May 24 18:47:58 <khem> GNUtoo: is your fs r/w ?
May 24 18:48:06 <khem> if not then udev will cringe
May 24 18:48:23 <GNUtoo> yes
May 24 18:48:26 <GNUtoo> it is
May 24 18:48:31 <GNUtoo> I added rw to the cmdline
May 24 18:48:37 <khem> ok
May 24 18:48:39 <dot> khem ping?
May 24 18:48:42 <khem> do u have tmpfs
May 24 18:48:46 <khem> dot: yes
May 24 18:48:46 <GNUtoo> basically here are the symptoms:
May 24 18:49:00 <GNUtoo> * the machine boot slowly and then stop responding before getting me a shell
May 24 18:49:02 <dot> khem, please test garnet at your leisure.
May 24 18:49:05 <GNUtoo> doing that unfreeze it:
May 24 18:49:08 <GNUtoo> mdev -s
May 24 18:49:11 <khem> dot: will hammer it soon
May 24 18:49:13 <GNUtoo> exit 0
May 24 18:49:15 <GNUtoo> and exit 0
May 24 18:49:26 <GNUtoo> in both udev and udev-cache init script
May 24 18:50:27 <GNUtoo> how to verify the tmpfs if I have no shell with init
May 24 18:50:30 <GNUtoo> I can do that tough:
May 24 18:50:36 <GNUtoo> init=/bin/ash
May 24 18:50:44 <khem> GNUtoo: look in kernel config
May 24 18:50:49 <GNUtoo> ah ok
May 24 18:50:50 <khem> TMPFS
May 24 18:50:56 <GNUtoo> I'll look
May 24 18:51:16 <GNUtoo> CONFIG_TMPFS=y
May 24 18:51:16 <GNUtoo> CONFIG_TMPFS_POSIX_ACL=y
May 24 18:51:27 <GNUtoo> I think pespin had the same problem than me with one of his phone
May 24 18:51:40 <GNUtoo> but it was at last fosdem
May 24 18:52:19 <GNUtoo> maybe it could be something that udev doesn't do rather than do?
May 24 18:52:34 <GNUtoo> for instance my dropbear keys were not generated
May 24 18:52:42 <GNUtoo> because there was no /dev/[u]random
May 24 18:57:59 <morphis> heyho
May 24 18:59:32 <khem> GNUtoo: yeah 
May 24 18:59:32 <GNUtoo> hi
May 24 19:00:19 <morphis> khem: good you are here, I saw you commited python 2.7.1 to OE in december
May 24 19:01:44 <morphis> khem: it fails build cause of a "ImportError: No module named sysconfig"
May 24 19:01:45 <morphis> s/build/to build/
May 24 19:04:17 <khem> morphis: yeah dont use it
May 24 19:04:17 <khem> morphis: mickey mentioned it had other issues 
May 24 19:04:17 <khem> as well
May 24 19:04:17 <khem> so stick to 2.6.x
May 24 19:04:26 <morphis> ok, so it is not ready yet to be used
May 24 19:05:18 <morphis> then I need to patch for providing a pkg-config file or do another work around in my software
May 24 19:20:35 <GNUtoo> hmmm
May 24 19:20:54 <GNUtoo> I've no idea why it does this tough:
May 24 19:22:13 <GNUtoo> http://pastie.org/1967725
May 24 19:22:18 <GNUtoo> before is with mdev -s
May 24 19:22:24 <GNUtoo> after is after starting udev
May 24 19:22:40 <GNUtoo> udev is the init.d script
May 24 19:22:58 <GNUtoo> I'll try to see if it's my image
May 24 19:25:22 <tharvey> I'm running into a build issue with release-2011-03 tk on a build server that was just recently upgraded from u9.04 (32bit) to u10.04 (32bit) - I've long built on a x64 u10.04 without issues but its looking a bit like the issue I'm encountering is tk's recipe allowing host libc to be references for non native tk
May 24 19:26:45 <tharvey> 686-commonos-linux-gcc -march=pentium-m --sysroot=/home/oe/tmp/sysroots/i686-commonos-linux -O2 -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb2 -pipe   -Wl,-O1 -Wl,--hash-style=gnu -Wl,--export-dynamic  tkAppInit.o -L/home/oe/tmp/work/i686-commonos-linux/tk-8.5.8-r2/tk8.5.8/unix -ltk8.5 \
May 24 19:26:45 <tharvey>                 -L/home/oe/tmp//sysroots/i686-commonos-linux/usr/lib -ltcl8.5  -lpthread -L/home/oe/tmp//sysroots/i686-commonos-linux/usr/lib -lX11 -lXft   -ldl  -lpthread -lieee -lm  -Wl,-rpath,/usr/lib -o wish
May 24 19:26:45 <tharvey> /usr/lib/libfreetype.so.6: undefined reference to `__longjmp_chk@GLIBC_2.11'
May 24 19:26:45 <tharvey> collect2: ld returned 1 exit status
May 24 19:26:48 <tharvey> make: *** [wish] Error 1
May 24 19:27:12 <tharvey> can't believe that release-2011-03 would have issues showing up on 32bit u10.04 - is there likely something else I'm missing?
May 24 19:28:40 <khem> tharvey: its using /usr/lib/libfreetype.so.6 which is dead wrong
May 24 19:29:37 <khem> tharvey: again you need to most probably upgrade libtool macros 
May 24 19:32:56 <pespin> GNUtoo, my advise would be setting an init script which runs udev in some verbose mode and log its output to find the exact errors :)
May 24 19:33:09 <GNUtoo> I've serial console
May 24 19:33:26 <pespin> GNUtoo, and udev hangs?
May 24 19:33:34 <GNUtoo> it doesn't hang
May 24 19:33:41 <GNUtoo> http://pastie.org/1967725
May 24 19:33:47 <GNUtoo> but let me try something
May 24 19:33:52 <GNUtoo> maybe it's the image that is wrong
May 24 19:33:57 <GNUtoo> I didn't push it to oe
May 24 19:34:02 <GNUtoo> so it might be wrong
May 24 19:34:40 <GNUtoo> ah console-image has the same issue
May 24 19:34:43 <GNUtoo> so not my image
May 24 19:35:08 <pespin> --debug ¿
May 24 19:35:14 <tharvey> khem, this isn't an sdk
May 24 19:35:16 <pespin> udev --debug
May 24 19:35:26 <pespin> it may give you some more info
May 24 19:35:38 <tharvey> khem, I mean to say, i'm not using an sdk here, I'm building on, this is a build failure from bitbake
May 24 19:37:22 <GNUtoo> I'll try udevd --debug
May 24 19:38:19 <GNUtoo> thanks for the pointer
May 24 19:39:41 <tasslehoff> How should I create my own machine that resembles the beagleboard, but has an own boardconfig in u-boot and linux. I suspect: create my own machine file, patch u-boot and linux with the new board config, and make u-boot tell linux what type of board it is. Sound about right?
May 24 19:40:25 <tasslehoff> I want everything except my u-boot and my kernel to be the same as for the beagleboard (I think)
May 24 19:41:12 <khem> tharvey: yes I know
May 24 19:41:28 <khem> tharvey: what distro ?
May 24 19:42:24 <tharvey> khem, u10.04 (32bit) - I only ask as that seems to me to be a very popular distro for those building OE and while I've been previously using u10.04 64bit I am surprised if there is a meta-data issue causing it to fail
May 24 19:42:40 <tharvey> I would agree it sure looks like tk's recipe doing something very wrong
May 24 19:42:54 <tharvey> which I would have expected someone to encounter and fix long ago if that were the case
May 24 19:42:57 <khem> tharvey: is it for x86 target
May 24 19:47:57 <GNUtoo> http://pastie.org/1967844
May 24 19:54:04 <kergoth> i should really shift the deprecation warning bits in bitbake into somewhere common so i can use it in bitbake-layers
May 24 19:54:07 <kergoth> i'm sick of the verbosity
May 24 19:54:19 <woglinde_> *g*
May 24 19:55:32 <GNUtoo> does someone have an idea on why udev only create the followin dev nodes:
May 24 19:55:38 <GNUtoo> fd       kmsg     pts      stderr   stdout initctl  null     shm      stdin
May 24 19:56:30 <kergoth> what's annoying about these deprecation warnings is that they're about bitbake apis, but we don't want to shift to the new apis until we also bump the minium required bitbake version to match that. it'd be nice if there was a clean way to silence the warnings only in the correct circumstances, somehow
May 24 19:57:30 <GNUtoo> I'll try something
May 24 19:57:42 <GNUtoo> /sbin/udevadm trigger
May 24 19:57:43 <GNUtoo> works
May 24 19:57:45 <GNUtoo> it seems
May 24 19:59:31 <kergoth> don't the startup scripts do that already, or something similar, for the "coldplug" basically?
May 24 19:59:35 * kergoth isn't up on current udev
May 24 19:59:57 <GNUtoo> it's the startup script
May 24 20:00:17 <GNUtoo> but only at first boot
May 24 20:00:21 <GNUtoo> else it does something like that:
May 24 20:00:31 <GNUtoo> /sbin/udevadm trigger --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus  --subsystem-nomatch=graphics  --subsystem-nomatch=backlight --subsystem-nomatch=video4linux  --subsystem-nomatch=platform ....
May 24 20:00:51 <kergoth> thats because it should have saved the previous created bits in the dev tarball and restored them with that
May 24 20:00:52 <kergoth> afaik anyway
May 24 20:00:55 * kergoth htinks
May 24 20:00:56 <GNUtoo> ouch that line looked less long before sending it
May 24 20:00:58 * kergoth thinks, even
May 24 20:01:16 <GNUtoo> ok
May 24 20:01:40 <GNUtoo> so next time....don't abort the first boot
May 24 20:02:55 <kergoth> hehe
May 24 20:03:39 <tharvey> khem, regarding tk recipe trying to link against things in / you say m4 macros are likely to blame, your talking about patching tk's m4 macros?
May 24 20:05:18 <khem> tharvey: thats my guess
May 24 20:05:26 <khem> tharvey: its the search order I think 
May 24 20:05:46 <khem> if you build 32bit x86 on ubuntu-32bit running on 32bit
May 24 20:06:04 <khem> then the host libraries can leak into build silently and it will be accepted as well
May 24 20:06:12 <tharvey> still not understanding why this would be cropping up now all the sudden considering how populare u10.04 32bit building OE should be, I'll start digging
May 24 20:06:17 <khem> which is what seems to happen in your case
May 24 20:06:32 <tharvey> right, which they wouldn't in 64bit x86 ubuntu building for 32bit x86
May 24 20:06:38 <khem> I assume you are build for i586 target on ubuntu-32bit
May 24 20:06:44 <tharvey> i686
May 24 20:06:55 <khem> yes thats similar
May 24 20:07:06 <GNUtoo> thanks a lot for the pointers and help btw
May 24 20:07:12 <khem> so I think in the search order /usr/lib is appearing first 
May 24 20:07:20 <tharvey> ok, I'll look there
May 24 20:07:32 <khem> but since for other arches it doesnot match it fails and search continues
May 24 20:07:40 <khem> but for i686 is matches and gets used
May 24 20:07:52 <khem> but ubuntu builds with fortify sources 
May 24 20:08:04 <khem> so it does not link properly with host libs
May 24 20:08:15 <tharvey> fortify sources?
May 24 20:08:33 <khem> FORTIFY_SOURCES define
May 24 20:08:38 <khem> you can google for it
May 24 20:08:44 <tharvey> k
May 24 20:08:50 <tharvey> by the way, I never did get a good understanding regarding use of LIBTOOL_SYSROOT_PATH in an sdk, where are you saying that is used?
May 24 20:08:54 <khem> explaining here will take lot of typing
May 24 20:10:03 <khem> tharvey: w.r.t. libtool and SDK it might be that we need to provide proper sysroot path into libtool
May 24 20:10:06 <khem> invocation
May 24 20:11:04 <tharvey> but where is libtool used in use of an external sdk?  via libtoolize when running autoreconf?
May 24 20:12:00 <khem> tharvey: its used in the build process
May 24 20:12:06 <khem> to do linking and compiling
May 24 20:12:14 <khem> but its generated duting autoreconf
May 24 20:12:35 <khem> libtool is a script acompanied with macros usually under m4/ dir
May 24 20:16:42 * GNUtoo doesn't understand
May 24 20:16:52 <GNUtoo> it blocks just the same at first boot
May 24 20:16:53 <tharvey> so I see how OE often passes a '--with-libtool-sysroot=' to configure, thats what your talking about right, doing the same when using the sdk?
May 24 20:17:16 <GNUtoo> Checking for built-in Bluetooth: no
May 24 20:17:19 <GNUtoo> and then nothing
May 24 20:17:28 <GNUtoo> how long should I wait?
May 24 20:17:29 <GNUtoo> 1h
May 24 20:17:30 <GNUtoo> more?
May 24 20:17:36 <GNUtoo> 10min?
May 24 20:17:57 <GNUtoo> pressing enter doesn't result in some visual feedback
May 24 20:18:13 <khem> tharvey: yes
May 24 20:19:25 <tharvey> I think you had previously mentioned that we include libtool in the sdk such that 'our' version is used, but I do notice 'libtool' is not in the path as augmeted by sdk env setup - libtoolize is
May 24 20:21:03 <tharvey> for an x86_64 sdk, 'x86_64-linux-libtool' is in SDK's path, and I wonder if there should be a libtool in that path symlinked to it
May 24 20:22:19 <GNUtoo> still blocked
May 24 20:22:36 <GNUtoo> what should I do?
May 24 20:22:53 <GNUtoo> I guess I should add debug code to udev init script
May 24 20:27:57 <khem> tharvey: hmmm libtool should be regenerated imo for target recipes during autoreconf 
May 24 20:28:05 <khem> or explicitly using libtoolize
May 24 20:29:33 <GNUtoo> hmmm I extracted it again and same thing
May 24 20:29:39 <GNUtoo> I think it doesn't call trigger
May 24 20:29:42 <tharvey> yes, it is - generates it in project dir.  so basically an upstreams project likely doesn't understand the --with-libtool-sysroot arg to configure but if you run autoreconf to regenerate configure (and libtool) then it does right?
May 24 20:30:32 <tharvey> so it seems like the correct instructions for using sdk against a project using autoconf is to 1) run autoreconf 2) run configure --host=$TARGET_SYS --with-libtool-sysroot=$LIBTOOL_SYSROOT_PATH
May 24 20:30:57 <tharvey> (assuming the issue with the various binconfigs that I mentioned previously is resolved - there were no responses to my RFC on the ML)
May 24 20:44:08 <GNUtoo>         /sbin/udevadm control --env STARTUP=1
May 24 20:44:12 <GNUtoo> I think that blocks it
May 24 20:46:34 <GNUtoo> what's the required kernel for 165?
May 24 20:47:08 <GNUtoo> oops
May 24 20:47:16 <GNUtoo> I meant udev 168
May 24 20:47:26 <GNUtoo> ah it's in the description
May 24 20:47:33 <GNUtoo> 2.6.27 is fine
May 24 20:49:15 <khem> tharvey: yes if SDK ships with libtool 2.4 
May 24 20:49:50 <khem> GNUtoo: is ur issue related to upgrade of udev
May 24 20:50:31 <khem> did 165 work well ?
May 24 20:50:32 <GNUtoo> possible, it worked before
May 24 20:50:35 <tharvey> khem, yes, current sdk does - ok think I understand the process then thx.  I'll have to put a patch together for prefixing binconfig paths with SDK_ROOT and see if I get response to that in ML
May 24 20:50:36 <GNUtoo> I think so
May 24 20:50:59 <khem> GNUtoo: ok then pin your udev to 165 and see if it works
May 24 20:51:05 <GNUtoo> ok
May 24 20:51:06 <khem> if it does then you know the culprit
May 24 20:51:14 <GNUtoo> yes but what to do?
May 24 20:51:26 <GNUtoo> fix udev 168?
May 24 20:51:27 <khem> it could be also related to kernel-headers in use
May 24 20:51:38 <khem> yes we need to figure out whats blocking
May 24 20:51:39 <GNUtoo> I've 2.6.27 kernel
May 24 20:51:43 <GNUtoo> and it says:
May 24 20:51:59 <GNUtoo> It replaces the hotplug package and requires a kernel not older than 2.6.27.
May 24 20:52:04 <GNUtoo> so normally I'm fine
May 24 20:52:15 <GNUtoo> else I must port forward all the support to more recent kernels
May 24 20:52:18 <GNUtoo> which is not good
May 24 20:52:23 <GNUtoo> since some stuff will lack
May 24 20:52:28 <GNUtoo> and it would take ages
May 24 20:52:30 <khem> well I would say pin udev
May 24 20:52:34 <GNUtoo> ok
May 24 20:52:37 <GNUtoo> there are udev compat
May 24 20:52:41 <GNUtoo> I could use that
May 24 20:52:44 <GNUtoo> or use mdev
May 24 20:52:57 <GNUtoo> but mdev is not a good solution
May 24 20:53:01 <GNUtoo> userland expects udev
May 24 20:53:07 <khem> why not use PREFERRED_VERSION_udev
May 24 20:53:09 <GNUtoo> (/dev/input etc...
May 24 20:53:13 <GNUtoo> I'll do it now
May 24 20:55:41 <GNUtoo> I pin for testing
May 24 20:55:47 <GNUtoo> but better fixing upstream
May 24 20:55:51 <GNUtoo> be it oe or udev
May 24 20:55:59 <khem> sure 
May 24 20:56:07 <khem> but we have to know whats blocking
May 24 20:56:08 <GNUtoo> that's why I kept talking
May 24 20:56:12 <GNUtoo> indeed
May 24 20:56:15 <GNUtoo> strace?
May 24 20:56:17 <khem> so debugging it is needed
May 24 20:56:20 <khem> yes strace
May 24 20:56:28 <khem> but you might not have strace that early
May 24 20:56:47 <GNUtoo> I can manage to have it
May 24 20:56:53 <khem> good
May 24 20:56:59 <khem> yeah figure out 
May 24 20:57:03 <GNUtoo> I just include it in the image etc...
May 24 20:57:03 <khem> I am sure its some syscall
May 24 20:57:09 <GNUtoo> ok
May 24 20:57:31 <khem> another thing you could do is use 2.6.27 kernel headers
May 24 20:57:35 <khem> or even older
May 24 20:57:45 <GNUtoo> ok
May 24 20:57:56 * GNUtoo looks what are the current kenrel headers for angstrom
May 24 20:58:29 <khem> GNUtoo: are u using oe-core+angstrom
May 24 20:58:34 <GNUtoo> no
May 24 20:58:35 <GNUtoo> old oe
May 24 20:58:39 <khem> k
May 24 20:58:48 <GNUtoo> there are still a lot of work to do for oe-core
May 24 20:59:00 <GNUtoo> and I don't have that much time for that
May 24 21:00:28 <GNUtoo> btw trying PREFERRED_VERSION_pn-udev = "165"
May 24 21:00:42 <GNUtoo> since PREFERRED_VERSION_udev = "165" failed to set it to 165
May 24 21:01:18 <khem> do PREFERRED_VERSION_udev_local
May 24 21:01:31 <GNUtoo> ah it was local
May 24 21:01:32 <GNUtoo> ok
May 24 21:01:34 <GNUtoo> thanks a lot
May 24 21:01:55 <woglinde_> udev 165 has memleaks
May 24 21:01:58 <woglinde_> better use 168
May 24 21:02:09 <GNUtoo> indeed I've some local in some local.conf
May 24 21:02:10 <khem> woglinde_: what use if it does not boot
May 24 21:02:12 <GNUtoo> MACHINE_KERNEL_PR_local = "r96"
May 24 21:17:49 <GNUtoo> udev 165 works
May 24 21:18:14 <woglinde_> memleaks memleaks
May 24 21:18:29 <GNUtoo> woglinde_, it's for debugging only
May 24 21:18:29 <woglinde_> good nite
May 24 21:18:36 <GNUtoo> I remember it worked
May 24 21:18:46 <GNUtoo> but khem told me to try anyway
May 24 21:20:36 <GNUtoo> now I'll strace the parts
May 24 21:55:10 <gnutoo_> poll([{fd=3, events=POLLIN}], 1, 60000
May 24 21:55:22 <gnutoo_> after that it closes and exit
May 24 21:55:26 <gnutoo_> and continue
May 24 21:57:46 <gnutoo_> maybe I should trace every udev part
May 24 22:03:46 <gnutoo_> I'll try with linux-next
May 24 22:03:52 <gnutoo_> patched for microsd support
May 24 23:12:56 <ericben> hi. When using amend.inc to apply a patch to a recipe (ex: to psplash-angstrom.bb) is it possible to exclude an other recipe from using the amend.inc (ex : psplash-zap.bb) ?
May 24 23:14:23 <kergoth> just put it in a more specific location.
May 24 23:14:27 <kergoth> its found via filespath
May 24 23:14:33 <kergoth> so you can put it anywhere you could put a recipe specific patch
May 24 23:14:37 <kergoth> pn, pn-pv, etc
May 24 23:15:54 <ant__> kergoth: I've seen the commits passing KERNEL_VERSION through legitimize_package_name
May 24 23:15:57 <ericben> hi kergoth 
May 24 23:16:17 <ant__> I hoped I could doo the same for comparing special kernel PV
May 24 23:16:22 <ericben> ok thanks
May 24 23:16:43 <ant__> but no success until now
May 24 23:17:08 <ant__> seems failing against '+'  e.g. linux_2.6.38+2.6.39-rc7
May 24 23:17:46 <ant__> (vercmp)
**** ENDING LOGGING AT Wed May 25 02:59:57 2011