| 00:23.09 | *** join/#oe Timelord (n=TL@68-191-189-54.static.fdul.wi.charter.com) |
| 00:47.22 | *** join/#oe wrobbie (n=rob@cm112.sigma248.maxonline.com.sg) |
| 00:47.48 | *** join/#oe furlongm__ (n=furlongm@83-71-68-174.b-ras1.prp.dublin.eircom.net) |
| 00:59.58 | *** join/#oe furlongm___ (n=furlongm@83.70.251.48) |
| 01:24.10 | *** join/#oe tmbinc_ (i=abcd@e176145213.adsl.alicedsl.de) |
| 01:24.39 | *** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 01:36.25 | *** join/#oe EvilDevil_ (n=miau@p54A6E506.dip.t-dialin.net) |
| 01:50.06 | *** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 02:23.22 | CIA-9 | 03lenehan 07org.oe.dev * rab3be7ba... 10/ (1 packages/ssmtp/ssmtp_2.61.bb): |
| 02:23.22 | CIA-9 | ssmtp 2.61: Add back the patch which prevents ssmtp from attempting to strip |
| 02:23.22 | CIA-9 | the binaries during install. Without this the install fails due to the use |
| 02:23.22 | CIA-9 | of the host install calling the host strip which does not understand the |
| 02:23.22 | CIA-9 | target binary type. OE will take care of stripping the binary itself during |
| 02:23.23 | CIA-9 | packaging. |
| 03:23.55 | *** join/#oe idealm (n=ideal@222.67.232.101) |
| 03:29.14 | *** join/#oe W8TVI (n=me@166.165.149.170) |
| 03:46.04 | *** join/#oe TheMasterMind1 (n=aman@c-65-96-169-40.hsd1.ma.comcast.net) |
| 03:46.41 | *** join/#oe Timelord0 (n=TL@68-191-189-54.static.fdul.wi.charter.com) |
| 04:14.25 | *** join/#oe Marex (n=Marex@213.194.240.165) |
| 04:24.17 | CIA-9 | 03lenehan 07org.oe.dev * ra0a75207... 10/ (1 packages/grep/grep-native_2.5.1.bb): grep 2.5.1: Add a -native version of grep. |
| 04:49.32 | *** join/#oe Kevin` (i=kevin@kwzs.be) |
| 05:01.49 | *** join/#oe giel (n=giel@twigs.unet.nl) |
| 05:10.57 | *** join/#oe goxboxlive (n=jrs@9.80-202-160.nextgentel.com) |
| 05:27.58 | *** join/#oe Sleep_Walker (n=Sleep_Wa@195.22.44.103.adsl.nextra.cz) |
| 05:31.11 | *** join/#oe eno__ (n=eno@adsl-70-137-132-22.dsl.snfc21.sbcglobal.net) |
| 05:35.31 | *** join/#oe __law__ (n=law@mail.stiftadmont.at) |
| 05:51.54 | *** join/#oe koen (n=koen@dominion.kabel.utwente.nl) |
| 05:51.56 | *** join/#oe SD840_ (n=lookback@ANancy-157-1-71-103.w86-213.abo.wanadoo.fr) |
| 05:54.06 | *** join/#oe gumz (i=lookback@une.vodka.danstaface.net) |
| 06:10.04 | koen | good morning all |
| 06:11.11 | *** join/#oe wrobbie (n=rob@cm112.sigma248.maxonline.com.sg) |
| 06:39.45 | *** join/#oe AvengerMoJ1 (n=alex@219.142.246.150) |
| 06:59.03 | CIA-9 | 03lenehan 07org.oe.dev * r1e38cb0e... 10/ (1 packages/perl/perl_5.8.7.bb): |
| 06:59.03 | CIA-9 | perl 5.8.7: Use grep -I to ignore binary files instead of looking at |
| 06:59.03 | CIA-9 | the output message from grep. The output message could change |
| 06:59.03 | CIA-9 | depending on the LOCALE which would break the current test. Make it |
| 06:59.03 | CIA-9 | DEPEND on grep-native to ensure we get the gnu version of grep which |
| 06:59.04 | CIA-9 | is needed for -I to work. As per bug #1439. |
| 07:03.25 | *** part/#oe AvengerMoJ1 (n=alex@219.142.246.150) |
| 07:06.24 | *** join/#oe Genesis (n=Genesis@dyn-88-123-203-156.ppp.as12876.net) |
| 07:12.40 | *** join/#oe theturtle (n=theturtl@guiness.lifl.fr) |
| 07:15.00 | *** join/#oe bluelightning (n=blueligh@125-237-75-10.jetstream.xtra.co.nz) |
| 07:27.23 | CIA-9 | 03koen 07org.oe.packaged-staging * rbcb47891... 10/ (5 files in 3 dirs): stage-manager: add in to contrib/scripts |
| 07:28.54 | mickeyl | morning |
| 07:31.34 | koen | hey mickeyl |
| 07:33.39 | mickeyl | me too |
| 07:33.53 | mickeyl | i have a shitload of things to do before thursday.. |
| 07:35.46 | mickeyl | and i definitly need to prepare my laptop to be able to work during travelling |
| 07:35.48 | RP | morning all |
| 07:35.51 | mickeyl | morning RP |
| 07:36.01 | koen | hey RP |
| 07:38.43 | RP | koen: FWIW, the build I left running from packaged staging got to generating the glib locales which failed for the expected reasons. I guess I'd better merge glibc with dev :) |
| 07:38.55 | koen | RP: :) |
| 07:43.44 | CIA-9 | 03koen 07org.oe.dev * rc2533135... 10/ (4 files in 2 dirs): angstrom: start removing overlap between task-base and task-angstrom |
| 07:46.18 | koen | RP: the next commit is for you :) |
| 07:46.23 | CIA-9 | 03koen 07org.oe.packaged-staging * r8975c1a4... 10/ (1 contrib/scripts/ipkg-build mtn:execute true): contrib/scripts/ipkg-build: add a modified ipkg-build that ignores usr/lib/ipkg/lists and ipkg.pyc |
| 07:47.08 | RP | koen: yay :) |
| 07:49.48 | RP | koen: Can you remind me why glibc-intermediate is ignored for packaged staging? |
| 07:50.08 | koen | because it needs file present in staging for 'make install' in do_stage() |
| 07:50.19 | koen | s/file/stuff/ |
| 07:50.31 | RP | So we should be able to work around that now? |
| 07:50.36 | koen | yes :) |
| 07:51.14 | hrw|work | morning |
| 07:51.19 | koen | hey hrw|work |
| 07:51.37 | RP | hi hrw|work |
| 07:51.53 | RP | koen: and the same applied to linux-libc-headers? |
| 07:52.05 | koen | iirc, yes |
| 07:52.06 | hrw|work | I also have some thigns to do before oedem |
| 07:52.15 | hrw|work | 1. finish session1 presentation |
| 07:52.27 | *** join/#oe ade|desk (n=ADAVEY@194.200.143.249) |
| 07:52.27 | hrw|work | 0. buy bag for clothes and stuff |
| 07:52.52 | ade|desk | morning all |
| 07:52.56 | koen | hey ade|desk |
| 07:53.00 | hrw|work | hi ade|desk |
| 07:53.17 | RP | hi ade|desk |
| 07:54.21 | koen | hm |
| 07:54.25 | koen | *mumble* |
| 07:54.35 | *** join/#oe J (n=john@cpc3-mfld2-0-0-cust829.nott.cable.ntl.com) |
| 07:54.41 | koen | note to self: do not use bitbake threading with p-s |
| 07:55.12 | *** join/#oe cyrilRom1in|zZz (n=cyrilRom@AToulouse-157-1-62-88.w86-207.abo.wanadoo.fr) |
| 07:55.38 | cyrilRomain | morning |
| 07:56.48 | *** join/#oe XorA (n=dp@www.xora.org.uk) |
| 07:57.14 | XorA | morning |
| 07:57.24 | RP | koen: As long as theres only populate-staging running, it should be ok - we need to add something to bitbake to support that though :) |
| 07:57.27 | RP | hi XorA |
| 08:00.33 | XorA | RP: I missed if you ever answered, but did you get mplayer + rgb on /dev/fb2 to work? |
| 08:01.31 | RP | XorA: I never tried |
| 08:01.55 | RP | XorA: rgb would be fb1, YUV would be fb2 |
| 08:02.08 | XorA | RP: ok, it doesnt seem to like any fb other than fb0 here, have to dig about and see why |
| 08:02.50 | RP | XorA: The other framebuffers are only created when something opens them and are destroyed along with all settings when closed |
| 08:03.01 | RP | They default to a size of 0x0 |
| 08:03.35 | XorA | RP: I know, but sending -fbmode blah -vm should set the mode from player |
| 08:04.18 | XorA | RP: but the fbdev/fbdev2 code in mplayer looks a bit crazy |
| 08:04.43 | RP | XorA: I've just not had a chance to look into ot |
| 08:06.07 | CIA-9 | 03rpurdie 07org.oe.packaged-staging * r397db3df... 10/ (8 files in 3 dirs): glibc: Sync with .dev |
| 08:10.07 | koen | ah, hmmm |
| 08:20.56 | CIA-9 | 03ade 07org.oe.dev * rac174cd1... 10/ (1 packages/rdesktop/rdesktop_cvs.bb): rdesktop: cvs change default pref to -1 |
| 08:29.39 | *** join/#oe bigd0g (n=b1gdo6@193.1.99.21) |
| 08:31.10 | *** join/#oe obergix[work] (n=olivier@inf-berger.int-evry.fr) |
| 08:42.37 | hrw|work | http://qtdeveloper.net/archives/2006/10/01/opie-fud/ |
| 08:43.30 | mickeyl | *sigh* |
| 08:44.25 | mickeyl | I'm pretty good at ignoring things nowadays... |
| 08:45.03 | koen | heh |
| 08:45.36 | hrw|work | I was thinking about removing opie-notes from opie and oe |
| 08:45.50 | hrw|work | qt4 version is easier to write |
| 08:46.03 | koen | qt4 is pretty awesome |
| 08:46.07 | kergoth | mickeyl: i particularly like how ljp advocates opie not breaking compatibility, yet thinks that can somehow magically be done without regularly open source releases on their end |
| 08:46.23 | hrw|work | QSql is nice |
| 08:46.37 | koen | hey kergoth |
| 08:46.40 | koen | ~mornings |
| 08:46.48 | ibot | Mornings MUST be destroyed! (see also http://www.destroymornings.com/) |
| 08:46.48 | kergoth | hey |
| 08:46.48 | mickeyl | kergoth: indeed :/ |
| 08:47.26 | kergoth | hehe |
| 08:48.17 | kergoth | i'm still surprised at just how fast ljp's priorities and tt's priorities became one and the same |
| 08:48.22 | *** join/#oe zecke (n=freyther@88.134.98.23) |
| 08:48.26 | RP | morning kergoth |
| 08:48.34 | kergoth | hey RP |
| 08:48.36 | mickeyl | kergoth: no kidding, this is the thing that annoys me the most. |
| 08:48.41 | zecke | hey |
| 08:48.59 | koen | hey zecke |
| 08:49.01 | mickeyl | kergoth: they almost sucked all community thinking out of him and transformed it into corporate thinking. although he claims otherwise, of course :/ |
| 08:49.03 | mickeyl | morning zecke |
| 08:49.13 | koen | zecke: didn't you look into openssl a while ago? |
| 08:49.33 | zecke | koen: 'look' == trying to use a non-vulnerable version? |
| 08:49.40 | koen | zecke: yes |
| 08:49.50 | zecke | koen: yes, but you did the same then :) |
| 08:49.56 | koen | and I failed :) |
| 08:50.28 | zecke | koen: ah well, I will go to the gym soon and then might look into cleaning it up and pushing some bits |
| 08:51.13 | koen | RP: http://rafb.net/paste/results/YqG5Dc77.html |
| 08:51.58 | koen | RP: any thoughts on marking unrelocatable stuff like quilt 'dirty' in OE? |
| 08:52.14 | koen | s/quilt/quilt-native/ |
| 08:53.07 | zecke | koen: make quilt relocatable |
| 08:55.10 | zecke | mickeyl: hmm, at least he admits Qtopia is not free |
| 08:58.22 | *** join/#oe AvengerMoJo (n=alex@219.142.246.150) |
| 08:58.31 | mickeyl | zecke: when I have a chance, I'll dig out my old mail about why Opie died and post it as comment |
| 09:00.15 | zecke | mickeyl: We lost marketing and failed to differentiate from Qtopia (simply phrased) |
| 09:00.24 | mickeyl | *nod* |
| 09:00.36 | zecke | mickeyl: and they are right. Why should I use Opie1.1 when I get Qtopia4 |
| 09:02.58 | koen | qt3 looks like gtk 1.0 on my devices |
| 09:03.08 | koen | I know it can do better :) |
| 09:03.33 | hrw|work | http://blogs.sun.com/andrei/entry/opteron_easter_egg ;D |
| 09:04.02 | zecke | koen: well, it tries to detect the WM and MB is not known so it defaults to motif look :) |
| 09:05.01 | koen | zecke: I use e17 |
| 09:06.32 | RP | koen: Looks good. We should probably add something to the metadata which says something can't be relocated. That will probably apply to all native packages to some extent though (certainly moving them from one system to another is likely to fail due to system lib differences) |
| 09:07.41 | koen | RP: I'd like to have something like www.angstrom-distribution.org/releases/2007.1/sdk/feed/ubuntu-dapper/ |
| 09:08.15 | koen | RP: a 'developer' only has to build stuff that isn;t relocatable like quilt to start using OE |
| 09:08.20 | RP | koen: I'd like to see this too... |
| 09:08.56 | koen | but with gcc-cross + binutils-cross + glibc the annoyance is a lot less |
| 09:09.21 | RP | koen: We're getting there - one step at a time |
| 09:09.47 | mickeyl | zecke: ok, found the mail and added a comment :) |
| 09:14.01 | RP | koen: glibc is the big benefit with packages staging, and with prepackaged libs, app development should be easier to as you'll not have to build the entire dependency chain |
| 09:14.32 | koen | RP: is the depchains stuff already in .dev? |
| 09:15.01 | RP | koen: Some of it certainly is, I'm not sure how much |
| 09:15.59 | koen | the stuff that adds RRECOMMENDS for -dev packages? |
| 09:17.56 | bigd0g | ~seen Crofton |
| 09:18.08 | ibot | crofton is currently on #casualti (1d 10h 27m 47s) #ol (1d 10h 27m 47s) #oe (1d 10h 27m 47s) #elinux (1d 10h 27m 47s). Has said a total of 13 messages. Is idling for 12h 24m 3s, last said: 'good movie'. |
| 09:18.08 | hrw|work | mickeyl: nice |
| 09:18.08 | *** join/#oe polyonymous (i=hacker@pD9539B18.dip0.t-ipconnect.de) |
| 09:18.32 | mickeyl | hrw|work: I'm too busy to make it a larger response now, but that should get the major point across |
| 09:19.14 | *** join/#oe ar__ (n=ar@port-ip-213-211-250-51.reverse.mdcc-fun.de) |
| 09:19.58 | *** join/#oe cedric (n=cedric@213.215.31.4) |
| 09:22.21 | hrw|work | mickeyl: yep. I do not plan to work too much on opie. have to test/integrate Marcos work from SoC and then will probably more or less dump the ship |
| 09:23.13 | *** join/#oe AvengerMoJo (n=alex@219.142.246.150) |
| 09:24.21 | *** join/#oe AvengerMoJ1 (n=alex@219.142.246.150) |
| 09:24.44 | mickeyl | i have mostly good feelings about that. Opie was a fantastic learning experience for me |
| 09:29.00 | zecke | ack |
| 09:31.30 | *** join/#oe ar_ (n=ar@port-ip-213-211-250-51.reverse.mdcc-fun.de) |
| 09:34.34 | koen | RP: my build is now at compiling glibc |
| 09:35.01 | RP | koen: excellent. Should I commit those changes? |
| 09:35.44 | koen | slightly ahead of you :) |
| 09:35.48 | CIA-9 | 03rpurdie 07org.oe.packaged-staging * r986d9bc3... 10/ (1 classes/packaged-staging.bbclass): classes/packaged-staging.bbclass: use stage-manager helper script to manage moving around staging/ and cross/ |
| 09:37.10 | XorA | poor cia |
| 09:37.24 | RP | koen: Complete with my own ID - interesting :) |
| 09:38.05 | koen | RP: 'mtn commit --author rpurdie@rpsys.net' |
| 09:38.42 | *** join/#oe florian_kc (n=fuchs@dns.kernelconcepts.de) |
| 09:38.45 | RP | koen: I guessed. I presume that still shows up as signed by you though? :) |
| 09:38.50 | koen | yes |
| 09:40.01 | koen | http://rafb.net/paste/results/fJiygc40.html |
| 09:42.30 | koen | NOTE: preparing tree for binary locale generation |
| 09:49.55 | hrw|work | for locale in localelist;do generate_locale &;done |
| 09:50.02 | hrw|work | ;D |
| 09:52.38 | florian_kc | hi all |
| 09:53.12 | florian_kc | :-) |
| 09:54.37 | hrw|work | hi florian_kc |
| 10:00.43 | koen | florian_kc: any news on a gpe-calendar release? |
| 10:01.20 | florian_kc | koen: no :-( did neal mention if he finished his paper? |
| 10:01.32 | koen | I haven't spoken to neal in weeks |
| 10:02.40 | florian_kc | :-( |
| 10:20.49 | XorA | gah, gnutls has moved to autoconf 2.60 |
| 10:22.26 | koen | XorA: add 2.60 to OE ? |
| 10:24.18 | XorA | koen: I started, but wolfson not be pleased if I spend all day porting our patches |
| 10:28.16 | koen | right :) |
| 10:28.36 | koen | ~lart 2.6.9-nbp |
| 10:28.44 | koen | ibot: botsnack |
| 10:28.44 | ibot | koen: aw, gee |
| 10:33.04 | *** join/#oe zinga (n=arnaudb@186.80-203-227.nextgentel.com) |
| 10:33.14 | XorA | koen: I will look at it in my own time |
| 10:34.24 | CIA-9 | 03rpurdie 07org.oe.packaged-staging * r7882ba5a... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: Remove unneeded special cases |
| 10:36.59 | *** join/#oe Imhotep (n=derBloX@p54AC9891.dip0.t-ipconnect.de) |
| 10:38.39 | CIA-9 | 03rpurdie 07org.oe.packaged-staging * rae09a62d... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: Remove merge artifact, reindent functions for clarity |
| 10:42.29 | CIA-9 | 03koen 07org.oe.packaged-staging * r3e228c55... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: update BUGS and TODO |
| 10:44.18 | *** join/#oe furlongm (n=furlongm@83.70.162.41) |
| 10:45.02 | koen | it's still generating locales.... |
| 10:45.17 | RP | NOTE: package glibc-2.4: completed |
| 10:47.10 | koen | XorA: didn't you have a quad? |
| 10:47.31 | XorA | koen: lrg over estimated :-) |
| 10:47.36 | CIA-9 | 03rpurdie 07org.oe.packaged-staging * r8e6d405d... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: Remove some debug, fix LIST_CMD to run on STAGING_DIR |
| 10:50.25 | koen | ~dict clobber |
| 10:52.42 | CIA-9 | 03koen 07org.oe.packaged-staging * r0c381b1c... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: introduce PSTAGE_MODE |
| 10:56.31 | koen | NOTE: package glibc-2.4-r10: task do_populate_staging: started |
| 10:58.25 | koen | RP: with depchains working PSTAGE_MODE = 'repopulate' would just install the generated packages and let the package manager pull in the rest, right? |
| 10:59.17 | RP | koen: If the staging packages can trigger the dep chain code |
| 10:59.29 | RP | koen: NOTE: package nano-1.3.9: completed |
| 11:00.24 | hrw|work | someone want to update nano to 1.9.99pre2? |
| 11:00.55 | *** join/#oe bluelightning (n=blueligh@125-237-75-10.jetstream.xtra.co.nz) |
| 11:01.21 | koen | RP: I knew I was forgetting something :( |
| 11:01.45 | RP | koen: We can reuse the code though |
| 11:02.15 | zecke | gosh I'm still pissed :} |
| 11:02.33 | koen | pissed as in drunk or as in angry? |
| 11:02.53 | zecke | sadly drunk |
| 11:08.07 | hrw|work | ~seen Crofton |
| 11:08.27 | ibot | crofton is currently on #casualti (1d 12h 18m 6s) #ol (1d 12h 18m 6s) #oe (1d 12h 18m 6s) #elinux (1d 12h 18m 6s). Has said a total of 13 messages. Is idling for 14h 14m 22s, last said: 'good movie'. |
| 11:13.50 | *** join/#oe ts____gin (n=gints@62.84.15.211) |
| 11:18.37 | koen | RP: are the pkgmaps getting generated with your build? |
| 11:19.42 | RP | koen: Just for glibc and gcc |
| 11:20.02 | koen | with bitbake trunk? |
| 11:20.10 | RP | koen: yes |
| 11:20.14 | koen | hmmm |
| 11:21.54 | RP | koen: I'm not sure the spawn files are though |
| 11:22.22 | koen | right |
| 11:22.32 | koen | that's what I feared |
| 11:23.16 | koen | and that's what I'm seeing here |
| 11:23.42 | RP | The other pkgmaps data is getting generated though |
| 11:24.10 | koen | I suspect the PACKAGE_FUNC stuff isn't working in p-s.bbclass |
| 11:24.43 | RP | perhaps it needs to inherit package,bbclass? |
| 11:25.25 | koen | I guess so |
| 11:27.14 | zecke | koen: check package.bbclass for PACKAGE_FUNC = vs. += vs. ?= |
| 11:27.58 | koen | PACKAGEFUNCS = " |
| 11:28.32 | RP | It should inherit package.bbclass, then it makes sure it can append to that variable |
| 11:28.45 | zecke | RP: but instead of appending you are overwriting :) |
| 11:28.48 | koen | 'inherit package' doesn't fix it |
| 11:28.49 | zecke | ~lart kergoth |
| 11:29.22 | RP | koen: hmm :-/ |
| 11:29.49 | zecke | koen: make it ?= again |
| 11:29.57 | koen | http://rafb.net/paste/results/C9Lmvh50.html |
| 11:30.23 | zecke | then you have these methods n time invoked |
| 11:30.38 | zecke | koen: e.g. if you have insanity, package_ipk and package_tar there |
| 11:30.50 | zecke | you call these methods a lot of times |
| 11:31.09 | zecke | and you have insanity's package func called before the package installs :) |
| 11:32.26 | RP | I was thinking the class handling was clever :). We need ?= in there as zecke says |
| 11:32.46 | zecke | RP: and it was there before kergoth messed with it :) |
| 11:32.50 | koen | http://rafb.net/paste/results/pbo9ae55.html |
| 11:33.01 | hrw|work | ~lart samba shares, monotone, sqlite for not cooperating |
| 11:33.08 | zecke | RP: but koen had one problem in the packaged staging branch |
| 11:33.31 | zecke | koen: what does your package.bbclass look like in the branch? |
| 11:34.06 | RP | zecke: I merged in the changes from .dev to the best of my abilities and have evidently broken it |
| 11:34.12 | koen | zecke: http://www.openembedded.org/filebrowser/org.openembedded.packaged-staging/classes |
| 11:34.25 | CIA-9 | 03koen 07org.oe.packaged-staging * rd669a2fc... 10/ (1 classes/package.bbclass classes/packaged-staging.bbclass): |
| 11:34.25 | CIA-9 | classes/packaged-staging.bbclass: inherit package |
| 11:34.25 | CIA-9 | classes/package.bbclass: use ?= for PACKAGEFUNCS |
| 11:34.43 | RP | zecke: What was the problem? |
| 11:34.45 | zecke | koen: you should have plucked that ;) |
| 11:34.51 | zecke | RP: I don't remember :) |
| 11:36.09 | RP | at least this highlights exactly what we need to change to get things working in .dev :) |
| 11:36.28 | koen | it was ?= in .dev a while ago |
| 11:36.39 | CIA-9 | 03koen 07org.oe.dev * r421c01eb... 10/ (1 classes/package.bbclass): |
| 11:36.39 | CIA-9 | classes/package.bbclass: use ?= for PACKAGEFUNCS *again* |
| 11:36.39 | CIA-9 | * people should really watch out with introducing regressions |
| 11:36.43 | koen | but it seems kergoth merged in poky's classes into OE |
| 11:37.08 | RP | koen: yes :-/ |
| 11:37.09 | zecke | koen: right, my fault. I bitched him and he said he need to wake up first. I didn't bicth him again |
| 11:37.45 | *** join/#oe likewise (n=chatzill@atwork-98.r-212.178.104.atwork.nl) |
| 11:39.44 | hrw|work | "Your best defense is to not use SQLite for files on a network filesystem." :( |
| 11:39.59 | koen | hey likewise |
| 11:40.06 | hrw|work | hi likewise |
| 11:40.14 | likewise | hi fooks |
| 11:41.11 | koen | RP: so p-s effectively didn't run today |
| 11:41.45 | RP | koen: It did at least package everything |
| 11:41.51 | koen | :) |
| 11:51.06 | zecke | RP: I feel forced to rewrite tinderbox3 :( |
| 11:52.21 | *** join/#oe TheCan (n=thecan@dslb-084-056-129-143.pools.arcor-ip.net) |
| 11:54.42 | RP | zecke: :-( |
| 11:54.43 | *** join/#oe kerwood|afk (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
| 11:55.11 | RP | zecke: I suspected that might be unavoidable :-( |
| 11:56.21 | RP | I suspect packaged staging and the packaged staging fetcher is going to have some interesting implications for bitbake trunk's taskdata/runqueue as well :-/ |
| 11:56.31 | NAiL | gah |
| 11:57.00 | zecke | RP: has o-hand.com done anything in regard to creating a tinderbox? It would be nice to see your requirements |
| 11:57.20 | NAiL | http://bugs.openembedded.org/show_bug.cgi?id=1447 <-- diet-x11 fails to build on hosts without X |
| 11:57.38 | RP | zecke: We've discussed the fact we need one and disucssed the requirements (i.e. why we need it and what it would be needed to do) |
| 11:58.15 | RP | zecke: mallum is still of the opinion that there is software out there we can use though. Personally, I think we'll probably have to create something |
| 11:58.26 | RP | or seriously modify something |
| 11:59.11 | koen | another point for OEDEM |
| 11:59.26 | RP | Yes, this one would be a good one to talk about in person |
| 12:00.26 | koen | a real neat feature would be to have some form of 'hidden' report |
| 12:00.28 | koen | s |
| 12:00.32 | hrw|work | NAiL: maybe we need kind of diet-x11/do_stage_headers() before do_configure? |
| 12:00.49 | koen | that way OE-core can monito breakages in super-secret IHV projects |
| 12:01.01 | koen | zecke: you might want to poke CELF about that as well |
| 12:01.38 | hrw|work | speaking about celf.. |
| 12:01.53 | NAiL | hrw|work: the missing headers are already in staging |
| 12:01.54 | hrw|work | koen: they have firewall blocked so no monotone |
| 12:02.05 | koen | hrw|work: that's a nonsense excuse |
| 12:02.05 | NAiL | diet-x11 just looks in the wrong place |
| 12:03.10 | koen | hrw|work: since mtn can work over file, ssh and http as well |
| 12:03.39 | hrw|work | koen: I will test that ways and will suggest better way for them |
| 12:04.10 | koen | hrw|work: tell them to open 1 (one) port in the firewall |
| 12:04.14 | koen | it's not that hard |
| 12:04.39 | RP | koen: It depends on the company... |
| 12:04.45 | XorA | iptable -A INPUT -p tcp --dport XXXX -j ACCEPT :-) |
| 12:05.14 | koen | if they are too incompetent to do that we could even give celf an account on oe.org so they can portforward over ssh |
| 12:05.49 | RP | koen: Its not incompetance thats the problem, its IT people' |
| 12:05.52 | RP | s policies |
| 12:05.56 | koen | or install stunnel/tor/whatever |
| 12:06.53 | koen | RP: right, so they want an OE test harness, but don't want it at the same time |
| 12:07.46 | koen | as you might have noticed, I'm too pragmatic to respect such policies |
| 12:08.42 | koen | just like those bogus disclaimers added to emails |
| 12:08.49 | RP | koen: Some of the people will want that, others will want network security. I'm not saying its right, but having been there, I know what trying to get policies changed can be like |
| 12:10.01 | koen | I've worked for a company where employees discovered 'poledit.exe' |
| 12:10.39 | koen | my desk was between the helpdesk and the techs |
| 12:10.39 | likewise | They can open the port from specific source IP addresses. |
| 12:10.43 | likewise | from=for |
| 12:11.05 | koen | you should have heard the curses flying by |
| 12:11.19 | RP | koen: Thats been around for years. It brings back good memories of the school network :) |
| 12:12.18 | hrw|work | what is poledit? I'm not familiar with MS Windows world |
| 12:12.34 | koen | poledit allows you to lock down windows |
| 12:12.53 | RP | or open it up again if not locked down properly :) |
| 12:12.54 | koen | hide drives, make the registry RO, etc |
| 12:13.39 | hrw|work | ah |
| 12:13.40 | koen | you can't secure around removing the tokenring plug and having a disk with poledit |
| 12:15.10 | XorA | first thing to set in global policy is do not allow local policy :-) |
| 12:15.23 | RP | koen: These machines had passworded BIOS and would only boot from the network via a BOOTROM on the network card, just to make life interesting |
| 12:15.45 | zecke | tmbinc_: you rock!!! |
| 12:15.54 | koen | RP: our school had something like that as well |
| 12:15.57 | XorA | RP: just what a zaurus with bootp is designed to hack |
| 12:16.16 | koen | RP: but bios passwords are easily cracked via userspace :) |
| 12:16.18 | CIA-9 | 03nail 07org.oe.dev * r86d76364... 10/ (3 files in 3 dirs): busybox: Fix slugos initscript to prevent dhcp server starvation. Closes oe bug #1417 |
| 12:16.41 | XorA | koen: also all Phoenix and Award BIOS have "default" password until a couple of years ago |
| 12:17.03 | koen | XorA: yep, they had when I was in highschool :) |
| 12:17.32 | RP | They'd had the sense to change that on these... |
| 12:17.44 | koen | they where pretty surprised when systems suddenly booted into linux |
| 12:18.09 | RP | They also had the A-Level CompSci students helping with security... |
| 12:18.11 | koen | bypassing their overpriced 'security cards' they installed |
| 12:19.05 | koen | when I had to do CS courses in my second year I used e16 as a WM over remote X :) |
| 12:19.30 | hrw|work | harder beasts are machines which lack any storage and have usb ports glued to not allow any external storage connected |
| 12:19.34 | koen | much better as the default RH6 wm |
| 12:21.05 | RP | hrw|work: back then, I didn't have USB disks or a Z to play with the network with. Just lots of floppy disks... |
| 12:24.50 | *** join/#oe Varoudis (n=dmn@87.203.169.178) |
| 12:30.06 | koen | zecke: new toy? |
| 12:31.09 | hrw|work | dreambox is nice toy (if you have DVB) |
| 12:32.33 | suihkulokki | and parse .de |
| 12:33.27 | suihkulokki | ups, nevermind, in mixed dbox2 and dreambox |
| 12:44.06 | RP | rmk just accepted the cxx00 qvga patch :) |
| 12:45.42 | hrw|work | great |
| 12:47.00 | Gerrath | I've compiled glibc 2.4 with nptl support in OE but I've noticed pthread_kill() is missing from its header. I did a search and pthread_kill() is part of the POSIX standard so it should be there. DirectFB uses pthread_kill() so it won't compile.. has anyone else run into this issue? |
| 12:47.25 | Gerrath | s/header/header files |
| 12:49.03 | *** join/#oe Marex (n=Marex@213.194.240.165) |
| 12:53.00 | koen | I have this: |
| 12:53.02 | koen | ork/armv5te-angstrom-linux-gnueabi/glibc-2.4-r10/glibc-2.4/conform/data/signal.h-data:157:function int pthread_kill (pthread_t, int) |
| 12:53.03 | koen | work/armv5te-angstrom-linux-gnueabi/glibc-2.4-r10/glibc-2.4/nptl/pthreadP.h:433:extern int __pthread_kill (pthread_t threadid, int signo); |
| 12:53.03 | koen | work/armv5te-angstrom-linux-gnueabi/glibc-2.4-r10/glibc-2.4/nptl/sysdeps/pthread/bits/sigthread.h:36:extern int pthread_kill (pthread_t __threadid, int __signo) __THROW; |
| 12:55.26 | Gerrath | koen, when I did a grep of staging/include no hits came up for pthread_kill() |
| 12:56.08 | koen | RP: we could that the 'stage-manager' thing a bit futher by renaming pstage to 'stage-left' :) |
| 12:56.52 | RP | koen: :) |
| 12:57.11 | koen | *still generating locales* |
| 12:58.21 | hrw|work | Crofton: current linux-omap1 git builds without problems |
| 12:58.25 | chouimat | morning |
| 12:58.32 | Crofton | good :) |
| 12:58.38 | Gerrath | koen, I grep'd the work directory of glibc as well and got the same thing as you, but why is there nothing in the staging area? Wouldn't it need to be there for an app to link against? |
| 12:58.43 | Crofton | I can build bs image fine atm |
| 12:58.50 | koen | hey chouimat |
| 12:58.53 | Crofton | I'll try flashing later today |
| 12:59.09 | koen | Gerrath: I'm compiling glibc atm, so I don't have anything in staging |
| 12:59.16 | hrw|work | hi Crofton chouimat |
| 12:59.33 | hrw|work | Crofton: still no 2.6.18-omap1 ;( |
| 12:59.52 | hrw|work | Crofton: do you remember how long after 2.6.17 was 2.6.17-omap1 released? |
| 13:00.17 | Crofton | no |
| 13:00.19 | Gerrath | koen, ok can you ping me when it has compiled and let me know what your results are for grep'ing pthread_kill in the staging area? |
| 13:00.33 | koen | Gerrath: sue |
| 13:00.35 | koen | sure* |
| 13:00.36 | Gerrath | koen, thanks. |
| 13:01.31 | hrw|work | Crofton: 2-4 weeks it looks |
| 13:01.33 | hrw|work | brb |
| 13:05.53 | *** join/#oe cyn_ (n=cyn@cpe-066-057-046-006.nc.res.rr.com) |
| 13:17.09 | CIA-9 | 03koen 07org.oe.packaged-staging * r067e01b9... 10/ (1 classes/packaged-staging.bbclass): packaged-staging.bbclass: don't abort when there are no .la files in staging |
| 13:17.38 | koen | RP: another bug fixed :) |
| 13:17.51 | RP | koen: nice :) |
| 13:18.07 | hrw|work | re |
| 13:18.31 | hrw|work | Crofton: if you will get board booting then can you add fixed-rev git version? |
| 13:18.46 | koen | Gerrath: indeed no pthread_kill in staging |
| 13:19.07 | RP | koen: One thing to note - currently stage-manager copies the files out of staging to package and when it installs the package, it overwrites them. It might be cleaner to move the files? |
| 13:19.31 | Gerrath | koen, I grep'd the glibc binary lib files in the staging area, pthread_kill had a hit so it is in the lib.. I then just added an external reference to pthread_kill in the staging area glibc header. Directfb now compiles with out any issue, so the problem seems to be a missing or incomplete glibc header. |
| 13:19.54 | koen | RP: yes, that would be cleaner |
| 13:20.12 | RP | koen: It just needs s/cp/mv/ and testing :) |
| 13:21.27 | Gerrath | koen, I'll submit a bug. |
| 13:26.15 | koen | RP: /media/hda4/OE/build/tmp-new/angstrom/cross/lib/gcc/arm-angstrom-linux-gnueabi/4.1.1/../../../../arm-angstrom-linux-gnueabi/bin/ld: skipping incompatible /lib/libc.so.6 when searching for /lib/libc.so.6 |
| 13:26.41 | koen | RP: it looks like we need to sed libc.so :( |
| 13:29.47 | hrw|work | hi CoreDump|home |
| 13:32.26 | Gerrath | koen, glibc bug report http://bugs.openembedded.org/show_bug.cgi?id=1448 |
| 13:36.56 | zecke | did anyone upgrade to edgy yet? |
| 13:37.24 | *** join/#oe joshin (i=josh@VDSL-130-13-154-27.PHNX.QWEST.NET) |
| 13:37.29 | koen | zecke: nope, seeing that they still manage to break dapper on a weekly base :( |
| 13:40.29 | *** join/#oe csmanx (n=csman@rak-pang.oz.com) |
| 13:40.57 | *** join/#oe leoncamel (i=leoncame@gateway/tor/x-97a66aa7e39617fc) |
| 13:41.41 | leoncamel | hi, folks. ;) |
| 13:42.09 | koen | hey leoncamel |
| 13:43.10 | leoncamel | koen, :). I am enjoying my holidays here, in China. So, how is OE going on ? |
| 13:44.17 | hrw|work | hi leoncamel |
| 13:44.26 | koen | we are close to having packaged-staging working |
| 13:44.39 | leoncamel | koen, you commit some patch on class/*.bbclass ? |
| 13:44.54 | leoncamel | hrw|work, hey. :) |
| 13:45.27 | leoncamel | koen, so, what is the problem ? what can I do for you ? |
| 13:46.11 | *** join/#oe Sleep_Walker (n=Sleep_Wa@r5bm116.net.upc.cz) |
| 13:47.44 | leoncamel | koen, I mean, I can do some basic test case for you .. :) |
| 13:53.36 | CIA-9 | 03koen 07org.oe.packaged-staging * r0ca9b992... 10/ (1 classes/packaged-staging.bbclass): |
| 13:53.36 | CIA-9 | packaged-staging.bbclass: fixes |
| 13:53.36 | CIA-9 | * blacklist dbg, gconf and charmap packages |
| 13:53.36 | CIA-9 | * fix up libc.so linker script with sed |
| 13:53.37 | koen | leoncamel: not at the moment |
| 13:54.00 | leoncamel | koen, :). you are always welcome.. |
| 13:54.15 | koen | RP: libogg compiles now :) |
| 13:54.29 | koen | RP: and s/cp/mv/ seems to be working as well |
| 13:56.18 | RP | koen: ok, that's good. It was just a cp at first as I didn't want to destroy things too much whilst making the script work :) |
| 13:56.47 | RP | koen: Why did we never see the libc problem before? |
| 13:57.20 | koen | RP: because do_stage did a *extra* 'make install' |
| 13:58.10 | RP | koen: Should it do two make installs? |
| 13:58.26 | koen | IMO not |
| 13:58.39 | koen | but the whole glibc stuff in OE is pretty arcane and obfuscated |
| 13:59.08 | RP | glibc is an area I stay away from... |
| 13:59.24 | chouimat|busy | http://www.extremeironing.com/ <--- sound like a fun thing to do :) |
| 14:03.56 | leoncamel | who is maintaining bitbake now ? |
| 14:06.17 | RP | leoncamel: Some combination of zecke and myself I guess |
| 14:13.05 | *** join/#oe tmbinc (i=abcd@e176137156.adsl.alicedsl.de) |
| 14:13.52 | CIA-9 | 03koen 07org.oe.packaged-staging * r2031ff65... 10/ (1 contrib/scripts/stage-manager): contrib/scripts/stage-manager: use 'mv' instead of 'cp' |
| 14:15.54 | Crofton | could you write parts of bb in c/c++ and use swig to call them from python? |
| 14:15.59 | leoncamel | koen, how many disk it would use ? |
| 14:16.20 | koen | leoncamel: not much, there are very few recipes present |
| 14:16.38 | koen | hrw|work: what's the status of rm_work? |
| 14:17.39 | *** join/#oe zecke (n=freyther@88.134.98.23) |
| 14:17.51 | zecke | mickeyl: ping |
| 14:18.22 | koen | RP: apart from the threading issues packaged-staging.bbclass is looking pretty nice for .dev |
| 14:19.30 | hrw|work | koen: basically it works but need one change in bitbake addtask to be really working ok |
| 14:19.51 | hrw|work | koen: now you can get hit by do_deploy() after do_rm_work() |
| 14:19.55 | *** join/#oe furlongm (n=furlongm@193.1.232.237) |
| 14:20.25 | koen | hrw|work: I was thinking of making angstrom inherit it |
| 14:20.48 | koen | to avoid the 'OMG DISKSPACE LOL' FUD |
| 14:21.22 | hrw|work | koen: enable it first and do builds - if any fail then you will know why it is not safe often |
| 14:21.38 | Genesis | to gain some diskspace |
| 14:21.44 | koen | hrw|work: right |
| 14:21.50 | Genesis | i write a little bash script for my team , |
| 14:22.07 | Genesis | that create an OE env for one or more project |
| 14:22.14 | hrw|work | Genesis: rm_work is simple shell script which remove all WORKDIR after building |
| 14:22.26 | Genesis | mine is different |
| 14:22.35 | Genesis | that create a personnal tmp dir |
| 14:22.43 | *** join/#oe hvontres|poodle (n=henry@63.92.216.147) |
| 14:22.49 | hrw|work | koen: some recipes would need patching to work with rm_work |
| 14:22.49 | Genesis | i paste it you'll see if you're interessting |
| 14:22.54 | hrw|work | Genesis: pastebin it |
| 14:22.59 | hrw|work | hi hvontres |
| 14:23.04 | koen | RP: can we make packaged-stage output something like "installing foo to ${STAGING_BASEDIR}", like package.bbclass does? |
| 14:23.06 | Genesis | i'll commit it when it 'll be finish |
| 14:23.51 | hvontres|poodle | hi hrw|work |
| 14:24.04 | RP | koen: I don't see why not - just add an oenote ? |
| 14:24.26 | koen | RP: doesn't oenote only work in python methods? |
| 14:24.29 | Genesis | http://code.bulix.org/45eiv2-18965 |
| 14:24.37 | Genesis | the idea is to have a official tree |
| 14:24.54 | Genesis | and work with a team |
| 14:25.17 | Genesis | i would like to rewrite it in a bbclass , but there is not a lot of documentation |
| 14:25.26 | RP | koen: I think it has shell script hooks |
| 14:25.43 | RP | koen: Or perhaps I'm confused |
| 14:25.47 | koen | RP: I remember something the shell version not working |
| 14:25.56 | koen | i.e. only outputting to the logs, not the sceen |
| 14:25.59 | koen | screen* |
| 14:26.14 | RP | Ah, I can understand that with the pipe redirection bitbake uses |
| 14:27.10 | hrw|work | Genesis: yep.. it is much larger thing |
| 14:28.04 | Genesis | it's useful for me :) |
| 14:28.14 | Genesis | and for my teamate i hope |
| 14:30.02 | zecke | BTW: anyone has used django? |
| 14:38.05 | koen | so far only pkgconfig (non-native) b0rked |
| 14:40.18 | RP | koen: How did that break? |
| 14:41.42 | koen | | testgthread.o: In function `test_private':testgthread.c:(.text+0x3dc): undefined reference to `pthread_join'| ./.libs/libgthread.al(gthread.lo): In function `g_private_set_posix_impl':gthread.c:(.text+0x1c4): undefined reference to `pthread_setspecific' |
| 14:42.29 | hrw|work | ~lart konqueror for hanging |
| 14:42.32 | koen | OE's copy of pkgconfig is ancient, mind you |
| 14:42.45 | zecke | koen: http://www.djangoproject.com/documentation/syndication/ |
| 14:42.54 | zecke | I think I will use django for OEs tinderbox |
| 14:43.22 | koen | cute |
| 14:48.11 | hrw|work | my website now looks nice on phones or other limited devices |
| 14:48.57 | koen | zecke: it even recommends using postgres :) |
| 14:49.18 | hrw|work | mickeyl: http://imthi.com/wp-pda/ |
| 14:49.41 | *** join/#oe CosmicPenguin (i=nobody@nat/amd/x-c6d4030a2a6195fe) |
| 14:54.40 | zecke | koen: I think it looks really good |
| 14:55.48 | koen | django was hot a year ago |
| 14:55.54 | koen | it seems to have matured since then |
| 14:57.25 | koen | RP: what's the next step for p-s? |
| 14:58.06 | koen | RP: integrating it with depchains? making it packageformat agnostic? |
| 14:58.32 | hrw|work | koen: build world? |
| 14:58.58 | koen | hrw|work: only pkgconfig and qemu failed in the packaged-staging branch with 'bitbake world -k' |
| 14:59.31 | RP | koen: good question - adding in the depchains support would certain be good to get the other mode of staging you want working |
| 14:59.59 | koen | RP: the -dev packages already should have the appropriate RRECOMMENDS |
| 15:00.57 | mickeyl | zecke: pong |
| 15:01.02 | RP | koen: but the staging packages are separate from the normal generated packages? |
| 15:01.03 | mickeyl | hrw|work: that's pretty cool |
| 15:01.14 | hrw|work | mickeyl: yep |
| 15:03.01 | koen | RP: ah, right you meant the native and cross ones |
| 15:03.19 | zecke | mickeyl: have you looked into django yet? |
| 15:03.54 | mickeyl | zecke: no, that's new to me |
| 15:04.44 | RP | koen: I've just missed part of the way this all works :) |
| 15:05.12 | RP | koen: If we can ensure the -dev package brings in all the depends, we're probably ok |
| 15:05.28 | koen | RP: that part should already be in OE |
| 15:05.38 | koen | RP: that's the commit with all the regressions..... |
| 15:05.39 | RP | koen: I suspect we need an ALLOW_EMPTY_${PN}-dev = "1" |
| 15:10.22 | Crofton | mtn 0.30 is reallly fast |
| 15:15.18 | *** join/#oe furlongm (n=furlongm@193.1.232.237) |
| 15:15.43 | zecke | furlongm: hey, you had some questions? |
| 15:16.12 | *** part/#oe Sleep_Walker (n=Sleep_Wa@r5bm116.net.upc.cz) |
| 15:16.18 | furlongm | zecke: yep, but still cleaning up after akademy, so it'll be a few days before i get back to normal stuff |
| 15:16.55 | zecke | furlongm: at least I remember the friday :) |
| 15:17.23 | zecke | be back later |
| 15:22.13 | hrw|work | 17:22 hrw@work:hrw$ apt-cache search wake on lan |
| 15:22.13 | hrw|work | emacs-goodies-el - Miscellaneous add-ons for Emacs |
| 15:22.21 | hrw|work | emacs roxx |
| 15:22.26 | Crofton | njs, faking configure to allow monotone compilation against boost 1.32.0 didn't work |
| 15:23.43 | koen | Crofton: that's why venge.net/monotone was a lot of static binaries :) |
| 15:24.53 | Crofton | hmmm |
| 15:25.03 | Crofton | I may have to pick one up :) |
| 15:25.37 | *** join/#oe hvontres|poodle (n=henry@68.120.74.196) |
| 15:27.47 | *** join/#oe goxboxlive (n=jrs@9.80-202-160.nextgentel.com) |
| 15:34.53 | goxboxlive | koen: Even though i moved over to Angstrom from Familiar diet-x11 and libx11 failes. Any idea why? http://pastebin.ca/188837 |
| 15:35.17 | koen | goxboxlive: did you clean tmp/ ? |
| 15:35.26 | goxboxlive | no |
| 15:35.37 | goxboxlive | I'll try that. thx |
| 15:36.01 | koen | NAiL: did you find a fix for the diet-x11 header problem already? |
| 15:39.05 | *** join/#oe pH5 (n=ph5@e178223056.adsl.alicedsl.de) |
| 15:40.32 | koen | hey pH5 |
| 15:40.47 | koen | pH5: what are your thought on making llh 2.6.18 the default? |
| 15:40.52 | pH5 | hey koen |
| 15:41.16 | pH5 | I had some problems building util-linux which I couldn't resolve yesterday. |
| 15:41.22 | koen | same here |
| 15:41.24 | pH5 | something fdisk / llseek related |
| 15:43.32 | pH5 | I'd like to at least build one full angstrom bootstrap image before making 2.6.18 default for everyone |
| 15:45.29 | pH5 | atm it looks like installing the full asm/unistd.h and removing the __KERNEL__ #ifdef would bring us to the state we had with '2.6.15.99' |
| 15:47.24 | koen | pH5: that'd be neat |
| 15:47.35 | koen | pH5: could you also check in the task-base stuff? |
| 15:48.39 | hrw|work | cu |
| 15:48.44 | koen | hrw|gone: cu |
| 15:51.26 | *** join/#oe tkp (n=tom@81-86-55-16.dsl.pipex.com) |
| 15:51.28 | tkp | hey.. |
| 15:51.34 | tkp | anyone know what's up with xcalibrateext_git.bb? |
| 15:51.44 | tkp | sources can't be found |
| 15:51.55 | tkp | how come it's now _git rather tan _csv? |
| 16:02.12 | pH5 | koen: task-base, that is the ipaq-pxa270 kernel module stuff? |
| 16:06.57 | *** join/#oe cyrilRomain (n=cyrilRom@AToulouse-157-1-62-88.w86-207.abo.wanadoo.fr) |
| 16:08.00 | *** join/#oe BobOfDoom (i=ato@2002:3d45:a3:0:0:0:0:1) |
| 16:08.08 | *** join/#oe SD840_ (n=lookback@ANancy-157-1-71-103.w86-213.abo.wanadoo.fr) |
| 16:09.10 | zecke | http://rafb.net/paste/results/iUWsfO35.html ideas? |
| 16:14.56 | RP | zecke: If its tbox3 compatible, can we deal with information about the tasks concurrently? (i.e. when multithreading) |
| 16:15.20 | zecke | RP: who needs multithreading anyway? |
| 16:15.20 | RP | zecke: Also, will it be able to help isolate failures by MACHINE, DISTRO, PN, task ? |
| 16:15.30 | RP | zecke: me ;-) |
| 16:15.46 | koen | pH5: yes, the module stuff |
| 16:16.07 | zecke | RP: oh well the idea is. That each task gets reported individually. So MACHINE, DISTRO, PN, PV, PR, TASK |
| 16:16.25 | zecke | RP: gets reported as the HTTP header (but this works today as well) |
| 16:16.48 | koen | zecke: run tests in qemu? |
| 16:16.51 | zecke | RP: my tinderbox will allow to 'compose' one long log file from all tasks |
| 16:17.24 | zecke | koen: well. You can do two things. We allow some people to upload images/ipk's |
| 16:17.52 | *** join/#oe pleemans (n=peter@d51A5E421.access.telenet.be) |
| 16:17.53 | zecke | koen: other boxes can use them and test and post results refering to the original upload |
| 16:18.11 | koen | zecke: right, but only images built by a tbox run, right? |
| 16:18.36 | koen | zecke: or signed using some key so scriptkiddies won't upload forkbombs, etc |
| 16:18.37 | zecke | koen: e.g. RP builds poky, I download and run it |
| 16:19.53 | koen | zecke: RP's tinderclient builds poky and uploads it and it get run? |
| 16:20.19 | zecke | koen: I could have a n770 sitting here and could flash+run the image |
| 16:20.23 | koen | zecke: you'd want to have a (co)relation between images and builds |
| 16:20.35 | zecke | koen: and have a predefined testing procedure and report it |
| 16:20.53 | CIA-9 | 03pH5 07org.oe.dev * r9482aba3... 10/ (4 files in 3 dirs): linux-libc-headers-2.6.18: don't sanitize the secret kernel syscall macros away, util-linux wants them |
| 16:21.08 | zecke | koen: see above. I download the image from one RUN. And do the testing. When reporting I refer to the original build |
| 16:21.19 | zecke | koen: I think that is good enough |
| 16:21.47 | koen | right |
| 16:22.47 | koen | ideally it knows about scm's as well |
| 16:22.48 | RP | zecke: If those things are part of the header, that should mean multithreading should work, unless tinderbox makes assumptions about task orders? |
| 16:22.57 | koen | or at least about 'revisions' |
| 16:23.46 | RP | Does anyone have any thoughts on the profile graph I posted? |
| 16:24.00 | RP | 3.5% seemingly in os.path.join? :-/ |
| 16:24.01 | zecke | RP: current tbox3 just apppends :) |
| 16:24.14 | zecke | RP: posted to mailing list? |
| 16:24.25 | RP | zecke: yes. bitbake and oe |
| 16:24.38 | RP | zecke: in reply to Pauls mail (bitbake past, present and future) |
| 16:24.42 | koen | zecke: http://rafb.net/paste/results/PthFQf27.html |
| 16:24.50 | zecke | koen: SCM's. Which SCM's OE?, BitBake? the ones we build? |
| 16:25.07 | Crofton | RP write bits of bb in c/c++ and use swig to extract python wrappers |
| 16:25.12 | koen | or http://lists.linuxtogo.org/pipermail/openembedded-devel/2006-October/000483.html |
| 16:25.23 | koen | zecke: the ones that contain OE trees |
| 16:25.40 | koen | zecke: right now that's svn and mtn |
| 16:26.04 | koen | so you'd send 'svn status' and 'mtn automake get_base_revision_id' |
| 16:27.32 | zecke | RP: hmm. feeder is quite low |
| 16:29.12 | zecke | RP: oh well. I think the proper way would be to reduce the number of data calls |
| 16:29.38 | RP | zecke: right, the problem is in the dataclass and as we can speed it up, we need to reduce calls or cache things |
| 16:29.46 | Genesis | bye |
| 16:29.51 | RP | s/can/can't/ ! |
| 16:29.51 | zecke | RP: e.g. mithro said that our string concatinations are really slow. If we do them less, or use stringbuffer we get around them |
| 16:30.28 | RP | zecke: which string concatinations? you mean things like "foo" + "bar" ? |
| 16:30.45 | *** join/#oe zap (n=zap@85.249.170.16) |
| 16:31.02 | zecke | RP: yes. and even getVar() + "new val" |
| 16:31.18 | zecke | RP: there might be a way to avoid this in the parser |
| 16:31.27 | RP | zecke: What worries me - 3.5% in os.path.join... |
| 16:31.42 | zecke | RP: that was from files_path? |
| 16:31.54 | RP | zecke: quite possibly, I don't know |
| 16:32.07 | RP | filespath is certainly featuring on that list though |
| 16:32.12 | *** join/#oe kerwood|afk (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
| 16:32.47 | zecke | RP: you use hotshot for profiling right? |
| 16:33.01 | zecke | RP: you can easily sort by callers? e.g. show me everyone which called os.path.join |
| 16:33.11 | RP | zecke: maybe not. I just ran import profile |
| 16:33.56 | *** join/#oe incinerator (n=sabine@82-41-24-164.cable.ubr04.edin.blueyonder.co.uk) |
| 16:33.59 | RP | These numbers were from when I fixed up taskdata |
| 16:34.43 | zecke | RP: http://rafb.net/paste/results/IOFeZO96.html |
| 16:35.35 | zecke | I think these calls can be cached easily |
| 16:36.38 | zecke | RP: and the same in BBHandler.py |
| 16:38.26 | zecke | I think by avoiding this we get 12.000 less calls of os.path.join |
| 16:38.42 | CosmicPenguin | twelve thousand? |
| 16:38.49 | RP | zecke: That would be a very good start :) |
| 16:39.04 | zecke | CosmicPenguin: simple math/guess |
| 16:39.08 | CosmicPenguin | holy nuts |
| 16:39.11 | RP | CosmicPenguin: That run shows over 200,000 calls to os.path.join :-/ |
| 16:39.20 | zecke | CosmicPenguin: 4 thousand .bb files |
| 16:39.33 | zecke | CosmicPenguin: most of them parsing base.bbclass so we are at eight thousand |
| 16:39.52 | zecke | CosmicPenguin: all of them include .inc files so we are at 12 thousand |
| 16:40.14 | RP | zecke: Note that bb.data.init() was a big factor in the graph as well |
| 16:40.40 | zecke | really? |
| 16:41.12 | RP | zecke: Sorry, I'm getting confused |
| 16:41.28 | zecke | welcome :) |
| 16:41.39 | zecke | Melancholic + Nuts == average OE dev |
| 16:41.59 | CosmicPenguin | zecke: This sort of experience with python will also come in handy on OLPC.. :) |
| 16:42.08 | CosmicPenguin | They need huge optimization help |
| 16:42.10 | RP | zecke: lib/bb/__init__.py, 2100 times but its an expensive call. I wonder if we can just inherit that from OE somehow? |
| 16:42.34 | zecke | RP: oh well, I try to remember mickeyl |
| 16:42.38 | CosmicPenguin | c |
| 16:42.45 | zecke | RP: import bb is executed exactly once |
| 16:42.55 | zecke | RP: from bb import data is executed every time |
| 16:44.23 | zecke | CosmicPenguin: I have built sugar, and I failed to understand the user concept :) |
| 16:44.27 | CosmicPenguin | heh |
| 16:44.30 | zecke | CosmicPenguin: at least I found the browser and F5 |
| 16:44.32 | CosmicPenguin | At least you got it to run |
| 16:44.46 | zecke | CosmicPenguin: I have used jhbuild and it needed only one handwork |
| 16:45.02 | CosmicPenguin | zecke: I don't understand all of the services it needs |
| 16:45.19 | CosmicPenguin | I'm sure there needs to be hacking to start avahi and dbus and whatnot before sugar, but I don't understand any of that |
| 16:45.26 | koen | CosmicPenguin: are your sugar .bbs online? |
| 16:45.31 | CosmicPenguin | when you are ready, I'll send you the shi^H^H^H .bbs that you need |
| 16:45.40 | *** join/#oe woglinde (i=woglinde@e178075193.adsl.alicedsl.de) |
| 16:45.57 | CosmicPenguin | I'll try to get them online sometime soon |
| 16:47.28 | *** join/#oe ggilbert (n=ggilbert@tinman.treke.net) |
| 16:49.37 | *** join/#oe redguy (n=mati@adt129.neoplus.adsl.tpnet.pl) |
| 16:53.21 | CIA-9 | 03pH5 07org.oe.dev * rf69b3e75... 10/ (1 conf/machine/ipaq-pxa270.conf): ipaq-pxa270.conf: remove movules from PXA270_MODULES that are already accounted for in task-base |
| 16:53.32 | CIA-9 | 03pH5 07org.oe.dev * r0888a421... 10/ (1 packages/tasks/task-base.bb): task-base: add pcmcia and pxa27x_udc kernel modules to pcmcia/usbgadget-rrecommends |
| 16:55.08 | pH5 | uh, 'movules'. I hope I put those typos only into the commit messages. |
| 16:56.37 | *** join/#oe den-ros (n=den@ppp83-237-44-114.pppoe.mtu-net.ru) |
| 16:59.48 | *** join/#oe bronson (n=bronson@66.160.177.207) |
| 17:09.56 | *** join/#oe woglinde (i=woglinde@e178075193.adsl.alicedsl.de) |
| 17:25.27 | *** join/#oe andersee (n=andersee@codepoet.org) |
| 17:26.16 | woglinde | hi andersee |
| 17:26.37 | andersee | woglinde: morning |
| 17:27.01 | woglinde | hm |
| 17:27.28 | woglinde | hehe |
| 17:27.37 | woglinde | andersee manages his family |
| 17:29.04 | *** join/#oe Sleep_Walker (n=Sleep_Wa@195.22.44.103.adsl.nextra.cz) |
| 17:32.35 | koen | andersee: uclibc release? |
| 17:33.42 | CosmicPenguin | sigh - apparently 2.6.18-rc6 is newer then 2.6.18 in ipkg's world.. :( |
| 17:34.16 | koen | CosmicPenguin: right, that's why we have a versioning policy |
| 17:34.20 | CosmicPenguin | nod |
| 17:34.40 | CosmicPenguin | but that doesn't work when I stupidly roll my own |
| 17:34.42 | koen | 2.6.18rc -> linux_2.6.17+2.6.818rc.bb |
| 17:34.46 | koen | :) |
| 17:36.21 | *** part/#oe Sleep_Walker (n=Sleep_Wa@195.22.44.103.adsl.nextra.cz) |
| 17:39.49 | tkp | I'm wondering of someone can help me understand a couple of things about using the oe filesystem in read-only mode.. |
| 17:40.40 | tkp | I have the root entry set to 'defaults' in fstab - as per the default fstab |
| 17:40.54 | tkp | and I pass ro to the kernel from my bootloader |
| 17:41.15 | tkp | this seems to work ok... the root filesystem is mounted as read only |
| 17:41.31 | tkp | then the init scripts run, and somethings get remounted as rw |
| 17:41.42 | tkp | specifically /var - since it's a tmpfs |
| 17:41.53 | koen | oe filesystem? |
| 17:42.09 | *** join/#oe likewise (n=chatzill@82-171-189-134.dsl.ip.tiscali.nl) |
| 17:42.21 | tkp | koen: I mean the base filesystem that gets generated from a base checkout... |
| 17:42.24 | tkp | generic x86 |
| 17:42.41 | tkp | using prety much the stock initscripts |
| 17:42.53 | andersee | koen: keep working on it |
| 17:42.54 | tkp | ( I have disabled a couple that I don't need) |
| 17:43.14 | likewise | hello ppl |
| 17:43.17 | andersee | koen: I hope to get a needed uClibc patch sorted out today and tested |
| 17:43.26 | tkp | there is a bootmisc initscript, which is supposed to ensure that /tmp is a symlink to the tmpfs at /var |
| 17:43.46 | tkp | but my /tmp seems to be a directory, not a symlink |
| 17:44.48 | tkp | I'm just a little puzzeled as to why that is |
| 17:44.57 | *** join/#oe e-ffi (n=cybercom@dslb-084-056-065-205.pools.arcor-ip.net) |
| 17:45.50 | *** join/#oe ken (n=ken@h207n2fls302o1049.telia.com) |
| 17:46.47 | tkp | is what I'm doing (forcing a ro rootfs by passing ro as a kernel param) either a normal, or a sane way to achieve a read-only root filesystem? |
| 17:47.35 | CosmicPenguin | as long as the typically volatile filesystems are put into ram, you should be fine |
| 17:47.59 | woglinde | hi kergoth |
| 17:48.13 | pH5 | tkp: I think checkroot.sh remounts your rootfs rw if you don't explicitly put ro into the fstab, too. |
| 17:48.39 | *** join/#oe angom (n=angom@red-corp-200.79.141.244.telnor.net) |
| 17:48.49 | tkp | when that bootmisc initscript is run, it complains that / is readonly |
| 17:49.10 | tkp | which is why it's failing to ensure that /tmp is indeed a symlink to /var |
| 17:50.18 | tkp | pH5: I can see that it might do that... but it doesn't |
| 17:50.42 | tkp | my problem is the opposite... at the point when bootmisc runs, the root is readonly |
| 17:51.45 | pH5 | I wonder why that /tmp symlink has to be generated by an init script instead of during the rootfs generation. |
| 17:52.01 | tkp | pH5: I wondered the same myself |
| 17:52.43 | *** join/#oe cyrilRomain (n=cyrilRom@AToulouse-157-1-62-88.w86-207.abo.wanadoo.fr) |
| 17:55.45 | *** join/#oe wsuetholz (n=kvirc@ip205.centonline.com) |
| 17:56.54 | likewise | anyone care for some simple live bug reports to fix on the spot? |
| 17:58.49 | woglinde | he mickeyl |
| 17:59.09 | koen | likewise: maybe |
| 17:59.09 | koen | I have 30 minutes left till CSI starts |
| 17:59.10 | mickeyl | heya |
| 17:59.21 | woglinde | koen hehe |
| 17:59.21 | mickeyl | koen: will you bring your MOTO to oedem? |
| 17:59.23 | tkp | so, what's the purpose of volatile.cache |
| 17:59.25 | woglinde | here only 15 |
| 17:59.57 | tkp | since it resides in /etc (which can not be written to in a ro rootfs) |
| 17:59.57 | tkp | I think that's where my problem may lie |
| 18:00.26 | tkp | I tried symlinking that file to somwhere in /var |
| 18:00.39 | *** join/#oe bloodrunner (n=bloodrun@dialup-4.233.194.58.Dial1.Manchester1.Level3.net) |
| 18:00.40 | tkp | and looking at it, it's full of error messages |
| 18:00.41 | koen | mickeyl: yes, it's my primary phone |
| 18:00.41 | koen | mickeyl: I'll also bring the nbp if I can revive it |
| 18:00.43 | likewise | koen: #1: lzma DEPENDS on zlib (because it uses the zlib.h header during building) |
| 18:00.50 | mickeyl | koen: excellent, then i can leave mine at home. i want marcin to have a look. |
| 18:01.27 | tkp | complaining 'Failed to set owner ....' '"Failed to set mode...', I think, one for each of the thinks in volatiles |
| 18:01.38 | koen | likewise: lzma-native? |
| 18:01.48 | likewise | koen: both -native, yes. |
| 18:02.23 | likewise | koen: #2 (related) zlib-native 1.2.3 fails to stage zlib.h, 1.2.2 works fine. (1.2.3 was converted to autotools) |
| 18:02.51 | likewise | koen: EOF. |
| 18:03.08 | CIA-9 | 03koen 07org.oe.dev * rf0096d0a... 10/ (1 packages/lzma/lzma-native_4.17.bb): lzma: depends on zlib-native, spotted by Leon Woestenberg |
| 18:03.38 | *** join/#oe stevenh (n=lews@65.167.23.2) |
| 18:03.45 | koen | likewise: zlib cross works? |
| 18:03.48 | likewise | #/me goes incognito |
| 18:04.05 | likewise | koen: untried for... |
| 18:05.57 | CIA-9 | 03koen 07org.oe.dev * r0b5e6bdf... 10/ (1 packages/zlib/zlib-native_1.2.3.bb): zlib-native: stage zlib.h, spotted by Leon Woestenberg |
| 18:06.16 | koen | likewise: happy now? |
| 18:06.17 | koen | :) |
| 18:07.07 | likewise | koen: didn't need any cre^H^H^Hblame me. |
| 18:07.11 | likewise | -me |
| 18:07.30 | likewise | koen: zlib cross seems to stage OK. |
| 18:07.41 | tkp | how can bootmisc ever expect to run on a readonly filesystem? |
| 18:08.09 | tkp | since the drive is mounted as readonly in mountall |
| 18:08.15 | tkp | (which runs before) |
| 18:10.00 | CIA-9 | 03Robert 07org.oe.dev * rb4ec3864... 10/ (6 files in 4 dirs): add scsi idle: turn off SCSI disks when idle |
| 18:10.39 | koen | likewise: some extra google juice for your efforts in the embedded world can't hurt :) |
| 18:11.28 | likewise | koen: enough juice already, and the 1% increase in spam will hardly be noticable anyway :-) |
| 18:12.16 | *** join/#oe gremlin[it] (n=gremlin@ppp-117-9.25-151.libero.it) |
| 18:14.12 | likewise | koen: thanks for the quick fix. You just closed a bug report and prevented me from filing a second one :-) |
| 18:14.22 | koen | :) |
| 18:16.55 | *** join/#oe dfoley (n=dfoley@h24-207-7-221.primesignal.com) |
| 18:17.52 | *** join/#oe chouimat (n=dieu@kde/developer/chouinard) |
| 18:18.52 | *** part/#oe bloodrunner (n=bloodrun@dialup-4.233.194.58.Dial1.Manchester1.Level3.net) |
| 18:21.49 | koen | likewise: isn't it likewise, MSc nowadays? |
| 18:22.19 | likewise | koen: yes |
| 18:23.05 | *** join/#oe Crofton (n=balister@hc6521504.dhcp.vt.edu) |
| 18:23.40 | likewise | koen: finally, after all those years (computers can really be distracting, you know? ;-)) |
| 18:24.37 | *** join/#oe darkschneider (n=gab@213-140-6-96.ip.fastwebnet.it) |
| 18:25.29 | tkp | so, anyone got any ideas about this bootmisc script? |
| 18:25.52 | koen | tkp: it's buggy |
| 18:26.10 | tkp | it's buggy? so this is a known problem... |
| 18:26.21 | tkp | that it's basically impossible to use in a ro rootfs |
| 18:26.30 | koen | I didn't know of the poblem till you mentioned it tonight |
| 18:27.04 | koen | problem* |
| 18:28.55 | zecke | wow django is nice |
| 18:30.15 | ggilbert | zecke: like it? |
| 18:30.23 | ggilbert | I've been thinking of trying it out |
| 18:30.54 | zecke | ggilbert: I'm not far but currently it is promising. It allows rapid development like I know from python |
| 18:31.11 | zecke | ggilbert: just use sqlite3 and you can just start developing |
| 18:32.47 | zecke | ggilbert: I have just started and only used the model api so far |
| 18:33.11 | zecke | ggilbert: I think it will be more complicated when thinking about performance, and good queries |
| 18:34.20 | zecke | ggilbert: http://rafb.net/paste/results/iDLEUq58.html. Create the model and enter python shell and you can try your code to populate the db |
| 18:46.17 | *** join/#oe tkp (n=tom@81-86-55-16.dsl.pipex.com) |
| 18:48.07 | likewise | for those who love Eclipse(.org): http://www.mail-archive.com/monotone-devel@nongnu.org/msg05360.html |
| 18:49.31 | goxboxlive | kone: Even though i cleaned up the tmp folder, diet-x11 and libx11 failes. Here is the output: http://pastebin.ca/189016 What do i have to do to solve this? Or do you think there is a bug in the bb files? |
| 18:49.49 | goxboxlive | koen the line above this |
| 18:57.29 | goxboxlive | zecke: do you have any idea? |
| 19:00.20 | zecke | goxboxlive: not now :) |
| 19:00.31 | goxboxlive | zecke: ok |
| 19:02.46 | goxboxlive | There have to be an bug in the file or so, because booth for diet-x11 and libx11 it complains about : makekeys.c:34:19: error: X11/X.h: Ingen slik fil eller filkatalog and that means, no such file or folder. And that goes also for 'Xos.h' and 'keysymdef.h' |
| 19:12.01 | RP | tkp: I think someone optimised the /var handling for speed and perhaps didn't consider someone wanting to use the filesystem readonly |
| 19:12.27 | tkp | RP: I see... |
| 19:12.34 | koen | RP: S98configure is a killer for RO filesystems as well |
| 19:12.45 | RP | tkp: I don't know if it worked before that |
| 19:13.11 | *** part/#oe den-ros (n=den@ppp83-237-44-114.pppoe.mtu-net.ru) |
| 19:13.13 | RP | koen: Right, so some work is needed to make a working ro system :-/ |
| 19:13.13 | tkp | koen: S98 fails to run too indeed |
| 19:13.40 | tkp | but I'm much more bothered about getting /var set up correctly... with /tmp being a symlink |
| 19:13.51 | koen | RP: I think we need to get creative with qemu to solve that |
| 19:14.41 | tkp | shouldn't mountall force things to be mounted as read/write... and then let one of the other scripts remount |
| 19:14.48 | RP | koen: Indeed. A load of postinst could run on offline and don't last time I looked though :-/ |
| 19:15.16 | koen | although stuff like blueprobe need to get adjusted |
| 19:15.40 | tkp | as far as I can tell, currently mountall mounts things as specified in fstab... |
| 19:15.44 | tkp | which in my case is ro |
| 19:16.04 | tkp | hense, anything after it can not make any alterations to the filesystem |
| 19:20.14 | hrw | hi |
| 19:20.22 | koen | hrw: wb |
| 19:21.56 | tkp | anyone else fancy looking into this problem? I'm sure someone else could sort it 100 times faster than me! |
| 19:23.18 | koen | tkp: is it possible to run it once with RW? |
| 19:23.32 | CosmicPenguin | You have two options - you either make a way for the volatile directories to be written to or you spend a goodly amount of time re-writing the initscripts, which probably wouldn't work anyway because lots of things expect read-write to work |
| 19:23.39 | *** join/#oe chrisromain (n=chrisrom@AToulouse-157-1-62-88.w86-207.abo.wanadoo.fr) |
| 19:23.42 | koen | RP: could be pinch sbrsh to do the heavy lifting? |
| 19:23.50 | CosmicPenguin | Its not super difficult - I've been using read-only directories for eons |
| 19:23.55 | tkp | koen: not for a final dist |
| 19:24.26 | hrw | tkp: use tmpfs for /var/ maybe? |
| 19:24.34 | tkp | hrw: it is already... |
| 19:24.53 | koen | tkp: run it in rw once, save that and distribute it as RO |
| 19:26.01 | tkp | but the point is, it's initially mounted as read only... and since /tmp is initially a directory, and it's bootmisc that turns that into a symlink - which it can't do on a read only filesystem |
| 19:26.06 | hrw | but if you use openssh/dropbear then remember that it generate keys on first initstart |
| 19:26.31 | tkp | hrw: this is true |
| 19:26.44 | CosmicPenguin | seesh - seriously |
| 19:26.46 | CosmicPenguin | man mount |
| 19:26.48 | CosmicPenguin | read about bind |
| 19:26.50 | CosmicPenguin | seesh |
| 19:26.55 | koen | hrw: we mentioned S98configure earlier :) |
| 19:27.11 | hrw | koen: S98 is S98. dropbear generating keys is other |
| 19:27.37 | hrw | koen: I remember patch to dropbear initscript to have keys generated and whole discussion about that |
| 19:27.54 | tkp | I don't think running once in read-write is really a viable solution |
| 19:27.57 | hrw | koen: it was one of my pre-r/w patches |
| 19:28.13 | koen | right, pregenerated keys are bad |
| 19:28.39 | koen | if you pregenerate they you can stop using encyption altogether |
| 19:28.48 | koen | or design a DRM system :) |
| 19:29.06 | tkp | although, I can't really think of another way without fixing these initscripts |
| 19:32.49 | hrw | heh... why ssh hrw@{one,two,three,...,any} ends on more powerfull machines then the one I'm using |
| 19:33.41 | goxboxlive | koen: I have found the bug in the diet-x11 and the libx11. But i dont know how to handle it. |
| 19:39.27 | *** join/#oe JaMa (n=martin@njama.mk.cvut.cz) |
| 19:39.42 | hrw | git can fetch over http or not? |
| 19:40.00 | CosmicPenguin | if the server supports it, yes |
| 19:40.21 | hrw | thx |
| 19:45.14 | hrw | Crofton: how goes booting recent kernel? |
| 19:45.27 | Crofton | meetings .... |
| 19:45.36 | Crofton | I need to run an errand and come back and flash |
| 19:45.45 | Crofton | thanks for nagging :) |
| 19:45.52 | hrw | Crofton: ;) |
| 19:45.57 | hrw | Crofton: your welcome |
| 19:49.42 | *** join/#oe pvanhoof (n=pvanhoof@d54C18260.access.telenet.be) |
| 19:57.08 | *** join/#oe eno (n=eno@nslu2-linux/eno) |
| 19:57.59 | *** join/#oe W8TVI (n=me@166.166.6.243) |
| 20:04.31 | JustinP | there are union tools and such in OE... |
| 20:06.40 | likewise | JustinfP: yes, unionfs etc. |
| 20:19.53 | koen | does unionfs still oops like crazy? |
| 20:21.07 | likewise | koen: CSI done? |
| 20:21.29 | *** join/#oe kerwood|afk (n=Marshall@69-174-191-58.frdrmd.adelphia.net) |
| 20:21.43 | likewise | koen: dunno, did not hear much complaints about the more recent unionfs releases |
| 20:22.02 | likewise | s/much/many |
| 20:23.47 | ljp | kergoth: my priorities have not changed. to you it may seem like I am only speaking from TT's view, but I sit on a fence and also communicate community concerns to management. |
| 20:24.15 | koen | likewise: csi and stargate atlantis |
| 20:24.32 | zecke | ljp: hey. :) |
| 20:25.14 | koen | hrw: are zaurus users that stupid and whiny, or is it just that oesf attracts morons? |
| 20:26.36 | ljp | kergoth: also, there _will_ be a qtopia 4 gpl releases, and regular snapshot releases. I have had many discussions about this internally. |
| 20:26.54 | *** join/#oe ggilbert (n=ggilbert@tinman.treke.net) |
| 20:28.12 | zecke | ggilbert: I think I like django. The DB API is quite convient |
| 20:32.51 | mithro | OLPC? |
| 20:32.53 | mithro | hey zecke |
| 20:33.07 | koen | zecke: ping mickeyl or me if you need a mod_python enabled dir on oe.org |
| 20:33.25 | koen | zecke: and ping kergoth for a tindebox.oe.org CNAME :) |
| 20:33.41 | zecke | koen: currently it is bonsai.oe.org |
| 20:33.55 | mithro | btw you are correct, python string concat's are slow because strings are immutable |
| 20:34.20 | koen | zecke: bonsai, tinderbox, lxr, whatever |
| 20:34.34 | zecke | mithro: I would like to do tinderboxing/QA for OLPC but Jim has not responded yet |
| 20:34.38 | mithro | i really wish somebody created a "mutable string" which was in the standard library |
| 20:34.47 | mithro | whats OLPC? |
| 20:34.57 | koen | mithro: $100 laptop thingy |
| 20:35.08 | mithro | ahh |
| 20:35.28 | mithro | os.join.path is string concatination btw :P |
| 20:35.56 | RP | mithro: Is there an easy way to avoid it? |
| 20:36.18 | mithro | depends what you mean by avoid :p |
| 20:36.53 | RP | In the context of bitbake, how can we make it faster? :) |
| 20:37.07 | mithro | well I have no idea why/when bitbake is using it |
| 20:37.59 | mithro | my guess is that you shouldn't need more then 1 or 2 joins per bitbake file |
| 20:38.20 | RP | Right, I agree with that :) |
| 20:38.35 | zecke | http://rafb.net/paste/results/jzVgHf91.html my bonsai updater for SVN |
| 20:38.59 | *** join/#oe ade|desk (n=ADAVEY@213-232-83-137.dsl.prodigynet.co.uk) |
| 20:39.39 | mithro | actually, you shouldn't need any joins in parsing - only when building |
| 20:39.56 | mithro | o btw, I'm unemployed now :/ |
| 20:40.17 | zecke | <PROTECTED> |
| 20:40.31 | RP | mithro: When parsing, it does need to find files so I suspect we'll not get away without doing it |
| 20:40.38 | RP | mithro: :-( |
| 20:42.21 | mithro | actually I doubt you need to do the joins |
| 20:42.40 | mithro | finding the files is quite an easy process |
| 20:43.07 | hrw | koen: what this time? |
| 20:43.50 | mithro | no, the company i was working for layed of the whole section related to report generation (which really was just 3 days - inc me) |
| 20:44.43 | Kristoffer | any monotone guru here? |
| 20:44.51 | mithro | i've still yet to figure out how they are going to furfill their contract obligations with other companies (as they have nobody who can keep the reporting stuff going :/) |
| 20:44.58 | Kristoffer | Im having issues with trying to push stuff to my monotone server keep getting denied |
| 20:45.03 | mithro | RP: you got some profiling output? |
| 20:45.41 | RP | mithro: http://svn.berlios.de/wsvn/bitbake/trunk/bitbake/lib/bb/parse/parse_py/ConfHandler.py?op=file&rev=0&sc=0 in handle() is the kind of use we have of joins. I've never looked at the parser though |
| 20:45.49 | RP | mithro: yes, one second |
| 20:46.56 | mithro | btw - some trivial optimisations |
| 20:47.23 | RP | mithro: http://www.rpsys.net/openzaurus/temp/bitbake-profile.txt |
| 20:47.30 | mithro | "x.a.b()" is a lot slower then "b = x.a.b; b()" |
| 20:48.10 | mithro | that loop is doing things totally the wrong way |
| 20:48.45 | mithro | btw - why check if it's readable? |
| 20:48.48 | mithro | if os.access(currname, os.R_OK): ? |
| 20:49.10 | RP | The file might not exist? |
| 20:49.43 | mithro | but that error would be caught by opening it with 'r' |
| 20:50.17 | RP | is try except faster than the readable check? |
| 20:50.35 | mithro | depends on the common case |
| 20:50.48 | RP | I suspect the common case is file not found |
| 20:51.29 | mithro | then it should be an os.path.exists? |
| 20:52.21 | mithro | one way to get around a os.path.join is to do a cwd |
| 20:52.39 | hrw | RP: do you have spectrum based wifi card? |
| 20:52.44 | RP | hrw: I do |
| 20:52.48 | mithro | but in this case I think it would be slower... might be something to test |
| 20:52.52 | hrw | rm_you|: get it to oedem please |
| 20:52.59 | hrw | RP: get it to oedem please |
| 20:53.07 | mithro | it would also depend on path length |
| 20:53.15 | hrw | RP: would be nice to make small zaurus hack party too |
| 20:53.21 | mithro | the bigger the strings the slower the concat |
| 20:53.29 | RP | hrw: What's up with it? |
| 20:53.54 | hrw | RP: I do not remember does 3.5.4.2-rc2 contain everything to get it working on poodle |
| 20:54.10 | RP | mithro: BBHandler in the same directory is probably the bigger problem as we have a lot more .bb's than conf files. It has all the same problems though |
| 20:54.49 | mithro | def obtain(fn, data = bb.data.init()): |
| 20:55.02 | RP | mithro: As you can see from the profile - the biggest cpu user is expand in the data class. We really need to reduce its usage to get the most speed improvements I guess |
| 20:55.04 | mithro | are you sure you want what that line does? |
| 20:55.36 | mithro | bb.data.init() will only get called once |
| 20:56.20 | RP | mithro: It won't be called each time the function is called with that arugment missing? |
| 20:56.29 | mithro | no |
| 20:56.32 | RP | zecke? :) |
| 20:56.41 | mithro | it will be called when the function object is created |
| 20:57.35 | mithro | default arguments are bound at the time the function (object) is created |
| 20:57.38 | mithro | ie |
| 20:57.47 | RP | That is probably not what is intended but I'd ask zecke about that one... |
| 20:58.04 | mithro | def a(b, c=[]): c.append(b); print c |
| 20:58.10 | RP | hrw: I don't know about poodle - I can probably test though |
| 20:58.12 | zecke | RP: we shouldn't call this without an argument anyway :) |
| 20:58.14 | RP | it will be with me |
| 20:58.33 | zecke | RP: it is from before I have ever touched BitBake and did not want to break 'compability' |
| 20:58.35 | mithro | a('a') -> ['a']; a('b') -> ['a', 'b'] ! |
| 20:58.42 | goxboxlive | aha now libx11 and diet-x11 compiled. It needed xorg headers installed on my machine. Shouldent this in the staging folder? |
| 20:58.56 | mithro | that is a WTF which gets a lot of people |
| 20:59.26 | RP | mithro: I can see that. I didn't realise python worked like that... |
| 20:59.48 | zecke | admitingly me neither but this is really old code :) |
| 20:59.58 | RP | That file is full of them... |
| 21:00.12 | mithro | my guess is that you actually never called it without data |
| 21:00.26 | mithro | because that would make little sense |
| 21:00.30 | RP | I'm going to remove it and see what happens... |
| 21:00.31 | zecke | mithro: right, it is from bitbake 1.x where x <= 1.2 |
| 21:01.32 | mithro | btw you are better off using lists everywhere |
| 21:01.41 | mithro | you seem to be continually splitting and joining |
| 21:02.16 | mithro | split when you do the parsing then treat it as a list |
| 21:03.03 | mithro | doing that will also make a lot of your string concats go away (as they become list additions) |
| 21:03.08 | mithro | but it's a rather major change |
| 21:03.27 | RP | mithro: splits in which file in particular? |
| 21:03.57 | RP | or you mean split certain variables up? |
| 21:04.45 | RP | that would be one major change... |
| 21:06.03 | RP | mithro: From what you said before, import domain from bb.msg would be faster than referencing bb.msg.domain all the time? |
| 21:06.05 | mithro | ie you currently have : and such |
| 21:06.13 | mithro | RP kinda of |
| 21:06.29 | mithro | do a "import bb.msg.domain" |
| 21:06.44 | mithro | then in the begining of your function do "domain = bb.msg.domain" |
| 21:06.55 | mithro | doing it in the beginining of your function is the key |
| 21:07.06 | mithro | because then it's a direct local lookup |
| 21:07.15 | RP | right, I see :) |
| 21:07.50 | mithro | currently it goes, "local to function, globals, bb, msg" |
| 21:08.12 | mithro | if you make it a function local it's a huge imporvment - specially with stuff called in loops |
| 21:08.14 | RP | so its like searching PATH in a shell :) |
| 21:10.13 | mithro | kind of |
| 21:10.43 | RP | mithro: Are references resolved in advance or at execution time? e.g. if you have some long reference in a loop but in an uncommon path, will it cost you speed? |
| 21:11.44 | mithro | storing things as strings is the anti-python methodology |
| 21:11.44 | mithro | not really |
| 21:11.44 | mithro | it only make an effect when you call the thing 100,000 times |
| 21:11.45 | RP | ok |
| 21:12.16 | RP | mithro: The problem is that the metadata is string based :-/ |
| 21:13.51 | mithro | you want to keep strings short and immutable |
| 21:17.49 | likewise | Does IMAGE_TYPES = squashfs compress to a squashfs using LZMA compression by default (as it depends on it) ?? |
| 21:18.40 | hrw | likewise: it use squashfs normal iirc |
| 21:19.03 | hrw | wrtoe distro defined squashfs-lzma for own usage iirc |
| 21:19.28 | hrw | likewise: did you find lzma patch for recent squashfs maybe? |
| 21:21.26 | mithro | most of your stuff is lists of strings |
| 21:21.48 | hrw | anyway - time to bed for me |
| 21:21.54 | hrw | cu you tomorrow guys |
| 21:22.06 | RP | cu hrw|gone |
| 21:22.57 | RP | mithro: This is another nasty that shows up on that profile: http://www.rpsys.net/openzaurus/temp/base.bbclass |
| 21:24.06 | mithro | which part? |
| 21:24.59 | mithro | that again is split/joins |
| 21:25.09 | RP | Just the variable becomes a very long string and its run for every .bb file |
| 21:25.40 | RP | right, and I'd bet thats where a lot of the os.path.joins come from |
| 21:26.12 | mithro | possible |
| 21:26.28 | mithro | i wish somebody would pay me to optimise bitbake - then I would have no excuse to put it off :P |
| 21:27.38 | mithro | koen|away: how did your SoC go? |
| 21:27.54 | RP | mithro: I added an example of what FILESPATH becomes to that link |
| 21:28.25 | RP | mithro: I wish someone would pay me to work on bitbake - I do far too much of it in my free time :-/ |
| 21:29.45 | mithro | RP: we should start bitbake inc then get CELF, Nokia and AMD to throw money at us ;P |
| 21:29.53 | CosmicPenguin | hah |
| 21:29.54 | CosmicPenguin | has if |
| 21:30.15 | RP | mithro: You can rule Nokia out - they have scratchbox |
| 21:31.53 | RP | The overrides = overrides + ":" in that files looks unneeded at the very least |
| 21:32.29 | mithro | RP: thats why we need to become jedi first so we can use our jedi mind tricks to get them to forget it! :P |
| 21:32.44 | RP | :) |
| 21:33.18 | mithro | just finished the second one an hour or two ago |
| 21:33.50 | mithro | RP: (after looking at the example) no wonder python is having a spaz |
| 21:35.19 | mithro | spliting and manipulating that string must take virtuall forever |
| 21:35.45 | RP | mithro: yes :-( |
| 21:36.14 | mithro | split it into a list and keep it that way - bazillion times faster |
| 21:37.03 | RP | but the metadata doesn't work that way :-/ |
| 21:38.20 | mithro | why not? |
| 21:38.45 | mithro | with a little bit of tricks you could easily make it transparent to the meta data |
| 21:39.22 | RP | mithro: When you run getVar, everything expects a string? or are you proposing a getVarList ? |
| 21:39.46 | RP | also, some variables are split by :, some by " " |
| 21:40.19 | mithro | i am proposing that you make the internals aware of lists of strings and then convert the meta data to lists when it's parsed |
| 21:40.53 | RP | but how do you know that a given variable is a list or not? |
| 21:41.26 | mithro | dunno, guess? |
| 21:41.55 | mithro | treat everything as lists of strings? |
| 21:42.16 | RP | Lists of one item would be the problem (OVERRIDES = "conf") as you'd guess wrong... |
| 21:42.43 | mithro | actually treating everything as a lists of strings may work quite well |
| 21:42.44 | RP | Sometimes, the variables are complete functions |
| 21:43.28 | mithro | you could make a "list of strings" object which behaves like a list or a string depending on the calling convention |
| 21:43.55 | RP | That would be the only way we could convert... |
| 21:44.08 | mithro | then use the lists of strings feature to optimize cases |
| 21:44.47 | RP | That could work |
| 21:45.04 | mithro | the other option would be to create a mutable string class |
| 21:45.39 | RP | I quite like the sound of that option... |
| 21:48.20 | mithro | that doesn't solve the split/join problem however |
| 21:48.27 | mithro | which i think is a pretty common case |
| 21:48.51 | RP | It is |
| 21:51.17 | mithro | which is more common, lists or real strings? |
| 21:51.51 | mithro | in the long term could you fix the meta data so that it makes a distinction? |
| 21:52.04 | mithro | it would really make your life so much similar |
| 21:52.18 | mithro | s/similar/simpilar/ |
| 21:53.46 | RP | in the metadata, blobs are much more common than lists |
| 21:53.56 | kergoth | mithro: we wont be able to talk anyone out of not using scratchbox until we're a usable development tool. we're far too weak on that end to compete with it for many companies |
| 21:54.00 | RP | but the blobs are stored as strings |
| 21:55.53 | mithro | RP: the metadata doesn't make any distinction between lists/blobs? |
| 21:56.24 | mithro | i havn't looked at BB metadata in 6 months so I can't really remember the details |
| 21:56.51 | RP | mithro: everything is a string, including 200 line functions |
| 21:57.18 | RP | mithro: all in one big data dictonary which we have to search at each data lookup |
| 21:57.42 | mithro | that data dicitionary needs a lot of optimistation too... |
| 21:57.59 | RP | mithro: The data dictonary is right at the top of that profile :-/ |
| 21:58.39 | mithro | i know, the parser/data dictionary was what i was going to concentrate on with my SoC proposal |
| 21:58.52 | mithro | there are quite a few things which can be done to speed it up |
| 21:58.59 | mithro | it's pretty horrible python in many ways |
| 21:59.43 | RP | http://www.rpsys.net/openzaurus/temp/bitbake_data_dump.txt gives an idea of the variables in the dictonary |
| 22:00.19 | Crofton | hrw|gone, kernel doesn't seem to boot |
| 22:00.39 | RP | mithro: http://svn.berlios.de/wsvn/bitbake/trunk/bitbake/lib/bb/data_smart.py?op=file&rev=0&sc=0 expand() is the biggest bottleneck |
| 22:00.58 | mithro | yeah |
| 22:01.12 | mithro | the way you do expanding just plan sucks :P |
| 22:02.08 | RP | mithro: How do we do it better? :) |
| 22:02.26 | mithro | it's partly a metadata problem |
| 22:02.58 | RP | The flexibility of the metadata is a big part of OE... |
| 22:03.11 | mithro | yeah i know |
| 22:06.19 | mithro | RP: how big is the OE metadata? IE whats a du -h of it produce? |
| 22:06.37 | RP | mithro: The .bb files? |
| 22:06.42 | mithro | yeah |
| 22:08.09 | RP | 151MB |
| 22:08.39 | mithro | how much memory does bitbake use currently (after parsing the whole bb data)? |
| 22:08.51 | likewise | mithro: (/RP) That's probably only the org.openembedded.dev branch |
| 22:09.28 | RP | mithro: Not that much as we throw away most of the data after parsing due to memory issues |
| 22:09.51 | likewise | what is the way to parallelize bitbake tasks, I cannot find the variable in the manual? |
| 22:09.52 | RP | mithro: Its faster to reparse any .bb file we need again |
| 22:10.13 | RP | 147MB of that is in actual packages btw |
| 22:10.17 | mithro | so currently you do a first parse to just build the dependency graph? |
| 22:10.20 | RP | although some will be patches |
| 22:10.30 | RP | mithro: yes |
| 22:10.56 | hvontres|poodle | RP: what about making the bb cache list-based? then anything past the parser can count on things being lists |
| 22:10.59 | RP | mithro: well, we save any data, accessed by the dependency / task planning code |
| 22:12.16 | RP | mithro: The cache is transparent to the dependency graph code - we just watch what it accesses and store that so on a subsequent run, we can return that data instead of reparsing everything |
| 22:12.20 | mithro | i think i know a way to make sure variables are expanded only once, and then only when they are needed |
| 22:12.49 | RP | That would be a big help as expanding them once would be much better than expanding all the time |
| 22:13.36 | mithro | it would be very similar to how the COW stuff works |
| 22:14.03 | RP | I think I might have been wondering about something similar :) |
| 22:14.16 | RP | although I'm not sure my python skills are up to it |
| 22:14.31 | mithro | to bad my time managment isn't up to it :/ |
| 22:14.43 | RP | :-( |
| 22:15.12 | likewise | Why isn't DEPENDS_append_machine = " libmad" written as DEPENDS_machine += "libmad" ? |
| 22:15.33 | mithro | I'm guessing it would take about 40 man hours to complete and test |
| 22:16.05 | RP | likewise: Presumably there is risk of something resetting DEPENDS |
| 22:16.51 | kergoth | likewise: those are two different operations. DEPENDS_machine will overwrite the contents of DEPENDS upon expansion. _append_machine conditionally appends. _machine += appends to a conditional |
| 22:17.16 | *** join/#oe JustinP (i=papercra@c-69-181-11-251.hsd1.ca.comcast.net) |
| 22:19.12 | mithro | RP: there is a chance I'll do some work on it now that I have 1 day free a week |
| 22:19.53 | RP | mithro: any help would be gratefully received... |
| 22:19.58 | likewise | kergoth: So _machine += will add a condition to the existing conditions (if any) ? |
| 22:20.20 | mithro | I guess the other thing is that I don't actually use any OE work at the moment |
| 22:20.38 | kergoth | no, it appends to a foo_machine variable, which is the machine specific version of that variable. it will blow away foo when it expands, not appending to it. |
| 22:20.53 | RP | likewise: The behaviour of using overrides and += is unpredictable and I'd keep off it |
| 22:21.20 | RP | well, not exactly unpredictable... |
| 22:21.38 | kergoth | unintuitive. |
| 22:21.40 | kergoth | not unpredictable |
| 22:21.48 | RP | mithro: Actually using OE does give an incentive for development... |
| 22:21.55 | RP | kergoth: right :) |
| 22:22.27 | likewise | kergoth: tnx |
| 22:22.28 | mithro | yeah, my zaurus is sitting in a box |
| 22:22.32 | likewise | RP: tnx |
| 22:22.38 | kergoth | it all comes back to the weakness of the way we do overrides. the append/prepend mess was a consequence of that |
| 22:22.47 | mithro | my laptop is small enough that it goes everywhere with me, so no need for the zaurus |
| 22:22.59 | *** join/#oe Sleep_Walker (n=Sleep_Wa@195.22.44.103.adsl.nextra.cz) |
| 22:22.59 | mithro | COW = Copy on Write |
| 22:23.13 | hvontres|poodle | mithro: ahh thanks... |
| 22:23.48 | *** part/#oe Sleep_Walker (n=Sleep_Wa@195.22.44.103.adsl.nextra.cz) |
| 22:25.06 | likewise | Can I test bitbake's multi-threading features already? |
| 22:25.09 | *** join/#oe pvanhoof (n=pvanhoof@d54C18260.access.telenet.be) |
| 22:25.42 | mithro | RP: actually my idea would make all the data stuff thread safe |
| 22:26.56 | mithro | zecke: how goes the test cases for bitbake? |
| 22:27.07 | RP | mithro: threading and python is something I've not got into, other than knowing how to fork. How would it help? |
| 22:28.42 | mithro | the biggest problem you need to be careful of, mutable stuff is shared between threads - so need to make sure you copy something if you want the other threads to not see the changes |
| 22:29.09 | mithro | there is also the global intepretor lock you need to watch out for |
| 22:29.38 | mithro | it's not like C, you can't crash or anything |
| 22:30.00 | RP | mithro: If I call python's fork, that behaves the same way as C though? |
| 22:30.10 | mithro | never used it |
| 22:30.23 | mithro | but i guess it would just be a wrapper around the C fork |
| 22:30.41 | RP | I decided to stick to what I knew - fork it as needed and use waitpid :) |
| 22:30.53 | mithro | waitpid? |
| 22:31.30 | RP | mithro: http://svn.berlios.de/wsvn/bitbake/trunk/bitbake/lib/bb/runqueue.py?op=file&rev=0&sc=0 |
| 22:31.34 | mithro | although, does bitbake really need to be multithreaded? a non-blocking version should be able to spawn multiple stuff |
| 22:31.38 | RP | mithro: waitpid is a unix thing |
| 22:32.00 | RP | s/unix/C/ |
| 22:32.54 | *** join/#oe rwhitby (n=rwhitby@nslu2-linux/rwhitby) |
| 22:32.54 | RP | mithro: Which module would you recommend for python threads (or "spawning multiple stuff") ? |
| 22:34.23 | mithro | rather intresting way of doing it |
| 22:34.49 | RP | mithro: very C like ;-) |
| 22:34.51 | mithro | seems rather complicated |
| 22:35.29 | RP | It just has to be careful about all the error cases |
| 22:36.32 | mithro | why don't you just build a proper tree? |
| 22:37.01 | RP | mithro: What do you mean by proper tree? |
| 22:37.04 | mithro | s/tree/graph |
| 22:38.02 | RP | I tried several things and couldn't see to manipulate them the way I needed. Pointers at good graph implementations welcome... |
| 22:38.07 | mithro | seems like your runqueue should be the following, |
| 22:39.33 | mithro | while true: if (len(running) < NUMBER_OF_THREADS): run(graph.nexttask()) else wait() |
| 22:41.27 | mithro | actually you could even make graph impliment the iter stuff properly and that would be even more natural |
| 22:42.05 | RP | Is there an existing graph implemenation? |
| 22:42.34 | mithro | probably, but I would most probably end up roling my own very simple one in about 1-2 hours |
| 22:43.02 | mithro | Set would be a good start |
| 22:43.15 | RP | ah well. Nice to know I totally waste my spare time :) |
| 22:43.41 | mithro | it works does it not? |
| 22:43.58 | RP | on the most part it does |
| 22:44.13 | mithro | so it's a 1000 times better then my implimentation at the moment ;) |
| 22:44.21 | RP | ;-) |
| 22:44.38 | mithro | python is really a KISS language |
| 22:44.46 | CosmicPenguin | as in KISS my ass |
| 22:45.22 | mithro | IE If you having trouble reading your code in english it's most probably to complicated |
| 22:46.08 | RP | mithro: The problem is that code is more C like than python. Since I think in C, it probably reads better to me though :) |
| 22:46.26 | mithro | RP: probably |
| 22:46.43 | RP | mithro: It also runs surprisingly quickly once I nuked a single bottleneck (in taskdata) |
| 22:47.02 | mithro | btw how do you choose which tasks to start first? |
| 22:47.23 | RP | mithro: There's a weighting algorithm in there |
| 22:47.36 | mithro | guessing bitbake doesn't really know about actual build times |
| 22:47.54 | mithro | GCC/GLIBC still a graph bottleneck? |
| 22:48.02 | RP | We just build the tasks with the most dependent tasks first |
| 22:48.34 | RP | and glibc comes quite well up there but another thread can be fetching, unpacking, patching so its not really a problem |
| 22:49.07 | mithro | btw do multiple threads do fetching at one time? |
| 22:49.21 | RP | mithro: They can |
| 22:49.36 | mithro | or is there one fetching, one unpacker, one patcher, etc |
| 22:49.54 | mithro | (IE Pipelineing |
| 22:49.56 | mithro | ) |
| 22:50.19 | kergoth | would be good to consider what system resources are used most by a given task, i remember us talking about needing that back when we discussing the possibilities for threading when schurig and i were first hashing it out |
| 22:50.19 | RP | The whole "how many threads to run" algothirm still needs writing. The fixed number of threads there is a better than nothing implemenation :) |
| 22:51.09 | mithro | I think the best implimentation would be a pipeline with multiple threads at some points in the line |
| 22:51.13 | RP | kergoth: I remember the dicussion well. The idea is we can fit an algorithm into runqueue when we're ready - it has a "get_next_task()" hook ready |
| 22:51.21 | kergoth | cool |
| 22:51.47 | mithro | ie it doesn't make much sense to have all threads downloading (as they would compete for bandwidth) |
| 22:52.14 | RP | mithro: The thinking is you'd set a limit on the number of threads of a given type that would run (say 3 fetchers) |
| 22:52.29 | mithro | yeah |
| 22:52.43 | mithro | that would even make sense on a single CPU machine |
| 22:52.50 | RP | mithro: right :) |
| 22:53.55 | mithro | (then it would be 1 thread for each type) |
| 22:54.19 | mithro | maybe a few for the fetcher if you have a fast link and slow downloads |
| 22:54.24 | *** join/#oe csmanx (n=csman@70.53.192.116) |
| 22:54.42 | mithro | btw do you still spawn wget for http/ftp downloads? |
| 22:54.51 | RP | mithro: we do |
| 22:55.27 | *** join/#oe chrisromain (n=chrisrom@AToulouse-157-1-62-88.w86-207.abo.wanadoo.fr) |
| 22:55.35 | mithro | while i'm dreaming about improvements.... |
| 22:55.52 | mithro | having that in python would allow you to run as many threads as bandwidth avaliable |
| 22:56.30 | kergoth | suppose you could use twisted for that, no? heavy dep though |
| 22:56.41 | mithro | ie while (used_bandwidth_average < actually_average): spawn more |
| 22:56.54 | mithro | kergoth: no need, the python inbuilt library would be good enough |
| 22:57.21 | mithro | but then again i'm biasest against twisted |
| 22:57.26 | kergoth | bitbake knows how to fetch a lot more than http/ftp. |
| 22:57.51 | mithro | sure, svn, cvs, mecurial, etc |
| 22:57.55 | kergoth | i'd rather see something independent like libcurl get the fetch stuff we support, but.. |
| 22:58.18 | RP | fetchers and bandwidth limits are a low priority... |
| 22:58.39 | mithro | eventually if you had all handlers able to report currently used bandwidth (however it's done) |
| 22:59.18 | mithro | thats just another thing to put on the never ending todo list :P |
| 22:59.46 | RP | I can near enough guarantee I'll not be doing that one ;-) |
| 23:01.29 | mithro | :P |
| 23:03.15 | mithro | maybe bitbake could burn my excess calories for me |
| 23:03.20 | mithro | that would be a cool feature! |
| 23:04.15 | RP | I think I just found a 40% speed increase in parsing :) |
| 23:05.59 | mithro | o, how? |
| 23:06.17 | RP | http://www.rpsys.net/openzaurus/temp/bitbake_expand_cache.patch |
| 23:07.43 | mithro | i would be a bit careful there |
| 23:08.03 | mithro | wouldn't that rapidly become very very large? |
| 23:08.28 | RP | Testing with metadata says its 40% faster... |
| 23:08.35 | RP | any write nukes the cache |
| 23:08.55 | mithro | compare the memory usage? |
| 23:09.13 | RP | For a 40% speed improvement, I'm not sure I care ;-) |
| 23:09.36 | RP | can I make python show memory usage? |
| 23:10.24 | mithro | profile should be able to show memory usage |
| 23:11.54 | RP | memory usage looks the same looking at top |
| 23:12.00 | RP | ~50MB max |
| 23:12.09 | likewise | a pipelined approach with only one fetching thread does not take into account that the bandwidth bottleneck may be at the server (i.e. it makes sense to have multiple download threads). |
| 23:12.24 | RP | likewise: That was why I said 3 |
| 23:12.36 | likewise | RP: good :-) |
| 23:12.37 | RP | likewise: but its all going to be configurable |
| 23:12.48 | RP | someone just needs to write the code ;-) |
| 23:13.43 | likewise | Design First, Code Later. (or was it Design in Code, and Code on Paper ?) |
| 23:14.44 | zecke | RP: how does that mix with COW? |
| 23:15.03 | zecke | RP: line 50 is the ctor? |
| 23:20.27 | zecke | nite |
| 23:23.58 | likewise | nite all |
| 23:27.49 | *** join/#oe nts____gi (n=gints@62.84.15.211) |
| 23:31.50 | *** part/#oe dfoley (n=dfoley@h24-207-7-221.primesignal.com) |
| 23:33.19 | *** join/#oe blumediaontheZ (n=blumedia@97.sub-75-208-220.myvzw.com) |
| 23:36.55 | RP | 'night all |
| 23:38.57 | kergoth | night |
| 23:41.38 | *** join/#oe Crofton_|laptop (n=balister@66-207-66-26.black.dmt.ntelos.net) |
| 23:53.22 | *** join/#oe redguy (n=mati@acq161.neoplus.adsl.tpnet.pl) |