**** BEGIN LOGGING AT Tue May 13 02:59:56 2008
May 13 05:38:15 <CIA-22> 03jeremy_laine 07org.oe.dev * rcf73613e... 10/ (1 packages/openssl/openssl-native_0.9.8g.bb): openssl-native_0.9.8g.bb: bring openssl-native in sync with latest openssl
May 13 06:16:06 <nathan7> Hi, my OE is failing with compiling.
May 13 06:16:12 <nathan7> I get this error.
May 13 06:16:29 <nathan7> http://paste.lisp.org/display/60663
May 13 06:17:30 <nathan7> Anyone?
May 13 06:18:48 <Crofton> pastebin the log file referenced
May 13 06:18:55 <nathan7> Okay
May 13 06:19:00 <nathan7> Annotate?
May 13 06:19:35 <nathan7> http://paste.lisp.org/display/60663#1
May 13 06:20:41 <nathan7> I tried making that directory, but I don't want uclibc, only glibc.
May 13 06:21:04 <nathan7> My local.conf has ANGSTROM_MODE = "glibc"
May 13 06:21:54 <Crofton> hmm
May 13 06:22:02 <Crofton> pastebin the local.conf ...
May 13 06:22:24 <nathan7> K
May 13 06:23:18 <nathan7> http://paste.lisp.org/display/60663#2
May 13 06:24:13 <Crofton> hmm
May 13 06:24:23 <Crofton> can you try without ANGSTROM_MODE Set?
May 13 06:24:41 <nathan7> Already did, same thing, will try again.
May 13 06:25:05 <nathan7> Bitbake running.
May 13 06:25:14 <nathan7> Handling bitbake files.
May 13 06:25:26 <Crofton> where did the magiciaon machine file come from?
May 13 06:25:44 <nathan7> do you need to put the file in your build dirs?
May 13 06:26:14 <Crofton> what file?
May 13 06:26:25 <nathan7> machine file (magician.conf)
May 13 06:26:29 <Crofton> I can't see anything obviously wrong :(
May 13 06:26:33 <Crofton> no
May 13 06:27:36 <nathan7> it is possible to build them, they are availible at http://handhelds.org/~htcpxa
May 13 06:28:13 <Crofton> yeah, I just can't see why the uclibc stuff is getting tripped
May 13 06:28:40 <Crofton> I was hoping it was something easy ...
May 13 06:29:13 <nathan7> Me too.
May 13 06:29:41 <nathan7> Bitbake files handling done
May 13 06:29:47 <nathan7> NOTE: preferred version 2.6.1 of glibc not available (for item virtual/arm-angstrom-linux-gnueabi-libc-for-gcc)
May 13 06:30:03 <Crofton> I think that is "normal"
May 13 06:30:07 <nathan7> Okay.
May 13 06:30:18 <Crofton> I'm going for breakfast in a few minutes
May 13 06:30:44 <nathan7> Okay, thank you for trying to help.
May 13 06:33:51 * nathan7 is now stuck with a crappy Qtopia/OpenMoko image, or Windoze Mobile 2003.
May 13 07:43:54 <RP> morning all
May 13 07:45:28 <XorA|gone> hey RP
May 13 07:45:44 <XorA> RP: do you read OM distro-devel
May 13 07:46:00 <RP> I did just look at zecke's patches
May 13 07:48:53 <hrw|gone> morning
May 13 07:50:23 <hrw> XorA: did you read my buildbot suggestion?
May 13 07:50:33 <XorA> hrw: yes thanks
May 13 07:51:09 <hrw> XorA: I am planning to have buildbot running on one of my machines at home.
May 13 07:51:31 <hrw> not soon due to lack of space for another computer case ;(
May 13 07:51:38 <XorA> heh heh
May 13 07:54:42 <hrw> it is hard to find really small miniatx case
May 13 07:59:30 <XorA> acer do one
May 13 07:59:39 <XorA> but in UK it always comes with 19 inch monitor
May 13 08:00:00 <hrw> ;DD
May 13 08:00:48 <hrw> I need a case with space for 1-2 3.5" hdd, miniatx mainboard and then small (but powerful enough) cpu cooler 
May 13 08:02:53 * XorA finally thinks he understands the SRCREV->SRCPV change
May 13 08:03:12 <Genesis> bonjour
May 13 08:03:35 * RP thinks the SRCPV stuff is a step too far into voodoo
May 13 08:03:55 <RP> I hate the srcrev stuff :(
May 13 08:04:21 <RP> You realise zecke's patch does downloading at .bb file parsing time?
May 13 08:04:43 <XorA> RP: yes I realised that with the sortable git
May 13 08:05:07 <XorA> RP: this stuff is giving me nightmares
May 13 08:06:43 * XorA begins to think just not using SRCREV in PV is best policy
May 13 08:07:01 <RP> XorA: and do what instead?
May 13 08:07:12 <XorA> RP: use PR :-)
May 13 08:07:29 <CIA-22> 03koen 07org.oe.dev * rfe12b769... 10/ (3 files in 2 dirs): gcc csl 2008: remove ldflags.patch that does the wrong thing, disable multilib, and remove some more patches
May 13 08:07:47 <RP> XorA: Each solution is unacceptable to a certain group of people :(
May 13 08:08:13 <XorA> zecke is normally the person that complains about network access during parsing
May 13 08:09:03 <RP> downloading stuff during parsing is going to totally break what I'm trying to do with client/server in trunk :/
May 13 08:09:29 <RP> as well as breaking the seperation layers we've built up...
May 13 08:09:44 <RP> i.e. actualy doing work in 'task' context
May 13 08:11:31 * RP will talk to zecke when he appears...
May 13 08:51:16 <likewise> hi zecke
May 13 08:51:31 <likewise> hi all, btw :-)
May 13 08:52:26 <hrw> hi likewise 
May 13 09:00:14 <zecke> did anyone get my mails on git and SRCREV?
May 13 09:00:21 <hrw> on openmoko ml?
May 13 09:00:29 <methril> morning
May 13 09:01:18 <zecke> no oe-dev :)
May 13 09:01:27 <zecke> it was on CC
May 13 09:02:06 <XorA> zecke: we got them
May 13 09:18:51 <zecke> XorA: I think we could merge the PV changes regarding unifiying the SRCREV for svn recipes
May 13 09:38:22 <Laibsch> good morning
May 13 09:39:01 * Laibsch thinks it is funny (or rather sad) that people consider a snapshot a stable branch
May 13 09:39:38 <Laibsch> I guess that is because we want it so badly we are going to ignore any actual problems with it to the point of the "branch" becoming org.oe.snapshot$date
May 13 09:43:52 <hrw> hi Laibsch schurig 
May 13 09:44:09 <schurig> hrw: hi 2u2
May 13 09:44:11 <hrw> Laibsch: but o.e.stable is more stable then .dev
May 13 09:45:21 <hrw> I wonder about booting...
May 13 09:45:46 <hrw> get 1gb cf card or 1gb usb stick or 1gb (micro)sd card with usb reader
May 13 09:46:46 <Genesis> hrw : i should receive my CF IDE adapter today
May 13 09:47:01 <hrw> Genesis: alix board has cf/ide integrated
May 13 09:47:01 <Genesis> i think CF via IDE is better than USB stick/reader
May 13 09:47:19 <Laibsch> hrw: Sure, take any snapshot on $day and it is more stable than .dev
May 13 09:47:25 <Genesis> i think CF is better so 
May 13 09:47:31 <hrw> but 1bg cf is harder to get then other solutions;)
May 13 09:47:31 <Laibsch> monontone supports that OOTB, we don't need a branch for that
May 13 09:47:44 <Genesis> i bought 4/8Go for 20$
May 13 09:47:55 <Laibsch> and the expectations raised by having it will create a credibility problem for OE
May 13 09:48:00 <Laibsch> look through the mailing list
May 13 09:48:01 <Genesis> so don't tell me it's hard to find 1Go , ebay is full of that for 10-20$
May 13 09:48:25 <Laibsch> There are already several complains about "what this is stable, it breaks all the time, there is no support"
May 13 09:49:52 <hrw> Genesis: I mean shops not auctions
May 13 09:51:10 <Genesis> i find reguliar shop using ebay
May 13 09:51:39 <hrw> ok - regular local shops
May 13 09:51:45 <Genesis> Ok sorry
May 13 09:51:50 <hrw> but I will have to go through few of them anyway
May 13 09:52:01 <Genesis> regular local shops never see me :x
May 13 09:52:38 <Genesis> du !
May 13 09:52:39 <Genesis> :)
May 13 09:53:11 <hrw> Genesis: it is faster to make a call and 15 minutes trip to get components then waiting 3 days for delivery
May 13 09:53:47 <Genesis> exept when local seller don't have what you need.
May 13 09:53:58 <hrw> Genesis: I live in big city 
May 13 09:54:14 <Genesis> i'm buying a usb dongle from estonia
May 13 09:54:14 <hrw> Genesis: my recent buy was split to two shops
May 13 09:54:34 <hrw> Genesis: posting is more expensive then dongle?
May 13 09:54:40 <Genesis> there are the only company to do that around the world ...
May 13 09:54:48 <Genesis> 30% of the price yes
May 13 09:55:12 <hrw> what kind of dongle it is?
May 13 09:55:22 <Genesis> it's LPC USB dongle
May 13 09:55:32 <Genesis> from artec ( like alix )
May 13 09:57:31 <hrw> url?
May 13 09:57:34 <Genesis> http://www.artecgroup.com/products/hardware-products/programmable-lpc-dongle.html
May 13 09:58:21 <hrw> ah..
May 13 09:58:28 <hrw> nice debu stuff
May 13 09:58:31 <hrw> debug
May 13 10:02:18 <Genesis> for other thing than LPC ?
May 13 10:03:22 <hrw> Genesis: lpc is enough
May 13 10:03:47 <hrw> alix for example has linuxbios port in progress but I would not flash it to not brick device
May 13 10:06:12 <Laibsch> RP: OE mtn2git import is looking good
May 13 10:06:20 <Laibsch> What do you say about the bk import?
May 13 10:06:34 <Laibsch> What are open tasks now?
May 13 10:07:17 <hrw> Laibsch: findout how to map keys into real names?
May 13 10:07:23 <florian> good morning
May 13 10:07:57 <hrw> hi florian 
May 13 10:10:35 <Laibsch> hrw: I was gone over the weekend
May 13 10:10:41 <Laibsch> I did the bk2git thing
May 13 10:10:50 <Laibsch> Then copied it to the server and left soon after
May 13 10:11:29 <Laibsch> hrw: I guess you were referring to the bk2git thing?
May 13 10:12:40 <hrw> more to mtn2git one
May 13 10:13:30 <zecke> Laibsch: the result has one bug (mtn2git). Check the stupid pvr folder, I have to track this down and fix it for the real conversion :)
May 13 10:13:52 <hrw> git.openembedded.net[0: 80.81.242.146]: errno=Connection refused
May 13 10:13:55 <Laibsch> hrw: I have not done anything about that part
May 13 10:14:00 <Laibsch> I assume it was RP doing it
May 13 10:14:05 <Laibsch> or maybe zecke
May 13 10:14:11 <Laibsch> zecke: were you?
May 13 10:14:26 <zecke> Laibsch: doing what?
May 13 10:14:27 <Laibsch> hrw: gitweb
May 13 10:14:30 <Laibsch> not git
May 13 10:14:44 <hrw> gitweb.openembedded.net[0: 80.81.242.146]: errno=Connection refused
May 13 10:14:50 <Laibsch> zecke: were you the one doing the mtn2git conversion over the weekend?
May 13 10:15:10 <hrw> 12:12 hrw@home:git$ git clone git://git.openembedded.net/org.openembedded.dev
May 13 10:15:10 <hrw> Initialized empty Git repository in /home/hrw/devel/oe/git/org.openembedded.dev/.git/
May 13 10:15:13 <hrw> git.openembedded.net[0: 80.81.242.146]: errno=Connection refused
May 13 10:15:13 <Laibsch> hrw: works fine here
May 13 10:16:09 <hrw> lucky you
May 13 10:16:41 <zecke> Laibsch: no, I pushed the revisions to this server...
May 13 10:17:07 <hrw> RP: ssh dss key for git trail sent
May 13 10:24:40 <RP> Hmm, we have an iceberg floating around waiting to sink something :/
May 13 10:24:56 <RP> expandKeys isn't being called on data being passed to task contexts
May 13 10:27:13 <Laibsch> zecke: After RP made the initial conversion?
May 13 10:38:35 <zecke> ibot: ping
May 13 10:38:35 <ibot> pong
May 13 10:40:49 * XorA notes the slightly crazy directory on git :-)
May 13 10:49:20 <RP> hrw: I have the mappings for most users
May 13 10:49:40 <RP> Laibsch: I've done some further research into bk2git and have more of an idea whats wrong now
May 13 10:49:55 <RP> Laibsch: I also have a better cvs export from bitmover since the previous one was incomplete
May 13 10:50:22 <hrw> cool
May 13 10:50:39 <RP> hrw: git refusing the connection looks bad, some problem with git daemon by the looks of it :/
May 13 10:55:00 <RP> hrw: key added
May 13 10:55:46 <hrw> thx
May 13 10:56:09 <hrw> Warning: Permanently added 'git.openembedded.net,80.81.242.146' (RSA) to the list of known hosts.
May 13 10:56:14 <hrw> cloning in progress
May 13 10:59:41 <Laibsch> RP: I can do the conversion one more time if you let me have your svn snapshot
May 13 11:00:02 * Laibsch looked for the crazy directory but failed to spot it
May 13 11:00:17 <RP> Laibsch: Whilst its better its not right yet. I'll continue to work on it for now...
May 13 11:00:35 <RP> Laibsch: Unless you feel like getting into cvsps internals?
May 13 11:00:49 <Laibsch> RP: I did not use cvsps
May 13 11:01:07 <RP> Laibsch: ah, you mean cvs2svn?
May 13 11:01:09 <Laibsch> Hm, bk2cvs did?
May 13 11:01:21 <Laibsch> RP: yes
May 13 11:02:59 <RP> Laibsch: Its corrupt, look at the duplicate entries
May 13 11:04:51 <Laibsch> example?
May 13 11:05:04 <Laibsch> I haven't looked around that much yet
May 13 11:05:15 <Laibsch> but so far I spotted no obvious problem
May 13 11:05:56 <RP> http://gitweb.openembedded.net/?p=laibsch_bk2cvs2svn2git;a=summary
May 13 11:06:01 <XorA> openembedded/packages/pvr*
May 13 11:06:33 <RP> "aticore: Disable parallel make" twice, "linux-oz-2.6: bump PR" twice
May 13 11:08:12 <Laibsch> yes, I see that now
May 13 11:08:25 <Laibsch> XorA: http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=tree;f=packages;h=ec4b9a7cbda3f0c9c1f157029aa0567b8a226cdd;hb=HEAD has no pvr directory
May 13 11:08:33 <Laibsch> which is what I was looking for previously
May 13 11:09:39 <hrw> RP: fetched
May 13 11:10:30 <XorA> Laibsch: http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=tree;f=openembedded/packages;h=146486e23d441d77d75b23de05e87eb5de9be7dc;hb=HEAD
May 13 11:15:46 <Laibsch> XorA: Thanks
May 13 11:17:03 * Laibsch has just added the "Infrastructure" product to http://bugs.openembedded.net/enter_bug.cgi to report and track problems with our servers, etc.
May 13 11:17:47 <Laibsch> It can also be used to increase transparency about open tasks for admin tasks in a wide sense
May 13 11:17:52 <Laibsch> broad sense
May 13 11:19:28 <Laibsch> XorA: I still don't see it.  But that's not important.  As long as you guys spot the problems
May 13 11:25:27 <hrw> http://pastebin.ca/1016815 - git remote fails with git server
May 13 11:27:06 <hrw> or I do something wrong
May 13 11:29:23 <XorA> Laibsch: look at the path, its obvious
May 13 11:30:46 <RP> hrw: stable is a branch within org.openembedded.dev atm
May 13 11:30:56 <RP> hrw: and yes this is wrong/bad/needs discussion ;-)
May 13 11:31:13 <Jin^eLD> re
May 13 11:32:11 <hrw> ah
May 13 11:32:26 <hrw> ~curse clipboard-manager 
May 13 11:32:27 <ibot> May you be reincarnated as a Windows XP administrator, clipboard-manager !
May 13 11:32:36 <hrw> ~curse maemo.org for lack of sensible hosting
May 13 11:32:38 <ibot> May the fleas of a thousand camels infest your most sensitive regions, maemo.org for lack of sensible hosting !
May 13 11:33:38 <Laibsch> RP: Where does cvsps come into the picture?  I remember that I looked into it on Friday, but I don't think cvsps is relevant for the path I took.  IIRC, I chose a different path (and not straight git-cvs) exactly because of limitations in cvsps
May 13 11:34:32 <RP> Laibsch: cvsps is used by git-cvsimport
May 13 11:34:48 <RP> Laibsch: cvsps works out which cvs revisions belong in which commit
May 13 11:35:12 <RP> git-svnimport works fine but cvsps isn't processing things correctly
May 13 11:35:30 <Laibsch> RP: I did not use git-cvsimport
May 13 11:35:49 <RP> Laibsch: I know. I still this its our best option though
May 13 11:35:49 <Laibsch> Look at how I named the branch ;-)
May 13 11:36:22 <Laibsch> Why don't we have a looked at how the import of your improved cvs tarball looks?
May 13 11:36:27 <Laibsch> we have nothing to loose
May 13 11:36:35 <Laibsch> only one more branch to gain ;-)
May 13 11:36:44 <RP> because it won't fix the problem I've shown you
May 13 11:37:03 <RP> Let me push my conversion
May 13 11:37:52 <Laibsch> you mean the one with the double entries
May 13 11:37:53 <Laibsch> ?
May 13 11:38:04 <RP> Mine doesn't have the double entries
May 13 11:38:29 <Laibsch> OK
May 13 11:41:16 <XorA> ~curse syncml
May 13 11:41:17 <ibot> May you be reincarnated as a Windows XP administrator, syncml !
May 13 11:41:32 <Jin^eLD> RP: remember you told me the nick of the guy who did some work on gcc toolchain tests in OE? I lost the nick :P
May 13 11:41:36 <Jin^eLD> who was it again?
May 13 11:42:05 <RP> Jin^eLD: Not sure, what kind of toolchain tests?
May 13 11:42:39 <Jin^eLD> RP: gcc has some test target to test the produced compiler
May 13 11:42:40 <Laibsch> RP: was http://bugs.openembedded.net/show_bug.cgi?id=4247 successful?
May 13 11:42:48 <Jin^eLD> and you need dejagnu and some other stuff for it
May 13 11:42:56 <Jin^eLD> I was asking if there was anything like that in OE
May 13 11:43:05 <Jin^eLD> and I think you told me who had a look at it
May 13 11:43:10 <Jin^eLD> but I lost the nick
May 13 11:43:12 <RP> Jin^eLD: no :(
May 13 11:43:28 <Jin^eLD> damn hmm
May 13 11:43:30 <Jin^eLD> :)
May 13 11:43:46 <RP> Jin^eLD: I don't remember anything about that :/
May 13 11:43:52 <RP> Laibsch: no, it didn't work
May 13 11:44:41 <Laibsch> Are you sure, the sender is white-listed?
May 13 11:44:44 <Jin^eLD> hmm OK I'll try again then :)
May 13 11:44:59 <Jin^eLD> does anyone know if work in OE has been done on toolchain tests?
May 13 11:45:38 <RP> Laibsch: It is now assuming you gave me the right sender
May 13 11:46:04 <RP> Laibsch: It was just a quick test, I've not got any further with it :/
May 13 11:46:12 <Laibsch> RP: http://rafb.net/p/iQ0y1Y26.html
May 13 11:46:19 <Laibsch> OK
May 13 11:46:25 <Laibsch> The mails are being sent, it seem
May 13 11:46:26 <Laibsch> s
May 13 11:47:20 <RP> Laibsch: but from www-data?
May 13 11:47:32 <RP> That would break it...
May 13 11:47:38 <Laibsch> I think that is just the process owner
May 13 11:47:58 <RP> and the from address according to those logs...
May 13 11:48:12 * Laibsch has not looked closely
May 13 11:48:54 <Laibsch> indeed
May 13 11:49:07 <Laibsch> all I can say is that the ones that I receive have
May 13 11:49:09 <Laibsch> bugzilla-daemon@amethyst.openembedded.net
May 13 11:49:15 <Laibsch> in From
May 13 11:49:35 <Laibsch> I always suspected some kind of address rewriting going on
May 13 11:49:41 <Laibsch> but I never looked under the hood
May 13 11:49:52 <Laibsch> Return-Path: <www-data@amethyst.openembedded.net>
May 13 11:50:05 <RP> you told me bugzilla@amethyst ;-)
May 13 11:50:14 <Laibsch> did I?
May 13 11:50:17 <Laibsch> Sorry, my mistake
May 13 11:50:47 <Laibsch> Above Return-Path also verifies the initial sender being www-data
May 13 11:51:24 <RP> I'll try adding some other entries as whitelisted when I get a few minutes
May 13 12:00:04 <Laibsch> mickeyl: the reverse DNS for amethyst is not set, mails are being lost
May 13 12:01:18 <mickeyl> k, i need to take this up with the hoster
May 13 12:02:15 <mickeyl> which mails, btw.?
May 13 12:02:54 <mickeyl> [ah, probably bugzilla ones]
May 13 12:09:18 <Laibsch> well, I guess everybody who rejects mail from hosts without a reverse DNS
May 13 12:09:43 <Laibsch> While looking for the problem RP was facing, I spotted one example
May 13 12:09:50 <Laibsch> There may be others
May 13 12:10:08 <RP> Laibsch: http://gitweb.openembedded.net/?p=org.openembedded.rp-bkcvs.git;a=summary
May 13 12:10:51 <RP> Problem 1 is the lack of useful commit summaries but we can fix that by tweaking the cvsps output
May 13 12:11:22 <RP> Problem 2 is http://gitweb.openembedded.net/?p=org.openembedded.rp-bkcvs.git;a=commit;h=fe358aa08fe2de668a69d227df4fc83d302d83e1 has two commits in it
May 13 12:12:20 <RP> and the author being screwed up in problem 1 due to the merge entries
May 13 12:13:05 <cdbot2> * * OE Bug 4248 has been created by bluelightning(AT)bluelightning.org
May 13 12:13:07 <cdbot2> * * Opie-image stops during boot on h2200
May 13 12:13:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4248
May 13 12:15:05 <cdbot2> * * OE Bug 4249 has been created by <Laibsch>
May 13 12:15:07 <cdbot2> * * evaluate git as a replacement for monotone
May 13 12:15:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4249
May 13 12:15:36 <hrw> !oeclose 4249 as wontfix
May 13 12:16:51 <Laibsch> ?
May 13 12:17:06 <Laibsch> hrw: You amaze me more and more every time lately
May 13 12:17:24 <Laibsch> I thought you were a staunch git advocate
May 13 12:20:46 <hrw> Laibsch: we are testing git now - when someone start hg server we will test it
May 13 12:21:03 <Laibsch> ???
May 13 12:21:30 <hrw> I am git advocate when it comes to Poky as this use svn 
May 13 12:21:30 <Laibsch> hrw: You amaze me more and more every time lately
May 13 12:21:39 <Laibsch> OK
May 13 12:22:01 <Laibsch> what is your favourite for OE itself?
May 13 12:22:05 <cdbot2> * * OE Bug 4250 has been created by <Laibsch>
May 13 12:22:06 <hrw> for OE - it depends. git and hg are options
May 13 12:22:07 <cdbot2> * * import old bitkeeper history
May 13 12:22:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4250
May 13 12:22:23 <Laibsch> hrw: yes, hg and git are options
May 13 12:22:27 <hrw> which is my favorite? no opinion now
May 13 12:22:49 <Laibsch> Why does that make 4249 wontfix?
May 13 12:23:04 <Laibsch> It is just a list of what RP are doing ATM
May 13 12:23:18 <Laibsch> I want to have to know what needs to be done and what the status is.
May 13 12:23:24 <henomis79> all: how can I remove a package in local.conf from image's package depends?
May 13 12:23:25 <hrw> because it looks like 'evaluate git and forget others' from title 
May 13 12:23:34 <Laibsch> henomis79: no
May 13 12:23:36 <hrw> henomis79: create own image recipe - it is easy
May 13 12:23:47 <Laibsch> hrw: you are making assumptions
May 13 12:23:58 <zecke> hrw: Do you propose to add " and solve world hunger" to every bug summary?
May 13 12:24:01 <zecke> ...
May 13 12:24:02 <Laibsch> evaluate is evaluate
May 13 12:24:15 <Laibsch> git is what I work on
May 13 12:24:24 <Laibsch> others are free to work on hg
May 13 12:24:24 <RP> It is going to inflame things :(
May 13 12:25:00 <hrw> ok ok - it is too hot here (~30°C if not more)
May 13 12:25:55 <Laibsch> RP: Sorry, but I think your point about inflamatory is strange, to say the least
May 13 12:25:57 <henomis79> hrw: ok, and I have some difficulties installing libstdc++.so.6...is there a specific package? I don't want to install gcc!
May 13 12:26:26 <hrw> henomis79: do not install libraries - install applications which use them
May 13 12:27:05 <RP> Laibsch: I just know its going to upset some people :(
May 13 12:28:52 <kwek> hey there.. its the first time playing with oe.. and trying to get it on my asus wl500gp router.. Making the image dies with an make error message. Does anyone know whats going on.. am i on the right track? http://pastebin.com/d14524f98
May 13 12:28:59 <henomis79> hrw: ok thanks. So i must find a small application that requires it
May 13 12:29:38 <Laibsch> RP: Well, maybe that can't be helped at times
May 13 12:29:51 <hrw> henomis79: why you want only library in image?
May 13 12:30:00 <hrw> henomis79: own binary app to use?
May 13 12:30:01 <Laibsch> To make sure I did everything possible to avoid that, I created
May 13 12:30:04 <Laibsch> !oebug 4251
May 13 12:30:05 <cdbot2> * * Bug 4251, Status: NEW, Created: 2008-05-13 14:30
May 13 12:30:06 <cdbot2> * * <Laibsch>: evaluate hg as replacement for monotone
May 13 12:30:07 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4251
May 13 12:30:19 <henomis79> hrw: just for future projects
May 13 12:30:45 <hrw> henomis79: then when future projects came you can built them with oe too
May 13 12:31:05 <cdbot2> * * OE Bug 4251 has been created by <Laibsch>
May 13 12:31:06 <Laibsch> RP: Makes no sense for me, because I don't intend to follow up on it at all.  And I guess the people possibly being sensitive here, won't use the bug tracker for coordination won't, either.  IOW, just wasted bandwidth
May 13 12:31:07 <cdbot2> * * evaluate hg as replacement for monotone
May 13 12:31:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4251
May 13 12:31:47 <henomis79> hrw: and what about a closed-source app that requires libstdc++?
May 13 12:39:05 <cdbot2> * * OE Bug 4252 has been created by <Laibsch>
May 13 12:39:07 <cdbot2> * * the git server should have hooks to trigger mails
May 13 12:39:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4252
May 13 12:39:29 <hrw> henomis79: you build it or someone other?
May 13 12:39:43 <hrw> henomis79: remember that OE is MIT licensed - you do not have to share own recipes
May 13 12:40:33 <henomis79> hrw: I have a touchscreen calibration app that is only-binary
May 13 12:41:14 <hrw> and custom touchscreen interface instead of kernel one?
May 13 12:41:44 <henomis79> hrw: yes
May 13 12:42:37 <hrw> impressed
May 13 12:44:05 <cdbot2> * * OE Bug 4253 has been created by <Laibsch>
May 13 12:44:07 <cdbot2> * * unpackaged software on amethyst
May 13 12:44:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4253
May 13 12:49:03 <Laibsch> RP: At this point in time, do we still need cgit?
May 13 12:50:18 <Laibsch> From what I understand, cgit has speed advantages, but gitweb looks reasonably fast to me
May 13 12:50:31 <Laibsch> so, I'd like to stick with gitweb for now, if possible
May 13 12:52:05 <cdbot2> * * OE Bug 4254 has been created by <Laibsch>
May 13 12:52:07 <Jin^eLD> RP: does meta-toolchain in Poky install the linux-libc-headers to the SDK dir?
May 13 12:52:07 <cdbot2> * * bugzilla on amethyst is unpackaged
May 13 12:52:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4254
May 13 12:56:05 <cdbot2> * * OE Bug 4255 has been created by <Laibsch>
May 13 12:56:07 <cdbot2> * * viewmtn is unpackaged
May 13 12:56:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4255
May 13 12:57:06 <cdbot2> * * OE Bug 4256 has been created by <Laibsch>
May 13 12:57:08 <cdbot2> * * monotone is unpackaged
May 13 12:57:10 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4256
May 13 13:07:24 <hrw> Laibsch: I replied to your image thread
May 13 13:08:01 <Crofton> hrw, I was waiting for someone to make the comment you made
May 13 13:08:10 <Crofton> I understand both viewpoints
May 13 13:08:30 <Laibsch> nothing here, yet
May 13 13:08:40 <RP> Jin^eLD: It would get pulled in by one of the task packages, yes
May 13 13:08:47 <Laibsch> and it is not "my" image thread
May 13 13:09:05 <hrw> Crofton: I understand both too. but having extra var which can change any-image into who-know-what-is-inside-image without changing name it insane
May 13 13:09:16 <hrw> Laibsch: ok
May 13 13:09:16 <RP> Laibsch: There is nothing wrong with having cgit and gitweb available
May 13 13:09:20 <Laibsch> OK, I was thinkgin about tha one, too
May 13 13:09:49 <Laibsch> hrw: I think having a non-empty IMAGE_EXTRA_INSTALL should add _extra to the image name or something
May 13 13:09:53 <Jin^eLD> RP: does that happen inside meta-toolchain or somewhere else?
May 13 13:10:00 <Laibsch> hrw: to indicate that the contents can be anything
May 13 13:10:05 <Crofton> How about we change the VAR to IMAGE_ONLY_SET_THIS_IF_YOU_ARE_NUTS?
May 13 13:10:06 <Jin^eLD> RP: basically my problem is - again - with meta-toolchin in OE stable
May 13 13:10:07 <Laibsch> otherwise, still useful to have
May 13 13:10:20 <Jin^eLD> the headers do not get installed with the toolchain
May 13 13:10:22 <hrw> Crofton: EXTRA_IMAGE_INSTALL = "abiword" bitbake minimal-image -- who will support "I installed abiword on device but it does not start"?
May 13 13:10:24 <Laibsch> Crofton: too short :-D
May 13 13:10:28 <Jin^eLD> and I am trying to figure out how to add them correctly
May 13 13:10:46 <Jin^eLD> my ideas ranging from a "common" staging directory for both, meta-toolchain and some linux-libc-headers-sdk packages
May 13 13:10:55 <Jin^eLD> to.. well. actually had no other ideas yet :)
May 13 13:11:06 <Jin^eLD> so wondering if that worked in Poky and if yes - how it was done
May 13 13:11:18 <Jin^eLD> do_populate_sdk() {
May 13 13:11:20 <hrw> Crofton: rather IMAGE_EXTRA_`md5sum_of_date_with_ms_in_it`_INSTALL?
May 13 13:11:22 <Jin^eLD> does not have anything special for it
May 13 13:11:23 <hrw> hi vivijim 
May 13 13:11:26 <Crofton> hrw, the intent is that it is used by competent people who know what they are doing
May 13 13:11:45 <hrw> Crofton: such people are usually capable or creating my-test-console-image.bb
May 13 13:11:47 <Laibsch> RP: agreed, but only *if* there is a package available.  I don't see the benefit of having a second web interface to git outweigh the drawbacks
May 13 13:11:54 <Crofton> we can't prevent every possible stupid use of OE
May 13 13:12:17 <vivijim> hi hrw
May 13 13:12:40 <Laibsch> hrw: it is not me being incapable of creating a new image.  I don't want to every time.
May 13 13:13:08 <Jin^eLD> RP: but I think I did understand the idea about the task packages now :) thanks
May 13 13:14:37 <hrw> Laibsch: then create one recipe like I wrote in mail
May 13 13:14:52 <Laibsch> yes, just read it
May 13 13:15:25 <Laibsch> I'd need to create three to four recipes (one for each GUI), but that is still doable, certainly
May 13 13:15:46 <Laibsch> It defeats collaboration though, although I think that will be a minor problem
May 13 13:16:26 <Laibsch> separating OE and $distro is still valid, the rgrep I gave should not return anything
May 13 13:16:37 <Laibsch> BTW, I like the $md5sum idea
May 13 13:17:00 <Laibsch> But I don't feel too strongly about this, either way
May 13 13:26:46 <RP> Jin^eLD: Sorry, I was called away, do you understand whats wrong now?
May 13 13:26:59 <RP> Jin^eLD: There are two sets of packages involved - host ones and target ones
May 13 13:27:18 <RP> the cross compiler runs on the host as do cross tools like binutils and gdb
May 13 13:27:24 <RP> the headers are a target package
May 13 13:27:39 <RP> There should be a set of target tasks which pull in the headers amongst other things
May 13 13:27:59 <Jin^eLD> RP: linux-libc-headers are not specifically listed in there
May 13 13:28:54 <RP> Jin^eLD: The -dev package chains pull it in within poky iirc
May 13 13:29:20 <Jin^eLD> hm, does not seem to happen in .stable, I miss asm-generic and stuf flike that
May 13 13:29:39 <RP> depchains probably doesn't work in stable
May 13 13:32:06 <Jin^eLD> I can't stop wondering how stable and maintained stable actually is :)
May 13 13:32:34 <Jin^eLD> Rolf has kind of got a point there
May 13 13:32:36 <Crofton> Jin^eLD, it depends entirely on the contributions from the users
May 13 13:32:47 <Crofton> people are missing this point
May 13 13:33:22 <broonie> If it's unmaintained it's stale in some sense :/
May 13 13:33:26 <RP> The thing is, the enhancements I've made to meta-toolchain are big invasive changes which relied on other fundamental changes made to OE
May 13 13:33:35 <Jin^eLD> well, what if you found the reason for the problem and figured out how it could be solved but are lacking the last bits to actually provide a clean patch?
May 13 13:33:37 <RP> When stable branched, meta-toolchain didn't work
May 13 13:33:42 <Jin^eLD> then it will stay in the bugtracker forever
May 13 13:33:45 <RP> meta-toolchain in stable still doesn't work
May 13 13:33:55 <Crofton> so basically, meta-toolchain is not a real feature in the current .stable
May 13 13:34:05 <RP> I'd say so, yes
May 13 13:34:09 <Crofton> rather work-in-progress
May 13 13:34:23 <RP> In stbale it had limited capabilities
May 13 13:34:29 <Crofton> exactly
May 13 13:34:32 <RP> We've made it much better
May 13 13:34:54 <Crofton> we need to finish the discussion on what features should exist for the next stable branch
May 13 13:35:21 <Crofton> I prefer a feature driven schedule as opposed to a calendar driven one
May 13 13:35:26 <Jin^eLD> RP: well, what about the bug that you helped me find, I posted all the steps and I did a fix locally but I do not know about the impllications of my local change for glibc based builds an so on, still I doubt that anyone will ever look at the PR
May 13 13:35:39 <Crofton> Jin^eLD,  is just in a difficutl place though
May 13 13:36:23 <RP> Jin^eLD: The libc.so.6 issue is a case of wrapping those functions in a if target_os uclibc based?
May 13 13:36:36 <RP> Jin^eLD: The check about whether the toolchain already exists is a separate bug
May 13 13:36:36 <Jin^eLD> RP: yes
May 13 13:36:46 <RP> Jin^eLD: So propose a patch to stable for it
May 13 13:36:48 <Jin^eLD> RP: the libc.so.6 thing
May 13 13:36:51 <RP> and state its not needed for .dev
May 13 13:37:10 <RP> I'll ack it and discuss with the stable maintainers if needed
May 13 13:37:45 <Jin^eLD> RP: I got a working solution for me, but the information is all there, so it's kind of hurting to see that it will get ignored in .stable
May 13 13:37:56 <RP> Jin^eLD: The emphasis is on people taking these things to their conclusion
May 13 13:38:00 <Jin^eLD> RP: well but isn't that the point - you're saying that you will have to discuss with the stable guys
May 13 13:38:00 <RP> Who should no it?
May 13 13:38:04 <RP> s/no/do/
May 13 13:38:29 <Crofton> There are no 100% dedictated stable maintainers
May 13 13:38:30 <RP> Jin^eLD: No, I said send stable the patch and if there is a problem I will back you up
May 13 13:38:32 <Jin^eLD> RP: well, in my OSS project, if I get a bug - I have a loot at it since I am the project maintainer
May 13 13:38:36 <hrw> Crofton: and let stable be populated with packages^Wrecipes instead of being copy of .dev
May 13 13:38:55 <hrw> Crofton: who will support asleap 2.1 in .stable otherwise
May 13 13:39:24 <Jin^eLD> RP: well but that's my problem for example - I only commented out one line and I have no clue about the deep implications of this for other builds - should I be sending such a patch?
May 13 13:39:51 <RP> Jin^eLD: I've told you how to write a patch which doesn't affect other buiilds
May 13 13:40:02 <Jin^eLD> and I think that's the point that Rolf was raising: if there are no maintainers for .stable then it should be obvious to people who are deciding with which branch to go 
May 13 13:40:05 <RP> Sending a patch to comment it out is clearly madness
May 13 13:40:25 <RP> koen at least has said he'll process patches for stable
May 13 13:40:31 <RP> nobody is sending them though
May 13 13:40:52 <RP> nobody can be bothered to clean things up to the required standard and go to the effort of submitting them
May 13 13:41:57 <Jin^eLD> I think the requird standard also requires quit an amount of insight into the whole system, not everyone has that
May 13 13:41:57 <Crofton> ok, I subscribed to the stable list
May 13 13:42:38 <RP> Jin^eLD: I hinted above how to write a patch which won't affect anything else
May 13 13:42:40 <Jin^eLD> if people find a bug in my upnp server - I do ask them for logs, steps to reproduce, etc, etc, but in the end I know what to fix and fix it because they simply do not have the insight and won't be able to do it on their own
May 13 13:42:50 <Crofton> there are guys on the stable list that can help with reiew
May 13 13:42:51 <hrw> org.openembedded.stable^Wunmaintained?
May 13 13:42:59 <RP> Jin^eLD: The bit about adding an "if target_os is uclibc" function
May 13 13:43:04 <hrw> Crofton: but nearly no one sends there
May 13 13:43:21 <RP> Jin^eLD: I'm not going to fix this for you in stable
May 13 13:43:27 <Crofton> I know, I was negligent about signing up
May 13 13:43:37 <RP> Jin^eLD: I've made it clear I don't have time for stable and I've said this from day one
May 13 13:43:50 <RP> I will help people address things but I won't do it for them
May 13 13:43:54 * Crofton makes a note to help with solutions ....
May 13 13:44:02 <Jin^eLD> RP: I was talking more generic right now, if you look at the bugtracker there is much more stuff than just that, and btw I am not accusing you of anything, I am actually very greatful for the help you provided 
May 13 13:44:43 <RP> Jin^eLD: Yes, I know, the bugzilla is full of stuff we need to deal with
May 13 13:45:04 <RP> We need more people with more knowledge than we have :/
May 13 13:45:39 * cbrake subscribes to stable maillist ...
May 13 13:45:42 <RP> We do the best we can. You're slowly learning about meta-toolchain which is good :)
May 13 13:46:01 <Jin^eLD> RP: well, I learned about it in .stable which in terms of the meta packages is obsolete ;)
May 13 13:46:14 <RP> Jin^eLD: The principle hasn't changed in .dev
May 13 13:46:32 <RP> Yes, the code is a bit different but it does the same thing, just better with less bugs
May 13 13:47:21 <Crofton> http://free-electrons.com/community/videos/conferences/
May 13 13:47:22 <Jin^eLD> I hope I'll get a better view of this with time
May 13 13:47:22 <RP> We're in the unfortunately position that we can't fix stable the same way without backporting a major infrastructure change though :(
May 13 13:47:32 <RP> Jin^eLD: You do
May 13 13:47:41 <Crofton> Who is Matt Locke?
May 13 13:47:45 <RP> I never thought I'd understand lobtool for example
May 13 13:47:59 <Crofton> now RP is a libtool guru :)
May 13 13:48:09 <Crofton> OpenEmbedded for product development, by Matt Locke (Embedded Alley): 
May 13 13:48:16 <Crofton> in the link above
May 13 13:48:25 <RP> Crofton: Was that from Linz?
May 13 13:48:34 <Crofton> CELF
May 13 13:48:39 <Crofton> San Jose?
May 13 13:48:53 <RP> I saw him at CELF Europe
May 13 13:49:07 <Crofton> ah
May 13 13:49:17 <Crofton> This looks to be from Mountain View in April 08
May 13 13:49:44 <RP> zecke/me were in the audience asking questions :)
May 13 13:50:04 <Crofton> cool
May 13 13:51:03 <Laibsch> Crofton: wrt "Jin^eLD, it depends entirely on the contributions from the users" "people are missing this point", I can only say that it looks to me that contributions go entirely to waste and otherwise stable is stale, a snapshot, not a branch
May 13 13:51:29 <Laibsch> It is sad, but that seems to be the way it is now.  Unless people step up to change that, OE should watch out.
May 13 13:52:41 <Jin^eLD> "people are missing this point" - that's true btw, I originally thought it was actively maintained
May 13 13:53:19 <RP> it depends how you define actively maintained
May 13 13:53:27 <Jin^eLD> I even think its not the problem if it is or not - just important to know how it is in reality so one does not have false expectations, that'S it
May 13 13:53:39 <RP> will someone else investigate your bugs and apply fixes, probably not
May 13 13:55:04 <Laibsch> Crofton: Matt Locke?  from BTS?  Look at the email, I think his nick is in there
May 13 13:55:15 <Jin^eLD> RP: in my project "actively maintained" means that I will at least respond to the bug submits and have at least a brief look at it if its not some obvious crap on the user side
May 13 13:55:41 <Jin^eLD> but that's just my "imho" thing 
May 13 13:55:50 <RP> Jin^eLD: In that sense .dev isn't actively maintained then :/
May 13 13:56:04 <RP> and if we can't actively maintain .dev, what hope does stable have?
May 13 13:56:10 <Crofton> even having one snapshot for people to start from is an improvement over the previous situation
May 13 13:56:16 <Jin^eLD> RP: good point :)
May 13 13:56:24 <Laibsch> RP: If you publically admit that noone from OE will fix bugs in .stable, we should stop it *right now*
May 13 13:56:26 <Crofton> see slide 9 :)
May 13 13:56:28 <Crofton> http://www.celinux.org/elc08_presentations/mlocke-elc2008-oe.pdf
May 13 13:56:35 <Laibsch> I did not think it was that bad .-(
May 13 13:56:37 <hrw> btw - is .stable better maintained then .oz354fam083/oz354x was?
May 13 13:56:41 <RP> Laibsch: That was not what I said
May 13 13:56:58 <Laibsch> will someone else investigate your bugs and apply fixes, probably not
May 13 13:57:00 <Laibsch> quoting
May 13 13:57:05 <Laibsch> I call that bug triaging
May 13 13:57:18 <Laibsch> I did that although I don't intend to work on stable
May 13 13:57:19 <timtimred> team foonas will come back from the dead to fix bugs :)
May 13 13:57:26 <Laibsch> after I did, the work I did was ignored
May 13 13:57:35 <Jin^eLD> I think those things should be clearly communicated; what will happen, what will not happen, etc.; it's OK if I *know* what I can expect
May 13 13:58:00 <RP> Laibsch: by investigate bugs I mean actually try to reproduce and develop fixes
May 13 13:58:03 <Laibsch> Jin^eLD: The problem seems to be "it is not really decided".  at least that is my impression
May 13 13:58:14 <Laibsch> RP: bug triaging, yes
May 13 13:58:17 <timtimred> although NAiL isnt active anymore to get my fixes in i gather
May 13 13:58:18 <RP> Laibsch: I think submitted patches will be applied for stable
May 13 13:58:37 <Laibsch> But only if you subscribe to yet another ml
May 13 13:58:51 <Laibsch> and mail directly
May 13 13:58:53 <Laibsch> why is that a requirement?
May 13 13:59:01 <Laibsch> bugzilla could mail the list
May 13 13:59:05 <RP> Laibsch: Why is hunting through the bugzilla a requirement?
May 13 13:59:12 <Laibsch> nobody said that
May 13 13:59:32 <hrw> Laibsch: look at linux-arm-kernel or linux-kernel mailinglists. linux kernel has bugzilla but patches goes to ML
May 13 13:59:32 <Laibsch> looking through your bugs IMHO is a requirement, though
May 13 13:59:45 <Laibsch> hrw: is that efficient?
May 13 13:59:53 <RP> Laibsch: I really don't understand your problem with stable. They've decided on a policy and asked people to stick to it
May 13 13:59:59 <Laibsch> hrw: do we have that kind of interest and man/brain-power?
May 13 14:00:08 <Laibsch> hrw: does it currently work for .stable?
May 13 14:00:19 <Laibsch> hrw: I think the answers are (unfortunately) obvious
May 13 14:00:25 <RP> Laibsch: mailing the patches to the list is not the people
May 13 14:00:39 <RP> finding people prepared to take the time to prepare patches is the issue
May 13 14:00:49 <Laibsch> I did prepare patches
May 13 14:00:56 <RP> and sent them to the list?
May 13 14:01:06 <Laibsch> But because I chose the official bts and not the ml, they are ignored
May 13 14:01:21 <RP> Laibsch: thats your own problem then
May 13 14:01:38 <RP> I wish you and koen would stop this petty war
May 13 14:01:45 <Laibsch> It is a disgrace that something officially named OE can ignore the bug tracker
May 13 14:01:52 <Laibsch> This is not a petty war
May 13 14:02:14 <timtimred> woah, isnt the bug tracker used? I submitted stuff there...
May 13 14:02:17 <Laibsch> RP: Shall I close the bugs because nobody will look at them now or shall I not?
May 13 14:02:25 <Laibsch> timtimred: no, forget it
May 13 14:02:36 <Laibsch> only .dev is maintained and uses the bug tracker
May 13 14:02:48 <timtimred> ok :)
May 13 14:02:52 <Laibsch> .stable willfully ignores it and there is no activity for it
May 13 14:02:55 <RP> timtimred: yes, it is, 
May 13 14:03:01 <timtimred> .stable? theres a .stable? :)
May 13 14:03:08 <Laibsch> .stale
May 13 14:03:16 <Laibsch> would be more appropriate
May 13 14:03:16 <RP> Laibsch: If the bugs are not resolved they should not be closed
May 13 14:03:28 <broonie> Stable distributions are always stale, it's kind of a design goal.
May 13 14:03:34 <RP> Laibsch: You'll have to wait for someone with more time to handle them through the proper procedure
May 13 14:03:43 <Laibsch> RP: I close bugs as wontfix for packages nobody picks up in .dev
May 13 14:03:52 <RP> Laibsch: Then thats wrong
May 13 14:04:01 <Laibsch> Why should .stable get an exception after they have clearly shown to have no interest in the BTS?
May 13 14:04:14 <Laibsch> RP: that is common practive
May 13 14:04:21 <Laibsch> I am not the only one doing it
May 13 14:04:27 <RP> Laibsch: It shoudn't be being done
May 13 14:04:29 <Laibsch> If you prefer LATER or something else, fine
May 13 14:04:56 <hrw> Laibsch: add flag "WORKSINDEVBUTBROKENINSTABLE"
May 13 14:04:56 <RP> Laibsch: WONTFIX means there is some policy in place than means a resolution isn't possible
May 13 14:05:05 <Jin^eLD> seems like the problem is: too complex system to handle, too few resources to cope with the PR flood, and too many cooks to decide to procedures and to stick to them :P
May 13 14:05:26 <Crofton> maybe the cooks are overworked
May 13 14:05:28 <Crofton> :)
May 13 14:05:39 <Jin^eLD> :)
May 13 14:05:49 <Laibsch> if we don't have the manpower, we should not pump out new products/branches
May 13 14:05:50 <Crofton> we need to train more cooks
May 13 14:05:59 <Laibsch> if we don't want to loose credibility
May 13 14:06:03 <Crofton> Laibsch, bull poop
May 13 14:06:05 <RP> and some cooks seem to enjoy attacking other cooks meaning yet further developer time is needed sorting out problems
May 13 14:06:11 <Laibsch> Crofton: me too
May 13 14:06:20 <Crofton> even having a stable branch for people to start with helps
May 13 14:06:20 <chouimat|work> I always thought that wontfix was "I don't feel like fixing your bug because it's obvious that you're too stupid to use our product correctly" ;)
May 13 14:08:09 <RP> Laibsch: At the end of the day, some people think we can handle a stable branch. I'm more than happy to see it and I agree its needed. If those people want to put policy in place to help their workload I'm also fine with it
May 13 14:08:47 <RP> If you don't like the policy put in place, tough. If its so bad, it will burn itself out, if it doesn't it can't have been a problem
May 13 14:08:48 <Laibsch> RP: What you say hurts.  Because you obviously talk about me.  I care about the bug tracker.  If it is only for .dev something is wrong.
May 13 14:09:16 <Laibsch> I don't thrive on fights as you suggest
May 13 14:09:18 <Crofton> Read the ELC presentation and you can see places where a stable snapshot will provide benefit to end users
May 13 14:10:05 <Crofton> We need to better define the "supported features" of the current stable branch
May 13 14:10:07 <RP> Laibsch: I am not saying the bugtracker is only for .dev
May 13 14:10:08 * Laibsch wonders how to deal with this mess effectively in the BTS, so I am not bothered by the crap from .stable
May 13 14:10:13 <Jin^eLD> RP: you said "the headers are a target package" - meaning - it if I want them I should add them to my RDEPENDS_task-sdk-bare ?
May 13 14:10:15 <Crofton> and plan the new features of the net stable branch
May 13 14:10:20 <Laibsch> RP: the stable people are
May 13 14:10:36 <Crofton> and we could do a better job cutting unsupported stuff from .stable
May 13 14:10:50 <Crofton> but, making it go away is the wrong move
May 13 14:10:51 <RP> Laibsch: by all means open a bug, file the patch and then send to the stable list for review noting it in the bugzilla
May 13 14:11:04 <Jin^eLD> RP: because that does not work, so want to check if I got your idea correctly (I get a dependency conflict)
May 13 14:11:21 <Laibsch> RP: Why should I be doing even more work?
May 13 14:11:34 <RP> Laibsch: because it saves the stable maintainers work
May 13 14:11:37 <Laibsch> Just so koen does not have to open a browser from time to time?
May 13 14:11:46 <Laibsch> Or read the mails that bugzilla is already sending him
May 13 14:12:01 <RP> Laibsch: This is how the stable maintainers want it to work
May 13 14:12:04 <Laibsch> Why do you defend the stable mailing list refusing the mails from bugzilla?
May 13 14:12:08 <Laibsch> They want mails?
May 13 14:12:18 <Laibsch> They GOOOOOTTTTTTTTT MAILSSSSSS!
May 13 14:12:26 <Laibsch> For chrissakes!
May 13 14:12:39 <RP> Laibsch: This is changing the suibject afaics?
May 13 14:12:46 <RP> Make up your mind what the problem is...
May 13 14:12:47 <Laibsch> no
May 13 14:12:51 <Laibsch> what is changing?
May 13 14:12:51 <broonie> Laibsch: Separating user discussion from developer discussion is a very common workflow - normally the two audiences are rather different and need at least different presentation of content for what they're doing.
May 13 14:13:16 <Laibsch> broonie: I don't think that is what is being discussed
May 13 14:13:32 <Jin^eLD> Laibsch: you could fork off an own stable with a clearly defined workflow and see if you can get people on board :)
May 13 14:13:41 <Laibsch> No way
May 13 14:13:44 <Jin^eLD> hehe
May 13 14:13:46 <Laibsch> Why should I do that
May 13 14:13:48 <Laibsch> ?
May 13 14:13:51 <Laibsch> I am fine in .dev
May 13 14:13:55 <Laibsch> Like everybody else
May 13 14:14:16 <Crofton> um
May 13 14:14:22 <Laibsch> I am just trying to get people to understand there are problems with labeling something .stable but not doing anything about it
May 13 14:14:23 <Jin^eLD> I was not serious anyway :>
May 13 14:14:34 <rwhitby> In case people who run Debian haven't seen it yet, an openssh debian-only weak key security advisory: http://lists.debian.org/debian-security-announce/2008/msg00152.html
May 13 14:14:36 <Crofton> lots of people take snapshots and use collections to fix their issues
May 13 14:14:38 <Laibsch> I am more in the mood of crying
May 13 14:14:48 <broonie> Also affects Ubuntu since feisty or sol.
May 13 14:14:51 <chouimat|work> rwhitby: this thing is scary :)
May 13 14:14:59 <RP> Laibsch: People are trying to do something about stable, you just don't agree with how they're doing it
May 13 14:15:01 <broonie> They're currently working on pushing out their security release.
May 13 14:15:19 <zecke> rwhitby: thanks... goes updating the debian packages to openssl...
May 13 14:15:23 <Laibsch> RP: I don't agree about them ignoring the official bug tracker
May 13 14:15:35 <Laibsch> I don't care how they decide on what to commit
May 13 14:15:45 <Laibsch> But IMNSHO they can not ignore the bug tracker
May 13 14:15:53 <Laibsch> should not be allowed to
May 13 14:16:02 <RP> Laibsch: They're asking for submission of patches to the list, not ignoring the bug tracker
May 13 14:16:09 <Laibsch> the patches that are being sent are rejected
May 13 14:16:14 <Laibsch> are you listening?
May 13 14:16:29 <Laibsch> And I think a mail with an URL to a patch should be sufficient
May 13 14:16:35 <RP> Did you send then as per their request?
May 13 14:16:36 <Laibsch> anything else is child's play
May 13 14:16:40 <RP> no.
May 13 14:16:43 <Laibsch> YESSSSSSS
May 13 14:17:14 * chouimat|work goes get some pop corn
May 13 14:17:17 <Laibsch> And in any case, I should not need to send them.  I think they should be doing some minimal bug work, too
May 13 14:17:40 <Laibsch> otherwise, the stable branch becomes the unsupported snapshot we have
May 13 14:17:47 <RP> Laibsch: I've made my opinion clear, I have nothing further to say
May 13 14:18:12 <Laibsch> good
May 13 14:18:13 <Crofton> amen
May 13 14:18:38 <Laibsch> I will create some suitable field so everybody can let the .stable bugs rot there
May 13 14:18:52 <Laibsch> I warned everybody, I guess there is nothing more I can do, either
May 13 14:19:17 <RP> Laibsch: Continue like this and I will use /ignore
May 13 14:20:01 <RP> rwhitby: Thanks for the heads up
May 13 14:20:59 <Laibsch> RP: feel free
May 13 14:26:24 <Jin^eLD> hey likewise 
May 13 14:27:16 <Crofton> http://www.celinux.org/elc08_presentations/glikely--fpga-lessons-learned.pdf
May 13 14:27:26 <Crofton> note the comments about user space being hard
May 13 14:27:34 <likewise> hi all,
May 13 14:27:45 <Crofton> gm
May 13 14:27:54 <likewise> fpga=virtex with powerpc probably ?
May 13 14:28:25 <Crofton> yeah
May 13 14:28:41 <Crofton> he gones on about compiling user space being a pain :)
May 13 14:33:53 <likewise> Grant has been living on one side of the user/kernel space border too much :-)
May 13 14:34:03 <Crofton> yeah
May 13 14:34:24 <Crofton> I've got a 403
May 13 14:34:35 <Crofton> One day I need to figure this out and post some images :)
May 13 14:38:05 <cdbot2> * * OE Bug 4257 has been created by <Laibsch>
May 13 14:38:07 <cdbot2> * * convert mtn repo to git repo
May 13 14:38:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4257
May 13 15:05:52 * rwhitby notes that NSLU2 kernel upstream support is now complete as of 2.6.26-rc2 - only took us three years, but we got there!
May 13 15:06:33 <zecke> hehe, congrats
May 13 15:06:38 <hrw> rwhitby: gratz
May 13 15:08:23 <chouimat|work> rwhitby: cool
May 13 15:08:59 <rwhitby> Now I can go back and reply to all those people who were hassling me about nslu2-linux.org not pushing stuff upstream fast enough ;-)
May 13 15:14:22 <rwhitby> Does OpenEmbedded's openssl have the same problem as Debian's?
May 13 15:14:57 <rwhitby> (I'm assuming not, since it was a Debian-specific problem, but you can't be too sure ...)
May 13 15:14:57 * XorA watches the panic spread
May 13 15:15:14 <XorA> rwhitby: http://lists.alioth.debian.org/pipermail/pkg-openssl-changes/2006-May/000191.html is the bad patch
May 13 15:15:57 <rwhitby> XorA: OMG!!!!! Hold the OpenMoko mass production - the Nor flash has openssl in it!!!! (just kidding)
May 13 15:16:43 <hrw> rwhitby: iirc we use debian patches
May 13 15:16:50 <rwhitby> Kurt must be feeling pretty good right now ...
May 13 15:17:00 <rwhitby> (author of that patch)
May 13 15:17:08 <rwhitby> hrw: yeah, that's why I'm asking.
May 13 15:17:22 <Genesis> http://lists.debian.org/debian-security-announce/2008/msg00152.html this patch ?
May 13 15:17:22 <Genesis> :)
May 13 15:17:23 <rwhitby> (since a lot of OE packages use Debian patches)
May 13 15:17:54 <XorA> OE openssl is also broken
May 13 15:18:04 <XorA> its in debian.patch in openssl directory
May 13 15:18:43 * rwhitby ponders the potential impact of that ...
May 13 15:18:56 <bernard_> fwiw, i wouldn't be surprised to expect another advisory shortly... they only reversed one of their hacks.
May 13 15:19:15 <bernard_> compare http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/rand/md_rand.c?rev=141&view=diff&r1=141&r2=140&p1=openssl/trunk/rand/md_rand.c&p2=/openssl/trunk/rand/md_rand.c
May 13 15:19:22 <bernard_> with http://svn.debian.org/viewsvn/pkg-openssl/openssl/trunk/crypto/rand/md_rand.c?rev=300&view=diff&r1=300&r2=299&p1=openssl/trunk/crypto/rand/md_rand.c&p2=/openssl/trunk/crypto/rand/md_rand.c
May 13 15:19:24 <broonie> bernard_: Yes, we've been discussing that.
May 13 15:19:45 * rwhitby wonders if he needs to create some new nslu2-linux firmware releases with fixed openssl in them ...
May 13 15:21:36 * mwester suspects there will be demand for openssl patches for the existing nslu2-linux firmwares to deal with, as well.
May 13 15:22:16 <XorA> good thing this was found before lenny release :-)
May 13 15:24:53 <rwhitby> mwester: looks like slugos-4.8-beta is not affected - it has openssl-0.9.7g
May 13 15:25:17 <mwester> whew!  that's one that we can strike off the list, anyway.
May 13 15:25:33 <rwhitby> same for Unslung-6.10-beta
May 13 15:25:54 <mwester> :) you beat me to that, I was just checking that one.
May 13 15:27:10 * rwhitby wonders about angstrom releases ...
May 13 15:28:46 <hrw> OZ releases...
May 13 15:29:36 <rwhitby> angstrom base-image didn't include openssl as far as I can see
May 13 15:35:32 * rwhitby sends a note to nslu2-linux ML, checks his own ssh key, then goes to bed.
May 13 15:46:33 <hrw> bye
May 13 15:46:56 <CIA-22> 03hrw 07org.oe.dev * r1cc13a06... 10/ (5 files in 3 dirs): gammu: updated to 1.20.0
May 13 15:47:00 <CIA-22> 03hrw 07org.oe.dev * rc93ef16a... 10/ (1 packages/gammu/gammu_1.20.0.bb): gammu: re-add stage task
May 13 15:47:05 <CIA-22> 03hrw 07org.oe.dev * r0a9a5a57... 10/ (3 files in 2 dirs): python-gammu: updated to 0.26
May 13 15:47:10 <CIA-22> 03hrw 07org.oe.dev * r58660340... 10/ (1 conf/checksums.ini): checksums.ini: added some entries from one build
May 13 15:47:15 <CIA-22> 03hrw 07org.oe.dev * rcfcb7ce8... 10/ (1 conf/checksums.ini): checksums.ini: merge Poky version
May 13 15:56:44 * RP worries about the server thats now offline after an apt-get upgrade :(
May 13 15:57:44 <florian> RP: oops
May 13 15:59:02 * XorA hates it when that happends
May 13 16:08:28 <mwester> "XXXX RAID controller: Disk 3: S.M.A.R.T. status indicates maximum run time is beyond normal range.  Press F1 to enter setup, F2 to continue."
May 13 16:09:06 <mwester> ^^^ The above BIOS message cost me a weekend after doing an update and restarting a server (that happened to be located in a locked-down datacenter)
May 13 16:09:53 <Laibsch> !oebug 1968
May 13 16:09:54 <cdbot2> * * Bug 1968, Status: NEW, Created: 2007-03-11 03:01
May 13 16:09:55 <cdbot2> * * milan.plzik(AT)gmail.com: bitbake gcc-cross fails in empty buildroot
May 13 16:09:56 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=1968
May 13 16:10:02 <Laibsch> is NOTOURBUG or is it?  buildroot?
May 13 16:18:07 * XorA applies an mtn-reset and tries again
May 13 16:26:05 <cdbot2> * * OE Bug 1739 has been marked as DUPLICATE of bug 2221 by <Laibsch>
May 13 16:26:07 <cdbot2> * * strace does not build for mipsel
May 13 16:26:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=1739
May 13 17:09:05 <cdbot2> * * OE Bug 2391 has been RESOLVED (FIXED) by <Laibsch>
May 13 17:09:07 <cdbot2> * * glibc fails locale generation due to bad dependency, patch included
May 13 17:09:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=2391
May 13 17:51:05 <CIA-22> 03Laibsch 07org.oe.dev * rbda2a641... 10/ (5 files in 4 dirs): chicken: first release with version 2.6. Closes 2454.
May 13 17:54:05 <cdbot2> * * OE Bug 2454 has been RESOLVED (FIXED) by <Laibsch>
May 13 17:54:06 <cdbot2> * * Bitbake build for Chicken Scheme
May 13 17:54:08 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=2454
May 13 18:09:23 <thesing> hi everybody
May 13 18:11:23 <kgilmer_> I have a question regarding OE conventions...
May 13 18:11:46 <kgilmer_> I have a package that has several build options that cause drasticly different binaries
May 13 18:12:06 <kgilmer_> do I create isolated recipies for each?
May 13 18:13:53 <XorA> kgilmer_: yes
May 13 18:14:04 <XorA> blah-feature1.bb
May 13 18:14:09 <XorA> blah-feature2.bb
May 13 18:14:27 <kgilmer_> ok cool...thanks.  Is there a convention for layering build options?
May 13 18:14:32 <XorA> kgilmer_: bit the common stuff you can put in blah.inc and just call require blah.inc
May 13 18:14:35 <kgilmer_> the package I'm talking about is a JVM
May 13 18:15:01 <kgilmer_> so, there are things like profile (classlib support), JIT, etc.
May 13 18:15:07 <XorA> kgilmer_: which jvm?
May 13 18:15:17 <kgilmer_> to represent them all could make for many many .BB files
May 13 18:15:22 <kgilmer_> phoneme advanced
May 13 18:15:27 <XorA> kgilmer_: you might want to talk to rschuster our jvm expert
May 13 18:16:37 <kgilmer_> alright.
May 13 18:16:42 <kgilmer_> thanks :)
May 13 18:16:50 <XorA> kgilmer_: jschuster is jalimo guy
May 13 18:16:54 <XorA> rschuster: 
May 13 18:17:03 * XorA doesnt know where the J came from
May 13 18:17:22 <kgilmer_> ah, cool
May 13 18:17:29 <kgilmer_> I think they are using jamvm or sablevm
May 13 18:17:44 <kgilmer_> AFAIK they have simpler build systems.
May 13 18:17:46 <woglinde> kgilmer who?
May 13 18:18:39 <kgilmer_> phoneme build system is pretty big
May 13 18:19:08 <kgilmer_> i work at Bug Labs, we make a linux computer
May 13 18:19:18 <kgilmer_> i'm looking into oe as a build system for our product
May 13 18:19:21 <kgilmer_> we depend on phoneme
May 13 18:19:43 <kgilmer_> currently we use LTIB
May 13 18:20:16 <woglinde> kgilmer why phoneme?
May 13 18:20:18 <XorA> kgilmer_: cool
May 13 18:20:53 <cyrilRomain> morning
May 13 18:20:59 <woglinde> hi cyrilromain
May 13 18:21:09 <kgilmer_> woglinde: several reasons...GPL, JIT, good support
May 13 18:22:40 <woglinde> kgilmer me and others working on cacao-cldc and midpath
May 13 18:22:52 <woglinde> and I my eyes midpath has more potential than phoneme
May 13 18:24:07 <kgilmer_> woglinde: I haven't heard of midpath.  I will check it out.  thx.  We use the CDC version of phoneme.
May 13 18:24:17 <woglinde> kgilmer oh
May 13 18:24:34 <woglinde> only useful backend for cdc version is gtk in phoneme
May 13 18:24:49 <woglinde> and last time I tested it, it was ugly
May 13 18:25:21 <kgilmer_> woglinde: we use QT currently, and yes you are right.  It's not going to win any beauty contests.
May 13 18:25:47 <kgilmer_> Sun is promising to GPL a new UI toolkit that runs from CLDC to SE next month.
May 13 18:26:04 <woglinde> since when is the qt port running in cdc?
May 13 18:26:43 <kgilmer_> woglinde: not sure.  It's been working for us for about a year.
May 13 18:26:45 <woglinde> last time 2 months ago I checked it and there was only cldc buidalble
May 13 18:27:06 <woglinde> which version of qt?
May 13 18:27:16 <woglinde> do you use
May 13 18:27:33 <kgilmer_> qt-x11-free is the recipie, 3.3.7 is the version i'm building against in OE
May 13 18:27:42 <kgilmer_> not sure off hand what version we are using in LTIB
May 13 18:28:09 <woglinde> hm midpath runs with qtembedded 2.0 qt3 qt4  4.4 and I am working on qtopia4
May 13 18:29:09 <woglinde> hm
May 13 18:29:14 <kgilmer_> woglinde: cool.  but...is midpath two just the ME UI stuff or AWT?
May 13 18:29:35 <woglinde> kgilmer hm nope its something in btw.
May 13 18:30:40 <kgilmer_> woglinde: interesting.  I will def check it out.
May 13 18:30:52 <woglinde> you can use any java vm to run it
May 13 18:31:01 <woglinde> yes check it
May 13 18:31:15 <woglinde> if you have questions please feel free to ask
May 13 18:31:35 <XorA> hmm, qtopia 4 would fit nicely on openmoko
May 13 18:31:43 <woglinde> on x86 I got operamini4 working with it
May 13 18:31:51 <woglinde> xora????
May 13 18:32:04 <woglinde> you mean it runs fine on the freerunner
May 13 18:32:08 <woglinde> *g*
May 13 18:32:17 <XorA> woglinde: should do :-)
May 13 18:32:26 <woglinde> should?
May 13 18:32:30 <kgilmer_> Here is some info on the ui stuff I mentioned: http://weblog.cenriqueortiz.com/javame,j2me/2008/05/08/lightweight-ui-toolkit-lwuit-for-java-me/
May 13 18:32:30 <XorA> a bit slow to render, but its running
May 13 18:32:30 <woglinde> it works
May 13 18:32:59 <XorA> woglinde: I mean qtopia4 freerunner stuff
May 13 18:33:07 <cyrilRomain> XorA: do you now why it is currently slow ?
May 13 18:33:11 <XorA> woglinde: depends how java renders whether its usable
May 13 18:33:34 <XorA> cyrilRomain: yeah, not bandwidth to framebuffer
May 13 18:33:44 <XorA> s/not/no/
May 13 18:34:15 <cyrilRomain> XorA: :[
May 13 18:34:17 <woglinde> xora hm actually cacao-clcd midpath dont work with qtopia4
May 13 18:34:51 <woglinde> kgilmer seems that should be the answer from sun against android
May 13 18:35:01 <cyrilRomain> for intested people: http://labs.trolltech.com/blogs/2008/04/22/side-by-side-video-windows-mobile-and-embedded-linux/
May 13 18:35:13 <woglinde> kgilmer but I dont know who should use it
May 13 18:35:21 <woglinde> because of the slowness of java
May 13 18:36:47 <kgilmer_> i saw it run on a few phones.  seemed to be ok.  we'll see as the source hasn't been released yet so no use in getting too involved until it actually happens.
May 13 18:38:57 <woglinde> kgilmer on which phones did you see lwt?
May 13 18:38:59 <XorA> I thought sun had ditched all j2me stuff in favour of JavaX
May 13 18:39:08 <woglinde> or  ist confidential?
May 13 18:39:18 <woglinde> xora?
May 13 18:39:22 <kgilmer_> XorA: :)  No it's public.  There are some timing issues with JavaX AFAIK
May 13 18:39:31 <woglinde> javafx
May 13 18:39:46 <kgilmer_> woglinde: HTC touch and a sonyerrickson...I forget the model.
May 13 18:39:54 <kgilmer_> I saw them running at javaone last week in sf.
May 13 18:40:43 <woglinde> hm ah
May 13 18:41:12 <kgilmer_> My understanding is that Sprint is releasing a new java based dev platform and LWUIT is a part of it.  I don't know if it was written for sprint specifically but the idea was to release it under GPL for a consistent UI.
May 13 18:41:26 <kgilmer_> (across devices/vms)
May 13 18:42:03 <woglinde> hm
May 13 18:42:12 <woglinde> what about sounds?
May 13 18:42:54 <kgilmer_> woglinde: not sure..  I didn't see anything.
May 13 18:44:21 <woglinde> midpath has alsa esd pulseaudio support *g*
May 13 18:44:36 <woglinde> but I didnt test it yet
May 13 18:45:29 <kgilmer_> woglinde: interesting.  will check it out as we also need sound support.
May 13 18:52:23 <woglinde> ah
May 13 18:52:36 <woglinde> you are making this plugable phone think
May 13 18:53:42 <woglinde> hi thesing
May 13 18:54:01 <kgilmer_> woglinde: well it's not a phone but yeah it's modular.
May 13 18:54:08 <woglinde> thesing we will see us at linuxtag?
May 13 18:54:51 <thesing_> I plan to be there every day. So probably yes ;)
May 13 18:55:13 <woglinde> okay
May 13 18:55:24 <woglinde> I will be there friday at the oe booth
May 13 18:55:48 <woglinde> I hope my simpad is ready then
May 13 18:56:31 <thesing_> why should it not?
May 13 18:56:49 <woglinde> I didnt flashed it for 3 months
May 13 19:13:12 * hrw -> maemo meeting
May 13 19:13:27 <woglinde> he hrw
May 13 19:20:03 <Laibsch> !oebug 1968
May 13 19:20:05 <cdbot2> * * Bug 1968, Status: NEW, Created: 2007-03-11 03:01
May 13 19:20:06 <cdbot2> * * milan.plzik(AT)gmail.com: bitbake gcc-cross fails in empty buildroot
May 13 19:20:06 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=1968
May 13 19:20:09 <Laibsch> is NOTOURBUG or is it?  buildroot?
May 13 19:21:18 <thesing> I think he meant s/buildroot/oe/
May 13 19:24:28 <woglinde> ask him
May 13 19:26:05 <cdbot2> * * OE Bug 1884 has been RESOLVED (WORKSFORME) by <Laibsch>
May 13 19:26:07 <cdbot2> * * udev_100.bb fails on link when extras/volume_id is included.
May 13 19:26:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=1884
May 13 19:26:54 <Laibsch> thesing: emtpy oe?
May 13 19:26:58 <Laibsch> woglinde?
May 13 19:27:03 <Laibsch> does that make any sense?
May 13 19:27:08 <Laibsch> It does not to me
May 13 19:27:11 <woglinde> laibsch?
May 13 19:27:23 <woglinde> if something ist not clear ask
May 13 19:27:32 <Laibsch> NOTOURBUG
May 13 19:27:38 <Laibsch> woglinde: I am asking ;-)
May 13 19:27:48 <thesing> I think he build from scratch.
May 13 19:27:50 <Laibsch> But I guess you meant somebody else that I shoudl ask
May 13 19:28:02 <Laibsch> OK, let's assume for now it is not buildroot
May 13 19:28:05 <Laibsch> I'll ask him
May 13 19:28:38 <Laibsch> If it was about buildroot, it would be NOTOURBUG, right? or is there some weird combination where the two work together?
May 13 19:32:13 <RP> Laibsch: we don't have anything to do with buildroot
May 13 19:32:28 <Laibsch> OK, thanks for confirming
May 13 19:34:01 <woglinde> hm seems he is a little bit confused
May 13 19:34:24 <woglinde> oh its an older bug
May 13 19:35:11 <woglinde> laibsch close it as wontfix
May 13 19:35:17 <woglinde> or invalid
May 13 19:35:38 <Laibsch> you suggested to ask, I asked ;-)
May 13 19:35:45 <Laibsch> 't was the right thing to do
May 13 19:35:55 <Laibsch> I can close if there is no response
May 13 19:36:42 <woglinde> hehe
May 13 19:36:44 <woglinde> okay :)
May 13 19:37:06 <woglinde> I thought it was a new bug
May 13 19:37:10 <woglinde> not over one year old
May 13 19:37:25 <Laibsch> most of the bugs we have are fairly old
May 13 19:37:53 <Laibsch> But at least there is some bug work being done
May 13 19:38:24 <Laibsch> !oebug 3742
May 13 19:38:25 <cdbot2> * * Bug 3742, Status: NEW, Created: 2008-02-05 14:08
May 13 19:38:26 <cdbot2> * * <Laibsch>: Latest opie images fail calibration (in qemu)
May 13 19:38:27 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=3742
May 13 19:38:47 <Laibsch> RP: is above bug fixed or the problem just masked by commiting the poky pointercal?
May 13 19:39:31 <RP> Laibsch: I told you, masked
May 13 19:39:58 <Laibsch> thanks for "I told you"
May 13 19:40:02 <Laibsch> I wasn't sure
May 13 19:40:09 <Laibsch> I see quite a number of bugs
May 13 19:40:17 <Laibsch> my memory is not 100%
May 13 19:40:18 <Laibsch> sorry
May 13 19:40:22 <Laibsch> my mistake
May 13 19:41:46 <RP> You cc'd me on the bug report and I did read it and would have corrected it if I disagreed
May 13 19:42:37 <woglinde> *g*
May 13 20:07:29 <Laibsch> as I said, my mistake. my imperfect is the to blame. deeply sorry.
May 13 20:07:36 <Laibsch> imperfect memory
May 13 20:10:05 <cdbot2> * * OE Bug 1953 has been RESOLVED (WORKSFORME) by <Laibsch>
May 13 20:10:07 <cdbot2> * * building glibc-initial-2.5 fails on x86_64 for i586 target
May 13 20:10:08 <otavio> I'm looking the thread about Git x Hg. Has it gotten any conclusion?
May 13 20:10:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=1953
May 13 20:13:12 <hrw> otavio: there is git server in testing
May 13 20:18:17 <kgilmer_> what is the appropriate SECTION for a jvm?  Jamvm doesn't define it and sablevm says "interpreters".
May 13 20:20:32 <hrw> guys: Geforce 7300GT or 8500GT?
May 13 20:20:54 <Laibsch> wb otavio
May 13 20:22:51 <mwester> hrw: how much heat do you want to generate?
May 13 20:23:45 <woglinde> kgilmer we didnt work on sable or jamvm the last time
May 13 20:23:46 <hrw> mwester: fan on my 6600gt dies. it has 3 point mounting so it is nearly non-replacable. alternative cooling is same price as card value....
May 13 20:23:58 * mwester has run Fedora on an 8600GT, but no heavy graphics, just ordinary graphics.
May 13 20:24:00 <woglinde> kgilmer rschuster and I concentraded on cacao and midpath
May 13 20:25:05 <cdbot2> * * OE Bug 1834 has been RESOLVED (FIXED) by <Laibsch>
May 13 20:25:07 <cdbot2> * * libol and syslog-ng broken
May 13 20:25:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=1834
May 13 20:25:58 <kgilmer_> woglinde: ok.  I see you used "interpreters" as well.
May 13 20:26:17 <kgilmer_> maybe I'm splitting hairs but with JIT i'm sure if it's appropriate...
May 13 20:26:37 <woglinde> kgilmer but I will look at it
May 13 20:26:46 <kgilmer_> but...I'm the n00b so I'll just follow the convention :)
May 13 20:28:45 <kgilmer_> woglinde: s/I'm sure/I'm not sure
May 13 20:29:30 <woglinde> ah section
May 13 20:29:32 <woglinde> hm
May 13 20:29:41 <woglinde> sections isnt so important
May 13 20:29:45 <woglinde> sorry
May 13 20:30:02 <woglinde> I thought you mean something like provdies
May 13 20:30:05 <cdbot2> * * OE Bug 2003 has been RESOLVED (LATER) by <Laibsch>
May 13 20:30:07 <cdbot2> * * gif2png 2.5.1 fails to build
May 13 20:30:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=2003
May 13 20:30:56 <kgilmer_> woglinde: oh, ok
May 13 20:31:25 <CIA-22> 03Laibsch 07org.oe.dev * r4cf7981e... 10/ (1 packages/gif2png packages/nonworking/gif2png): gif2png: moving to nonworking and closing 2003 as LATER.
May 13 20:34:45 <kgilmer_> thanks woglinde, heading out.
May 13 20:40:05 <cdbot2> * * OE Bug 2382 has been RESOLVED (FIXED) by <Laibsch>
May 13 20:40:07 <cdbot2> * * CROSS COMPILE BADNESS while compiling gst-plugins-good-0.10.4-r0
May 13 20:40:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=2382
May 13 20:42:05 <cdbot2> * * OE Bug 2626 has been RESOLVED (FIXED) by <Laibsch>
May 13 20:42:06 <cdbot2> * * collie keyboard woes at boot
May 13 20:42:08 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=2626
May 13 20:43:05 <cdbot2> * * OE Bug 3264 has been RESOLVED (WORKSFORME) by <Laibsch>
May 13 20:43:07 <cdbot2> * * linux-libc-headers depends on gettext-native
May 13 20:43:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=3264
May 13 20:53:04 <cdbot2> * * OE Bug 3313 has been RESOLVED (FIXED) by <Laibsch>
May 13 20:53:06 <cdbot2> * * Fix for task-sdk-opie
May 13 20:53:08 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=3313
May 13 20:54:42 <ant_> gm
May 13 20:55:26 <CIA-22> 03Laibsch 07org.oe.dev * rfdaef9f1... 10/ (1 packages/tasks/task-sdk-opie.bb): task-sdk-opie: replace libqpe1 with libqpe-opie. Closes 3313.
May 13 21:03:57 <ant_> FYI I just needed to wipe /tmp (but keeping /pstage) in order to build angstrom-2008.1-test-c7x0
May 13 21:04:25 <ant_> was stuck on do_rootfs before
May 13 21:08:04 <ant_> RP: something changed about initramfs-image? I have only console-image and x11-image as targets but Angstrom-initramfs-image-glibc-ipk-2008.1-test-20080513-c7x0 was built...
May 13 21:09:20 <ant_> thesing: ping
May 13 21:09:29 <ant_> ^^^^
May 13 21:13:25 <Laibsch> hrw, RP: does poky-qemu normally have a working net interface?
May 13 21:13:43 <Laibsch> I am looking for a way to install some extra packages into a qemu image
May 13 21:15:05 <cdbot2> * * OE Bug 3483 has been RESOLVED (WONTFIX) by <Laibsch>
May 13 21:15:07 <cdbot2> * * guile-native-1.6.4 fails do_compile, time for removal?
May 13 21:15:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=3483
May 13 21:15:14 <hrw> Laibsch: it does
May 13 21:15:22 <Laibsch> damn
May 13 21:15:25 <Laibsch> it does not here
May 13 21:15:32 <Laibsch> DHCP or fixed IP?
May 13 21:15:41 <Laibsch> I have an eth0:avahi
May 13 21:15:55 <Laibsch> With a 169.X.X.X IP address
May 13 21:23:46 <Laibsch> hrw: ?  ^^^
May 13 21:24:54 <woglinde> laibsch the kernel have to support the netinterface too
May 13 21:25:19 <woglinde> qemu can provides 2 different networkcard emualtions
May 13 21:25:25 <woglinde> look at the docu
May 13 21:26:05 <Laibsch> woglinde: do you happen to know by chance if the OE qemu kernel supports such a network card?
May 13 21:26:11 <Laibsch> I guess the one poky does
May 13 21:26:13 <hrw> fixed 102.168.7.2
May 13 21:26:17 <Laibsch> as always ;-)
May 13 21:26:22 <Laibsch> hrw: thanks
May 13 21:26:26 <CIA-22> 03Laibsch 07org.oe.dev * re0a3a460... 10/ (4 files in 4 dirs): guile: move guile-native-1.6.4 to nonworking and close 3503.
May 13 21:26:36 <woglinde> laibch you could look at the .config
May 13 21:26:39 <Laibsch> I suspect some fixing needs to be done in .dev
May 13 21:26:55 <Laibsch> woglinde: .config from poky?
May 13 21:27:05 <Laibsch> Oh, you mean kernel .config, right?
May 13 21:27:10 <woglinde> right
May 13 21:27:13 <Laibsch> OK
May 13 21:27:15 <Laibsch> will do
May 13 21:29:54 <woglinde> laibsch the openmoko and the qtopia neo image didnt have the modules
May 13 21:30:15 <Laibsch> qtopia neo image
May 13 21:30:19 <Laibsch> where is that coming from?
May 13 21:30:21 <woglinde> so I had to take the ugly usbnet gadgetfs solution
May 13 21:30:28 <woglinde> form trolltech?
May 13 21:30:34 <woglinde> check qtopia.net
May 13 21:30:42 <Laibsch> aha, they are OE customers, too?
May 13 21:30:51 <Laibsch> Or are they using their own stuff?
May 13 21:30:55 <Laibsch> to compile
May 13 21:31:15 <woglinde> unfornatly they use buildroot for the toolchain
May 13 21:31:17 <woglinde> or crosstool
May 13 21:31:21 <woglinde> cant remeber
May 13 21:31:29 <Laibsch> woglinde: wouldn't it have been better to recompile the kernel?
May 13 21:31:51 <woglinde> crosstool
May 13 21:31:58 <woglinde> for greenphone
May 13 21:37:18 <Laibsch> woglinde, hrw: defconfig for qemuarm is md5sum identical in .dev and poky
May 13 21:37:42 <hrw> and your host lack tap0?
May 13 21:38:24 <Laibsch> I have tap0 with addr:192.168.7.1
May 13 21:41:10 <hrw|gone> have a good night everyone
May 13 21:41:24 <cbrake> hrw|gone: same to you
May 13 22:13:05 <cdbot2> * * OE Bug 4258 has been created by <Laibsch>
May 13 22:13:07 <cdbot2> * * qemu image has no working network interface
May 13 22:13:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4258
May 13 22:14:28 <tharvey> pretty new to OE... trying to understand how to determine what bitbake tasks exist.  If I understand correctly you create a conf file that specifies the machine/distro you want - so the available tasks are per the distro?
May 13 22:14:32 <Laibsch> RP: maybe you can share some insight for bug 4258 as to what needs to be ported from poky
May 13 22:14:55 <Laibsch> tharvey: what do you understand as "a task"?
May 13 22:16:43 <Laibsch> RP: defconfig for qemuarm is md5 identical in .dev and poky
May 13 22:17:36 <RP> Laibsch: You're not going to get any sense out of me until the weekend now, too much else to do :(
May 13 22:17:36 <tharvey> well... to build say the kernel/rootfs/whatever for a given platform you would do something like 'bitbake <task>' - just not sure what 'tasks' are avail - guess I could use some more examples
May 13 22:18:00 <Laibsch> RP: sure.  Can I cc you on the bug as a reminder?
May 13 22:18:40 <Laibsch> tharvey: Try "MACHINE=$whatevermachineyouwanttobuildfor bitbake console-image"
May 13 22:18:47 <Laibsch> That should get you going
May 13 22:22:03 <tharvey> ok. so what is 'console-image'?  its a task right... how do I know what it does?  How would I know that it exists as a possible task?   (I'm used to buildroot/openWRT so OE is pretty alien to me... please bear with me)
May 13 22:23:35 <tharvey> I've read over http://oe.linuxtogo.org/wiki/GettingStarted and several of the other docs there, and they do a nice job at giving a 'script' of commands but not explaining what the commands are doing...
May 13 22:23:57 <Laibsch> no it is not a task
May 13 22:24:02 <Laibsch> it is a target
May 13 22:24:09 <Laibsch> target for bitbake
May 13 22:24:27 <poli> openwrt is oe now? cool.
May 13 22:24:31 <tharvey> ok... so 'nano' and 'task-base' are also packages
May 13 22:24:35 <Laibsch> I don't think so
May 13 22:24:37 <tharvey> openwrt is not oe
May 13 22:24:46 <Laibsch> nano is a package
May 13 22:25:02 <Laibsch> task-base is not AFIAK
May 13 22:25:04 <poli> oh ok
May 13 22:25:05 <tharvey> its based off a modified buildroot - just saying that that type of env is what I've worked with in the past and am familiar with 
May 13 22:25:28 <tharvey> task-base is in the 'Start building' example described as a 'package set' if I understand correctly
May 13 22:25:35 <Laibsch> tharvey: If you are really very familiar with wrt, OE also supports building packages for wrt
May 13 22:25:44 <Laibsch> but that area could use some love
May 13 22:25:46 <poli> by the way, did anyone around get openmoko running on a 4700? koen has a webpage for that, but server has been offline for a while now :(
May 13 22:25:53 <Laibsch> I don't think anybody looked at it for some time
May 13 22:25:54 <RP> Laibsch: You can cc me if you like, I'm not sure its going to free up more time to help though
May 13 22:26:06 <tharvey> so the only way I would know what the heck 'nano' is would be to look at packages/nano/*.bb then?
May 13 22:26:22 <Laibsch> tharvey: you should approach this the other way round
May 13 22:26:26 <Laibsch> What do you want?
May 13 22:26:32 <tharvey> I'm not really interested in building packages for OpenWRT - its build system is fine for that - I'm looking at adopting OE for a BSP
May 13 22:26:39 <Laibsch> And then you look for that in the packages
May 13 22:26:41 <tharvey> just trying to understand....
May 13 22:27:05 <Laibsch> If you want a flashable image "console-image" is a first possibility
May 13 22:27:52 <tharvey> well I would think of packages such as 'linux', 'uboot', 'busybox', 'madwifi' etc... what about building say a kernel/uboot/rootfilesystem for a target?  
May 13 22:27:59 <Laibsch> poli: what is the benefit of openmoko on a 4700?  That is an ipaq, right?
May 13 22:28:25 <Laibsch> tharvey: yes for those packages
May 13 22:28:32 <Laibsch> It is "bitbake $package"
May 13 22:28:42 <Laibsch> for the rootfs you will want an image
May 13 22:28:46 <poli> Laibsch: that's right, it is an ipaq. The benefit is I will have a development platform, even if with no GSM modem, given the GSM-capable ones are just not being sold.
May 13 22:28:53 <Laibsch> look through packages/images/*
May 13 22:29:06 <Laibsch> poli: I see
May 13 22:29:12 <Laibsch> how about qemu?
May 13 22:29:28 <tharvey> now I thought for an 'image' I would be using a distribution, ie 'unslung', 'angstrom'?
May 13 22:29:42 <Laibsch> tharvey: you always use a distro
May 13 22:29:55 <poli> Laibsch: already working on qemu, and doing fine, I just want to test the touch-screen and real-size VGA screen
May 13 22:30:12 <Laibsch> yeah, nothing beats the real feeling,I guess ;-)
May 13 22:30:20 * poli chuckles
May 13 22:30:33 <tharvey> ok, so kernel is simply  a package, distro defines what packages would be in an image, and image defines how the image is built? 
May 13 22:32:30 <Laibsch> no
May 13 22:32:33 <Laibsch> but close
May 13 22:32:37 <tharvey> what confuses me is that I see things in packages/images that would seem to be to be distros... guess they are more targetting a specific distro tailored for a specific purpose? 
May 13 22:32:38 <Laibsch> distro defines policy
May 13 22:33:05 <Laibsch> an image defines what is in that image
May 13 22:33:50 <tharvey> ah... ok.  So to 'build' you are building either a 'package' or an 'image'? 
May 13 22:34:49 <Tartarus> yes, but hte build system doesn't treat 'em differently
May 13 22:34:55 <tharvey> right
May 13 22:35:30 <tharvey> ok... starting to sink in a little more then.  defining MACHINE triggers compilers and patches in the build process right?
May 13 22:36:09 * Tartarus kicks his NS
May 13 22:36:23 <Tartarus> somewhat, yes
May 13 22:36:36 <Tartarus> a combination of machine and distro set compilers and patches
May 13 22:36:59 <Tartarus> (generally speaking, machine-specific patches are just in the kernel, which has its own recipe generally)
May 13 22:37:38 <tharvey> yes... that makes sense
May 13 22:37:45 <Tartarus> but the machine conf says what arch it is, and the tune file for cflags
May 13 22:38:05 <Tartarus> distro generally picks compiler/libc on arch, but with some exceptions for stuff that must be slightly different
May 13 22:38:12 <tharvey> so if I want to tweak the kernel config... is there a way to invoke 'make menuconfig' for a specific kernel recipe then or would that be done manually?
May 13 22:38:24 <Tartarus> well
May 13 22:38:33 <Tartarus> bitbake -c devshell recipe works, in some limited cases
May 13 22:38:41 <Tartarus> (ie it's all at your desktop)
May 13 22:38:57 <Tartarus> devshell will setup env and plop you in the workdir
May 13 22:39:00 <Tartarus> so you can run make menuconfig
May 13 22:39:18 <Tartarus> but in general, kernel dev outside OE, make OE build your whole BSP (ie kernel and rootfs)
May 13 22:40:26 <tharvey> ah... do deveshell puts you in a workdir thats been pre-downloaded, patched and configured per the recipe
May 13 22:41:38 <Tartarus> i'm not 100% what it does first, i cant use it usually :)
May 13 22:42:11 <tharvey> so there is also no 'menuconfig' to tweak what packages a distro/image includes then?
May 13 22:42:34 <Tartarus> nope, that's controlled at the image level, mostly
May 13 22:42:43 <Tartarus> there's no overall menuconfig
May 13 22:43:59 <tharvey> it seems like every project that uses OE creates their own distro (conf/distro) and also one or more images - does that seem like the case?
May 13 22:46:34 <Tartarus> tweak images, yes
May 13 22:47:32 <tharvey> so I'm looking at using OE to maintain OS images for several different embedded boards where each board may be used in one or more applications - sounds like I need to create a machine conf for each board (assuming different architectures) then create images for each application, and perhaps create a single distro that sets the overall policy of the images?
May 13 22:48:25 <Tartarus> mostly
May 13 22:48:41 <Tartarus> 1 machine conf per board, assuming none share final kernel images
May 13 22:49:02 <Tartarus> 1 kernel recipe for each board, unless it's all 100% upstream and you can just provide differnet kernel configs
May 13 22:49:07 <Tartarus> 1 image recipe per application
May 13 22:49:18 <Tartarus> And think strongly about using an existing distro for policy
May 13 22:49:52 <Tartarus> IMHO, it seems a lot of the distro policy stuff comes down to stuff for installing packages once deployed
May 13 22:50:59 <tharvey> I'm still not understanding distro in this sense well... I think of distro as 'Ubuntu', 'Debian', 'Fedora', 'RHEL', 'SUSE' etc
May 13 22:51:24 <tharvey> you mean stuff for installing packages once deployed such as 'ipkg' vs 'dpkg' etc?
May 13 22:51:39 <Tartarus> and default feeds to look for packages
May 13 22:52:36 <tharvey> ah... default feeds is probably the largest reason for all the distros currently defined would be my guess
May 13 22:57:05 <cdbot2> * * OE Bug 1474 has been RESOLVED (WORKSFORME) by <Laibsch>
May 13 22:57:07 <cdbot2> * * opie does not start on c3200
May 13 22:57:09 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=1474
May 13 23:06:47 <tharvey> looking at a few projects/BSP's that are based off of OE, it looks like they distribute and in some cases revision control (outside of the oe monotone repo) a 'snapshot' of OE - I assume so that they are using a known/stable version - how do I tell what snapshot it came from (I'm completely ignorant about monotone and how it references revisions)
May 13 23:09:36 <Tartarus> look in the _MTN dir
May 13 23:11:05 <tharvey> so given 'old_revision [5480bec3f64046446cb2d5fdbba10a7a45e5d5f7]' how do I relate this to a date/revision in oe's browsable repo?
May 13 23:12:28 <Tartarus> 5480bec3f64046446cb2d5fdbba10a7a45e5d5f7 is the reproducible key
May 13 23:13:24 <tharvey> then use http://amethyst.openembedded.net/oe/viewmtn/viewmtn.py/OE1/revision/browse/<key>?
May 13 23:13:39 <Tartarus> perhaps, never used the web viewer :)
May 13 23:13:51 <Tartarus> i jsut keep track of the keys i use
May 13 23:13:59 <woglinde> nite
May 13 23:14:26 <tharvey> cool that seemed to work.  A key is the unique revision identifier (akin to an svn revision) correct?
May 13 23:14:38 <Tartarus> yes
May 13 23:14:39 <Tartarus> or git hash
May 13 23:18:41 <tharvey> is the key per branch or per repo?
May 13 23:18:53 <tharvey> looks like its per repo
May 13 23:28:07 <Tartarus> yes, per repo
May 13 23:39:04 <cdbot2> * * OE Bug 4259 has been created by mas(AT)ecs.soton.ac.uk
May 13 23:39:06 <cdbot2> * * pxa2xx_udc: fix clock setup
May 13 23:39:08 <cdbot2> * * http://bugs.openembedded.net/show_bug.cgi?id=4259
May 14 00:25:12 <tharvey> thanks for the help.... be back tomorrow
May 14 00:32:44 <Marex> would be nice to have thing merged http://marex.hackndev.com/01-add-palmwk.patch ;)
**** ENDING LOGGING AT Wed May 14 02:59:57 2008