| 00:05.03 | *** join/#oe chouimat (~dieu@chouinard.developer.kde) |
| 00:05.20 | *** join/#oe TimRiker (~timr@c-24-1-105-52.hsd1.tx.comcast.net) |
| 00:05.43 | *** join/#oe fido_hl (~hl@cm113-60.liwest.at) |
| 00:05.55 | *** join/#oe jh_ (~jason@69.144.85.206) |
| 00:09.26 | *** join/#oe subdue (~chopstix@198-79-109-131.hi.net) [NETSPLIT VICTIM] |
| 00:09.35 | *** join/#oe offroadgeek (~offroadge@offroadgeek.sustaining.supporter.pdpc) |
| 00:09.58 | *** join/#oe zimbo (~zimbo@callisto.dom.bonis.de) [NETSPLIT VICTIM] |
| 00:10.09 | *** join/#oe kergoth (~kergoth@ip71.churchill-park.dfw.ygnition.net) |
| 00:10.18 | *** join/#oe robtaylor (~robtaylor@217.204.121.82) |
| 00:10.29 | *** join/#oe kurre2 (~tomimo@a84-231-39-238.elisa-laajakaista.fi) |
| 00:10.43 | *** join/#oe treke (~ggilbert@68-66-243-62.ventca.adelphia.net) |
| 00:12.23 | *** join/#oe koen|sleep (~koen@cl-148.ams-05.nl.sixxs.net) [NETSPLIT VICTIM] |
| 00:31.51 | reenoo_ | 'night all |
| 00:35.11 | *** join/#oe Luke-Jr (~luke-jr@207.192.219.246) |
| 00:37.19 | *** join/#oe tomimo_ (~kurre@a84-231-39-238.elisa-laajakaista.fi) [NETSPLIT VICTIM] |
| 00:38.03 | *** join/#oe CosmicPenguin (~nobody@aus-ext-proxy02.amd.com) [NETSPLIT VICTIM] |
| 00:51.59 | *** join/#oe Geo_KM (~keith@bh02i525f01.au.ibm.com) |
| 00:59.41 | *** join/#oe AMDPenguin (~nobody@aus-ext-proxy02.amd.com) |
| 01:03.08 | *** join/#oe CIA-13 (~CIA@flapjack.navi.cx) |
| 01:10.38 | *** join/#oe dkey (~dkey@193.170.48.234) |
| 01:19.32 | *** join/#oe noclouds (~mhfan@60.166.162.20) |
| 01:20.14 | *** join/#oe mithro (~tim@dsl1-83.gw1.adl1.airnet.com.au) |
| 01:22.38 | *** join/#oe Laibsch (~leggewie@G151e.g.pppool.de) |
| 01:23.56 | *** join/#oe aphistic (~aph@CPE-24-160-241-191.wi.res.rr.com) |
| 01:26.23 | *** join/#oe rwhitby-away (~rwhitby@rwhitby.nslu2-linux) |
| 01:28.07 | *** join/#oe CIA-8 (~CIA@flapjack.navi.cx) |
| 01:35.51 | ljp | anyway to force a pcmcia disk to be /dev/hdb ? as opposed to /dev/hda ? |
| 01:36.59 | _ggilbert | udev |
| 01:41.53 | chouimat | hey!!!! |
| 01:42.09 | ljp | how about for 2.4 kernels |
| 01:42.29 | chouimat | no elections next month!!! |
| 01:42.37 | *** join/#oe robert__ (~chatzilla@220.248.128.10) |
| 01:43.34 | chouimat | hey _ggilbert ljp |
| 01:44.11 | *** join/#oe hufnus (~slonsiki@m3a3236d0.tmodns.net) |
| 01:44.19 | _ggilbert | ljp: nope. Don't think so |
| 01:44.28 | ljp | can't even bitchslap it? |
| 01:44.31 | chouimat | robert__: yes? |
| 01:44.47 | robert__ | hey, chouimat |
| 01:44.49 | _ggilbert | ljp: nope |
| 01:45.17 | kergoth | ljp: well, you oculd do something silly like renaming the device nodes in /dev/. its the major/minor that matters, not the filename. but you'd have to make adjustments to ensure that the cardmgr automounting mounted the new name. |
| 01:45.26 | kergoth | since you'd be working behind its back |
| 01:45.29 | chouimat | hey kergoth moved yet? |
| 01:45.53 | kergoth | chouimat: not yet, need to finish cleaning my apartment.. procrastinating.. the closet is really bad.. |
| 01:45.56 | kergoth | heh |
| 01:46.06 | robert__ | hehe |
| 01:46.40 | kergoth | thankfully most of it can be thrown out, just a matter of sifting through it for things of value. still, no fun |
| 01:46.42 | chouimat | kergoth: I found out that I need to add syslog and snort to my bsd based embedded firewall to have all my reseller back ... took me 15 minutes ;) |
| 01:46.47 | kergoth | chouimat: hehe |
| 01:46.49 | kergoth | nice |
| 01:47.00 | kergoth | chouimat: any luck on the job front? |
| 01:47.14 | chouimat | kergoth: I have to build a "log analysis" software but ;) |
| 01:47.22 | kergoth | hehe |
| 01:48.25 | chouimat | kergoth: read this for the job front http://www.kdedevelopers.org/node/view/1074 but the plan b is looking good and the "getting laid with the chick behind the bar" too ; |
| 01:49.15 | kergoth | hehe |
| 01:49.23 | kergoth | where do you see yourself in 10 years. what a crock |
| 01:49.29 | kergoth | 10 years is a _long_ time, especially in this field |
| 01:49.31 | kergoth | who knows |
| 01:49.47 | chouimat | kergoth: liked my answer ? I actualy answered it |
| 01:49.54 | kergoth | hehe |
| 01:50.32 | chouimat | kergoth: first time was not ambitious enought ... so I guess not serious enought is improvement ;) |
| 01:51.15 | chouimat | kergoth: I know my problem for job interview I'm way to much cynical and ironic ... |
| 01:52.20 | kergoth | yeah. you need to think about it like a salesperson. starting with the resume, you're selling yourself. focusing on your strengths, basically acting the role of a good salesperson.. and cynicism and bitterness rarely serves a salesperson well :P |
| 01:52.26 | *** join/#oe offroadgeek (~offroadge@offroadgeek.sustaining.supporter.pdpc) |
| 01:52.37 | *** join/#oe a-atwood (~xf009976@proxysb02.ext.ti.com) |
| 01:52.56 | chouimat | kergoth: I know ... now I know what to answer to this one if I ever get it again |
| 01:53.33 | chouimat | kergoth: to have enough money to don't care if the work I do succeed or not ;) |
| 01:53.44 | kergoth | lol |
| 01:54.26 | chouimat | kergoth: my father told me the guy who ask the question has a lot of money, a house and a family so you have to answer something he doesn't have |
| 01:55.35 | *** join/#oe Geo_KM (~keith@bh02i525f01.au.ibm.com) |
| 01:56.58 | chouimat | kergoth: that mean I will care until I have enough money to say: so long suckers ;) |
| 01:58.36 | ljp | say, "I envision myself working for your company, doing the same crappy job, getting the same crappy pay rate as when I started" |
| 01:58.43 | kergoth | haha |
| 01:59.31 | kergoth | i think i've been lucky, i dont think i've had that exact question in an interview before. at least, not that i can remember |
| 01:59.37 | chouimat|tv | ljp: so if you ever seem my resume at tt.au remind me this ;) |
| 02:00.28 | chouimat|tv | kergoth: the usual question I get here is: Are you able to manage a 5 millions email account system with sendmail? |
| 02:00.42 | chouimat|tv | ok stargate sg1 is on tv |
| 02:00.46 | kergoth | to which the answer is "not if i can help it"? |
| 02:00.48 | kergoth | :P |
| 02:02.07 | chouimat|tv | kergoth: yup ... give me exim or postfix ... but not sendmail |
| 02:02.13 | kergoth | :) |
| 02:10.50 | kergoth | hmm, the channel topic needs updating |
| 02:11.09 | kergoth | should mention the new bitbake version requirement, and remove the miniconf or add a link to the slides and stuff |
| 02:12.06 | chouimat|tv | kergoth: looked at gentoo gnap? |
| 02:12.12 | kergoth | nope |
| 02:14.57 | chouimat|tv | http://www.gentoo.org/proj/en/base/embedded/gnap-userguide.xml |
| 02:18.27 | kergoth | hehe. oe could do exactly that without much difficulty |
| 02:25.18 | chouimat|tv | kergoth: I know ... but it's interesting anyway |
| 02:26.26 | chouimat|tv | i installed it ... but like the embedded stuff I'm working on right now is based on freebsd ... |
| 02:26.36 | chouimat|tv | both of them are not an option |
| 02:33.22 | kergoth | hmm, we arent missing many packages in oe to be able to easily build non-busybox images |
| 02:33.32 | kergoth | i should set that up. would be good for building development environments |
| 02:33.39 | kergoth | where thingsl ike busybox's ar are a problem |
| 02:36.15 | *** join/#oe raster (~raster@vagw.valinux.co.jp) |
| 02:40.50 | kergoth | yay, got my colinux debian setup all happy again, now to get the dev env cleaned up so i can be productive |
| 02:44.02 | *** join/#oe Laibsc1 (~leggewie@G151e.g.pppool.de) |
| 02:50.30 | *** join/#oe cdbot (~cdbot@hentges.net) |
| 03:03.02 | kergoth | hmm |
| 03:06.38 | *** join/#oe wrobbie (~rob@cm17.sigma183.maxonline.com.sg) |
| 03:07.12 | *** join/#oe offroadgeek (~offroadge@offroadgeek.sustaining.supporter.pdpc) |
| 03:08.23 | offroadgeek | anyone know where I can download openembedded_0.1-2_all.deb, the link on oe.org is dead (linked to hrw's site?) |
| 03:08.32 | kergoth | dunno |
| 03:09.11 | offroadgeek | ok... I'll try hrw when he's back.. thanks |
| 03:15.18 | CIA-8 | 03kergoth * r183 10bitbake-data/doc/doxygen/Makefile.am: Comment out the hackish way we're executing the doxygen-doc makefile target, since it breaks when doxygen docs arent built. Revisit later. |
| 03:17.20 | CIA-8 | 03kergoth * r184 10bitbake-data/TODO: |
| 03:17.20 | CIA-8 | Clean out and start a new TODO list. Finishing up this library to make it |
| 03:17.20 | CIA-8 | suitable for use in both bitbake and bitbake-ng shouldn't take more than a day |
| 03:17.20 | CIA-8 | or two for code/unit test and perhaps a week's real world use case testing. |
| 03:28.06 | chouimat | ljp: how is Brisbane? |
| 03:28.43 | ljp | becoming "winter" |
| 03:29.13 | chouimat | ljp: but winter there is more hot than winter here (-40C) |
| 03:29.48 | chouimat | kergoth: old band but good |
| 03:30.16 | chouimat | kergoth: ask ljp ;-P |
| 03:30.53 | chouimat | http://ulyx.ath.cx/ex.jpg <--- guess who is the guy and who is the chick |
| 03:35.13 | kergoth | chouimat: whats your email addy again? |
| 03:49.41 | kergoth | yay family guy album |
| 03:49.41 | kergoth | <babysitter> time for your bottle my sweet. |
| 03:49.42 | kergoth | <babysitter thinking> this little brat smells like piss. |
| 03:49.42 | kergoth | <stewie> always a succulent treat. |
| 03:49.42 | kergoth | <stewie thinking> while i suck that, you suck this! |
| 03:50.25 | chouimat | kergoth: I have to watch the last 3 weeks of family guy and american dad |
| 04:04.57 | *** join/#oe mikeklem (mikeklem@fury.csh.rit.edu) |
| 04:25.40 | *** join/#oe W8TVI (~w8tvi@209.165.254.252) |
| 04:50.57 | chouimat | kergoth: got the video |
| 05:21.04 | *** join/#oe man-di (~man-di@dyndsl-080-228-195-118.ewe-ip-backbone.de) |
| 05:48.55 | wrobbie | | /home/rob/oe/build/tmp/work/display-image-1.0-r0/temp/run.do_rootfs.4083: line 193: makedevs: command not found |
| 05:49.09 | kergoth | bitbake makedevs-native |
| 05:49.13 | kergoth | heh |
| 05:49.25 | wrobbie | yup, but shouldn't that be included somewhere already? |
| 05:49.52 | kergoth | should be. no idea what display-image is, so no idea why it wouldnt be |
| 05:51.02 | wrobbie | it's copied from bootstrap-image, with addons.. how does bootstrap-image get its makedevs.. |
| 05:56.18 | *** join/#oe man-di_ (~man-di@dyndsl-080-228-195-186.ewe-ip-backbone.de) |
| 06:08.24 | wrobbie | is there a ipkg tool to see the contents of a .ipk file? |
| 06:09.18 | kergoth | i'm sure there is |
| 06:09.22 | kergoth | i just use a shell function in my .bashrc |
| 06:09.23 | kergoth | ipkgfiles () { |
| 06:09.24 | kergoth | »·······ar p $1 data.tar.gz | tar -tvz |
| 06:09.24 | kergoth | »·······return $? |
| 06:09.24 | kergoth | } |
| 06:09.26 | kergoth | heh |
| 06:10.08 | wrobbie | ah, i was messing with 'ar x' etc. ok, i'll try yours |
| 06:10.20 | kergoth | that just displays the files in the archive |
| 06:10.26 | kergoth | you'd use x to extract them |
| 06:10.34 | kergoth | ipkgcontrol () { |
| 06:10.34 | kergoth | »·······ar p $1 control.tar.gz | tar -zxO ./control |
| 06:10.34 | kergoth | »·······return $? |
| 06:10.34 | kergoth | } |
| 06:10.37 | kergoth | thats a handy one as well |
| 06:10.40 | kergoth | displays the control file contents |
| 06:10.43 | wrobbie | thanks :) |
| 06:10.47 | kergoth | np |
| 06:10.52 | wrobbie | weird that ipkg can't do it.. |
| 06:11.17 | kergoth | i'm sure theres a tool in ipkg-utils to do it |
| 06:11.26 | kergoth | thers ipkg-build, ipkg-unbuild, etc |
| 06:12.53 | *** join/#oe minipanda (~zhanght@221.122.51.131) [NETSPLIT VICTIM] |
| 06:12.53 | *** join/#oe jamie (~jamie@softmodem.org) [NETSPLIT VICTIM] |
| 06:15.30 | *** join/#oe Pend-Gone (Pendalar@h154.122.140.67.ip.alltel.net) |
| 06:29.05 | *** join/#oe dkey (~dkey@193.170.48.234) |
| 06:32.27 | *** join/#oe do13 (~dirk@do13.in-dsl.de) |
| 06:35.45 | *** join/#oe P|Pe (~P|Pe@p54B9AB4E.dip0.t-ipconnect.de) |
| 06:52.00 | *** join/#oe Laibsch (~leggewie@G151e.g.pppool.de) |
| 06:55.58 | *** join/#oe P|Pe (~P|Pe@p54B9AB4E.dip0.t-ipconnect.de) |
| 06:56.01 | *** join/#oe tigrux (~tigrux@201.128.115.137) |
| 07:19.10 | *** join/#oe __law__ (~law@mail.stiftadmont.at) |
| 07:19.43 | __law__ | i have tryed to build ah fresh opie-image today :-( (http://pastebin.com/286852) |
| 07:20.28 | kergoth | __law__: OE now requires current bitbake. either the 1.2.1 release, or current svn. |
| 07:21.24 | *** join/#oe Cwiiis (~cwiiis@user-214-207-151-83.e7even.com) |
| 07:22.07 | __law__ | kergoth, i have done svn up bitbake before |
| 07:22.46 | __law__ | BitBake Build Tool Core version 1.1, bitbake version 1.2.1 |
| 07:24.12 | hrw | __law__: clear cache |
| 07:24.14 | hrw | hi all |
| 07:25.18 | hrw | 1 hour hrw 1.3350 konqueror-embedded_20030705: fixed SRC_URI |
| 07:25.20 | hrw | <PROTECTED> |
| 07:25.36 | hrw | my system does not run cia triggers and I dont know why |
| 07:26.57 | ljp | BK_USER ? |
| 07:27.26 | Spyro | guys |
| 07:27.29 | hrw | BK_USER is set BK_SILENT is not set |
| 07:27.38 | Spyro | how do I specify a specific version of a package to build? |
| 07:27.58 | Spyro | I want to build xserver-xorg_6.8 not xserver-xorg_CVS |
| 07:28.01 | hrw | Spyro: PREFERRED_VERSION_package="version" |
| 07:28.16 | hrw | in conf |
| 07:28.22 | Spyro | cheers |
| 07:28.36 | kergoth | pfft, that one is even in the bitbake manual :P |
| 07:29.03 | Spyro | kergoth: :-~ |
| 07:29.28 | hrw | I have to find some time and replace PSU fan with zalman... |
| 07:31.55 | hrw | I will be back in 30 minutes - have to go to work |
| 07:59.50 | __law__ | hrw|gone, i have remove the whole tmp dir, but i have got the same problem :-( |
| 08:05.10 | *** join/#oe eumel (~chatzilla@p54832979.dip0.t-ipconnect.de) |
| 08:07.45 | robert__ | what problem |
| 08:09.46 | __law__ | robert__, (http://pastebin.com/286852) |
| 08:10.46 | hrw|work | re |
| 08:11.54 | hrw|work | __law__: update to bitbake trunk maybe? |
| 08:12.00 | robert__ | __law__: which version of python you used? |
| 08:12.39 | robert__ | PYTHONPATH=/usr/local/lib/python2.3/site-packages |
| 08:18.07 | __law__ | python -V |
| 08:18.07 | __law__ | Python 2.3.4 |
| 08:18.30 | __law__ | i have exporte my PYTHONPATH already |
| 08:19.28 | __law__ | hrw|work, i should install a newer bitbake version? how? i always say svn up bitbake |
| 08:19.28 | robert__ | try to update your bitbake to 1.2.1 |
| 08:19.49 | __law__ | bitbake --version |
| 08:19.49 | __law__ | BitBake Build Tool Core version 1.1, bitbake version 1.2.1 |
| 08:20.10 | hrw|work | <PROTECTED> |
| 08:20.11 | hrw|work | BitBake Build Tool Core version 1.2.1, bitbake version 1.2.1 |
| 08:20.23 | robert__ | BitBake Build Tool Core version 1.2.1, bitbake version 1.2.1 |
| 08:20.26 | hrw|work | Updated to revision 184. |
| 08:21.04 | robert__ | update again.maybe some error your bitbake have |
| 08:23.47 | gints|wrk | __law__: I always delete bitbake directory and refetch it... |
| 08:24.17 | *** join/#oe mallum (~mallum@host81-153-48-235.range81-153.btcentralplus.com) |
| 08:25.25 | __law__ | hrw|work, how can i update to revision 184 ? |
| 08:25.44 | __law__ | i will delete the whole bb dir and refetch |
| 08:26.07 | hrw|work | __law__: I just do "svn up" as I use trunk |
| 08:26.18 | gints|wrk | __law__: I keep bitbake and openebmedded in different dirs ... |
| 08:26.23 | __law__ | hrw|work, how can i use trunk ? |
| 08:30.17 | robert__ | get bitbake and install it |
| 08:30.44 | hrw|work | __law__: fetch, keep in one dir and add that dir into PATH? |
| 08:32.05 | __law__ | hrw|work, i have build a rpm for fedora core 3 |
| 08:33.01 | b0ti|work | what variable can I use to get the staging directory of a native package from a non-native build? |
| 08:38.38 | *** join/#oe kergoth (~kergoth@covenant.kergoth.com) |
| 08:38.54 | *** join/#oe Laibsch (~leggewie@G0e51.g.pppool.de) |
| 08:47.21 | b0ti|work | how can I get the HOST ARCH (i686-linux in my case) from bitbake? |
| 08:48.40 | b0ti|work | is it ${HOST_SYS} ? |
| 08:49.36 | hrw|work | b0ti|work: use bbread |
| 08:53.15 | *** join/#oe zinga (~arnaudb@186.80-203-227.nextgentel.com) |
| 08:53.28 | hrw|work | finally one user started to work on bt950_cs drived cards for 2.6 |
| 08:59.23 | mickeyl | morning |
| 08:59.38 | kergoth | b0ti|work: how do you define 'host'? host is ambigious. try to use the terms 'build' and 'target' to make it clear. |
| 09:00.01 | hrw|work | hi mickeyl |
| 09:01.15 | kergoth | fyi, i started on a series of emails to the bitbake-dev list outlining plans and the bitbake-ng design bits. still a bunch more info to send yet though |
| 09:01.36 | kergoth | hmm.. should sleep |
| 09:05.29 | hrw|work | kergoth: how long you will be in TX? |
| 09:07.44 | CIA-8 | 03mickeyl 07 * r1.3348.1.3 10openembedded/packages/gpsbabel/gpsbabel_1.2.5.bb: add gpsbabel, courtesy Patrick Ohly. Thanks |
| 09:07.47 | CIA-8 | 03mickeyl 07 * r1.3348.1.2 10openembedded/packages/libsigcx/ (7 files in 2 dirs): add libsigcx 0.6.4, courtesy Steven Brown. Thanks |
| 09:07.51 | CIA-8 | 03mickeyl 07 * r1.3348.1.1 10openembedded/packages/libeasysoap++/ (4 files in 2 dirs): add libeasysoap 0.6.1, courtesy Steven Brown. Thanks |
| 09:11.04 | RP | morning mickey|sick |
| 09:11.54 | mickey|sick | morning RP |
| 09:12.28 | RP | mickey|sick: What were the problems you were seeing with orinoco? |
| 09:12.41 | mickey|sick | RP: it goes like that: |
| 09:13.18 | RP | mickey|sick: doesn't work at all? |
| 09:14.08 | RP | mickey|sick: so far I've patched 0.13e to 0.14alpha2 and its still working. The 0.13e-SN6 driver seems to have bits of 0.15rc2 in it... |
| 09:14.22 | mickey|sick | 0.13e works great |
| 09:14.34 | mickey|sick | 0.15rc1 introduces lots of dropped packages |
| 09:14.49 | RP | right. I'm just wondering what to look for |
| 09:14.49 | mickey|sick | 0.15rc2 not even registers the netdev and when it does it drops 99% of packages |
| 09:15.43 | *** join/#oe Titeuf (~Titeuf@2m01.net) |
| 09:15.54 | mickey|sick | i never did tests with the 0.14 series, so i dunno |
| 09:16.34 | mickey|sick | the interesting stuff debuted in 0.15 |
| 09:16.39 | hrw|work | uf.. good that I have hostap card |
| 09:16.45 | mickey|sick | monitor mode extensions, iw scan, native monitoring, etc. |
| 09:16.49 | koen | good morning all |
| 09:16.50 | CIA-8 | 03koen 07 * r1.3352 10openembedded/packages/gpe-contacts/gpe-contacts_0.38.bb: Add gpe-contacts 0.38 |
| 09:16.52 | mickey|sick | morning koen |
| 09:16.57 | RP | mickey|sick: The 0.14 changes look quite sane. The 0.13e-SN6 we use is rather different from 0.13e though... |
| 09:16.58 | koen | get well soon mickey|sick |
| 09:17.03 | RP | morning koen |
| 09:17.10 | koen | hey RP |
| 09:17.18 | mickey|sick | thanks koen |
| 09:17.20 | hrw|work | hi koen |
| 09:17.21 | RP | mickey|sick: Do we care abou 2.4 kernels? |
| 09:17.31 | koen | hey hrw|work |
| 09:17.32 | mickey|sick | RP: not for 0.15. |
| 09:17.33 | RP | mickey|sick: yes, GWS! |
| 09:17.45 | kergoth | hrw|work: will be here for another couple days. |
| 09:17.47 | mickey|sick | RP: 0.13 works fine on 2.4, we can stick with that for a long time. |
| 09:17.52 | RP | mickey|sick: Right. That makes my life easier :) |
| 09:18.23 | mickey|sick | the 0.13e-26 looks kind of different because of the monitor mode patches from shmoo are already in that tarball |
| 09:18.50 | mickey|sick | RP: thanks. just something with stomach. didn't keep my dinner last nite to where it belongs :/ |
| 09:19.14 | RP | mickey|sick: Right - that'll be what's confusing my diffs. It rules out some 0.15 code though which is good |
| 09:20.08 | RP | mickey|sick: Ugh :-/. Not nice :-( |
| 09:21.23 | kergoth | Now, with the 2.6.12-rc3 kernel, and a patch for module-init-tools, the |
| 09:21.23 | kergoth | USB hotplug program can be written with a simple one line shell script: |
| 09:21.23 | kergoth | modprobe $MODALIAS |
| 09:21.23 | kergoth | So, with a few more kernel patches for the other subsystems (hint, I'll |
| 09:21.23 | kergoth | gladly take them...) the other helper programs can too go away entirely. |
| 09:21.23 | kergoth | That will leave us with only the main /sbin/hotplug multiplexor program |
| 09:21.25 | kergoth | that any distro that uses udev is starting to abandon entirely. |
| 09:21.27 | kergoth | heh, nifty |
| 09:22.38 | hrw|work | heh.. that reminds me that I had to test hotplug-perl or hotplug-ng on my destktop |
| 09:22.50 | mickey|sick | yeah, some exciting things on lkml recently |
| 09:22.53 | RP | mickey|sick: Is 18/115 "lots of dropped packets" ? |
| 09:23.23 | mickey|sick | RP: i've experienced more like 40% and a whole lot of dmesg entries with "BAP error" |
| 09:23.53 | mickey|sick | 0.13e doesn't emit any BAP errors, 0.15rc1 continuesly and 0.15rc2 even more |
| 09:24.03 | mickey|sick | (when it registers netdev at all) |
| 09:24.27 | RP | mickey|sick: Ok. I'm not seeing any BAP errors with 0.14alpha2 |
| 09:24.35 | kergoth | hm, i forgot to mention 'scopes' as a required relationship between recipes, on the list of bitbake-ng requirements i sent to the list |
| 09:24.49 | RP | Was just getting a bit worried by the number of dropped packets... |
| 09:24.52 | kergoth | and the obvious consequence, that the api needs to have a means of doing scoped lookups |
| 09:25.19 | mickey|sick | RP: good. the amount of BAP errors in the log is the major indication if things go wrong or not |
| 09:26.18 | RP | kergoth: I read your emails and think we're in basic agreement :) |
| 09:26.27 | kergoth | good good |
| 09:27.07 | kergoth | if you think of any other requirements, be sure to note them. i want to make sure we dont forget about any key functionality |
| 09:27.08 | RP | kergoth: The one question in my mind was will bitbake-ng find any users outside of openembedded? |
| 09:27.23 | b0ti|work | kergoth: are you suggesting that I should use ${BUILD_SYS} instead of ${HOST_SYS}? I'll try that. |
| 09:27.57 | kergoth | RP: the portage guys are looking forward, long long term, at a possible rewrite. i've discussed my intentions with bitbake-ng, and there was some interest amongst developers. i think that if we get it rolling, we can sell it as a backend to a portage rewrite. |
| 09:28.05 | kergoth | thats one of the key other use cases |
| 09:28.22 | RP | Right, I wasn't aware of that but it makes sense |
| 09:28.28 | kergoth | and the real reason, other than marc singer's opinions, for the requirement involving imperative recipe formats |
| 09:28.51 | kergoth | consider the possibilities of a flexible library like this. it could easily underly any major build infrastructure tools |
| 09:28.54 | kergoth | apt-build, even |
| 09:29.52 | RP | I apprecite its possibilities, I just wondered if we had some actual potential target users. We have so that makes sense :) |
| 09:29.56 | kergoth | right :) |
| 09:30.18 | kergoth | only 2, but i think those 2 are diverse enough that they cover all the major requirements, and scalability concerns |
| 09:31.09 | RP | It might be an idea to spell that out somewhere as I wasn't aware of that and its something any ponential bitbake-ng developer should know about |
| 09:31.16 | kergoth | was planning on putting that in the next email :) |
| 09:31.24 | RP | right :) |
| 09:31.35 | kergoth | i probably shouldve sent those first, since use cases drive requirements, not the other way around |
| 09:31.36 | kergoth | oh well :) |
| 09:32.36 | kergoth | RP: oh, was thinking.. a good candidate for an incremental improvement that would benefit the rewrite as well is simply to start work on yanking bb.fetch in favor of do_fetch hooking into curl for most things. |
| 09:32.48 | kergoth | fetching really didnt belong in the core anyway. |
| 09:33.06 | kergoth | dunno if anyone wants to take that one on |
| 09:34.50 | RP | kergoth: Its a good idea. Personally, I want to try some more tweaks to memory usage and then see what can be done for "multi tasking" but someone might want to pick that up |
| 09:36.04 | kergoth | yeah, i agree. that one isnt as critical or user visible, but itd be a good task to hand off to someone that wants it, since itd help clean out the crap from the codebase |
| 09:36.27 | kergoth | i wonder if zecke has a TODO for the bitbake work yet |
| 09:41.52 | RP | If not, he probably should have :) |
| 09:43.45 | hrw|work | NOTE: [11:43] package autofs-4.1.4: completed |
| 09:43.47 | hrw|work | ;) |
| 09:44.11 | mickey|sick | nice |
| 09:45.52 | kergoth | hm, i should reply to this unionfs thread. the developers solicited use cases for direct writes to members of the union, since it fucks up unionfs cache coherency |
| 09:46.00 | kergoth | ipkg dests via unionfs is such a use case |
| 09:46.03 | kergoth | heh |
| 09:46.12 | mickey|sick | right |
| 09:46.50 | kergoth | i'm glad someone else pointed out the other obivous one, a setup with an ro flash / underlying the union, but letting the user write back certain files to that member on shutdown if they choose to, otherwise having their changes lost (ramdisk) |
| 09:47.00 | kergoth | thats a common one on lots of devices |
| 09:47.02 | kergoth | 2heh |
| 09:47.07 | kergoth | s/^2// |
| 09:47.11 | hrw|work | someone have idea why CIA trigger does not run on my machine? |
| 09:47.28 | koen | bk co Bitkeeper/triggers/* |
| 09:47.35 | kergoth | hrw|work: not offhand.. its python.. and requires the python xmlrpc.. |
| 09:47.37 | __law__ | i have reinstalled bitbake from scratch, same error :-( (http://pastebin.com/286852) |
| 09:48.03 | hrw|work | ah |
| 09:48.12 | hrw|work | maybe I removed xmlrpc python |
| 09:48.19 | koen | __law__: have removed the cache? |
| 09:49.21 | hrw|work | no.. it is installed |
| 09:50.10 | kergoth | koen: that wouldnt do anything :P. /* would only match files if they're already in the directory :) |
| 09:50.44 | koen | kergoth: that would explain why it doesn't always work |
| 09:50.56 | kergoth | bk co BitKeeper/triggers would do what you intended |
| 09:50.57 | koen | I guess I did a bk co triggers |
| 09:51.00 | kergoth | :) |
| 09:52.51 | *** join/#oe BigAl (~bigal@dsl-202-45-98-149.ACT.netspace.net.au) |
| 09:53.11 | hrw|work | hi BigAl |
| 09:53.38 | CIA-8 | 03mickeyl 07 * r1.3351.1.2 10openembedded/packages/python/ (5 files in 2 dirs): add dedicated python-dbus packages instead of polluting the dbus one |
| 09:53.41 | CIA-8 | 03mickeyl 07 * r1.3351.1.1 10openembedded/packages/ (3 files in 2 dirs): add python-pyrex{-native}, a language specially designed for writing Python extension modules |
| 09:54.21 | mickey|sick | hi BigAl, how's the CXK 2.6 doing? |
| 09:54.29 | mickey|sick | s/X/3/ |
| 09:55.08 | kergoth | mickey|sick: boy you can tell i've been out of it. the first i heard about the distros merging was your latest newsletter :) |
| 09:55.11 | BigAl | mickey|sick: Haven't had much time to work on it over the last couple of days unfortunately, but I'm going to try to get the LCD going this weekend. |
| 09:55.33 | mickey|sick | BigAl: cool |
| 09:55.37 | koen | kergoth: any ideas for the new name? |
| 09:55.43 | mickey|sick | kergoth: heh, really? D'oh |
| 09:55.52 | kergoth | not really. looked over the wiki page but didnt come up with much |
| 09:56.01 | kergoth | ELD looked the best out of the ones there |
| 09:56.15 | mickey|sick | yeah, i also favour ELD |
| 09:57.10 | __law__ | koen, i have remove the whole tmp/ dir |
| 09:57.20 | koen | __law__: just tmp/cache |
| 09:57.30 | kergoth | heh. does oe require 1.2.1 atm, or does it require svn? |
| 09:57.43 | mickey|sick | kergoth: btw., can you adjust the permissions of index.php in oe homedir please |
| 09:57.52 | kergoth | mickey|sick: k |
| 09:57.55 | mickey|sick | thanks |
| 09:57.59 | kergoth | mickey|sick: btw, you heard hh isnt hosting us anymore? |
| 09:58.04 | hrw|work | I like ELD name |
| 09:58.07 | mickey|sick | d'oh. |
| 09:58.11 | mickey|sick | kergoth: why's that ? |
| 09:58.12 | __law__ | koen, to late ;-) |
| 09:58.20 | kergoth | IT rules changing to the HP ones from the old ones |
| 09:58.27 | kergoth | they can host an hh subdomain, like oe.handhelds.org |
| 09:58.29 | kergoth | but not our domain |
| 09:58.32 | mickey|sick | hmm |
| 09:58.35 | mickey|sick | fine with me |
| 09:58.41 | kergoth | told them to do that for now, can forward to it |
| 09:58.46 | kergoth | decide what ot do later |
| 10:01.06 | mickey|sick | bbl, need to lay down |
| 10:01.50 | Spyro | guys |
| 10:02.08 | Spyro | the xorg 6.8 build is broken as well as the CVS build, in exactly the same way |
| 10:02.27 | koen | damn |
| 10:02.35 | koen | Spyro: I guess you have to pester pb about that |
| 10:03.01 | Spyro | k :) |
| 10:06.04 | Spyro | looks like the Makefiles arent getting created in the build subdirs |
| 10:11.07 | Spyro | should xc/config/Makefile contain nothing? (seems doubtful :-) |
| 10:11.43 | *** join/#oe cedric (~cedric@freeway.rd.francetelecom.com) |
| 10:16.38 | CIA-8 | 03kergoth * r185 10bitbake-data/doc/test_scoped_lookups.sql: |
| 10:16.38 | CIA-8 | Set up the scopes for autotools.bbclass and base.bbclass in the |
| 10:16.38 | CIA-8 | test_scoped_lookups.sql, so that variable values can be looked up for those |
| 10:16.38 | CIA-8 | recipes in the sample. Also add an example select doing an additional JOIN so |
| 10:16.38 | CIA-8 | that you can specify the recipe you're looking up in by name rather than by the |
| 10:16.39 | CIA-8 | recipe_id in the table. |
| 10:18.38 | *** join/#oe XorA (~dp@81-178-152-212.dsl.pipex.com) |
| 10:18.42 | kergoth | SELECT val FROM vars |
| 10:18.42 | kergoth | JOIN scope ON vars.recipe_id = scope.scope_recipe_id |
| 10:18.42 | kergoth | JOIN recipes ON scope.recipe_id = recipes.id |
| 10:18.42 | kergoth | WHERE vars.var = 'CC' AND recipes.recipe = 'base.bbclass' |
| 10:18.42 | kergoth | ORDER BY scope.priority DESC |
| 10:18.43 | kergoth | limit 1; |
| 10:18.46 | kergoth | hehe |
| 10:18.47 | kergoth | getting awfully ugly |
| 10:18.47 | XorA | morning |
| 10:18.50 | kergoth | morning |
| 10:19.07 | hrw|work | hi XorA |
| 10:20.17 | kergoth | oh, i forgot to add another requirement to the list. for performance reasons, Should be able to manipulate scopes at runtime, so that changing, and thereby reparsing, base.bbclass, doesn't require a reparse of all files using it. |
| 10:24.06 | *** join/#oe [g2] (~g2@cpe-066-057-008-035.nc.res.rr.com) |
| 10:25.45 | *** join/#oe roh (~roh@port-195-158-177-246.dynamic.qsc.de) |
| 10:26.05 | roh | re |
| 10:29.27 | wrobbie | hmm. in my tmp/rootfs, there's a few devices in dev.. Shouldn't those come from my device_table, when doing the genext2fs? (i.e., why are those devices in tmp/rootfs/dev?) |
| 10:29.58 | kergoth | ehh, first of all, _why are you root_? |
| 10:30.03 | kergoth | :P |
| 10:30.13 | wrobbie | If I re-do genext2fs manually, it clashes |
| 10:30.17 | wrobbie | root? |
| 10:30.29 | kergoth | you cant create device nodes as a user, and you shouldnt be building as root |
| 10:30.43 | wrobbie | i'm not running as root... |
| 10:31.02 | kergoth | once again, you cannot create device nodes as a user. |
| 10:31.08 | kergoth | are you sure they arent just symlinks or something? |
| 10:31.44 | wrobbie | hm. they are just plain files.. how weird. |
| 10:31.51 | wrobbie | -rw-r--r-- 1 rob rob 0 May 19 12:13 fb0 |
| 10:31.51 | wrobbie | -rw-r--r-- 1 rob rob 0 May 19 12:13 hda |
| 10:31.56 | kergoth | odd |
| 10:32.16 | wrobbie | normally rootfs/dev should not exist? |
| 10:32.47 | hrw|work | mickey|sick: opie-cardmon 20050520 will probably need PARALLEL_MAKE="" |
| 10:33.06 | kergoth | rootfs/dev willl exist. it gets created by base-files. |
| 10:33.20 | wrobbie | but, be empty? :) |
| 10:33.46 | wrobbie | i was just at base-files.. scanning some more.. |
| 10:33.51 | kergoth | thats the idea, it should be empty, yep |
| 10:34.30 | wrobbie | ok, perhaps residue then from some previous screwup.. not the first time |
| 10:34.44 | kergoth | hell, i'm up late enough that i'm hungry for breakfast again. i hate that |
| 10:35.09 | wrobbie | that can't be good :) |
| 10:38.36 | *** join/#oe cbrake2 (~cbrake@cpe-204-210-216-174.neo.res.rr.com) |
| 10:50.25 | *** join/#oe zecke (fakeuser@p54BD05A8.dip0.t-ipconnect.de) |
| 11:04.08 | hrw|work | bitbake does not notice changed recipe (r184 here) |
| 11:10.35 | koen | hrw|work: yes, I've also noted that problem |
| 11:13.27 | *** join/#oe raster (~raster@YahooBB219198104088.bbtec.net) |
| 11:20.39 | zecke | hrw|work: bah, do you've time to look at the problem? |
| 11:20.48 | zecke | (inserting one print statement) |
| 11:20.53 | hrw|work | zecke: I can |
| 11:22.06 | hrw|work | just say where |
| 11:24.15 | zecke | hrw|work: lib/bb/make.py |
| 11:24.27 | zecke | hrw|work: uncomment lines 79 and 82 |
| 11:24.46 | hrw|work | ok |
| 11:25.32 | zecke | hrw|work: and print "Cache times: old: %s new: %s" % (cache_mtime, file_mtime) on line 78 |
| 11:26.12 | hrw|work | zecke: dont have that 78 line |
| 11:26.22 | hrw|work | a.. add ;) |
| 11:27.15 | zecke | hrw|work: must be a bug in your FileSystem driver, what do you use reiser? |
| 11:27.43 | hrw|work | reiserfs3 |
| 11:28.00 | hrw|work | 13:27 hrw@home:husky$ bitbake meta-opie|grep meta-opie |
| 11:28.00 | hrw|work | Cache times: old: (33188, 2631060L, 773L, 1, 1000, 1000, 86974L, 1116588419, 1116587016, 1116587016) new: 1111145545 for /home/hrw/zaurus/oe/openembedded/packages/meta/meta-opie-dynamic.bb |
| 11:28.04 | hrw|work | <PROTECTED> |
| 11:28.07 | hrw|work | Cache times: old: (33188, 16272303L, 773L, 1, 1000, 1000, 94574L, 1116588419, 1116587017, 1116587017) new: 1116588456 for /home/hrw/zaurus/oe/openembedded/packages/meta/meta-opie.bb |
| 11:28.10 | hrw|work | <PROTECTED> |
| 11:28.19 | hrw|work | <PROTECTED> |
| 11:28.20 | zecke | oops |
| 11:29.14 | zecke | nice relation (int,long,long,int...)x int |
| 11:29.24 | zecke | I wonder how < is defined on that relation... |
| 11:29.28 | hrw|work | zecke: cache_mtime have a little more data ;) |
| 11:30.50 | zecke | hrw|work: line 328 in data_smart.py |
| 11:30.53 | zecke | hrw|work: add a [8] |
| 11:31.43 | hrw|work | <PROTECTED> |
| 11:31.46 | hrw|work | this? |
| 11:32.09 | zecke | http://www.openbsd.org/zaurus.html |
| 11:32.10 | zecke | wow |
| 11:32.20 | hrw|work | <PROTECTED> |
| 11:32.37 | zecke | no |
| 11:32.41 | zecke | behind the statement |
| 11:32.47 | zecke | return os.stat()[8] |
| 11:34.16 | hrw|work | aha |
| 11:34.16 | zecke | hrw|work: sorry I can't remember more than 2 seconds :} (line numbers...) |
| 11:34.17 | hrw|work | zecke: like goldfish? |
| 11:34.17 | hrw|work | Cache times: old: 1116587016 new: 1111145545 for /home/hrw/zaurus/oe/openembedded/packages/meta/meta-opie-dynamic.bb |
| 11:34.18 | hrw|work | <PROTECTED> |
| 11:34.18 | hrw|work | Cache times: old: 1116587017 new: 1116588785 for /home/hrw/zaurus/oe/openembedded/packages/meta/meta-opie.bb |
| 11:34.18 | hrw|work | <PROTECTED> |
| 11:34.18 | hrw|work | works |
| 11:35.06 | hrw|work | will you push that fix? |
| 11:40.25 | zecke | hrw|work: yupp |
| 11:40.38 | hrw|work | ok |
| 11:43.40 | CIA-8 | 03zecke123 * r186 10bitbake/lib/bb/ (data_dict.py data_smart.py): |
| 11:43.40 | CIA-8 | bitbake/lib/bb/data_smart.py: |
| 11:43.40 | CIA-8 | <PROTECTED> |
| 11:43.40 | CIA-8 | bitbake/lib/bb/data_dict.py: |
| 11:43.40 | CIA-8 | <PROTECTED> |
| 11:44.51 | hrw|work | thx zecke |
| 11:46.08 | *** join/#oe _law_ (~law@213.173.86.202) |
| 11:46.39 | proti | morning |
| 11:47.23 | hrw|work | hi seb |
| 11:47.43 | proti | hi, it's been long time I went ther. |
| 11:47.51 | hrw|work | yep |
| 11:48.24 | proti | A lot to do. I've seen bitbake is moving along. |
| 11:48.55 | _law_ | has anyone the new bitbake running with fedora core 3? |
| 11:49.25 | hrw|work | proti: 43M memory usage during build |
| 11:49.49 | proti | proti: Nice. with bbmasks ? |
| 11:50.00 | proti | hrw|work: Nice. with bbmasks ? |
| 11:50.19 | hrw|work | with empty bbmask |
| 11:50.27 | hrw|work | all 23xx packages in |
| 11:51.10 | proti | hrw|work: Really nice. I think it can be improved. |
| 11:51.27 | proti | I had this idea for a long time : |
| 11:51.28 | hrw|work | works little slower but does not need extra ram |
| 11:51.48 | proti | Why does bitbake keeps the cache files ? |
| 11:52.02 | *** join/#oe mithro (~tim@dsl1-83.gw1.adl1.airnet.com.au) |
| 11:52.06 | zecke | proti: because it is secondary storage |
| 11:52.16 | proti | In fact to caculate the dependencies of the packages. |
| 11:52.46 | proti | zecke: nope, to improve the parsing of metadata. |
| 11:53.03 | proti | zecke: it's a shortcut. |
| 11:53.54 | proti | hrw|work: I was thinking, how about to make bitbake caculate itself the BBMASK. |
| 11:54.12 | zecke | proti: the data format is not changed |
| 11:54.56 | proti | zecke: correct, but you restart at the stage where the file is parsed. And just after is the dependency calculation. |
| 11:55.29 | b0ti|work | I build my package twice as native and cross, but the include files in staging do not get installed into arm-linux, only i686-linux. What should I change? |
| 11:56.54 | proti | If you parsed all the bb files. Then you calculate the dependencies and then you store those dependencies in the cache files. |
| 11:57.29 | hrw|work | b0ti|work: thats correct |
| 11:57.52 | b0ti|work | hrw|work: what is correct? |
| 11:58.05 | hrw|work | b0ti|work: native stage in native, cross in cross |
| 11:58.39 | b0ti|work | hrw|work: but I have no staging includes for cross, that's not correct. |
| 11:58.43 | proti | Next time you use that cache to build the BBMASK and parse only the need bb files (which IMHO should not be more than 100 files max). |
| 11:59.07 | hrw|work | b0ti|work: s/cross/arm-linux |
| 11:59.50 | proti | Those dependencies will not change a lot along dev once they are correct. |
| 11:59.50 | b0ti|work | hrw|work: my problem is that I build a package that depends on the cross compiled package's includes, and they are not in staging/arm |
| 12:00.07 | hrw|work | ah.. |
| 12:00.26 | hrw|work | includes are generated during -native build? |
| 12:00.57 | zecke | proti: no inner deps are calculated already |
| 12:01.08 | b0ti|work | -native build is exactly the same as the cross |
| 12:01.08 | zecke | proti: but yes we could cache all deps as well |
| 12:01.20 | zecke | proti: or do not calculate all deps at once but only the needed ones |
| 12:01.35 | zecke | proti: or example look at each bbfile not three times but only once |
| 12:02.17 | b0ti|work | hrw|work: I even get an -dev package with the includes from the cross build. |
| 12:02.34 | hrw|work | b0ti|work: and do_stage() in cross build is wrong? |
| 12:02.42 | proti | zecke: bb file are parsed only once if I remember. But the update_data and update_keys are killing performances. There is 3 invokation of thoses functions and they are really expensive. |
| 12:03.45 | b0ti|work | hrw|work: I didn't touch do_stage() |
| 12:04.10 | proti | zecke: The bb files are designed in a way that you need to have all the metadata online to be able to caclulate dependencies. Not shortcut is possible at this stage. |
| 12:04.28 | hrw|work | b0ti|work: outside of OE packages? |
| 12:04.33 | b0ti|work | hrw|work: but indeed the log file for do_stage() is empty |
| 12:04.44 | hrw|work | b0ti|work: default do_stage() is empty |
| 12:04.51 | zecke | proti: if you've any profiling hints they're welcome |
| 12:05.54 | proti | zecke: Yes I do. update_data is a prime target. Invoked twice after each parsing of bb file. |
| 12:05.55 | b0ti|work | hrw|work: so I need to explicitly tell in the cross.bb what do_stage() should do? |
| 12:06.03 | hrw|work | yes |
| 12:06.46 | proti | zecke: The second culprit is of course the update_keys. |
| 12:07.49 | proti | But my main point is : cut the crap. I want to build that cross_gcc packages, I don't need you to read the whole 2300 packages. |
| 12:08.37 | proti | But to build the BBMASK automatically, I need the dependencies. |
| 12:08.37 | hrw|work | proti: dont you need to read them until you got the one which gives gcc-cross? |
| 12:09.35 | proti | hrw|work: Hey, the name of the bb file is not the name of the package. Then you could have several candidate. How do know that without parsing the bb files ? |
| 12:10.15 | hrw|work | proti: exactly. I was answering to "cut the crap. I want to build that cross_gcc packages, I don't need you to read the whole 2300" |
| 12:10.15 | proti | hrw|work: A good example are the linux kernels. |
| 12:11.03 | proti | hrw|work: Yes. Me too. look. You want to build gcc-cross. What file do you need to read to have the recipes for gcc-cross ? |
| 12:11.47 | proti | The one who says gcc-cross.bb is wrong. |
| 12:12.11 | hrw|work | proti: dont know, so I read all until got correct one - then I think that I can stop reading - but how can I know does it is best one... |
| 12:12.53 | proti | hrw|work: The good answer is all the bb files you can get. That is a design spec. |
| 12:13.10 | hrw|work | proti: so I read all from BBFILES anyway |
| 12:14.24 | proti | hrw|work: No, you read once all the files, write down the packages name they provides (use the caches files for this). Then you don't have to reparse them because you already have this information in the cache files, you use it. |
| 12:14.55 | proti | Write down the dependencies they need too. |
| 12:14.55 | *** join/#oe tmbinc (tmbinc@dsl-213-023-011-072.arcor-ip.net) |
| 12:15.16 | hrw|work | ok - I will go to lunch and then will try to follow discussion |
| 12:15.31 | proti | hrw|work: Bon appetit. |
| 12:18.05 | hrw|work | ~curse mozilla cvs fetcher |
| 12:18.08 | ibot | May the fleas of a thousand camels infest your most sensitive regions, mozilla cvs fetcher ! |
| 12:18.44 | *** join/#oe Crofton (~balister@jhr-476-5192.mprg.ee.vt.edu) |
| 12:18.54 | *** join/#oe zecke (fakeuser@p54BD05A8.dip0.t-ipconnect.de) |
| 12:18.57 | zecke | re |
| 12:26.51 | zecke | proti: what you want is to not build the world tree |
| 12:29.34 | proti | zecke: What I want is to have the information when I need it, not all the information at the beginning which I don't need at all. |
| 12:30.30 | *** join/#oe mithro (~tim@dsl1-83.gw1.adl1.airnet.com.au) |
| 12:32.17 | RP | proti: Basically what you're saying is we should only cache the provider and dependency data? Whilst that's a good idea, the design of bitbake makes that difficult. |
| 12:44.48 | *** join/#oe mrz80 (1000@caledonia.cns.ufl.edu) |
| 12:45.10 | proti | RP: Correct. Once you know the files you need to read and the order you need to read them, it leaves you with a few files to read which is bearable with the current implementation. |
| 12:47.14 | hrw|work | anyone remember how long mozilla/firefox/minimo fetch from cvs? |
| 12:47.47 | koen | hrw|work: long |
| 12:47.54 | koen | > 20 minutes |
| 12:48.09 | hrw|work | NOTE: [14:13] package minimo-0.0cvs20050520-r8: task do_fetch: started |
| 12:48.16 | hrw|work | and still fetching on 1Mbps |
| 12:48.35 | koen | minimo cvs is < 1Mbit/s anyway :) |
| 12:49.05 | Spyro | Heres a thought for bitbake... |
| 12:49.05 | Spyro | rather than use a stamp to indicate successful compilation |
| 12:49.26 | Spyro | allow packages to nominate a file that will be produced and depend on that instead |
| 12:52.48 | *** join/#oe pH5 (~ph5@p5485C885.dip.t-dialin.net) |
| 13:01.12 | *** join/#oe molivier2 (~mac@l13m-8-181.d2.club-internet.fr) |
| 13:02.35 | hrw|work | argh... screen was frozen... |
| 13:03.08 | hrw|work | minimo do_fetch was 10minutes.. |
| 13:03.50 | zecke | proti: with the cache your almost there, parse data once, next time check if it is present (see for depends you need to parse the file anyway as you could include or inherit deps) |
| 13:04.07 | zecke | proti: and stop creating the world dep tree |
| 13:06.10 | *** join/#oe pb_ (~pb@2002:5246:d929:1:20a:5eff:fe00:391e) |
| 13:12.31 | proti | zecke: The big picture of bitbake is : 1- parse bb files, 2- compute the deps, 3- find the impacted files, 4- on those files, follows the recipes. |
| 13:12.54 | *** join/#oe VoodooZ_Work (~VoodooZ@CPE00c0f021712c-CM014110003785.cpe.net.cable.rogers.com) |
| 13:13.00 | VoodooZ_Work | hey |
| 13:13.10 | koen | hey VoodooZ_Work |
| 13:13.29 | VoodooZ_Work | another "noobs" question... |
| 13:13.30 | proti | zecke: I propose : 1- read the already calculated deps. 2- compute impacted files. 3- parse the needed files. 4- follows the recipes. |
| 13:13.51 | VoodooZ_Work | I'm adding a package for the more recent OV511 webcam driver... |
| 13:14.20 | VoodooZ_Work | I added a new patch to my .bb file but when I bitbake it doesn't seem to skip it. |
| 13:14.24 | proti | zecke: And for the dep calculation (which could be done offline), 1- read all the files, 2- compute deps 3- write down deps. |
| 13:14.33 | VoodooZ_Work | I did a -c clean and it still doesn't pick it up. |
| 13:14.50 | koen | try -b file.bb |
| 13:14.55 | VoodooZ_Work | I had a similar problem with previous patches but they eventually worked after I wiped out tmp. |
| 13:15.02 | koen | the new bitbake doesn't notice changed files |
| 13:15.03 | VoodooZ_Work | I'd rather not have to do that everytime though. |
| 13:15.11 | proti | And voila. No more cache files involved. Just one full parse to update the dependencies from time to time. |
| 13:15.14 | VoodooZ_Work | i see. |
| 13:15.32 | VoodooZ_Work | so bitbake -b package? |
| 13:17.05 | koen | bitbake -b path/to/file.bb |
| 13:17.27 | koen | that only builds the .bb, it doesn't do dependencies |
| 13:17.33 | koen | that's why it's so fast |
| 13:18.23 | VoodooZ_Work | perfect. thanks. works |
| 13:18.27 | *** join/#oe tux_mike (~mike@zelda.tuxnami.org) |
| 13:19.56 | zecke | proti: what you miss 1. look at the deps |
| 13:20.10 | zecke | proti: they might have changed as conf/local.conf is different, a .bb file was changed |
| 13:20.13 | zecke | proti: or a bbclass |
| 13:21.04 | zecke | proti: sure we can write down the deps as well but we do not gain much |
| 13:21.41 | zecke | proti: You could start profiling if there is a difference in unpickling a dict/list with some entries |
| 13:21.48 | zecke | proti: and a dict with 1000 entries |
| 13:22.00 | pb_ | hi zecke |
| 13:22.40 | proti | zecke: No. I propose that the user should decide when to update the deps. That is his choice to rebuild it. |
| 13:22.43 | zecke | pb_: Sorry, for my ignorance at #gpe, obviously GUADEC is taking place in Stutgart |
| 13:22.55 | pb_ | zecke: hehe, right |
| 13:23.05 | zecke | proti: dep build toolchain |
| 13:23.21 | zecke | proti: but what if he added an ASSUME_PROVIDED, see a dep cache can be outdatet as well |
| 13:23.44 | pb_ | zecke: I guess GUADEC is not of much interest to you. |
| 13:24.02 | zecke | pb_: I could see the great Miguel :} |
| 13:24.07 | pb_ | heh |
| 13:24.46 | proti | zecke: ASSUME_PROVIDED is shortcut. It does not really change the dependencies calculated. It just drops a part of the dep subtree. |
| 13:25.39 | zecke | proti: it can drop huge parts, anyway by looking at the cache first you do not know if it is current |
| 13:26.31 | proti | zecke: Well, up to the user to update the deps. A manual action from time to time instead of a full parse each time bitbake is invoked. |
| 13:26.56 | VoodooZ_Work | kergoth: long time no c! |
| 13:27.05 | pb_ | proti: you're proposing that the user should update bitbake's dependencies by hand? That sounds rather unsatisfactory. |
| 13:28.39 | proti | No, I suggest that the user provoke an update of the deps calculation. First time (no deps calculated) could be automatic, but not the updates. |
| 13:29.06 | VoodooZ_Work | koen: I was wondering if It's worthwhile for me to push my new package? The 2.6 kernel comes with OV511 built-in but it's relatively old and doesn't support the newer cards/V4L2. |
| 13:29.13 | zecke | proti: will you respond to users wondering why bitbake does not 'work'? |
| 13:29.15 | proti | See. do bk pull. bitbake --dep-updates. Then you are ready to do anything to build. |
| 13:30.34 | proti | zecke: FAQ. remove cache files and reinvoke the bitbake to rebuild. |
| 13:30.54 | pb_ | I think that would be a significant retrograde step. |
| 13:31.00 | zecke | proti: not before I die |
| 13:31.32 | zecke | oops I shouldn't say stuff like this with my disease... |
| 13:32.04 | zecke | pb_: I'm currently considering going to Stuttgart with my microwave and bags of popcorn |
| 13:32.13 | *** join/#oe offroadgeek (~offroadge@offroadgeek.sustaining.supporter.pdpc) |
| 13:32.15 | zecke | pb_: I predict the funny language war to take place |
| 13:32.43 | proti | Well, just a hint. One could find a smarter way to find that deps should be updated. But, the only way I can think of finding deps have changed is to rebuild the deps themselves and compare to the cache. |
| 13:33.06 | *** join/#oe drw (~drw@c-24-0-157-195.hsd1.tx.comcast.net) |
| 13:33.18 | proti | Zero win. back to start. |
| 13:33.35 | zecke | proti: sure one could 'diff' the pickled and freshly parsed data but remember you want to save time |
| 13:34.02 | pb_ | zecke: ah, good idea. You could start a C++ faction. |
| 13:34.21 | proti | zecke: Or maybe, keep the old behaviour. Add an option that says : I know there is no modification in dependencies, I know what I do, don't re-compute them. |
| 13:34.28 | zecke | make Gtk based on Arthur (Qts paint engine) |
| 13:34.31 | *** join/#oe Marsupilami23 (~Marsupila@66.60.139.152) |
| 13:35.03 | pb_ | proti: yeah, you could do that if you want. |
| 13:35.06 | zecke | proti: help me profiling the actual bottlenecks |
| 13:36.09 | proti | zecke: I will have a look at the bottlenecks at home (in 4 hours now). |
| 13:36.42 | zecke | proti: we can write the world cache to a cache |
| 13:36.49 | proti | My point is : To keep bitbake usable, it need to keep the working set of bb files in a reasonable size. |
| 13:36.53 | zecke | proti: and use it if when parsing nothing was changed |
| 13:37.07 | zecke | proti: size in terms of what? |
| 13:37.48 | proti | zecke: Number of parsed files. Don't parse the qt files when you are build the cross compiler. It's a waste. |
| 13:37.56 | proti | /build/building/ |
| 13:38.31 | zecke | proti: bitbake does not know anything about OpenEmbedded packages |
| 13:39.54 | pb_ | zecke: regarding the "world" thing, we should make bitbake only compute the cache if the user actually specified "--world" on the command line. There is no point generating that data for the 99.9% of builds that do not involve world. |
| 13:40.06 | zecke | yupp |
| 13:40.24 | pb_ | and, if you _are_ building world, the ten seconds that it takes to calculate the dependencies are negligible compared to the ten weeks that it takes to actually compile all the packages. |
| 13:40.40 | proti | Yes. It was just an example. The point is to be able to decide something, bitbake must have parsed all the metadata because of possible side-effects. |
| 13:40.55 | pb_ | indeed. |
| 13:41.58 | proti | So give it a hint to ease its work. (deps are a precalculated hint for instance) |
| 13:42.58 | pb_ | If you can propose a way of doing that without causing a significant functional regression, please go ahead. |
| 13:44.46 | *** join/#oe Marsupilami24 (~Marsupila@66.60.139.152) |
| 13:45.00 | CIA-8 | 03pb 07 * r1.3355 10openembedded/packages/howl/ (3 files in 2 dirs): update howl to 1.0.0 |
| 13:45.03 | proti | pb_: I will try. It was the point of the whole discussion. The main difficulty is to be able to decide when a dependency has changed without reparsing the whole world. |
| 13:46.17 | pb_ | Personally, I think that it would be better to direct effort towards making the parser run faster, rather than trying to find ways to avoid running it. |
| 13:48.01 | proti | 2 different ways. I know the parser well now. To accelerate it, you need to make the update_data and update_keys functions faster, or to call them less often (3 times per bb file). |
| 13:48.44 | proti | Or modify the rules for variable expansions. |
| 13:51.46 | koen | VoodooZ_Work: we do the same for hostap |
| 13:52.17 | VoodooZ_Work | hostap? |
| 13:52.47 | koen | we build them outside the kernel, since the kernel has old ones |
| 14:02.27 | hrw|work | NOTE: [16:01] package openttd-0.4.0: completed |
| 14:02.31 | hrw|work | ;) |
| 14:06.35 | hrw|work | it builds, not yet package and who know does it even works.. |
| 14:08.29 | koen | all open bugs are assigned to oe@handhelds.org now |
| 14:08.50 | *** join/#oe qfh (~qfh@ppp-82-135-4-208.mnet-online.de) |
| 14:11.50 | VoodooZ_Work | koen: ok. |
| 14:15.38 | CosmicPenguin | Morning |
| 14:18.17 | *** join/#oe Laibsch (~leggewie@G0e51.g.pppool.de) |
| 14:19.35 | koen | hey CosmicPenguin |
| 14:20.28 | zecke | hrw|work: does it have a Qt backend or is it SDL based? |
| 14:21.20 | hrw|work | zecke: sdl |
| 14:26.34 | Crofton | zecke have you thought about my patches anymore? |
| 14:32.32 | zecke | Crofton: did you send them to me? |
| 14:32.54 | Crofton | the ones for the Osk board? |
| 14:33.03 | Crofton | I think I was talking to you about them ... |
| 14:33.39 | zecke | Crofton: yes and I want to apply your patches, either mail them to me |
| 14:33.47 | zecke | Crofton: or send the URI again :} |
| 14:33.48 | Crofton | http://pastebin.ca/12257 |
| 14:33.52 | Crofton | OK |
| 14:34.20 | Crofton | http://omap-dev.balister.org/~balister/p1.patch |
| 14:34.27 | Crofton | through p5.patch |
| 14:34.44 | zecke | Crofton: see I'm not home, I will not remember the uri when I'm home :} |
| 14:34.48 | Crofton | then I can send new patches per your comments |
| 14:35.00 | Crofton | what is your email? |
| 14:35.29 | zecke | Crofton: zecke@handhelds.org |
| 14:36.05 | hrw|work | <PROTECTED> |
| 14:36.18 | Crofton | ok |
| 14:36.33 | pb_ | hrw|work: is there any reason they can't be submitted via bugzilla right now? |
| 14:36.37 | pb_ | afaik, bugzilla is working fine. |
| 14:37.15 | hrw|work | pb_: there is none |
| 14:37.58 | hrw|work | Crofton: linux-omap_bk.bb get kernel from file:// - how other devs can get it? |
| 14:38.18 | Crofton | I need to delete it :( |
| 14:38.33 | Crofton | I screwed up and put mixed stuff in one changeset |
| 14:38.49 | Crofton | the only way I know to proceed is apply the patch, then delete |
| 14:38.57 | pb_ | why can't you just fix the patch? |
| 14:39.37 | pb_ | if there is junk in those patches that shouldn't be there, please remove it. |
| 14:39.41 | hrw|work | anyway in p4.patch I see linux-omap1_2.6.12-rc2.bb |
| 14:39.51 | Crofton | yep that is the good one |
| 14:40.46 | Crofton | I made the patches via bk, I didn;t want to hand edit and screw them up |
| 14:44.02 | Crofton | I do promise to clean the cruft out as I move forward, and get better at defining changesets |
| 14:44.17 | Crofton | of course then we get to learn a new system in another month or so :( |
| 14:45.19 | hrw|work | p1.patch does not apply to site/arm-linux |
| 14:46.47 | CosmicPenguin | mmmm... quilt |
| 14:47.13 | Crofton | p1 adds a few lines |
| 14:49.54 | hrw|work | fsck.. I forgot that at work bk refuse to do commit ;( |
| 14:52.04 | Crofton | from p1, the important changes are the arm-linux, i686-linux, omap5912osk.conf, and openomap.conf |
| 14:55.30 | *** join/#oe marcan (1337@80.26.156.69) |
| 14:59.12 | *** join/#oe man-di (~man-di@dyndsl-080-228-195-186.ewe-ip-backbone.de) |
| 15:00.11 | offroadgeek | what's the DISTRO variable that I should put in local.conf (is it openzaurus)? |
| 15:02.49 | hrw|work | depends which version you want to build |
| 15:03.03 | hrw|work | offroadgeek: use openzaurus-3.5.4 |
| 15:03.17 | offroadgeek | hrw|work: thanks |
| 15:05.24 | *** join/#oe _Psy (~Bob@HSE-Ottawa-ppp3495732.sympatico.ca) |
| 15:09.11 | *** join/#oe cedric (~cedric@freeway.rd.francetelecom.com) |
| 15:10.20 | offroadgeek | should it possibly be 3.5.3? |
| 15:10.22 | offroadgeek | michael@deb-serv-1:~/stuff/build$ bk clone -ropenzaurus-3.5.4 bk://openembedded.bkbits.net/openembedded |
| 15:10.22 | offroadgeek | remote: ERROR-rev openzaurus-3.5.4 doesn't exist |
| 15:12.15 | hrw|work | Crofton: http://home.hrw.one.pl/oe/diffs/ - files 1.patch to 7.patch - please take a look at them and compare to your patches |
| 15:12.34 | hrw|work | offroadgeek: grab latest OE |
| 15:14.19 | hrw|work | Crofton: maybe linux-omap1 should be just linux-omap |
| 15:14.46 | Crofton | well, there will be omap2 kernels in the future |
| 15:15.46 | hrw|work | I see... |
| 15:16.00 | Crofton | http://focus.ti.com/general/docs/wtbu/wtbuproductcontent.tsp?templateId=6123&navigationId=11990&path=templatedata/cm/product/data/omap_2420 |
| 15:16.03 | hrw|work | it's rather linux-2.6.12-rc2-omap1 |
| 15:16.10 | offroadgeek | hrw|work: if I just did a bk clone this morning, shouldn't that be the latest OE? |
| 15:16.23 | hrw|work | offroadgeek: exactly |
| 15:17.10 | Crofton | In the machine file I call for linux-omap1 |
| 15:17.36 | Crofton | this way I get the latest omap1 kernel without calling for a psecific version |
| 15:17.50 | *** join/#oe bedboi ([U2FsdGVkX@signserv.Signal.Uu.Se) |
| 15:17.52 | bedboi | hi there. |
| 15:18.03 | bedboi | is there any known issue in the current bitbake? |
| 15:18.15 | bedboi | if i try to bitbake something it fails with the following error |
| 15:18.18 | hrw|work | bedboi: update to atleast 1.2.1 |
| 15:18.31 | bedboi | File "/dvdrip/stuff/openembedded/packages/gnu-config/gnu-config-native_cvs.bb:base_do_fetch", line 4, in base_do_fetch |
| 15:18.31 | bedboi | AttributeError: 'module' object has no attribute 'createCopy' |
| 15:18.39 | bedboi | hrw|work: i updated today (with svn) |
| 15:19.10 | hrw|work | Crofton: I would also suggest using linux-2.6.11 + patch-2.6.12-rc2 - less downloading when you switch to 2.6.12-rc4 ;) |
| 15:19.17 | hrw|work | bedboi: bitbake --version gives? |
| 15:19.32 | bedboi | BitBake Build Tool Core version 1.1, bitbake version 1.2 |
| 15:19.35 | hrw|work | old |
| 15:19.39 | bedboi | cool |
| 15:19.40 | hrw|work | BitBake Build Tool Core version 1.2.1, bitbake version 1.2.1 |
| 15:19.42 | bedboi | how to update? |
| 15:20.12 | hrw|work | svn update or grab 1.2.1 from berlios or checkout trunk via svn |
| 15:20.48 | Crofton | hrw|work, too late I already have the rc4 kernel downloaded :) |
| 15:20.54 | Crofton | 1.patch looks good |
| 15:21.07 | bedboi | i svn updated today iirc. |
| 15:21.10 | bedboi | let me see |
| 15:21.25 | koen | bedboi: and remove TMPDIR/cache |
| 15:21.41 | Crofton | there are some minot nits I will fix once I get the base stuff in |
| 15:21.44 | hrw|work | Crofton: basically I applied p1-p5 and made separate patches for it |
| 15:21.57 | Crofton | I understand |
| 15:22.13 | Crofton | When I fix small stuff, I'll keep the changesets better organized |
| 15:22.39 | hrw|work | larger changes are easier to look when split to small ones |
| 15:22.47 | Crofton | yes |
| 15:23.40 | Crofton | 2 and 3 look fine |
| 15:24.38 | Crofton | ok that looks good |
| 15:24.43 | Crofton | all of them |
| 15:24.45 | hrw|work | Crofton: consider rename linux-omap1_2.6.12-rc2.bb into linux-omap_2.6.12-rc2-omap1.bb - then omap5912osk.conf can have "linux-omap" as kernel and when you switch to newer patches only version will change (but maybe I'm wrong - maybe omap1 and omap2 are not related in the same way as rc2 rc3) |
| 15:25.15 | Crofton | omap1 and omap2 won't run on the same machine |
| 15:25.21 | hrw|work | aha ok |
| 15:25.33 | hrw|work | NOTE: [17:21] package gpe-image-1.0: completed |
| 15:25.46 | koen | Crofton: omap1 and omap2 are like pxa255 and pxa270? |
| 15:25.52 | hrw|work | those arm-linux changes are ok too? |
| 15:25.54 | koen | different archs? |
| 15:25.54 | Crofton | hmmm, but configs come from seperate directories |
| 15:26.08 | Crofton | I'm not sure about the pxa |
| 15:26.21 | hrw|work | Crofton: its like i486 and i586? |
| 15:26.40 | bedboi | BitBake Build Tool Core version 1.1, bitbake version 1.2.1 <- is it good? |
| 15:26.43 | hrw|work | anyway - I go home and from there I can push those changes |
| 15:26.47 | hrw|work | bedboi: 1.2.1+1.2.1 |
| 15:26.50 | Crofton | yes |
| 15:27.01 | hrw|work | cu |
| 15:27.03 | Crofton | There are a few people interested is using OR with OSK |
| 15:27.08 | Crofton | thanks alot |
| 15:27.14 | bedboi | how to update build tool core? |
| 15:27.20 | Crofton | getting the exposure will help us make things better |
| 15:27.26 | CosmicPenguin | ooh, evil - Perforce/Emacs integration |
| 15:28.22 | Crofton | The patch from muru.com might change between omap1 and omap2 |
| 15:40.33 | *** join/#oe hufnus (~slonsiki@m011536d0.tmodns.net) |
| 15:49.07 | *** join/#oe bedboi ([U2FsdGVkX@signserv.Signal.Uu.Se) |
| 15:53.23 | hrw | re |
| 15:53.31 | hrw | Crofton: I'm pushing those changes now |
| 15:55.14 | hrw | pushed |
| 15:56.38 | hrw | 1 hour hrw 1.3354.1.7 Add flags to help build omniorb into site files (patch by Philip Balister) |
| 15:56.41 | hrw | <PROTECTED> |
| 15:56.44 | hrw | <PROTECTED> |
| 15:56.47 | hrw | <PROTECTED> |
| 15:56.50 | hrw | <PROTECTED> |
| 15:56.52 | hrw | <PROTECTED> |
| 15:56.55 | hrw | <PROTECTED> |
| 15:59.39 | *** join/#oe RP|tablet (~richard@tim.rpsys.net) |
| 16:01.56 | hrw | cu |
| 16:04.33 | wrobbie | meh. can makedevs make directories at all, or is that part completely broken.. |
| 16:08.25 | Crofton | heh, now I can work on fixing them :) |
| 16:08.29 | Crofton | Thanks alot |
| 16:09.41 | *** join/#oe dmunicio (~dmunicio@138.4.9.103) |
| 16:11.18 | *** join/#oe zap (~zap@217.170.93.196) |
| 16:20.16 | *** join/#oe dmunicio (~dmunicio@138.4.9.103) |
| 16:25.57 | *** join/#oe ar_ (~ar@port-ip-213-211-233-142.reverse.mdcc-fun.de) |
| 16:28.10 | CIA-8 | 03jcrouse 07 * r1.3350 10openembedded/ (2 files in 2 dirs): |
| 16:28.10 | CIA-8 | libxfce4util_4.2.2.bb: |
| 16:28.10 | CIA-8 | <PROTECTED> |
| 16:28.10 | CIA-8 | delete unneeded 4.0.5 files |
| 16:28.13 | CIA-8 | 03jcrouse 07 * r1.3338.1.1 10openembedded/ (41 files in 14 dirs): Remove xfce 4.0.5 etal, and add 4.2.2 (I hope) |
| 16:28.47 | CosmicPenguin | Ok - If I fucked that up - remmeber, its a miracle my dumb ass got that far |
| 16:30.42 | kergoth | proti, pb_: methinks i should add a specific requirement to the list for scalability, both with regard to performance and memory usage. Both use cases will require it, and it's extremely obvious, but it really should be on the list. |
| 16:31.00 | kergoth | (regarding proti's comments on the bitbake-dev list) |
| 16:31.44 | Spyro | pb_: Im told I should talk to you re: xorg 6.8 build failure? |
| 16:34.43 | pb_ | kergoth: ah, I'm not on that list |
| 16:34.53 | pb_ | so, unfortunately, I have no idea what you are talking about. |
| 16:34.54 | pb_ | heh |
| 16:35.40 | CosmicPenguin | kergoth: yeah |
| 16:35.48 | kergoth | pb_: https://lists.berlios.de/pipermail/bitbake-dev/2005-May/thread.html |
| 16:35.49 | *** join/#oe stevenh (~xev@65.167.23.2) |
| 16:35.49 | CosmicPenguin | kergoth: I think parallalization should be a key goal too |
| 16:35.52 | pb_ | kergoth: thanks |
| 16:38.28 | kergoth | CosmicPenguin: good point. that's one of those things we always talk about, but which isnt on the list |
| 16:38.44 | pb_ | yeah |
| 16:38.52 | Ken|JLime | Anyone else having issues with flex not downloading |
| 16:40.09 | koen | Ken|JLime: change the sourceforgemirror in bitbake.conf |
| 16:40.56 | koen | I strongly suspect aleron.sf.net has a faulty flex |
| 16:41.09 | Ken|JLime | Ah, thx. Where can i find a list of mirrors? |
| 16:41.29 | koen | download something from sourceforge :) |
| 16:41.45 | koen | I have heanet.sf.net (ireland based) |
| 16:42.20 | CosmicPenguin | I use easynews in Arizona, USA |
| 16:42.31 | CosmicPenguin | can't remember the server name right off the bat |
| 16:42.31 | Ken|JLime | thx man |
| 16:42.33 | koen | pretty amazing downloading from ireland is faster than a mirror from my country |
| 16:43.03 | Spyro | koen: heanet is well fast :) |
| 16:43.14 | hrw|husky | I use heanet too |
| 16:43.37 | Spyro | and so we see that mirror based systems really work. LOL |
| 16:43.39 | koen | I used to get 3MB/s on my old connection with heanet |
| 16:44.18 | CosmicPenguin | Personally, I blame the mirrors more then I blame Sourceforge |
| 16:44.25 | CosmicPenguin | Not to say that Sourceforge isn't blameless |
| 16:45.30 | CosmicPenguin | Heh - I sort of like that missing variables cause warnings in the new bitbake - its like use strict; in per |
| 16:45.31 | CosmicPenguin | l |
| 16:47.55 | *** join/#oe andersee (~andersee@codepoet.org) |
| 16:51.29 | kergoth | proti: i think your email on the bitbake-dev list comes down to just one requirement. the one i just sent regarding scalability. then comes how exactly to make that happen. the next emails i'm sending will be the actual current bitbake-ng design, and i'd welcome your comments and criticisms on the approaches. |
| 16:52.26 | CosmicPenguin | kergoth must have had a visit from sweet lady motivation |
| 16:52.33 | *** join/#oe zecke (~ich@83-169-170-199-dynip.superkabel.de) |
| 16:52.38 | koen | hey zecke |
| 16:52.55 | treke | morning |
| 16:53.00 | hrw|husky | CosmicPenguin: or bad women leave...... |
| 16:53.05 | hrw|husky | hi treke |
| 16:53.06 | zecke | home :1 |
| 16:57.47 | *** join/#oe uv1 (~Werner@p5089348D.dip0.t-ipconnect.de) |
| 17:01.09 | proti | kergoth: Correct. I was seeing it as do what I asked, and not more. You can however spell it like this : keep the workset as small as possible in memory. |
| 17:07.52 | CosmicPenguin | I still think fixchicken takes the cake as the best patch name |
| 17:09.41 | kergoth | proti: the current implementation of the bitbake-data library uses sqlite3 to hold the parsed data, and is capable of attaching scopes at runtime, so that changing base.bbclass will not result in a reparse of the other files. so when a given file changes, the parser reloads it and stuffs it into the db, adjusts any scopes, if necessary, and everyone else is free to poke at it from there. |
| 17:10.24 | hrw|husky | bye |
| 17:10.29 | kergoth | if we find bottlenecks in sqlite3 performance due to sillyness like requesting the same variable over and over, we can always implement a running cache in ram if need be. wont know whether thats necessary until we profile |
| 17:10.43 | hrw|husky | I go shopping |
| 17:11.05 | zecke | kergoth: sqlite3 seems to perform badly on writing to ext3 |
| 17:11.46 | kergoth | zecke: note that sqlite3 is -much- faster if you do all your operations in a single run. so do all your writes of the changes from a parsed file in a single BEGIN TRANSACTION / COMMIT and that may help matters, due to the way sqlite3 manages its cache. |
| 17:12.11 | kergoth | thats the impression i got form reading performance information adn benchmarks on their site |
| 17:12.52 | *** join/#oe _alwin_ (alwin@cable-81-173-164-239.netcologne.de) |
| 17:13.30 | kergoth | course i'm not exactly sure how to implement that in the api, but we'll figure out something :) |
| 17:13.50 | zecke | kergoth: I guess even with BEGIN TRANSACTION :} |
| 17:14.05 | kergoth | what i was thinking about is a couple functions to supply _hints_ to the datastore. "hey, i'm going to be operating on this file a _lot_ over the next few minutes, so yeah, you might want to consider holding it in ram or something" |
| 17:14.12 | kergoth | hwh |
| 17:14.15 | kergoth | heh |
| 17:14.46 | zecke | kergoth: hinting is always good |
| 17:15.27 | kergoth | anyway, lets cross that bridge when we come to it. i figured we might hit something like that, so it shouldnt be difficult to implement if the numbers justify it |
| 17:15.59 | CosmicPenguin | It might be that SQL is way over complicated for what we need |
| 17:16.13 | kergoth | heh, i've already benefited from it hugely |
| 17:16.19 | kergoth | scoped lookups are nearly free |
| 17:16.25 | kergoth | as is reattaching them on the fly |
| 17:16.30 | zecke | kergoth: do you plan to generate the 'trees' on the fly? |
| 17:16.42 | *** join/#oe stevenh (~xev@65.167.23.2) |
| 17:16.42 | zecke | kergoth: or do you want to store them as well? |
| 17:17.24 | kergoth | zecke: havent yet decided. lots of the design is still open to discussion, like the exact semantics of the builders and representations of inter-recipe relationships |
| 17:17.31 | kergoth | what do you think? |
| 17:17.58 | kergoth | CosmicPenguin, zecke: |
| 17:17.59 | kergoth | SELECT val FROM vars |
| 17:17.59 | kergoth | JOIN scope ON vars.recipe_id = scope.scope_recipe_id |
| 17:17.59 | kergoth | JOIN recipes ON scope.recipe_id = recipes.id |
| 17:18.00 | kergoth | WHERE vars.var = 'CC' AND recipes.recipe = 'base.bbclass' |
| 17:18.00 | kergoth | ORDER BY scope.priority DESC |
| 17:18.01 | kergoth | limit 1; |
| 17:18.07 | kergoth | heh :) |
| 17:18.52 | CosmicPenguin | heh |
| 17:19.02 | CosmicPenguin | Now thats some tasty SQL |
| 17:19.29 | kergoth | so all the variables for all the files are kept in the db, independent from one another, and when you do the query, it only hands you the highest scope of each variable |
| 17:19.39 | kergoth | given CC in multiple scopes, the highest priority scope's value is what you'll get |
| 17:19.53 | *** part/#oe VoodooZ_Work (~VoodooZ@CPE00c0f021712c-CM014110003785.cpe.net.cable.rogers.com) |
| 17:20.37 | kergoth | so the sql is doing what COW was doing, the chained lookups, automatically. |
| 17:20.43 | kergoth | without having to have it all in ram |
| 17:21.55 | _law_ | i have updated to revision 186 but building opie-image always doenst work :-( (http://pastebin.com/287044) |
| 17:22.02 | _law_ | tmp is also clean |
| 17:23.48 | zecke | OT: is there a way to get mails for each commit to openembedded? |
| 17:24.06 | kergoth | drop a new trigger in BitKeeper/triggers |
| 17:24.08 | kergoth | heh |
| 17:24.32 | treke | though I suspect it isnt worth the effort |
| 17:24.40 | treke | since there's only what? another month to go? :p |
| 17:24.43 | kergoth | hehe |
| 17:27.23 | kergoth | eh, whats the comment delimiter in a .sql? |
| 17:27.47 | zecke | dunno |
| 17:33.10 | kergoth | hmmm |
| 17:41.33 | zecke | kergoth: does base.bbclass in oe doing do_unpack? |
| 17:41.47 | kergoth | yes |
| 17:42.23 | zecke | ok one TODO is placed wrongly there |
| 17:42.43 | CIA-8 | 03zecke123 * r187 10bitbake/TODO: |
| 17:42.43 | CIA-8 | bitbake/TODO: |
| 17:42.43 | CIA-8 | <PROTECTED> |
| 17:43.17 | zecke | basic even... god damn |
| 17:46.47 | kergoth | hehe |
| 17:47.34 | zecke | treke: I can not query all bugs :} |
| 17:47.41 | treke | ? |
| 17:48.28 | treke | anyone can do that |
| 17:48.47 | treke | hell I dont think you can turn that off in bugzilla |
| 17:49.09 | zecke | treke: I get an SQL error |
| 17:49.22 | treke | be more specific. |
| 17:49.23 | zecke | treke: 'Search' -> 'Open' -> 'OpenEmbedded' -> 'Search' |
| 17:49.23 | CosmicPenguin | werks for me |
| 17:49.37 | zecke | treke: when I use 'All' instead of 'Open' it works |
| 17:50.04 | zecke | treke: I would paste the error message but it is on another X display |
| 17:50.11 | CosmicPenguin | zecke: this url? |
| 17:50.13 | CosmicPenguin | http://bugs.openembedded.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=Openembedded&content= |
| 17:50.23 | treke | works for me |
| 17:50.54 | koen | me too |
| 17:51.10 | treke | find me a url that breaks |
| 17:53.31 | zecke | treke: ok will do |
| 17:53.36 | koen | www.undefined.void |
| 17:54.48 | zecke | treke: doesn't happen now, I had it today and yesterday... |
| 18:00.35 | kergoth | hmm, i really need to learn sql better |
| 18:00.36 | kergoth | lets see |
| 18:05.50 | CosmicPenguin | Stupid frickin' corporate expense report system |
| 18:06.00 | treke | yours sucks also? |
| 18:06.03 | treke | ~lart concur |
| 18:09.08 | zecke | lol the mcci usb driver looks funy |
| 18:09.21 | *** join/#oe offroadgeek_ (~offroadge@offroadgeek.sustaining.supporter.pdpc) |
| 18:09.45 | treke | hehe yeah I saw that source |
| 18:09.55 | treke | I dont see how it's been obfuscated :p |
| 18:10.08 | treke | thought it was just written in perl |
| 18:11.12 | CIA-8 | 03zecke123 * r188 10bitbake/lib/bb/data_dict.py: |
| 18:11.12 | CIA-8 | bitbake/lib/bb/data_dict.py: |
| 18:11.12 | CIA-8 | <PROTECTED> |
| 18:11.12 | CIA-8 | <PROTECTED> |
| 18:37.15 | koen | treke: could you change 'OpenZaurus' to 'Derived Distros' or something in bugzilla? |
| 18:37.28 | treke | sure |
| 18:37.36 | treke | well |
| 18:37.36 | koen | thanks |
| 18:37.37 | treke | maybe |
| 18:38.02 | CIA-8 | 03zecke123 * r189 10bitbake/lib/bb/data.py: |
| 18:38.02 | CIA-8 | bitbake/lib/bb/data.py: |
| 18:38.02 | CIA-8 | <PROTECTED> |
| 18:38.02 | CIA-8 | <PROTECTED> |
| 18:38.02 | CIA-8 | <PROTECTED> |
| 18:38.05 | koen | mickey|sick's comment was "Yes, change it" |
| 18:38.37 | treke | and the answer is no.It can't be changed |
| 18:38.47 | treke | oh wait wrong window |
| 18:38.48 | treke | it can |
| 18:39.55 | treke | Are you sure we want it changed? It was intended to be bugs strictly for openzaurus and not for derived distributions |
| 18:39.55 | koen | Is there a difference? |
| 18:40.04 | treke | yes |
| 18:41.31 | treke | ipkg-1.4.21 not working isn't a bug in openzaurus if we don't ship ipkg1.4.21. It may be a bug in familiar if you ship it |
| 18:42.36 | treke | I can still change it if everyone wants it changed |
| 18:44.08 | *** join/#oe zmiq (~chatzilla@59.Red-80-35-121.pooles.rima-tde.net) |
| 18:45.06 | koen | treke: the problem is that the ipkg-1.4.21 bug would be caused by OE, but currently has no place in bugzilla |
| 18:45.12 | koen | at least no logical one |
| 18:46.26 | treke | unfortunatly bugzilla sucks as well for us :p |
| 18:47.10 | koen | a distinction between 'metadata' and 'runtime' bugs might be usefull in bugzilla |
| 18:47.30 | treke | the problem here is that versions are product specific and not component specific |
| 18:47.53 | treke | So I guess OpenZaurus could become a Version Number |
| 18:47.56 | treke | and not a Component |
| 18:48.31 | treke | and no one is going to have a clue what runtime is |
| 18:48.49 | koen | that's also true |
| 18:49.43 | treke | maybe the versions method is the more sane way to go |
| 18:50.20 | CosmicPenguin | Do we really have that many packages that are specific enough that it wouldn't be interesting to other distros / platforms that might use those packages? |
| 18:50.46 | kergoth | heh, we had a distros queue in the oe bug tracker |
| 18:50.55 | kergoth | and everyone bitched and moaned left and right about OZ bugs being opened in it |
| 18:51.02 | kergoth | "oh my, oz bugs on the oe list! eep!" |
| 18:51.06 | treke | exactly |
| 18:51.15 | treke | so I gave oz bugs their own place to go to shut them up |
| 18:51.17 | kergoth | doing that again is just going to hit the same complaints |
| 18:51.46 | koen | CosmicPenguin: afaik there aren't any distro specific packages in OE |
| 18:51.47 | treke | The option is I set OZ 3.5.3 and Familiar 0.8.2 as Versions for the Distros component |
| 18:52.05 | koen | CosmicPenguin: maybe distro specific overrides in some packages |
| 18:52.11 | treke | koen: but I don't necessarilly care about every bug in OE |
| 18:52.24 | treke | I want to know what bugs have been reported against OZ when it comes time to do updates |
| 18:53.00 | koen | treke: suppose I file a bug about a package not working in $random_distro |
| 18:53.11 | kergoth | and users wont know if a bug is oz specific or not |
| 18:53.15 | koen | that would also apply to the other distros |
| 18:53.22 | treke | not necessarily |
| 18:53.23 | kergoth | seperating them is going to cause confusion for them in an attempt to make us happier |
| 18:53.31 | kergoth | heh |
| 18:53.41 | koen | so you still need to manually poke bugzilla for a complete overview |
| 18:53.49 | treke | kergoth: they know they use OZ |
| 18:53.58 | CosmicPenguin | versions make sense to me |
| 18:54.16 | treke | versions might make the most sense here |
| 18:54.43 | treke | having a bug tracker that can't tell us what bugs are present in a particular release puts us in the position opie is in |
| 18:54.49 | kergoth | anyone really good at sql? |
| 18:55.12 | treke | define really good :p |
| 18:55.42 | CIA-8 | 03zecke123 * r190 10bitbake/lib/bb/data.py: |
| 18:55.43 | CIA-8 | bitbake/lib/bb/data.py: |
| 18:55.43 | CIA-8 | <PROTECTED> |
| 18:55.43 | CIA-8 | <PROTECTED> |
| 18:55.54 | koen | 'select * from users' got my my boss' password and SS number :) |
| 18:56.01 | treke | So what I'll do is just create a Distros component, and use the different ${DISTRO} values as versions and move everything over |
| 18:56.15 | koen | that makes sense |
| 18:56.29 | *** join/#oe pb_ (~pb@2002:5168:d38c:1:a00:1fff:fe06:93c) |
| 18:56.39 | treke | which gets around the problem that bugzilla can't do per component versions |
| 18:57.05 | kergoth | koen: hah |
| 18:57.19 | zecke | kergoth: the data implementation is correct dunno where the TARGET_FPU problem comes from |
| 18:57.46 | kergoth | weird |
| 18:59.08 | zecke | kergoth: or my test case is broken, incomplete |
| 19:05.22 | zecke | kergoth: yeah the fetcher does not call expand but getVar |
| 19:05.45 | zecke | oh wait |
| 19:05.58 | kergoth | getVar calls expand :P |
| 19:06.56 | bedboi | going home |
| 19:07.08 | *** part/#oe bedboi ([U2FsdGVkX@signserv.Signal.Uu.Se) |
| 19:07.51 | zecke | kergoth: This shows a need for a baseclass for the data modules |
| 19:10.22 | treke | kergoth: you should probably be playing with scms and not bb-ng :p |
| 19:10.28 | kergoth | heh, yeah, probably |
| 19:10.36 | pb_ | heh |
| 19:11.12 | CIA-8 | 03zecke123 * r191 10bitbake/lib/bb/data.py: |
| 19:11.13 | CIA-8 | bitbake/lib/bb/data.py: |
| 19:11.13 | CIA-8 | <PROTECTED> |
| 19:11.28 | pb_ | very good |
| 19:11.34 | zecke | treke: maybe we can use bb-ng as a SCM? |
| 19:11.48 | zecke | treke: using git as recipe handler |
| 19:11.55 | kergoth | hehe |
| 19:11.58 | pb_ | good idea, we can store all the .bb files in a big sql database |
| 19:12.16 | kergoth | i'm already doing that part :P |
| 19:12.31 | pb_ | fear |
| 19:12.44 | kergoth | SELECT val FROM vars |
| 19:12.44 | kergoth | JOIN scope ON vars.recipe_id = scope.scope_recipe_id |
| 19:12.44 | kergoth | JOIN recipes ON scope.recipe_id = recipes.id |
| 19:12.44 | kergoth | WHERE vars.var = 'CC' AND recipes.recipe = 'base.bbclass' |
| 19:12.44 | kergoth | ORDER BY scope.priority DESC |
| 19:12.45 | kergoth | limit 1; |
| 19:13.00 | zecke | pb_: I prefer to store the .bb files as Gödel Number in a file |
| 19:14.47 | pb_ | zecke: good idea. I suppose we could also reimplement bitbake as a turing machine. |
| 19:15.16 | pb_ | then we could use kergoth's large sql database to simulate an infinite tape. |
| 19:15.44 | treke | or we could all just buy palms and try to forget this conversation ever happened |
| 19:15.48 | kergoth | haha |
| 19:16.02 | pb_ | treke: no, that'd suck |
| 19:16.40 | treke | hehe |
| 19:17.29 | kergoth | bleh, time to learn about subselects |
| 19:19.21 | *** join/#oe _law_ (~law@213.173.86.202) |
| 19:19.31 | pb_ | enjoy |
| 19:21.38 | kergoth | hmm |
| 19:21.56 | kergoth | dont suppose any of you know sql well? |
| 19:22.04 | kergoth | heh |
| 19:22.13 | Crofton | used too |
| 19:22.18 | Crofton | in another universe |
| 19:22.34 | pb_ | heh, me too. |
| 19:22.55 | pb_ | I used to hack sql at futuretv, but that was half a decade ago and I have mostly managed to suppress those memories. |
| 19:23.03 | kergoth | to simplify, we've got a table with variable name, variable value, and priority (scope). i want a single query to get the highest priority value of all variables. |
| 19:23.12 | kergoth | and cant see to find a wayt do it |
| 19:23.33 | gb2 | I sometimes pretend to know sql |
| 19:23.43 | pb_ | seems that now would be a good time. |
| 19:23.44 | *** join/#oe do13 (~dirk@p213.54.186.150.tisdip.tiscali.de) |
| 19:24.03 | kergoth | i cant just arbitrarily use MAX(), because thatd get the max priority of the entire table. if i GROUP BY the variable name so that the MAX ends up correct, then the value is hosed from the GROUP BY. |
| 19:24.36 | kergoth | i can look up a single variable easily, because i can ORDER BY priority LIMIT 1 |
| 19:25.18 | zecke | lol the test case is wrong :} |
| 19:25.23 | kergoth | hah |
| 19:25.27 | pb_ | ~herring zecke |
| 19:25.28 | ibot | ACTION whacks zecke on the side of the head with a large red herring named alfred |
| 19:25.45 | zmiq | kergoth: you can use group by and then the 'having' clause |
| 19:27.45 | kergoth | zmiq: already tried. doesnt work. if i say HAVING priority = MAX(priority) with a group by on the variable name, it returns nothing for any variables that have more than one value/priority. you see, when the gruop by happens, it seems to blow away the value and priority fields, giving us the values for those columns from the first instance of the variable. so that by the time we get to HAVING, _none_ match the clause |
| 19:27.53 | kergoth | at least, thats how i'm seeing it. i'm pretty new to this |
| 19:28.06 | zecke | why does bitbake have so many default parameters? |
| 19:28.11 | treke | source archive is down while I put the new one in place |
| 19:28.22 | treke | should just take 5 or so minutes |
| 19:28.56 | pb_ | zecke: usually for backwards compatibility. |
| 19:29.11 | pb_ | the defaulted arguments are ones that didn't originally exist in the function signature. |
| 19:29.25 | kergoth | ah yeah, good call |
| 19:29.47 | zecke | pb_: ok that would make sense if it wouldn't be the data you're operating on |
| 19:30.26 | treke | perhaps this is a sign that you don't want to do this with sql :p |
| 19:30.48 | kergoth | treke: heh, well, sql has given us enough benefits that its definately what i'm using in general, but you're probably right for htis particular operation |
| 19:31.00 | kergoth | i can just query for all the variables for a given recipe and its scopes, and sort out the highest priority of each in C |
| 19:31.02 | treke | what are you trying to do? |
| 19:31.08 | kergoth | i just want to see all the vars for a damn recipe |
| 19:31.10 | kergoth | like bbread |
| 19:31.12 | kergoth | dead simple |
| 19:31.17 | pb_ | zecke: heh. that does sound rather funky. |
| 19:31.23 | kergoth | i want the highest priority (most local scope) of each variable |
| 19:31.26 | treke | kergoth: so what is making it complicated? |
| 19:31.46 | kergoth | figuring out an sql query to get me only the highest priority value for each variable in the table. |
| 19:31.53 | treke | hehe |
| 19:32.07 | kergoth | this is so fucking simple, its trying me nuts that i cant find a way to do it in sql |
| 19:32.10 | kergoth | :\ |
| 19:32.15 | treke | tell your cursor to order by the priority field? |
| 19:32.30 | kergoth | thats how i do a lookup for one variable. i order by priority, then limit to 1 |
| 19:32.38 | treke | should be the same thing |
| 19:32.44 | kergoth | but i want a query to show _all_ variables, and then only get the highest priority of each] |
| 19:32.59 | treke | kergoth: group by |
| 19:33.09 | kergoth | group by variable name using MAX() blows away the value. |
| 19:33.20 | kergoth | ends up having a value of the first variable it found, not the _value_ of the max |
| 19:33.28 | kergoth | already tried |
| 19:33.36 | treke | what database/ |
| 19:33.37 | treke | ? |
| 19:33.39 | kergoth | sqlite3 |
| 19:34.31 | treke | kergoth: email me your db greg@treke.net. Maybe I can fiddle about with it |
| 19:34.47 | kergoth | treke: http://svn.berlios.de/viewcvs/bitbake/trunk/bitbake-data/doc/test_scoped_lookups.sql?rev=185&view=markup |
| 19:35.02 | kergoth | treke: thats it. the example queries are to get the highest priority value of a single variable |
| 19:35.48 | kergoth | who knows, maybe this functionality (scoped lookup of all variables for a given recipe) wont be needed, but i suspect it will, for debugging if nothing else |
| 19:35.53 | kergoth | heh |
| 19:37.07 | CIA-8 | 03zecke123 * r192 10bitbake/lib/bb/data.py: |
| 19:37.07 | CIA-8 | bitbake/lib/bb/data.py: |
| 19:37.07 | CIA-8 | <PROTECTED> |
| 19:37.07 | CIA-8 | <PROTECTED> |
| 19:37.25 | koen | Moo! |
| 19:38.14 | treke | kergoth: we want in order of priority? |
| 19:38.27 | kergoth | treke: we want a query to get each variable's value, but only the highest priority value. |
| 19:38.49 | kergoth | so if CC has two values defined, one in bitbake.conf and one in base.bbclass, the highest priority (base.bbclass) one is the value we see |
| 19:39.46 | kergoth | treke: http://kergoth.com/files/test_scoped_lookups.sql with a couple more queries added, and comments showing what each is doing |
| 19:40.00 | CIA-8 | 03zecke123 * r193 10bitbake/lib/bb/ (fetch.py parse/BBHandler.py): |
| 19:40.00 | CIA-8 | bitbake/lib/bb/fetch.py: |
| 19:40.00 | CIA-8 | <PROTECTED> |
| 19:40.00 | CIA-8 | <PROTECTED> |
| 19:40.01 | CIA-8 | bitbake/lib/bb/parse/BBHandler.py: |
| 19:40.01 | CIA-8 | <PROTECTED> |
| 19:40.03 | CIA-8 | <PROTECTED> |
| 19:41.20 | treke | ok so the value is in scope? |
| 19:42.29 | CIA-8 | 03zecke 07 * r1.3352 10openembedded/classes/base.bbclass: |
| 19:42.29 | CIA-8 | classes/base.bbclass: |
| 19:42.29 | CIA-8 | <PROTECTED> |
| 19:43.35 | zmiq | kergoth: would something like this work? : select vars.val, scope.priority, max(scope.priority) |
| 19:43.37 | zmiq | <PROTECTED> |
| 19:43.38 | zmiq | <PROTECTED> |
| 19:43.40 | zmiq | scope.recipe_id=recipes.is and |
| 19:43.42 | zmiq | <PROTECTED> |
| 19:43.43 | zmiq | <PROTECTED> |
| 19:43.45 | zmiq | <PROTECTED> |
| 19:44.39 | *** join/#oe aboeglin (~aboeglin@213.154.79.4) |
| 19:46.25 | kergoth | sqlite> .read doc/test_scoped_lookups.sql |
| 19:46.25 | kergoth | base.bbclass_cc|2|2 |
| 19:46.25 | kergoth | bitbake.conf_cc|1|1 |
| 19:46.25 | kergoth | bitbake.conf_cxx|1|1 |
| 19:46.37 | kergoth | both values of CC show up with that query |
| 19:46.38 | kergoth | :\ |
| 19:46.47 | kergoth | and man, that query went way over my ability to comprehend |
| 19:48.12 | zmiq | kergoth: yeah, both last values are supposed to be equal, thus the having clause; apart from that, are you getting the rows you expect? |
| 19:48.36 | kergoth | you missed my point. the first two results of that are both CC |
| 19:48.43 | kergoth | we want only the highest priority value of each variable |
| 19:48.47 | kergoth | that returned both |
| 19:49.20 | kergoth | sqlite> .read doc/test_scoped_lookups.sql |
| 19:49.20 | kergoth | CC|base.bbclass_cc|2|2 |
| 19:49.20 | kergoth | CC|bitbake.conf_cc|1|1 |
| 19:50.03 | kergoth | so you see from that that the MAX() isnt the MAX for a given variable |
| 19:50.07 | kergoth | due to the dual group by |
| 19:50.14 | kergoth | the MAX() for CC is always 2 |
| 19:50.17 | CIA-8 | 03zecke 07 * r1.3353 10openembedded/packages/opie-lockapplet/opie-lockapplet.inc: |
| 19:50.17 | CIA-8 | opie-lockapplet/opie-security: |
| 19:50.17 | CIA-8 | <PROTECTED> |
| 19:50.17 | CIA-8 | <PROTECTED> |
| 19:50.17 | CIA-8 | <PROTECTED> |
| 19:50.39 | koen | and zecke closes another bug! |
| 19:51.54 | zmiq | then what about this: select vars.var, scope.priority, max(scope.priority) |
| 19:51.56 | zmiq | <PROTECTED> |
| 19:51.57 | zmiq | <PROTECTED> |
| 19:51.59 | zmiq | scope.recipe_id=recipes.is and |
| 19:52.00 | zmiq | <PROTECTED> |
| 19:52.02 | zmiq | <PROTECTED> |
| 19:52.03 | zmiq | <PROTECTED> |
| 19:52.27 | zmiq | just changes vars.val by vars.var |
| 19:52.44 | zecke | koen: if # do not grow over 10 we will be able to fix all of them :} |
| 19:52.52 | kergoth | sqlite> .read doc/test_scoped_lookups.sql |
| 19:52.52 | kergoth | CC|bitbake.conf_cc|1|1 |
| 19:52.53 | kergoth | CC|base.bbclass_cc|2|2 |
| 19:52.54 | zecke | koen: I know we won't |
| 19:52.57 | kergoth | reversed the order, same behavior |
| 19:53.17 | kergoth | s/^/it / |
| 19:54.08 | koen | zecke: a lot of bugs will be: can't fetch source |
| 19:56.00 | zecke | koen: well, I hope to be able to find that out without bug reports |
| 19:56.52 | koen | as soon as the lab has been moved I'll work at bb_qa a bit more |
| 19:57.01 | treke | ok |
| 19:57.04 | treke | new oemirror is live |
| 19:57.11 | treke | this one sucks a bit less :p |
| 19:57.24 | zecke | treke: how do you mirror source? |
| 19:57.32 | treke | with oemirror.py |
| 19:57.53 | zecke | treke: ran with a cron job? |
| 19:57.56 | treke | yes |
| 19:58.09 | zmiq | uhm... I really don't understand what you are trying to do; my last try: select vars.var, vars.val, scope.priority, max(scope.priority) |
| 19:58.11 | zmiq | <PROTECTED> |
| 19:58.12 | zmiq | <PROTECTED> |
| 19:58.14 | zmiq | scope.recipe_id=recipes.is and |
| 19:58.15 | zmiq | <PROTECTED> |
| 19:58.17 | zmiq | <PROTECTED> |
| 19:58.18 | zmiq | <PROTECTED> |
| 19:58.43 | kergoth | i want _only_ the _highest priority_ _value_ of a given variable. |
| 19:59.09 | kergoth | for CC, in a base.bbclass lookup, i only want to get one row back, the CC|base.bbclass_cc|2 |
| 20:00.48 | kergoth | to make things simpler, ignore the joins and everything. consider a table that contains variable name, value, and priority, with CC|gcc|1, CC|gcc2|2, and CXX|g++|1 |
| 20:00.52 | zmiq | kergoth: have you tried my last try? |
| 20:00.54 | kergoth | a query of that shoudl return: |
| 20:00.59 | kergoth | CC|gcc2|2 |
| 20:01.02 | kergoth | CXX|g++|1 |
| 20:01.13 | kergoth | yes, and it returns: |
| 20:01.14 | kergoth | CC|bitbake.conf_cc|1|1 |
| 20:01.18 | kergoth | CC|base.bbclass_cc|2|2 |
| 20:01.25 | kergoth | which is wrong. the max priority for CC isnt 1, its 2. |
| 20:01.36 | kergoth | so we should only be seeing the base.bbclass one due to the HAVING clause |
| 20:01.42 | kergoth | that isnt whats happening because the MAX() is wrong |
| 20:03.21 | zmiq | can sqlite do subqueries? |
| 20:03.48 | kergoth | zmiq: i think so, yeah. do you have a query using them thatd work? iv'e been trying, and failing, to come up with one |
| 20:03.52 | kergoth | it seems the most likely possibility though |
| 20:04.27 | *** join/#oe mrz80 (~scotsman@n128-227-55-136.xlate.ufl.edu) |
| 20:08.04 | zmiq | uhm... what about this: select vars.var, vars.val, scope.priority, max(scope.priority) |
| 20:08.05 | zmiq | <PROTECTED> |
| 20:08.07 | zmiq | <PROTECTED> |
| 20:08.08 | zmiq | scope.recipe_id=recipes.is and |
| 20:08.10 | zmiq | <PROTECTED> |
| 20:08.11 | zmiq | <PROTECTED> |
| 20:08.13 | zmiq | <PROTECTED> |
| 20:08.14 | zmiq | <PROTECTED> |
| 20:08.16 | zmiq | <PROTECTED> |
| 20:08.17 | zmiq | <PROTECTED> |
| 20:08.19 | zmiq | <PROTECTED> |
| 20:08.20 | zmiq | <PROTECTED> |
| 20:09.09 | kergoth | okay this is the big dillemma. even if that works, what i _really_ want to do is do a query for all the variables, and get only the highest priority of _each_, which means that subselect would have to be on a per variable basis |
| 20:09.20 | kergoth | i think i'm just gonna say fuck it and do it in C :) |
| 20:12.09 | zmiq | ok. i'm pretty sure we were close, but you know, friday night here already .... good luck. |
| 20:12.14 | kergoth | hehe |
| 20:12.18 | kergoth | thanks for the help man |
| 20:13.33 | *** join/#oe pb_ (~pb@2002:5168:d38c:1:a00:1fff:fe06:93c) |
| 20:15.13 | treke | kergoth: just iterate over all the variables and et the highest of that one :p |
| 20:15.48 | kergoth | hehe |
| 20:15.48 | CosmicPenguin | heh - "fuck it and do it in C" |
| 20:15.49 | kergoth | yep |
| 20:15.53 | CosmicPenguin | I should have a sign made and put it over my desk |
| 20:16.02 | pb_ | heh |
| 20:16.06 | kergoth | heh |
| 20:16.06 | pb_ | good idea |
| 20:16.14 | treke | it seems that no matter your schema there is always some odd thing that's fucking annoying to code |
| 20:16.52 | *** join/#oe dkey (~dkey@L0007P20.dipool.highway.telekom.at) |
| 20:17.50 | *** join/#oe luke-jr_ (~luke-jr@207.192.221.172) |
| 20:25.57 | zecke | hrw|husky: is houseoffish.org down or behind a broken router? |
| 20:27.04 | *** join/#oe _alwin_ (alwin@cable-81-173-131-202.netcologne.de) |
| 20:30.01 | kergoth | zmiq: tested your last query, and it does indeed behave the way it should, returns just CC|base.bbclass_cc|2|2 |
| 20:30.07 | *** join/#oe PenZ (Pendalar@67.141.163.211) |
| 20:32.00 | zecke | wb _alwin_ |
| 20:41.30 | kergoth | zmiq: |
| 20:41.31 | kergoth | SELECT vars.var,vars.val,scope.priority FROM vars |
| 20:41.31 | kergoth | JOIN scope ON vars.recipe_id = scope.scope_recipe_id |
| 20:41.31 | kergoth | JOIN recipes ON scope.recipe_id = recipes.id |
| 20:41.31 | kergoth | JOIN (SELECT vars.var var,MAX(scope.priority) max |
| 20:41.33 | kergoth | <PROTECTED> |
| 20:41.35 | kergoth | <PROTECTED> |
| 20:41.37 | kergoth | <PROTECTED> |
| 20:41.39 | kergoth | <PROTECTED> |
| 20:41.41 | kergoth | <PROTECTED> |
| 20:41.43 | kergoth | WHERE recipes.recipe='b.bb' AND |
| 20:41.45 | kergoth | scope.priority=m.max; |
| 20:41.47 | kergoth | there's probably a more optimal way, but that works |
| 20:42.00 | kergoth | joining the results of a subselect, named, on the variable names matching :) |
| 20:42.16 | kergoth | jesus is that ugly |
| 20:42.32 | zecke | kergoth: store these as functions? |
| 20:43.42 | zmiq | kergoth: glad you made it; as ugly as a sith? |
| 20:43.53 | kergoth | hehe |
| 20:45.54 | zmiq | so now it's my turn: using oe-oz3.5.3 and the python packages, what packages are required to get pickle working? I get the error 'self.append(rep.decode("string-escape")) LookupError: no codec search functions registered: can't find encoding' when doing pickle.load |
| 20:46.18 | zecke | zmiq: rm tmp/cache? |
| 20:46.39 | zmiq | it's a python question, not oe |
| 20:46.52 | zecke | zmiq: import pickle |
| 20:47.11 | zecke | zmiq: or for a better pickler use cPickle |
| 20:47.16 | zmiq | import pickle is already there ;-) |
| 20:47.36 | XorA|gone | add more vinegar for perfect pickle |
| 20:48.00 | zmiq | the problem is that even i have ipkg installed python-pickle, I get this error ... |
| 20:48.06 | koen | mmmm pickles |
| 20:48.24 | zecke | zmiq: ok maybe some module is missing? |
| 20:48.41 | zmiq | which one? |
| 20:48.58 | zmiq | i wouldn't like to install them all ... |
| 20:49.37 | zecke | zmiq: dunno, some picker format implementation :} |
| 20:49.44 | zecke | zmiq: you would need to look into the code |
| 20:49.49 | zmiq | the script actually works on my gentoo; it's on the zaurus that I get this error, without info on what is missing ... |
| 20:50.08 | *** join/#oe skopii (~john@c-67-167-202-47.hsd1.il.comcast.net) |
| 20:50.30 | zmiq | and pickle.dump works fine; it pickle.load that brings the error ... |
| 20:50.50 | zecke | zmiq: 'no codec search functions registered' |
| 20:51.05 | zecke | zmiq: sounds pretty obvious it can't ask/create the factory |
| 20:52.33 | zmiq | zecke: i'm kind of newbie to python; what do you mean? Actually I think i need to install some other python-* package; just wondering which one. Anything I can try? |
| 20:53.06 | zecke | zmiq: I don't know how pickle works internally but I know the concept of a factory as it is pretty language neutral |
| 20:53.17 | zecke | zmiq: did you look into pickle.py yet? |
| 20:53.31 | zecke | zmiq: it might be a packaging bug |
| 20:53.33 | zmiq | no |
| 20:54.05 | zmiq | should I? oh.. I hate to spend time on this type of debugging, while it works in the desktop ... |
| 20:55.35 | zecke | zmiq: so now I should spend time to look into pickle.py for you? |
| 20:55.51 | zecke | zmiq: what is rep? |
| 20:56.21 | treke | kergoth: you have a larger version of img.jpg? |
| 20:56.26 | zmiq | uhmm... I'm not asking for that; I was just asking for some help some of you guys could just give right away ... |
| 20:56.26 | treke | er logo.png |
| 20:56.46 | CIA-8 | 03kergoth * r194 10bitbake-data/doc/test_scoped_lookups.sql: Update the scoped db example queries to show a query that displays the highest priority values of all variables in a given recipe and its scopes (not like a bbread on the recipe). |
| 20:56.48 | kergoth | treke: we have the svg :P |
| 20:56.51 | kergoth | make whatever size you want |
| 20:56.53 | treke | whehe cool |
| 21:04.35 | *** join/#oe woglinde (woglinde@p54BD7115.dip.t-dialin.net) |
| 21:06.18 | *** join/#oe reenoo_ (~r@p5489BE06.dip.t-dialin.net) |
| 21:06.34 | reenoo_ | evening |
| 21:08.55 | Spyro | anyone got a non-kdrive xserver binary handy ? |
| 21:09.46 | CIA-8 | 03kergoth * r195 10bitbake-data/doc/test_scoped_lookups.sql: Make the sql queries in the .sql a bit more readable. |
| 21:14.18 | *** join/#oe molivier2 (~mac@f01m-31-11.d4.club-internet.fr) |
| 21:16.10 | *** part/#oe subdue (~chopstix@198-79-109-131.hi.net) |
| 21:22.54 | woglinde | hi xora |
| 21:24.53 | tmbinc | hi woglinde |
| 21:26.12 | woglinde | he tmbinc |
| 21:26.42 | woglinde | tmbinc I saw that you tested gcc4.0 for the dreambox |
| 21:28.07 | CosmicPenguin | http://users.bigpond.net.au/Peter-Williams/ |
| 21:28.08 | CosmicPenguin | heh |
| 21:28.33 | kergoth | zecke: http://www.sqlite.org/cvstrac/wiki?p=PerformanceConsiderations |
| 21:28.43 | kergoth | I did a timed test with inserting 1000 records into a table in various ways to compare performance: |
| 21:28.43 | kergoth | <PROTECTED> |
| 21:28.43 | kergoth | <PROTECTED> |
| 21:28.43 | kergoth | <PROTECTED> |
| 21:28.43 | kergoth | <PROTECTED> |
| 21:28.45 | kergoth | heh |
| 21:28.50 | kergoth | </quote from that page> |
| 21:29.30 | zecke | kergoth: that is sqlite2 and no fs specified |
| 21:29.35 | *** join/#oe offroadgeek_ (~zaurus@offroadgeek.sustaining.supporter.pdpc) |
| 21:30.32 | kergoth | zecke: yeah, i know, but you get the idea. http://www.sqlite.org/speed.html has info as well |
| 21:33.23 | zecke | kergoth: Don't take this complaining too seriously |
| 21:33.39 | kergoth | just pointing out what i read before |
| 21:34.21 | kergoth | hmm, the sqlite sources includes a .tcl for speed testing |
| 21:34.24 | kergoth | going to try it |
| 21:35.20 | tmbinc | woglinde: hu? no i'm sticking with gcc 3.4.3. I'm not good at testing experimental gccs :) i'm happy if i have a stable environment, and right now i wouldn't consider gcc4 to be that much stable... |
| 21:36.31 | woglinde | hm I meant ihr |
| 21:36.37 | woglinde | hm or only ghostrider |
| 21:44.15 | *** join/#oe do13 (~dirk@p213.54.180.37.tisdip.tiscali.de) |
| 21:47.29 | roh | woglinde: gcc4 is still misscompiling a lot of code... i would not want to use it right now |
| 21:48.15 | woglinde | roh i saw commits for engima |
| 21:48.16 | zecke | roh: no pain no gain |
| 21:48.37 | woglinde | fixing code for gcc-4 *g* |
| 21:49.25 | zecke | woglinde: You can compile code with g++-4.0 it is pickier/better |
| 21:51.04 | CIA-8 | 03zecke123 * r196 10bitbake/lib/bb/fetch.py: |
| 21:51.04 | CIA-8 | bitbake/lib/bb/fetch.py: |
| 21:51.04 | CIA-8 | <PROTECTED> |
| 21:51.04 | CIA-8 | <PROTECTED> |
| 21:51.28 | zecke | hrw|husky: where do I get knights from? |
| 21:52.40 | roh | woglinde: i would wait till the bugs in gcc4 are fixed... and only fix code if its really the code and not gcc thats buggy. |
| 21:59.23 | *** part/#oe pH5 (~ph5@p5485C885.dip.t-dialin.net) |
| 22:00.13 | *** part/#oe zmiq (~chatzilla@59.Red-80-35-121.pooles.rima-tde.net) |
| 22:01.22 | *** part/#oe offroadgeek_ (~zaurus@offroadgeek.sustaining.supporter.pdpc) |
| 22:06.54 | *** join/#oe jamie (~jamie@softmodem.org) |
| 22:15.07 | *** join/#oe jamie (~jamie@softmodem.org) |
| 22:15.13 | *** join/#oe offroadgeek_ (~zaurus@offroadgeek.sustaining.supporter.pdpc) |
| 22:17.06 | *** join/#oe Hertog (~gertjan@cc233190-a.ensch1.ov.home.nl) |
| 22:18.34 | koen | hey Hertog |
| 22:19.06 | Hertog | Hey Koen :) |
| 22:19.43 | Hertog | koen: and, what's your estimate, how many Zauri in Enschede? |
| 22:19.56 | koen | 3, maybe 4 |
| 22:20.21 | koen | I've seen someone with a 5600 on the uni |
| 22:21.21 | Hertog | ah, prolly bought em in Germany, they where officially released there a while ago I think |
| 22:21.51 | koen | a few years back I almost bought one in the german mediamarkt |
| 22:22.20 | Hertog | :) I know the feeling ;) |
| 22:22.56 | koen | I got an ipaq 2210 instead |
| 22:23.06 | koen | no keyboard, but it does have bluetooth |
| 22:23.21 | Hertog | hehe, I go even further back, I think.. Philips Nino |
| 22:23.31 | Hertog | Massive brick |
| 22:23.36 | *** join/#oe hufnus (~slonsiki@m7b3036d0.tmodns.net) |
| 22:23.39 | koen | I *almost* ordered a c1000 last week |
| 22:23.51 | koen | till I realized it still hasn't bt and wifi |
| 22:23.59 | koen | (and I have too much gadgets allready) |
| 22:24.14 | kergoth | hehe |
| 22:24.29 | XorA|gone | koen: you never have too much until the wife moans |
| 22:24.46 | Hertog | nope, the perfect handheld still doesn't excist.. clamshell, keyboard, HD a plenty, buildin wifi&bluetooth |
| 22:24.52 | koen | XorA|gone: girlfriend complained a while ago, so I gave her the h2210 |
| 22:25.24 | koen | showed her virtualdub, and now it's her mobile friends+ER watching device |
| 22:25.24 | Hertog | Girlfriend can complain all she wants, I just bought three Samsung 173P 17'' LCD's :) |
| 22:25.28 | XorA|gone | mine didnt want a 5500 |
| 22:25.51 | Hertog | Makes for one hell of a desktop,, not really mobile tho |
| 22:26.45 | koen | Hertog: I once had a sparc5 + 3x 20" working |
| 22:26.55 | koen | I had to give it up when I moved |
| 22:27.14 | Hertog | eh, sucks |
| 22:27.32 | ljp | I thought I read you had to give your girlfriend up when you moved ;) |
| 22:28.44 | koen | heh, no |
| 22:32.20 | woglinde | hehe |
| 22:34.02 | *** join/#oe aboeglin (~aboeglin@213.154.79.4) |
| 22:45.52 | reenoo_ | 'night all |
| 22:46.25 | Hertog | hmmpf, smash me to pieces if this is the wrong place, but, err, is mtd-utils-native supposed not to be available on the downloadsites? |
| 22:47.54 | Hertog | it wants to fetch mtd-snapshot-20050414.tar.bz2, but there is no 200504XX at the various sites |
| 22:48.32 | *** join/#oe treke (~ggilbert@68-66-243-62.ventca.adelphia.net) |
| 22:48.56 | treke | the template system in bugzilla is pretty ugly :p |
| 22:51.26 | treke | and theres a line on oe.org I litterally see no reason for |
| 22:52.35 | woglinde | koen oh my god |
| 22:53.59 | zecke | init=emerge gcc-2.95.3 |
| 22:55.54 | zecke | ~lart tinderbox2 |
| 22:56.57 | treke | wtf |
| 22:57.09 | treke | the same html renders differently on two different servers |
| 22:57.42 | koen | yeah |
| 22:57.51 | koen | apache server much better html as IIS |
| 22:58.06 | koen | s/server/serves/ |
| 22:58.12 | Spyro | koen: LOL :) |
| 23:00.38 | treke | http://bugs.openembedded.org/oz.html |
| 23:00.42 | treke | http://openembedded.org/ |
| 23:00.53 | treke | do those look the same to you? |
| 23:01.52 | koen | extra line on the right |
| 23:01.56 | koen | argh |
| 23:01.58 | treke | I dont get it |
| 23:01.58 | koen | the latter |
| 23:02.02 | treke | it's the same HTML |
| 23:02.22 | koen | i've seen reports of hh.org messing up css by setting hte wrong mime-type |
| 23:02.56 | treke | the css is in the file |
| 23:05.52 | treke | there is no logical reason they should render exactly the same way |
| 23:13.11 | zecke | tinderbox outsmarts me |
| 23:14.14 | treke | hehe |
| 23:14.18 | treke | what's going wrong |
| 23:14.35 | treke | zecke: take a look at http://buildbot.sourceforge.net/ |
| 23:16.36 | zecke | treke: is that python based? |
| 23:16.46 | zecke | it must be better than tinderbox then :} |
| 23:17.29 | treke | zecke: yes |
| 23:17.46 | treke | zecke: Was talking to someone who used it before for a fairly large app. He was mostly happy |
| 23:17.52 | treke | http://bugs.openembedded.org/ is less ugly now |
| 23:17.54 | zecke | BuildBot like BitBake... |
| 23:18.07 | treke | at least the main page |
| 23:18.09 | *** join/#oe BigAl (~bigal@dsl-202-45-98-149.ACT.netspace.net.au) |
| 23:20.04 | koen | 'night all |
| 23:23.18 | zecke | treke: can I create a new category in the bug tracker? |
| 23:23.22 | zecke | treke: missing source? |
| 23:23.33 | treke | you can't |
| 23:23.43 | treke | those belong in the build section |
| 23:28.39 | zecke | treke: I would like to send automatically generated bug reports with tinderbox... |
| 23:28.50 | zecke | treke: but not spam the bug tracker, hence different sections |
| 23:31.56 | treke | they belong in the proper section |
| 23:32.06 | treke | if the source isn't accessible it's a build problem |
| 23:32.15 | treke | so spam the fucking tracker if there are that many of them |
| 23:33.25 | Hertog | I guess that means I should file a bug for mtd-snapshot then |
| 23:53.59 | treke | zecke: you fiddled with buildbot at all year? |
| 23:54.08 | treke | yet |
| 23:54.19 | kergoth | just saw Collateral. pretty good movie |
| 23:54.26 | treke | yeah |
| 23:54.28 | treke | I liked it |
| 23:55.09 | kergoth | can never go wrong with the classic 'ordinary guy gets thrown into extraordinary circumstances" plot lines |
| 23:55.11 | kergoth | heh |
| 23:59.07 | zecke | treke: no, I guess I'll get tinderbox running first |
| 23:59.39 | treke | zecke: if you need hardware, you can install it on treke.net |
