**** BEGIN LOGGING AT Thu Jun 24 02:59:58 2010
Jun 24 04:35:15 <newbie_sreddy> hi
Jun 24 04:47:54 <newbie_sreddy> how to set teh AEABI in kernel features 
Jun 24 04:48:35 <newbie_sreddy> i have checked nt defconfig and it is set ( CONFIG_AEABI=y)
Jun 24 07:26:00 <hrw> morning
Jun 24 07:27:41 <JaMa> moin
Jun 24 07:28:32 <JaMa> is BBCLASSEXTEND also adding -native to PROVIDES? ie libice-native PROVIDES = "ice-native" now, do I have to add PROVIDES_virtclass-native = "ice-native" to BBCLASSEXTENDed libice recipe?
Jun 24 08:00:31 <pb__> JaMa: it does that automatically
Jun 24 08:04:11 <JaMa> pb__: thanks
Jun 24 08:15:18 <TheExplorer> greetings
Jun 24 08:15:33 <TheExplorer> I have a nightmare, that i hope one of you is brilliant enough to solve.
Jun 24 08:15:55 <TheExplorer> The HP, Ipaq, HX2000 series (HX2495b)
Jun 24 08:16:27 <TheExplorer> I want so badly for this device to have linux, even if it is lacking of wifi/bluetooth (Which in time i can correct the drivers of)
Jun 24 08:29:33 <hrw> hx2000... there was some work done for it 
Jun 24 08:30:30 <hrw> but quite long time ago
Jun 24 08:41:52 <GNUtoo|laptop> http://www.handhelds.org/moin/moin.cgi/HpIpaqHx2000
Jun 24 08:43:11 <GNUtoo|laptop> TheExplorer ^^^
Jun 24 08:43:30 <TheExplorer> oooooh
Jun 24 08:46:46 <TheExplorer> I think i ran into this site once long ago
Jun 24 08:48:01 <hrw> and port is 4 years old
Jun 24 08:48:19 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rbb684983bf 10openembedded.git/ (2 files in 2 dirs): efl: bump SRCREV
Jun 24 08:48:45 <hrw> TheExplorer: "MACHINE=hx2000 bitbake virtual/kernel" and check will it build at all
Jun 24 08:49:09 <hrw> then you will have lot of work to make it work with current kernels
Jun 24 08:59:30 <GNUtoo|laptop> btw I've that:
Jun 24 08:59:36 <GNUtoo|laptop> |  * satisfy_dependencies_for: Cannot satisfy the following dependencies for task-base: |  * 	angstrom-version * 
Jun 24 08:59:57 <GNUtoo|laptop> when bitbaking an image wich depends on task-base
Jun 24 09:00:11 <GNUtoo|laptop> should I pull? is it fixed?
Jun 24 09:05:53 <JaMa> another BBCLASSEXTEND question: if there is DYNAMIC_PACKAGES defined, then the same packages are dynamic in -native version (without -native postfix) is it fixable in any way or can I drop it with DYNAMIC_PACKAGES_virtclass-native = "" (we probably don't require dynamic native evas loaders and pango stuff..)
Jun 24 09:16:20 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rf4dcd0e6b6 10openembedded.git/recipes/mplayer/mplayer_git.bb: 
Jun 24 09:16:20 <CIA-2> mplayer_git: bump SRCREV and enable vpx like mplayer_svn does
Jun 24 09:16:20 <CIA-2> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jun 24 09:16:22 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * rce26c079f2 10openembedded.git/recipes/xorg-lib/ (libx11_1.3.3.bb libx11_1.3.4.bb): 
Jun 24 09:16:22 <CIA-2> libx11: add -fforward-propagate also to newer 1.3.[34] versions
Jun 24 09:16:28 <CIA-2> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jun 24 09:16:29 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r487b101b42 10openembedded.git/recipes/xorg-lib/xorg-lib-common.inc: 
Jun 24 09:16:29 <CIA-2> xorg-lib-common: use BPN instead of PN as default XORG_PN
Jun 24 09:16:30 <CIA-2> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jun 24 09:16:30 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r136054d11f 10openembedded.git/recipes/xorg-lib/pixman_0.18.2.bb: 
Jun 24 09:16:31 <CIA-2> pixman_0.18.2: increase D_P also for shr
Jun 24 09:16:31 <CIA-2> Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>
Jun 24 09:16:32 <CIA-2> 03Martin Jansa <Martin.Jansa@gmail.com> 07org.openembedded.dev * r8b616f148b 10openembedded.git/recipes/xorg-lib/ (5 files): 
Jun 24 09:16:32 <CIA-2> libxcursor: convert to BBCLASSEXTEND
Jun 24 09:21:03 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * ra35e2d9b12 10openembedded.git/recipes/gnome/libwnck_2.30.0.bb: libwnck-native: change dep from csource-native to gtk+-native, this makes it work for more users
Jun 24 09:45:03 <CIA-2> 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * rc0adf95caf 10openembedded.git/recipes/qt4/qt4-tools-native.inc: qt4-tools-native.inc: Pulled -static configure argument into a variable (for overridability).
Jun 24 09:45:04 <CIA-2> 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * rd020e23c02 10openembedded.git/recipes/swt/swt-gtk.inc: 
Jun 24 09:45:04 <CIA-2> swt-gtk.inc: Support SWT 3.6, remove legacy staging support.
Jun 24 09:45:04 <CIA-2> swt3.6-gtk 3.6: New recipe.
Jun 24 09:45:04 <CIA-2> 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r64e7aaced5 10openembedded.git/recipes/jamvm/ (5 files): jamvm.inc: Make libjvm.so a private lib.
Jun 24 09:45:05 <CIA-2> 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r4b7eaa7b90 10openembedded.git/recipes/cacao/ (cacao.inc cacao_0.99.3.bb cacao_0.99.4.bb): cacao.inc: Make libjvm.so a private lib.
Jun 24 09:45:06 <CIA-2> 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r744c4322b5 10openembedded.git/recipes/qt4/qt4-tools-native.inc: qt4-tools-native: Revert change to add part of the configure flag into a variable.
Jun 24 09:45:09 <CIA-2> 03Robert Schuster <robertschuster@fsfe.org> 07org.openembedded.dev * r8615c5014c 10openembedded.git/recipes/ (3 files in 2 dirs): 
Jun 24 09:45:09 <CIA-2> libecj-bootstrap 3.5: Removed (was not stable for openjdk builds).
Jun 24 09:45:09 <CIA-2> libecj-bootstrap 3.6: New recipe.
Jun 24 11:44:44 <hrw> XorA: http://www.youtube.com/watch?v=C6QF_MtVPGo
Jun 24 11:50:23 <XorA> hrw: nice, and Run DMC as well :-)
Jun 24 11:52:07 <mwester> Did we ever have a discussion on a hypothetical "dbus-no-X11" recipe?
Jun 24 11:52:41 <pb_> I don't recall one, but of course that doesn't mean it didn't happen.
Jun 24 11:53:53 <mwester> Well, as I consider opening/re-opening such a discussion, I guess I'm really just wondering if this is one of those topics that isn't even worth bringing up again, if it's been beaten about over and over.
Jun 24 11:55:27 <pb_> I don't think it is one of those.  If the current dbus is causing you a problem then I think it's legitimate to bring it up.
Jun 24 11:56:06 <XorA> is this a build time issue? the fact that dbus recipe drags in libx11?
Jun 24 11:56:11 <pb_> I guess the obvious question would be whether what you really want is a no-X11 dbus recipe specifically, or whether you just want to be setting some equivalent to "no-x11" in your DISTRO_FEATURES and turning x11 off more globally.
Jun 24 11:56:32 <JaMa> mwester: does it need new recipe or you have problem with space on target and better dbus-x11 package would be enough?
Jun 24 11:57:50 <mwester> :)  That is exactly the issue.  It's pointless to build x11 for a device that has only 32MB of RAM, really -- so all it does it increase build time, and it makes it more likely that we encounter build failures on packages that will never ever get installed.  If there is a way to handle this in DISTRO_FEASTURES, I would love to know about how to do that.
Jun 24 11:58:54 <JaMa> mwester: see "tk" DISTRO_FEATURE used in python
Jun 24 11:59:05 <mwester> JaMa: Thanks!
Jun 24 11:59:06 <XorA> mwester: there is no way currently, but I think x11 as a DISTRO_FEATURE makes perfect sense
Jun 24 11:59:29 <XorA> doing it that way also wont accidently affect angstrom and minimal
Jun 24 11:59:54 <mwester> I shall investigate that, then.  Sounds like a better way to handle this than to do "spot edits" on individual recipes.
Jun 24 12:00:11 * XorA would be happy to review such a series of patches
Jun 24 12:00:21 <XorA> Id suggest a feature branch
Jun 24 12:00:34 <JaMa> isn't it more like MACHINE_FEATURE? but it would break multi machine build dirs..
Jun 24 12:00:43 <mwester> Now all I need to do is invent the 36-hour day so I have time. :)
Jun 24 12:00:49 <XorA> as I suspect no-x11 will hit other recipes as well
Jun 24 12:01:09 <XorA> I assume we are talking SlugOS?
Jun 24 12:01:37 <mwester> I hope no-x11 would affect other recipes; I was really surprised by the dependency graph that SlugOS had; so many things seem to (indirectly) pull in libx11 and friends.
Jun 24 12:01:43 <mwester> Yes, this is SlugOS.
Jun 24 12:01:57 <XorA> so its a pretty targeted DISTRO anyway
Jun 24 12:02:11 <XorA> but people have asked for a no-x11 angstrom varient a few times
Jun 24 12:02:37 <XorA> and I suspect micro would benefit as well
Jun 24 12:03:22 <mwester> dbus seems the "poster child" for this issue -- it's a need-to-have for many utilities now, even on small distros.  But there's no busybox-like solution, and that's what I was looking for when I realized that x11 is not actually mandatory for dbus to build.
Jun 24 12:04:01 <XorA> dbus/gstreamer/directfb come to mind immediately
Jun 24 12:05:29 <mwester> I'm not sure about the need for hal, but I think that too ends up tangled in the dependencies for bluez -- which would be nice to have for (for example) a small bluetooth gateway device.
Jun 24 12:06:19 <mwester> and hal pulls in cairo and pango and lots of other stuff, which I think comes in via gstreamer or something like that.  The dependency graph is a bit big for my little monitor here :D
Jun 24 12:06:28 <XorA> hal should die
Jun 24 12:06:36 <mwester> Anyway, I'll take a look. Thanks.
Jun 24 12:06:40 <XorA> pretty much everything that used hal now uses libudev
Jun 24 12:31:23 <hrw> hal pulls bluetooth which pulls gstreamer which pulls x11,gtk,gnome,whoknows
Jun 24 12:32:06 * JaMa doesn't have hal pulled as runtime dependency to shr-lite-images anymore
Jun 24 12:32:36 <GNUtoo|laptop> hi JaMa 
Jun 24 12:32:38 <GNUtoo|laptop> OPKG_SRCREV ?= "532" #BAD
Jun 24 12:32:41 <JaMa> last package pulling it was tslib .. http://git.openembedded.org/cgit.cgi/openembedded/commit/?id=809138a4a19b815894dbfdaf69ec6d39b0a5a032
Jun 24 12:33:33 <JaMa> GNUtoo|laptop: hi, koen just bumped it to 538, but reading changes I don't expect your issue to be changed..
Jun 24 12:33:51 <JaMa> GNUtoo|laptop: do you have now the problem narrowed to something usable?
Jun 24 12:34:11 <GNUtoo|laptop> JaMa, yes I just posted the exact commit of opkg which broke it
Jun 24 12:34:21 <GNUtoo|laptop> #OPKG_SRCREV ?= "531" #GOOD
Jun 24 12:34:21 <GNUtoo|laptop> OPKG_SRCREV ?= "532" #BAD
Jun 24 12:34:25 <JaMa> GNUtoo|laptop: I think that with small testcase graham will find and fix your issue quickly
Jun 24 12:34:54 <GNUtoo|laptop> maybe I should try to understand why it's #bad
Jun 24 12:36:33 <JaMa> GNUtoo|laptop: please fill the ticket on opkg site, while trying to understand it.. maybe Graham will fix it sooner (no offence :))
Jun 24 12:36:46 <GNUtoo|laptop> ok
Jun 24 12:37:09 <JaMa> GNUtoo|laptop: and no change in installed-packages in testlab?
Jun 24 12:37:21 <JaMa> GNUtoo|laptop: so only files are missing not packages
Jun 24 12:37:28 <GNUtoo|laptop> I'll look
Jun 24 12:37:33 <GNUtoo|laptop> but I'll post before
Jun 24 12:37:38 <GNUtoo|laptop> as you requested
Jun 24 12:38:29 <JaMa> thanks
Jun 24 12:44:11 <ant_work> JaMa: I stumbled in an unwanted side-effect of [oe] [PATCH] recipes: conform to OE packaging guidelines with RSUGGESTS/RPROVIDES/RCONFLICTS/RREPLACES
Jun 24 12:44:35 <JaMa> where?
Jun 24 12:44:42 <ant_work> maybe you can help me understand what is proper fix
Jun 24 12:45:06 <ant_work> http://cgit.openembedded.org/cgit.cgi/openembedded/tree/recipes/opie-taskbar/opie-taskbar-images.inc
Jun 24 12:45:08 <JaMa> I remember you showing something like RPROVIDES_${PN} = ${PN}?
Jun 24 12:45:19 <ant_work> yes
Jun 24 12:45:30 <ant_work> but the recipe is funny
Jun 24 12:45:33 <JaMa> this is IMHO very strange
Jun 24 12:45:46 <ant_work> read opie-taskbar.inc ...
Jun 24 12:45:58 <ant_work> #RDEPENDS_${PN} = "opie-taskbar-images"
Jun 24 12:46:14 <JaMa> see http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=14c265b107725a8f7534dfb354ad12edf9f7aec3 RRECOMMENDS change
Jun 24 12:46:39 <ant_work> I really don't know much about opie internals, just trying to make it build again
Jun 24 12:47:20 <JaMa> there it was RRECOMMENDS_${PN} was applied only to "main" package with font, but not to subpackages also with fonts, needed same RRECOMMENDS, but better fix would be to list all subpackages with right RRECOMMENDS_${PN}-sub in recipe including this
Jun 24 12:47:54 <ant_work> I see
Jun 24 12:48:14 <dcordesZzleeepin>  khem nope same build time error
Jun 24 12:48:35 <JaMa> neither do I know internals, but I would expect some constant text on right side of RPROVIDES
Jun 24 12:49:04 <ant_work> the nte about broken ipkg must be very old...
Jun 24 12:50:47 <GNUtoo|laptop> JaMa, it's not in installed packages
Jun 24 12:51:12 <ant_work> JaMa: so we need a RPROVIDES for each member of PACKAGES
Jun 24 12:53:05 <JaMa> ant_work: I don't understand why it's even needed..
Jun 24 13:06:29 <ant_work> JaMa: perhaps  http://bugs.openembedded.org/show_bug.cgi?id=828
Jun 24 13:09:16 <ant_work> there is no ${PN} in PACKAGES
Jun 24 13:09:42 <ant_work> so RPROVIDES_${PN} = "${PN}" will fail
Jun 24 13:09:59 <ant_work> or am I totally wrong?
Jun 24 13:10:25 <ant_work> btw this recipe is awckward
Jun 24 13:10:30 <ant_work> :/
Jun 24 13:15:20 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * rd602d85d3a 10openembedded.git/recipes/devicekit/libatasmart_0.13.bb: libatasmart: convert to new style staging
Jun 24 13:15:31 <CIA-2> 03Vitus Jensen <vjensen@gmx.de> 07org.openembedded.dev * r59235795f8 10openembedded.git/recipes/libusb/libusb1_1.0.8.bb: 
Jun 24 13:15:31 <CIA-2> libusb1_1.0.8: new recipe
Jun 24 13:15:31 <CIA-2> Signed-off-by: Vitus Jensen <vjensen@gmx.de>
Jun 24 13:15:31 <CIA-2> Signed-off-by: Koen Kooi <koen@openembedded.org>
Jun 24 13:17:24 <Torne> is it reasonably possible to use bitbake to set up a build system for something from scratch, without the openembedded files? :)
Jun 24 13:17:44 <PS> Hi all, I am facing following error please let me know your suggestions:
Jun 24 13:17:47 <PS>  /etc/init.d/dbus-1 start
Jun 24 13:17:47 <PS> Starting system message bus: Failed to start message bus: The pid file "/var/run/messagebus.pid" exists, if the message bus is not running, remove this file
Jun 24 13:18:04 <PS> /etc/init.d/dbus-1 stop
Jun 24 13:18:05 <PS> Stopping Hardware abstraction layer hald
Jun 24 13:18:05 <PS> run-parts: /etc/dbus-1/event.d/20hal exited with code 1
Jun 24 13:18:55 <JaMa> ant_work: I think it's different issue then RDEPENDS bug.. as you can have  RPROVIDES_${PN} = "blah" and blah is not defined anywhere else
Jun 24 13:19:41 <JaMa> PS: does that file exist, is daemon running? -> if the message bus is not running, remove this file
Jun 24 13:21:47 <PS> yes,  /usr/bin/dbus-daemon --system is running
Jun 24 13:22:49 <PS> JaMa: yes daemon is running
Jun 24 13:25:37 <PS> JaMa: yes file also exist, cat /var/run/messagebus.pid
Jun 24 13:25:37 <PS> 2917
Jun 24 13:32:08 <JaMa> same pid as running daemon?
Jun 24 13:32:45 <PS> JaMa: yes
Jun 24 13:33:37 <PS> ps -aux | grep dbus-*
Jun 24 13:33:38 <PS> 12        2897  0.0  0.0   2252   788 ?        Ss   Jun23   0:00 /usr/bin/dbus-daemon --system
Jun 24 13:33:38 <PS> 12        2917  0.0  0.0   2252   792 ?        Ss   Jun23   0:00 /usr/bin/dbus-daemon --system
Jun 24 13:33:57 <JaMa> PS: after 2nd read of your paste, I think the problem is only with hald isn't it?
Jun 24 13:34:43 <JaMa> PS: in case dbus was running before you tried to start it first and then stopping dbus-1 which needs to stop hald first fails in /etc/dbus-1/event.d/20hal
Jun 24 13:35:22 <JaMa> I don't have hald here to check what's in that file, but I think you should dig there
Jun 24 13:35:37 <PS> ok
Jun 24 13:36:40 <JaMa> wtf enabling xcb in libx11 breaks package naming :/ and I have libx11 instead of libx11_6
Jun 24 13:47:50 <hrw> check what is in package
Jun 24 14:06:25 <khem> dcordes: hmmm whats detailed error ? can u paste it somewhere
Jun 24 14:06:41 <khem> good morning to all
Jun 24 14:09:22 <kergoth> morning
Jun 24 14:11:23 <khem> g'morning kergoth 
Jun 24 14:11:26 <etrunko> morn
Jun 24 14:11:27 <kergoth> hey
Jun 24 14:11:28 <pb_> yo kergoth
Jun 24 14:11:44 * pb_ birthday today, bleh
Jun 24 14:12:05 <kergoth> got a successfully completed task-base with checking enabled that errors if a task tries to access a variable that wasn't included in the generated signature from the varref code :)
Jun 24 14:12:12 <kergoth> happy birthday! how old?
Jun 24 14:12:16 <pb_> kergoth: very cool
Jun 24 14:12:20 <pb_> 34
Jun 24 14:12:39 <pb_> and thanks :-)
Jun 24 14:12:49 <etrunko> sight... i'm still having problems with xf86-input-{keyboard,mouse}... have any of you got into this: FATAL: This autoconf log indicates errors, it looked at host includes.
Jun 24 14:12:51 <khem> happy bday pb_ 
Jun 24 14:13:29 <pb_> etrunko: the error means pretty much what it says: something in the autoconf process started examining your host includes from /usr, which oughtn't to happen.
Jun 24 14:14:25 <etrunko> pb_: that's what i was thinking... but what could be the reason of that?
Jun 24 14:14:47 <pb_> a bug in the script, bogus pkgconfig input, wrong environment vars, ...
Jun 24 14:16:37 <etrunko> might help if i update bitbake?
Jun 24 14:16:43 <pb_> unlikely
Jun 24 14:19:47 <kergoth> etrunko: read the configure.in/configure.ac to start
Jun 24 14:20:29 <khem> lets see if Italy will make it into last 16 
Jun 24 14:22:52 <etrunko> kergoth: ok
Jun 24 14:24:26 <etrunko> and i also did check run.do_configure and config.log... they're in http://people.profusion.mobi/~etrunko/
Jun 24 14:24:38 <etrunko> ouch
Jun 24 14:24:46 <etrunko> slovenia scored
Jun 24 14:29:03 <CIA-2> 03Koen Kooi <koen@openembedded.org> 07org.openembedded.dev * r00f9b91c33 10openembedded.git/recipes/parted/parted_1.8.8.bb: parted 1.8.8: 'fix' configure, it builds again now
Jun 24 14:45:01 <etrunko> well. workaround this by hacking a do_qa_configure() {return} in recipes/xorg-driver/xorg-driver-common.inc :/
Jun 24 14:55:25 <kergoth> etrunko: you'll just hit problems later on instead of immediately
Jun 24 14:55:33 <kergoth> good luck
Jun 24 14:57:19 <etrunko> hehe
Jun 24 14:57:22 <etrunko> i know that
Jun 24 14:58:20 <khem> etrunko: why dont you try to look into logs and pin the problem 
Jun 24 14:58:51 <khem> etrunko: it should be the log.do_* files that OE generates plus config.log file that you will need
Jun 24 14:58:58 <khem> all of them I in build dir
Jun 24 15:22:41 <Jin^eLD> hi
Jun 24 15:23:26 <Jin^eLD> I finally updated my 6 month old oe.dev to current, I see patch=1 is no longer used for patches? are there other significant differences that I should be aware of when porting my collection with modified packages?
Jun 24 15:25:11 <kergoth> if the patch ends in .diff/.patch/.diff.gz/.patch.gz/etc you don't need to tell oe that its a patch anymore.  if it has that name and you don't want it applied, you can use apply=no.  and you set striplevel= instead of pnum= for the -p
Jun 24 15:25:17 * kergoth tries to remember other changes
Jun 24 15:25:28 <kergoth> Jin^eLD, might not be a bad idea to review the git log of classes/
Jun 24 15:26:04 <Jin^eLD> thanks
Jun 24 15:26:13 <Jin^eLD> regarding other stuff, roger that, will browse through the history
Jun 24 15:26:27 <kergoth> by definition, the classes are higher impact than the recipes, and should have much fewer commits to deal with
Jun 24 15:29:38 <kergoth> could also do a git log with --shortstat or something, check commits that affect a large number of lines :)
Jun 24 15:30:07 <Jin^eLD> :)
Jun 24 15:30:13 <kergoth> Jin^eLD, one change is that linux-libc-headers-native is built by default now, to ensure we can support rhel4 (iirc).  tom rini sent out a notification email to the list about that one
Jun 24 15:30:27 * kergoth should have sent a notification out on the patch changes.. there was a thread, but no big obvious WARNING
Jun 24 15:30:56 <kergoth> for more sane distros, you can likely safely add linux-libc-headers-native to ASSUME_PROVIDED
Jun 24 15:40:37 <Jin^eLD> bye :)
Jun 24 15:40:39 <Jin^eLD> oops wrong window
Jun 24 15:41:05 <Jin^eLD> kergoth
Jun 24 15:41:20 <Jin^eLD> : well, its no big deal if it gets built
Jun 24 15:41:25 <Jin^eLD> even better since we use different distros
Jun 24 15:41:44 * kergoth nods
Jun 24 15:41:55 <kergoth> it doesn't actually build anything anyway, so likely doesn't really affect build time
Jun 24 15:49:21 <Jin^eLD> whats the NATIVE_INSTALL_WORKS="1" thing, saw it in one package
Jun 24 15:49:26 <Jin^eLD> and did staging change a lot?
Jun 24 15:49:39 <kergoth> ahh, you hadn't updated since the new style staging change?
Jun 24 15:49:44 <Jin^eLD> right
Jun 24 15:49:47 <kergoth> yeah, its huge, the new stuff populates staging with the do_install output
Jun 24 15:49:51 <kergoth> no need for an explicit do_stage
Jun 24 15:49:54 <Jin^eLD> cool
Jun 24 15:49:55 <kergoth> (awesome, really)
Jun 24 15:50:03 <kergoth> lots of recipes still need converting
Jun 24 15:50:17 <Jin^eLD> so I can get rid of do_stage in all my recipes?
Jun 24 15:50:22 <kergoth> at any rate, native is special cased, there are a lot of variables that can control the behavior
Jun 24 15:50:30 <kergoth> yeah, unless you do some sort of special mangling or something
Jun 24 15:50:36 <kergoth> in which case you can add a hook for it to the staging bits
Jun 24 15:50:46 <kergoth> do a git grep is_legacy_staging
Jun 24 15:50:58 <kergoth> thats the logic of how it determines whether to use the new stuff or not
Jun 24 15:51:25 <kergoth> also, the tsc has determined to make packaged staging mandatory
Jun 24 15:51:30 <kergoth> just haven't gotten around to doing it
Jun 24 15:52:08 <Jin^eLD> do recipe need to do any extra stuff for packaged stating?
Jun 24 15:52:16 <kergoth> nope
Jun 24 15:52:22 <kergoth> it was just a distro level policy decision
Jun 24 15:52:29 <kergoth> the upside is do_clean can remove your shit from staging
Jun 24 15:52:36 <kergoth> which is really nice
Jun 24 15:52:50 <kergoth> and of course, the pstage output can be reused in subsequent builds to avoid having to rebuild it
Jun 24 15:52:54 <kergoth> it'll just use the package instead
Jun 24 15:53:47 <Jin^eLD> I see
Jun 24 15:54:17 <kergoth> basically it just takes the staging bits and shoves them into an ipk, based from TMPDIR, and installs/uninstalls there as though it was a rootfs
Jun 24 16:13:00 <kergoth> mickey|zzZZzz, ping, whenever you're around
Jun 24 16:51:02 <khem> kergoth: Why dont we populate sysroot with ipk's too
Jun 24 16:51:19 <khem> kergoth: I mean the very same ipk that will be installed on the target
Jun 24 16:51:28 <kergoth> khem, pb_ has spoken about that too
Jun 24 16:51:35 <khem> kergoth: ok
Jun 24 16:51:39 <kergoth> it would make it so we spot bugs in the -dev packages much sooner
Jun 24 16:51:45 <khem> kergoth: yes
Jun 24 16:51:47 <kergoth> its an interesting approach
Jun 24 16:51:59 * kergoth would be curious to see a prototype implementation
Jun 24 16:52:06 <khem> kergoth: and actually also populate the packaged_staging using the same ipks
Jun 24 16:52:15 <kergoth> wrong button
Jun 24 16:52:22 <khem> heh
Jun 24 16:52:47 <khem> kergoth: by doing this rebuilding a package would be consistent
Jun 24 16:53:00 <kergoth> well, somewhat :)
Jun 24 16:53:08 <khem> as we will uninstall the ipk's 
Jun 24 16:53:28 <khem> and the opkg should tell us if one ipk is stepping on another;s toes
Jun 24 16:53:35 <kergoth> there's still the problem of multiple versions overwriting one anothers packages, etc, still really need private staging areas for that.. but that would make it easier to implement private staging areas, since you'd have to map recipe to the packages it emitted
Jun 24 16:54:20 <khem> kergoth: infact I was thinking of having private staging areas for intermediate packages in toolchain
Jun 24 16:54:30 <khem> but then didnt prototype
Jun 24 16:54:47 <kergoth> oh that would improve lots of issues with cleaning individual pieces of the toolchain too, if you did it right
Jun 24 16:54:54 <kergoth> today things just explode :)
Jun 24 16:55:34 <khem> yep
Jun 24 16:55:46 <khem> but its liking a yarn bundle
Jun 24 16:56:16 <kergoth> yeah, well said
Jun 24 16:56:36 <khem> kergoth: however I was thinking how will it chooses which gcc to use 
Jun 24 16:56:51 <khem> rather which private staging is active at a point
Jun 24 16:57:18 <kergoth> we really need proper version specific support for DEPENDS, to ensure the toolchain components match up with one another, so the distro doesn't have to specific each individual bit
Jun 24 16:57:36 <khem> then the headers where do they get installed and how do we tell gcc to look for headers from different staging or should be replicate those in individual staging areas
Jun 24 16:57:39 <khem> etc. etc.
Jun 24 16:58:19 <khem> but having cross ipk's will help a bit 
Jun 24 16:58:21 <khem> :)
Jun 24 16:58:31 <khem> is it possible to have cross ipks
Jun 24 16:58:32 <khem> atm
Jun 24 16:58:35 <khem> I dont think so
Jun 24 16:58:37 <kergoth> i'd say each staging area should be populated with all the bits that recipe needs, and use sysroot to point at it, and don't point outside it
Jun 24 16:58:44 <kergoth> then what we do is cache the staging areas based on what went into them
Jun 24 16:58:52 <kergoth> so other recipes with the same dependence set can share it
Jun 24 16:58:57 <kergoth> or actually, build on top of a previous one
Jun 24 16:59:29 <kergoth> alternatively, we populate it with symlinks to individual output areas
Jun 24 16:59:35 <kergoth> or don't populate it at all, and point gcc at each area
Jun 24 16:59:38 * kergoth thinks
Jun 24 16:59:55 <kergoth> this is starting to remind me of that functional package manager, have you seen it?
Jun 24 17:00:04 <khem> no
Jun 24 17:00:09 <kergoth> each installed package gets its own area by checksum
Jun 24 17:00:13 <kergoth> so nothing can step on anything else
Jun 24 17:00:22 <kergoth> http://nixos.org/
Jun 24 17:00:32 <kergoth> http://nixos.org/nix/
Jun 24 17:00:35 <kergoth> its an interesting concept
Jun 24 17:00:40 <khem> do yah nix
Jun 24 17:00:44 <khem> I know that
Jun 24 17:00:52 <khem> pacman ?
Jun 24 17:00:54 * kergoth hasn't tried it personally, but the concepts could be useful
Jun 24 17:00:58 <khem> archlinux uses it
Jun 24 17:01:07 <khem> I experimented with it recently 
Jun 24 17:01:10 <kergoth> haven't looked at that one
Jun 24 17:01:11 <khem> seems to work well
Jun 24 17:02:26 <kergoth> the concern i see with nix is relocatability, but that needs to be fixed anyway
Jun 24 17:02:35 <kergoth> although..
Jun 24 17:02:46 <khem> hmm garbage collection :)
Jun 24 17:03:54 <kergoth> god, we could use that..
Jun 24 17:03:55 <khem> it could be better than opkg who knows
Jun 24 17:04:03 <kergoth> staging collects cruft
Jun 24 17:04:08 <kergoth> well, not so bad with pstage
Jun 24 17:04:09 <kergoth> but still
Jun 24 17:04:21 <kergoth> hell, we could use gc for workdirs, or make rm_work mandatory ..
Jun 24 17:04:40 <khem> I dont like rm_work to be mandatory 
Jun 24 17:05:00 <khem> many a times people want to debug build failures and ask for logs 
Jun 24 17:05:04 <khem> they wont have them
Jun 24 17:05:08 <JaMa|Off> BBCLASSEXTEND = "sdk" should add -sdk postfix to PROVIDES as "native" does?
Jun 24 17:05:10 <kergoth> i wouldn't mind it, *if* we used separate build dirs from source, and put the source elsewhere
Jun 24 17:05:21 <JaMa> seems not doing that here.. ERROR: Multiple .bb files are due to be built which each provide xau (/OE/dev/recipes/xorg-lib/libxau_1.0.5.bb virtual:sdk:/OE/dev/recipes/xorg-lib/libxau_1.0.5.bb).
Jun 24 17:05:24 <kergoth> khem, well, if the build fails, it isn't removed
Jun 24 17:05:27 <kergoth> its the final task
Jun 24 17:05:34 <khem> JaMa: I have seem same problem
Jun 24 17:05:59 <khem> kergoth: thats right. but 
Jun 24 17:06:01 <JaMa> but for native it seems to work and pb confirmed today that it should work
Jun 24 17:06:13 <JaMa> when I asked about native..
Jun 24 17:06:17 <khem> sometimes you want to develop on the recipe
Jun 24 17:06:38 <kergoth> could add a variable to explicitly disable it for what you're developing, perhaps
Jun 24 17:06:40 * kergoth ponders
Jun 24 17:06:53 <khem> yeah that would work
Jun 24 17:06:54 <kergoth> i still think itd be nice to separate the fetch/unpack/patch from the rest somehow
Jun 24 17:07:07 <kergoth> seems silly we can't reuse it
Jun 24 17:07:12 <khem> kergoth: oh you means /srcdir and /objdir
Jun 24 17:07:15 <kergoth> maybe i should resurrect my task workdir monitoring
Jun 24 17:07:16 <kergoth> yeah
Jun 24 17:07:25 <kergoth> i had a class that used git to track what the tasks did in workdir
Jun 24 17:07:28 <JaMa> last PN in xorg-lib to convert but libx11-trim/libx11/diet-x11 is a bit messy :/
Jun 24 17:07:28 <kergoth> so you could *back up*
Jun 24 17:07:29 <khem> kergoth: yeah it could be nice 
Jun 24 17:07:30 <kergoth> to a previous task
Jun 24 17:07:34 <kergoth> which would be awesome
Jun 24 17:08:12 <kergoth> (aside: anyone else think the stamps being outside of workdir is stupid? originally it was so you could rm the stamps, but that's not advised today, and will actually *break* shit)
Jun 24 17:09:31 <khem> I think its ok to be in side packages workdir
Jun 24 17:09:46 <kergoth> we should really make all output go there
Jun 24 17:09:48 <kergoth> so we can track it
Jun 24 17:09:52 <kergoth> and have later steps pull from there
Jun 24 17:09:56 <kergoth> into the deploy dirs
Jun 24 17:10:02 <khem> kergoth: another thing I would like is to have multimachines share same /tmp
Jun 24 17:10:14 <kergoth> will be necessary for us to drop stamps later on, need both metadata and file input/output tracking
Jun 24 17:10:19 <khem> so I could share native staging
Jun 24 17:10:53 <kergoth> that reminds me, i like that we support multimachine and stuff, but ... that means thew orkdirs are like 42 directories deep in tmp, not exactly friendly
Jun 24 17:10:58 <kergoth> separate objdir would help that too
Jun 24 17:11:11 <khem> yes
Jun 24 17:11:19 * kergoth ponders
Jun 24 17:11:42 <khem> right now if I bitbake a console-image half the time its baking native recipes
Jun 24 17:12:14 <kergoth> on that note, another thing we need, is an infrastructure for build environment testing
Jun 24 17:12:23 <kergoth> if we have > version X of Y, set ASSUME_PROVIDED ..
Jun 24 17:12:28 <kergoth> :)
Jun 24 17:13:06 <khem> yeah but then I could end up braking others
Jun 24 17:13:15 <khem> becasue I changed git and did not rebuild git-native
Jun 24 17:13:51 <kergoth> the upside would be, we'd finally distinguish between things that we *have* to build native of, because we patch them specially, from the ones that are just build dep replacements
Jun 24 17:13:58 <kergoth> need a way to indicate this
Jun 24 17:14:10 <kergoth> checking for patches isn't enough, maybe we need a variable
Jun 24 17:14:21 <kergoth> or, a different PN
Jun 24 17:14:24 <kergoth> add vendor or something
Jun 24 17:14:28 <kergoth> coreutils-oe-native
Jun 24 17:14:31 <khem> kergoth: I think we need to say 
Jun 24 17:14:44 <khem> this package is needed to be native on distro x
Jun 24 17:14:58 <khem> but not on distro y
Jun 24 17:15:06 <khem> one can use the distro provided 
Jun 24 17:15:21 <kergoth> thats an idea, but might not be sufficient
Jun 24 17:15:30 <kergoth> consider debian sid, there's no telling what versions of shit is installed
Jun 24 17:15:54 <khem> yeah
Jun 24 17:16:16 <CIA-2> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r3950ba031a 10openembedded.git/classes/package_ipk.bbclass: 
Jun 24 17:16:16 <CIA-2> package_ipk: Fix syntax error - incorrect usage of bb.data.expand
Jun 24 17:16:16 <CIA-2> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Jun 24 17:16:25 <CIA-2> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * r0cf498e7c8 10openembedded.git/classes/ (autotools.bbclass base.bbclass): 
Jun 24 17:16:25 <CIA-2> Rename base_dep_prepend and autotools_dep_prepend
Jun 24 17:16:25 <CIA-2> When we start including methodpool funcs in the metadata, these blow up, since
Jun 24 17:16:25 <CIA-2> the _prepend gets evaluated at finalize time.
Jun 24 17:16:26 <CIA-2> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Jun 24 17:16:51 <khem> other machine at home is not responding I hope home is not on fire
Jun 24 17:16:55 <kergoth> clearly, there's a lot of cool stuff we can work on :)
Jun 24 17:17:08 <khem> kergoth: yeah agree
Jun 24 17:17:40 <kergoth> my dillemma is always *what* to work on.  have to just pick something and sit down and make a prototype, otherwise its just this giant vague pile of things itd be nice to see "someday"
Jun 24 17:17:55 * khem ponders hooking freebsd or netbsd as target OS into OE
Jun 24 17:18:12 <kergoth> that'd be fun to play with
Jun 24 17:18:16 <khem> kergoth: exactly the problem
Jun 24 17:18:18 <kergoth> i wonder how hard it is to build their kernels
Jun 24 17:18:28 <khem> kergoth: its simple
Jun 24 17:18:35 <khem> surprisingly
Jun 24 17:18:38 <kergoth> nice
Jun 24 17:19:33 <khem> may be thats something I can even get my manager to let me work on at work :)
Jun 24 17:19:57 * khem thinks
Jun 24 17:20:35 <khem> FIFA world cup: next italy will meet France .. (at the airport)
Jun 24 17:20:59 <CIA-2> 03Chris Larson <chris_larson@mentor.com> 07org.openembedded.dev * rbcb0f04458 10openembedded.git/classes/cpan_build.bbclass: 
Jun 24 17:20:59 <CIA-2> cpan_build.bbclass: rename cpan_build_dep_prepend
Jun 24 17:20:59 <CIA-2> Same reasoning as the {autotools,base}_dep_prepend rename.
Jun 24 17:20:59 <CIA-2> Signed-off-by: Chris Larson <chris_larson@mentor.com>
Jun 24 17:21:10 <khem> I was supporting italy and argentina 
Jun 24 17:52:27 <kergoth> can someone remind me what the irc nick is of frans meulenbroeks?
Jun 24 17:52:31 <kergoth> is that ant? i never remember
Jun 24 17:55:36 <Jin^eLD> kergoth: no clue about the nick but one question about staging though, suppose I was staging a single .h file in the "old-style" recipe, its not handled by do_install(), what would be the new preferred way in that situation?
Jun 24 17:56:26 <kergoth> install it in do_install.
Jun 24 17:56:33 <kergoth> is there some reason you don't want a -dev package?
Jun 24 17:57:22 <Jin^eLD> hmm, I never thought about that :) but I get the idea.. since everything is packaged I'd have to install the headers and make sure they go to -dev packages
Jun 24 17:57:53 <kergoth> just install it into ${D}${includedir}, done :)
Jun 24 17:58:28 <Jin^eLD> :)
Jun 24 18:00:17 <Jay7> kergoth: eFfeM_work iirc
Jun 24 18:00:24 <Jay7> kergoth: ant is Andrea Adami
Jun 24 18:01:07 <tharvey> I'm struggling with an oe build that keeps trying to fetch something thats clearly already in sources dir with an md5 sum - any ideas why the fetcher could not be happy with it or what I can do to find out why?
Jun 24 18:01:33 <kergoth> ahh right
Jun 24 18:01:34 <kergoth> thanks
Jun 24 18:01:52 <kergoth> tharvey, incorrectly set DL_DIR, or the filenames don't match up
Jun 24 18:02:56 <tharvey> kergoth, ack - DL_DIR defaulted to $TMPDIR/downloads - thanks that was it
Jun 24 18:03:05 <kergoth> :) np
Jun 24 18:03:09 <kergoth> bitbake -e is our friend :)
Jun 24 18:03:19 * kergoth uses it all the time to check and see if things are what he assumes they are
Jun 24 18:04:20 <tharvey> oh that is handy - thanks I didn't know about bitbake -e
Jun 24 18:04:32 <kergoth> np
Jun 24 18:04:37 <kergoth> bitbake -e without an argument is config metadata
Jun 24 18:04:40 <kergoth> with an argument is recipe metadata
Jun 24 18:04:41 <kergoth> both quite useful
Jun 24 18:05:53 <kergoth> the piece we're missing is the ability to see *where* a variable got set
Jun 24 18:05:59 <kergoth> so you can know what overrode you
Jun 24 18:06:01 <kergoth> but we'll get there
Jun 24 18:16:14 <JaMa> otavio: hi, are you sure http://bugs.openembedded.net/show_bug.cgi?id=3372 patch is still valid? XCB seems to be popular again IMHO, xls* xorg projects were converted to use xcb lately and I noticed problem building mesa (when there is staged libxcb then it expects libx11 even when mesa itself has xcb disabled)
Jun 24 18:22:19 <otavio> JaMa: I'm not; 
Jun 24 18:22:23 <otavio> JaMa: not sure
Jun 24 18:22:27 <otavio> JaMa: :-)
Jun 24 18:24:44 <JaMa> otavio: so the motivation was to make dependency tree a bit smaller by removing libxcb?
Jun 24 18:26:24 <otavio> JaMa: It was looooooooong time ago
Jun 24 18:26:40 <otavio> JaMa: I really do not remember the motivation of it
Jun 24 18:27:16 <JaMa> ok, so if you won't mind I'll enable it during some cleanups see http://gitorious.org/~jama/angstrom/jama-shr-experimental/commit/e014133eade787290b0c90b5d43de017218c7d69
Jun 24 18:27:57 <otavio> JaMa: awesome
Jun 24 18:28:01 <otavio> JaMa: please go ahead
Jun 24 18:28:13 <otavio> JaMa: if needed we can sort it out later again
Jun 24 19:06:48 <JaMa> how to add extra dependency only to non-native non-sdk version while using BBCLASSEXTEND :/, I've tried variable with _virtclass-native override and then appending it to DEPENDS, but it always picks also this extra dependency and add -native to it :/
Jun 24 19:11:23 <JaMa> found workaround
Jun 24 19:36:50 <CIA-2> 03Henning Heinold <heinold@inf.fu-berlin.de> 07org.openembedded.dev * rde6e07edd8 10openembedded.git/recipes/classpath/ (classpath-native_0.98.bb files/ecj_java_dir.patch): 
Jun 24 19:36:50 <CIA-2> classpath-native: update the ecj-patch
Jun 24 19:36:50 <CIA-2> * the java-files in tools aren't UTF8 at all
Jun 24 19:36:50 <CIA-2> so we need the same handling as with asm-files
Jun 24 19:36:50 <CIA-2> * bump PR
Jun 24 20:53:48 <oneshel> I'm trying to remove angstrom-feeds-configs from my image build, I took out ${ANGSTROM_FEED_CONFIGS} from angstrom-2008.1.conf, rebuild task-base, but it still ends up in my image
Jun 24 20:56:32 <oneshel> either that, or can I tell opkg to read just the conf file I pass to it and nothing under /etc/opkg?
Jun 24 21:28:57 <djszapi> hi
Jun 24 21:29:06 <djszapi> openembedded tries to build angstrom by default
Jun 24 21:29:10 <djszapi> how could I set to qt ?
Jun 24 21:31:03 <Jay7> angstrom is distro, qt is toolkit
Jun 24 21:31:10 <Jay7> what do you want exactly?
Jun 24 21:32:32 <djszapi> if I write a program in Qt, I would like to run it on as poor system as I can.
Jun 24 21:32:41 <djszapi> not with X, but with qws.
Jun 24 21:33:32 <djszapi> so a lightweight solution
Jun 24 21:33:49 <djszapi> angstrom is slow.
Jun 24 21:33:57 <djszapi> the devboard is mini2440
Jun 24 21:42:47 <ant__> Jay7: we have the events again ! I'll push in a few mins.
Jun 24 21:43:18 <Jay7> ant__: good :)
Jun 24 21:44:43 <ant__> it seems /dev needs 755
Jun 24 21:52:28 <CIA-2> 03Andrea Adami <andrea.adami@gmail.com> 07org.openembedded.dev * r7c6095059a 10openembedded.git/files/device_table-minimal.txt: 
Jun 24 21:52:28 <CIA-2> device_table-minimal: create /dev/input before adding input events.
Jun 24 21:52:28 <CIA-2> Signed-off-by: Andrea Adami <andrea.adami@gmail.com>
Jun 24 23:24:15 <undrwater> Jay7: ping
Jun 24 23:24:35 <undrwater> are kexecboot kernels still being made?
Jun 24 23:24:43 <ant__> yes
Jun 24 23:24:56 <undrwater> ant__: where can they be had? specifically for omap
Jun 24 23:26:29 <ant__> an old demo for beagle was around in Angstrom site
Jun 24 23:26:45 <Jay7> undrwater: pong
Jun 24 23:26:56 <Jay7> ant has answered you :)
Jun 24 23:28:08 <undrwater> ant__: looked there yesterday...couldn't find one...but i'll look again...nothing new?
Jun 24 23:28:18 <Jay7> seems we should provide a range of images for different machines..
Jun 24 23:28:26 <undrwater> Jay7: i was talking to you a while back about a donateable tosa and collie
Jun 24 23:28:37 <Jay7> undrwater: yes, I've remember :)
Jun 24 23:29:11 <ant__> can't say: when I asked koen about removing 2.6.29 and 2.6.32 he said no, 2.6.34 is not yet ready
Jun 24 23:29:36 <Jay7> what kernel is most stable and usable on beagle?
Jun 24 23:29:51 <Jay7> we can build image with this kernel
Jun 24 23:30:06 <ant__> no idea, kexec itself was broken on Omap time ago
Jun 24 23:30:46 <undrwater> i'm considering getting the igepv2 board...
Jun 24 23:31:19 <undrwater> the developers of the board have a kernel for it
Jun 24 23:33:42 <Jay7> undrwater: if they will provide toolchain and kernel sources you can build kexecboot image by hands :)
Jun 24 23:34:28 <ant__> I think now Narcissus provides a toolchain
Jun 24 23:34:38 <ant__> never tested
Jun 24 23:36:46 <undrwater> Jay7: i don't think they provide toolchain...users are using deb, gentoo, etc...
Jun 24 23:38:30 <ant__> unfortunately LTG seems offline
Jun 24 23:40:53 <undrwater> Jay7: do you still need a collie?
Jun 24 23:41:08 <undrwater> or does andrea? need a tosa?
Jun 24 23:41:20 <Jay7> undrwater: XorA have sent me one.. it's in NL now
Jun 24 23:41:30 <Jay7> my friend should bring it to me
Jun 24 23:41:39 <undrwater> ok
Jun 24 23:41:44 <undrwater> how about tosa?
Jun 24 23:41:59 <Jay7> ant__: having tosa is good idea :)
Jun 24 23:42:17 <ant__> hm..I already have 3 dogs here...
Jun 24 23:42:30 <ant__> one is going to Dmitry?
Jun 24 23:42:34 <Jay7> you can get 2 more :)
Jun 24 23:42:46 <undrwater> there was a request for update of tosa kernel on ML yesterday
Jun 24 23:42:46 <Jay7> no, to dmitry going XorA's tosa :)
Jun 24 23:43:16 <undrwater> they have enough? or someone needs another?
Jun 24 23:43:29 <Jay7> we have still not tested new kernels on tosa..
Jun 24 23:43:33 <Jay7> that is my bad
Jun 24 23:43:46 <ant__> tosa need some more kernel hacking
Jun 24 23:43:57 <ant__> does MArek have one?
Jun 24 23:44:13 <ant__> or Eric Miao?
Jun 24 23:44:28 <ant__> really, needs serious kernel sponsorship...
Jun 24 23:44:40 <ant__> poodle too, it seems
Jun 24 23:44:54 <Jay7> we can ask on zaurus-devel@ ML
Jun 24 23:46:44 <undrwater> who loves the tosa?
Jun 24 23:48:10 * Jay7 loves the tosa but have one already :)
Jun 24 23:48:54 <undrwater> :)
Jun 24 23:49:11 <Jay7> I need a good new computer now to do builds quickly
Jun 24 23:49:25 <undrwater> i'd like to see illume running smoothly on tosa
Jun 25 00:04:46 <kergoth> ~seen schurig
Jun 25 00:04:48 <ibot> schurig <n=schurig@pD95F989E.dip0.t-ipconnect.de> was last seen on IRC in channel #oe, 447d 9h 44m 34s ago, saying: '*IF* the current to the chip is your problem (not likely, agreed), than it's not the sustained current, but the spike current (not sure how to say that in english)'.
Jun 25 00:04:56 <kergoth> 447d? hmm
Jun 25 00:05:11 <kergoth> mickey|: ping
Jun 25 00:10:29 <Jay7> time to sleep
Jun 25 00:18:45 <grg> ~seen grg
Jun 25 00:18:46 <ibot> grg is currently on #oe (1h 7m 16s). Has said a total of 1 messages. Is idling for 2s, last said: '~seen grg'.
Jun 25 00:19:07 <grg> woot
Jun 25 01:01:27 <hgs> hi all, are there any patches for /etc/init.d/checkroot of oe/angstrom for performing fsck om MMC before mounting it as root??
Jun 25 01:02:26 <hgs> currently it is failing when it tries to remount the mmc as read only??
Jun 25 01:16:25 <grg> hgs, what error do you get?
Jun 25 01:16:52 <hgs> grg: *** ERROR!  Cannot fsck root fs because it is not mounted read-only!
Jun 25 01:17:37 <grg> hgs, what happens when you mount readonly manually? e.g. mount -n -o remount,ro /
Jun 25 01:18:07 <hgs> the fs resides on mmc and its root fs
Jun 25 01:18:43 <hgs> grg: i want to fsck on boot before mounting the mmc partition as root
Jun 25 01:18:52 <grg> yes
Jun 25 01:19:18 <grg> looking at the checkroot script, it looks like 'mount -n -o remount,ro /' is failing to return 0.
Jun 25 01:19:19 <hgs> grg: says mount: / is busy 
Jun 25 01:19:37 <grg> have you tried passing 'ro' to the kernel at boot time?
Jun 25 01:19:51 <hgs> grg: yes 
Jun 25 01:19:59 <grg> same error?
Jun 25 01:20:37 <hgs> grg: i guess the fs was not mounted properly, i cannot log in to shell to check the debug logs
Jun 25 01:21:21 <grg> are you using an initrd?
Jun 25 01:21:48 <hgs> initrd = ramdisk, then i am not using
Jun 25 01:22:23 <grg> good, that simplifies things
Jun 25 01:22:42 <grg> and it also means that the root filesystem must be mounted ok otherwise the checkroot script wouldn't be running
Jun 25 01:24:09 <grg> can you create the file /fastboot on your mmc card and then boot, in order to play a bit?
Jun 25 01:25:01 <GNUtoo|laptop> hi, it seem that some people are playing with GNU/Linux on android devices?
Jun 25 01:25:02 <hgs> yes, i will do other information, i have everything in my mmc as two partitions, one holding  bootload, kernel(/dev/mmcblk0p2) and the other partition holding rootfs (/dev/mmcblk0p1)
Jun 25 01:25:15 <GNUtoo|laptop> (fastboot)
Jun 25 01:26:12 <grg> GNUtoo|laptop, hello. I'm not sure I understand your opkg bug report properly. Can you clarify some things?
Jun 25 01:26:23 <GNUtoo|laptop> hi
Jun 25 01:26:30 <GNUtoo|laptop> what should I clarify
Jun 25 01:26:31 <GNUtoo|laptop> ?
Jun 25 01:26:54 <grg> which commit did you bisect back to?
Jun 25 01:27:12 <GNUtoo|laptop> I did 2 things
Jun 25 01:27:20 <hgs> grg:  iam seeing this "Fast boot, no filesystem check"
Jun 25 01:27:31 <GNUtoo|laptop> I first bisected openembedded.dev
Jun 25 01:27:38 <grg> hgs, yup. can you login now, and try some things manually?
Jun 25 01:28:03 <GNUtoo|laptop> and then I "bisected" opkg revisions
Jun 25 01:28:19 <GNUtoo|laptop> I bet you mean between which opkg revision I bisected
Jun 25 01:28:26 <grg> GNUtoo|laptop, ok. That is sort of what I thought you had done.
Jun 25 01:28:54 <grg> GNUtoo|laptop, i was interested in both OE and opkg commits
Jun 25 01:28:56 <hgs> grg: i am not getting it grg, i wanted to perform fsck on my ext3 fs to remove any stale entries, 
Jun 25 01:29:31 <GNUtoo|laptop> http://pastebin.com/v7RGwNsA]
Jun 25 01:29:33 <GNUtoo|laptop> http://pastebin.com/v7RGwNsA
Jun 25 01:29:41 <GNUtoo|laptop> oops for the first link
Jun 25 01:29:49 <GNUtoo|laptop> here's for opkg commits
Jun 25 01:30:01 <GNUtoo|laptop> basically I had luck for ipkg commits
Jun 25 01:30:22 <GNUtoo|laptop> for oe I'll look
Jun 25 01:31:12 <grg> GNUtoo|laptop, http://cgit.openembedded.org/cgit.cgi/openembedded/commit/?id=731e6defe6da58bff482f33508058544ad1013a9 ?
Jun 25 01:31:29 <GNUtoo|laptop> yes
Jun 25 01:31:33 <GNUtoo|laptop> that's the commit I found
Jun 25 01:32:07 <grg> GNUtoo|laptop, do you have build logs for a good and a bad build?
Jun 25 01:32:34 <GNUtoo|laptop> http://pastebin.com/QTkL07gC
Jun 25 01:32:36 <GNUtoo|laptop> for oe
Jun 25 01:32:39 <grg> hgs, can you manually mount read only and fsck?
Jun 25 01:32:44 <GNUtoo|laptop> I've only bad for now
Jun 25 01:32:50 <hgs> grg: "/dev/root / ext3 rw,relatime,errors=continue,data=writeback 1 1" is the entry in fstab entry 
Jun 25 01:32:55 <hgs> grg: previously i had "rootfs               /dev/root            auto       defaults              1  1"
Jun 25 01:33:07 <GNUtoo|laptop> you mean do_rootfs?
Jun 25 01:33:55 <grg> GNUtoo|laptop, i'm not sure. the problem may not even be in do_rootfs. But that would be a start
Jun 25 01:34:02 <GNUtoo|laptop> ok
Jun 25 01:34:33 <hgs> grg: i cannot do it manually on the board as it is mounted as root right (saying "mount: / is busy")
Jun 25 01:34:40 <grg> GNUtoo|laptop, certainly, if you can see the problem just by rebuilding opkg and rerunning do_rootfs, that would help narrow it down.
Jun 25 01:34:49 <GNUtoo|laptop> ok
Jun 25 01:36:51 <GNUtoo|laptop> do_rootfs: http://pastebin.com/j8z1PQia
Jun 25 01:38:45 <grg> GNUtoo|laptop, is that good or bad?
Jun 25 01:38:48 <GNUtoo|laptop> it doesn't seem to install the "kernel-modules" package
Jun 25 01:38:49 <GNUtoo|laptop> bad
Jun 25 01:38:54 <GNUtoo|laptop> I've only bad now
Jun 25 01:39:05 <GNUtoo|laptop> the good are rm -rfed
Jun 25 01:39:18 <GNUtoo|laptop> I couldn't keep everything
Jun 25 01:39:26 <GNUtoo|laptop> I already don't do rm_work
Jun 25 01:39:33 <GNUtoo|laptop> but with the number of revs
Jun 25 01:39:40 <GNUtoo|laptop> I couldn't keep each rev
Jun 25 01:40:01 <grg> sure. i understand
Jun 25 01:40:12 <GNUtoo|laptop> ok
Jun 25 01:40:28 <GNUtoo|laptop> I can easily build a good if you want
Jun 25 01:40:45 <GNUtoo|laptop> but I'll have to build from scratch I think
Jun 25 01:40:53 <GNUtoo|laptop> else it won't work
Jun 25 01:41:03 <GNUtoo|laptop> I built from scratch each time during the tests
Jun 25 01:41:14 <GNUtoo|laptop> it would take 2/3 hours to build from scratch
Jun 25 01:41:25 <grg> ok. Well, can you save any log files that you've got lying around for the bad build, just in case they are relevant?
Jun 25 01:41:35 <GNUtoo|laptop> I can keep 2 builds
Jun 25 01:41:39 <GNUtoo|laptop> but not 10/20
Jun 25 01:41:41 <grg> excellent
Jun 25 01:41:46 <grg> :)
Jun 25 01:42:03 <GNUtoo|laptop> do you want me to rebuild from scratch now?
Jun 25 01:42:11 <grg> yes please
Jun 25 01:42:18 <GNUtoo|laptop> ok
Jun 25 01:43:31 <grg> hgs, sorry, i'm not sure i can help any more. I don't know what would make mount -oremount,ro say / is busy... maybe something is logging to the filesystem already?
Jun 25 01:44:34 <grg> hgs, if you boot single user, there should be nothing preventing remounting readonly
Jun 25 01:45:08 <hgs> grg: yes actually i am redirecting the output of checkroot to a file in the directory, but how can i confirm fsck is done with out the those logs??
Jun 25 01:46:07 <grg> are you getting normal console output
Jun 25 01:46:08 <grg> ?
Jun 25 01:47:31 <hgs> grg : yes this what i see http://pastebin.com/af4waKzA
Jun 25 01:47:41 <hgs> grg: regarding EXT3
Jun 25 01:48:26 <grg> hgs, yep, those are the kernel messages. Are you getting boot messages after the kernel mounts the root filesystem?
Jun 25 01:49:26 <grg> GNUtoo|laptop, what is your GMT offset right now?
Jun 25 01:49:32 <hgs> grg: oh ok, but i could not see checkroot echos (i am running psplash)
Jun 25 01:49:49 <GNUtoo|laptop> grg, ouch...you've a huge chance to find me here
Jun 25 01:49:55 <GNUtoo|laptop> I couldn't sleep
Jun 25 01:50:01 <GNUtoo|laptop> GMT+1
Jun 25 01:50:26 <grg> almost 4am...
Jun 25 01:50:40 <GNUtoo|laptop> indeed
Jun 25 01:52:05 <grg> hgs, i suspect you need to modify your kernel parameters to ensure that the console is set to the correct serial port
Jun 25 01:52:51 <GNUtoo|laptop> what is hgs doing? I saw the fastboot word
Jun 25 01:53:33 <grg> he has problems with the checkroot script
Jun 25 01:53:49 <grg> it wont remount his / read only
Jun 25 01:53:55 <grg> thus, it wont fsck
Jun 25 01:56:01 <grg> hgs, do you have something like console=ttyS3,115200n8 as a kernel parameter? (but with the correct tty for your serial port)
Jun 25 01:56:50 <grg> hgs, you may also need to edit /etc/inittab to spawn a getty (the login thingo) on your serial console
Jun 25 01:56:55 <GNUtoo|laptop> ok
Jun 25 01:57:05 <GNUtoo|laptop> what's his bootloader?
Jun 25 01:57:11 * grg shrugs
Jun 25 01:58:13 <grg> hgs> hi all, are there any patches for /etc/init.d/checkroot of oe/angstrom for performing fsck om MMC before mounting it as root??
Jun 25 01:58:14 <grg> <hgs> currently it is failing when it tries to remount the mmc as read only??
Jun 25 01:58:14 <grg> <grg> hgs, what error do you get?
Jun 25 01:58:14 <grg> <hgs> grg: *** ERROR!  Cannot fsck root fs because it is not mounted read-only
Jun 25 01:58:51 <GNUtoo|laptop> basically it has to do with udev cache I think
Jun 25 01:59:01 <GNUtoo|laptop> we must find a fix for that
Jun 25 01:59:04 <grg> fuck i hate udev
Jun 25 01:59:14 <GNUtoo|laptop> because we need rw because of that
Jun 25 01:59:20 <GNUtoo|laptop> there were fixes posted
Jun 25 01:59:30 <GNUtoo|laptop> but I'm not shure they worked for me
Jun 25 01:59:31 <grg> so the checkroot script should run before udev?
Jun 25 01:59:57 <GNUtoo|laptop> hmmm I think the problem is worse
Jun 25 02:00:05 <GNUtoo|laptop> people put rw as kenrel argument
Jun 25 02:00:12 <GNUtoo|laptop> because of this udev cache problem
Jun 25 02:00:24 <grg> yeah, i have that to work around something that i've long forgotten about...
Jun 25 02:00:41 <GNUtoo|laptop> maybe it's worth trying ro 
Jun 25 02:00:46 <GNUtoo|laptop> to see if it has been fixed
Jun 25 02:01:15 * grg is still running an oe tree that was checked out in january
Jun 25 02:01:30 <GNUtoo|laptop> ouch
Jun 25 02:01:36 <GNUtoo|laptop> I can test if you want
Jun 25 02:02:05 <GNUtoo|laptop> ???
Jun 25 02:02:14 <GNUtoo|laptop> I think I moved the wrong dir
Jun 25 02:02:31 <GNUtoo|laptop> ah no
Jun 25 02:02:38 <GNUtoo|laptop> I was bitbaking for the wrong machine
Jun 25 02:02:43 <GNUtoo|laptop> that's why it finished now
Jun 25 02:03:09 <GNUtoo|laptop> ok restarting
Jun 25 02:09:34 <hgs> grg: sorry was not at my desk, i have console=ttyS2,115200n8
Jun 25 02:09:47 <hgs> GNUtoo|laptop: i am using uboot
Jun 25 02:09:57 <GNUtoo|laptop> ok
Jun 25 02:10:14 <GNUtoo|laptop> so you can change the arguments of the kenrel
Jun 25 02:10:19 <GNUtoo|laptop> but be carefull
Jun 25 02:10:44 <hgs> GNUtoo|laptop: yes i can, ok
Jun 25 02:10:58 <grg> just save your current bootargs in another variable. setenv oldbootargs ${bootags}
Jun 25 02:10:59 <GNUtoo|laptop> long time ago I messed up my environment of my om-gta02 
Jun 25 02:11:01 <hgs> grg: the kernel argument reads fine rite
Jun 25 02:11:20 <GNUtoo|laptop> and I couln't use the bootloader anymore so I flashed qi
Jun 25 02:11:28 <GNUtoo|laptop> (there were 2 bootloaders)
Jun 25 02:11:33 <GNUtoo|laptop> so the second one saved me
Jun 25 02:11:34 <hgs> grg: ok and what shld it be replaced with
Jun 25 02:11:51 <grg> hgs, well i don't know what serial port you need to use...
Jun 25 02:12:11 <grg> i don't know what hardware you have and even if i did, i still probably wouldn't know
Jun 25 02:12:16 <GNUtoo|laptop> some uboot contain hard coded serial parameters (serial of uboot ) whichh is a good protection against brickage
Jun 25 02:12:21 <GNUtoo|laptop> I've that on my bug device
Jun 25 02:12:48 <GNUtoo|laptop> for knowing the serial port:
Jun 25 02:12:49 <grg> hgs, check the manual(s) for your device to find out if it says anything about what serial port is used for console output
Jun 25 02:12:55 <GNUtoo|laptop> boot GNU/Linux on it
Jun 25 02:13:01 <GNUtoo|laptop> and try it out
Jun 25 02:13:08 <GNUtoo|laptop> try serial communication
Jun 25 02:13:09 <GNUtoo|laptop> like:
Jun 25 02:13:40 <GNUtoo|laptop> ssh->shell->picocom<--serial--->usb_to_serial->computer
Jun 25 02:14:03 <hgs> grg: ttyS2 is a serial device, i getting just the kernel logs through the serial port of the device
Jun 25 02:14:21 <GNUtoo|laptop> ok
Jun 25 02:14:46 <grg> hgs, but you said you don't get any output after the root filesystem is mounted... ?
Jun 25 02:15:51 <hgs> grg: only the kernel logs gets displayed (like messages on loading kernel modules etc)
Jun 25 02:15:52 <GNUtoo|laptop> hmmm
Jun 25 02:15:57 <GNUtoo|laptop> ahh ok
Jun 25 02:16:07 <GNUtoo|laptop> init logs aren't displayed
Jun 25 02:16:48 <hgs> yes those with runlevel S and 1,2,3,..
Jun 25 02:16:56 <hgs> are not getting displayed
Jun 25 02:17:24 <grg> i'm afk for a lunch meeting... back later..
Jun 25 02:18:14 <GNUtoo|laptop> I'll boot a device and look
Jun 25 02:18:41 <hgs> iam seeing the following "S:2345:respawn:/sbin/getty 115200 ttyS0" in /etc/inittab
Jun 25 02:18:59 <GNUtoo|laptop> I think that's for the root prompt login
Jun 25 02:19:02 <GNUtoo|laptop> like:
Jun 25 02:19:04 <GNUtoo|laptop> username:
Jun 25 02:19:06 <GNUtoo|laptop> password:
Jun 25 02:20:50 <GNUtoo|laptop> maybe look in
Jun 25 02:20:55 <GNUtoo|laptop> /etc/default/rcS
Jun 25 02:20:59 <GNUtoo|laptop> there is a verbose option
Jun 25 02:21:06 <GNUtoo|laptop> not shure if it fix that tough
Jun 25 02:21:26 <hgs> ok actually enabled it :(
Jun 25 02:21:47 <hgs> long time back it did not help
Jun 25 02:21:51 <GNUtoo|laptop> ok
Jun 25 02:22:05 <GNUtoo|laptop> I never had this issue on embedded things
Jun 25 02:22:20 <GNUtoo|laptop> only on x86 powerfull routers
Jun 25 02:22:41 <GNUtoo|laptop> and their init system and the fix was quite different
Jun 25 02:24:48 <GNUtoo|laptop> hmmm what's /proc/cmdline?
Jun 25 02:24:58 <GNUtoo|laptop> is there a quiet or similar option
Jun 25 02:25:25 <hgs> yes id do have "mem=442M console=ttyS2,115200n8 vram=32M omapfb.vram=0:8M,1:16M,2:8M console=tty0 omapfb.mode=dvi:640x480MR-16@60 root=/dev/mmcblk0p2 rw rootwait"
Jun 25 02:26:02 <hgs> it is the bootargs that is being passed to the kernel
Jun 25 02:26:06 <GNUtoo|laptop> ok
Jun 25 02:32:16 <GNUtoo|laptop> maybe udev?
Jun 25 02:32:27 <GNUtoo|laptop> print something before udev
Jun 25 02:32:37 <GNUtoo|laptop> and see if it appears on the serial port
Jun 25 02:36:05 <GNUtoo|laptop> hgs, do you see the please wait booting?
Jun 25 02:36:19 <hgs> GNUtoo|laptop: i setup is taken away from me, have to wait for some time
Jun 25 02:36:26 <GNUtoo|laptop> ok
Jun 25 02:41:59 <hgs> GNUtoo|laptop: from my previous logs snaps http://pastebin.com/WZ75tczR, is what i see, wrt to mmc/ext3 and udev, i dont see "please wait booting" in those logs though
Jun 25 02:43:35 <hgs> GNUtoo|laptop: my ttyS device number in kernel bootargs and that in initab are not matching...may it could be the issue...waiting for my setup huh..
Jun 25 02:44:15 <GNUtoo|laptop> ok
Jun 25 02:51:55 <hgs> GNUtoo|laptop: as you had mentioned i could only see the login console, i could not feed any input through the serial device
**** ENDING LOGGING AT Fri Jun 25 02:59:57 2010