IRC log for #oe on 20070324

00:14.33*** join/#oe mwester-laptop (n=mwester@gw.mwester.net)
00:25.54*** join/#oe orion__ (n=orion@59.176.111.177)
00:31.15*** join/#oe cedric (n=cedric@mieuh.bluebugs.org)
00:39.06*** join/#oe idealm (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au)
00:44.47JoseJX<PROTECTED>
00:47.34*** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net)
00:50.09*** join/#oe orion__ (n=orion@59.176.111.177)
00:53.19*** join/#oe marcan (n=marcanso@160.10.7.121)
00:56.02*** join/#oe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net)
00:59.29*** join/#oe vivijim (n=vivijim@20132170187.user.veloxzone.com.br)
01:31.27*** join/#oe cworth (n=cworth@c-67-160-161-141.hsd1.or.comcast.net)
01:34.04*** join/#oe punkass (n=user@unaffiliated/punkass)
01:43.09*** join/#oe wooddragon (n=orion@59.176.111.177)
01:52.19*** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net)
02:10.08*** join/#oe kerwood|afk (n=Marshall@c-69-255-98-58.hsd1.md.comcast.net)
02:10.10*** join/#oe do13- (n=nnnnnndi@do13.in-dsl.de)
02:21.36*** join/#oe Varoudis (n=varoudis@athedsl-106866.otenet.gr)
02:29.06*** join/#oe do13- (n=nnnnnnnd@do13.in-dsl.de)
02:44.11*** join/#oe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net)
02:56.15*** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net)
03:33.37*** join/#oe Ifaistos (n=stelios@ipa226.211.tellas.gr)
03:56.28*** join/#oe daurnimator (n=fake@unaffiliated/daurnimator)
04:04.23*** join/#oe T0mW (n=Tom@24.238.86.158.res-cmts.sth.ptd.net)
04:13.43*** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net)
04:49.30*** join/#oe _schurig (n=schurig@pd95fbecb.dip0.t-ipconnect.de)
04:50.04*** join/#oe SonicvanaJr (n=Garrett@cblmdm72-240-97-94.buckeyecom.net)
05:16.32*** join/#oe T0mW (n=Tom@24.238.86.158.res-cmts.sth.ptd.net)
05:48.06*** join/#oe hufnus (i=root@69-12-177-67.dsl.static.sonic.net)
06:33.20*** join/#oe rd_ (n=redragon@vnsecurity.net)
07:36.42*** join/#oe idealm (n=ideal@c58-107-18-60.belrs2.nsw.optusnet.com.au)
07:49.23*** join/#oe Sleep_Walker (n=Sleep@195.22.44.103.adsl.nextra.cz)
07:49.41*** join/#oe greentux (n=lemke@195.227.105.180)
07:56.42*** join/#oe zap (n=zap@16.170.249.ozerki.net)
08:20.40*** join/#oe den-ros (n=den@ppp91-76-77-111.pppoe.mtu-net.ru)
08:20.50*** join/#oe psokolovsky__ (n=psokolov@82.193.98.7)
08:21.28*** join/#oe koen_ (n=koen@212.41.157.237)
08:25.07*** join/#oe ssvb (n=user@87.252.225.64)
08:27.06*** join/#oe ssvb (n=user@87.252.225.64)
08:32.25*** join/#oe koen__ (n=koen@212.41.157.237)
08:36.38*** join/#oe koen___ (n=koen@212.41.157.237)
08:37.42*** join/#oe koen____ (n=koen@212.41.157.237)
09:16.32*** join/#oe goxboxlive (n=goxboxli@206.80-202-161.nextgentel.com)
09:21.05*** join/#oe grma (n=grma@85-126-107-146.static.sdsl-line.inode.at)
09:29.11CIA-1103koen 07org.oe.dev * rb0b98bec... 10/ (1 packages/mplayer/mplayer_svn.bb): mplayer: add optimizations for a780 and hx4700
09:33.39rwhitbydid someone forget to check in a no-xwc.patch ?
09:34.21CIA-1103koen 07org.oe.dev * r183ae1b2... 10/ (1 packages/gsm/files/default): gsm: add default 'default' file
09:34.57koen____rwhitby: that or checked in a wrong SRC_URI
09:35.05koen____rwhitby: but if you get that message, you hit a bug
09:35.26koen____(I'm not aware you have a machine that uses directFB)
09:37.41*** join/#oe pH5 (n=ph5@p5485db94.dip.t-dialin.net)
09:40.09rwhitbyyeah, all the PREFERRED_PROVIDER_gdk-pixbuf-loader-* stuff is missing from moko svn.  when mickey|zzZZzz gives me an account I can fix that :-)
09:40.38koenor when they finally deprecate their svn
09:42.15*** join/#oe mrdata (i=mrdata@dslb-088-074-149-086.pools.arcor-ip.net)
09:53.52*** join/#oe Marex (n=Marex@85.132.236.161)
10:05.32CIA-1103koen 07org.oe.dev * re2677fad... 10/ (1 packages/tasks/task-openmoko.bb): task-openmoko: remove some duplication with task-base and add sms and rss app
10:08.00keesjwhat base distro/gcc version do people use here .
10:08.32keesjI have two gentoo based system and only one of them is capable of  compiling gcc
10:08.55keesj(that is the oe gcc) of course gentoo is able to compile any gcc version
10:09.29*** join/#oe koen (n=koen@212.41.157.237)
10:10.34*** join/#oe likewise (n=Leon_Woe@82-171-189-134.dsl.ip.tiscali.nl)
10:11.56*** join/#oe dion (n=dion@inhex.net)
10:14.24keesjon this machine I keep hitting this message CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/libffi
10:15.06likewisekeesj: what are you building? (hoi)
10:16.11keesjI am trying to build nano , but the error comes from gcc-cross-initial-4.1.1
10:16.52keesjI have my machine set to smdk2440 and my DISTRO set to generic.
10:17.38keesjI tried different tastes
10:18.00*** join/#oe koen__ (n=koen@212.41.157.237)
10:18.23likewisekoen__: good morning
10:19.31koenhey likewise
10:22.57koenNAiL: You're using uclibc svn for ARM?
10:23.45likewisekeesj: my nano seems not to depend on libffi
10:24.03NAiLkoen: I'm trying ;)
10:24.45likewiseNAiL: Isn't uclibc almost unmaintained currently?
10:24.56likewiseNAiL: Sorry, the SVN tree I mean.
10:25.12keesjlikewise I guess that anything I try to build will fail , perhas I must try the task-base first?
10:25.36NAiLlikewise: I don't know. But I get further with the svn tree than 0.9.28
10:25.52likewisekeesj: in theory no, dependencies should be respected
10:26.58koenlikewise: CSL and others are waiting for the .29 release to merge their stuff
10:27.19koenso proper development is halted till Erik does 'make dist'
10:27.38likewisekoen: yup, that would be a nice point to jump in on uclibc again.
10:28.06likewisekeesj: I wonder why there is also a package called "libffi-2.0+gcc3.4.1" if you seem to have problems with the gcc-4.1.x combo
10:28.10koenthe release was supposed to happen shortly after fosdem
10:35.47keesjkoen was it nice in recife, I did not see much coverage
10:36.06koenkeesj: very nice!
10:37.49keesjgreat
10:38.56*** join/#oe Laibsch (n=Laibsch@F733c.f.ppp-pool.de)
10:39.07likewiseLaibsch: morning!
10:39.15Laibschgood morning likewise
10:39.25Laibschgood morning everyone
10:40.09likewisewhooo, mtn annotate takes it easy...
10:40.43koenlikewise: mtn >= 0.32?
10:41.19likewiseI would expect the annotate algorithm to work backwards until all lines are covered, instead of going through 13k revisions... mtn == 0.31
10:41.32koenright, 0.31 is slow
10:41.44koen0.32 is a few orders of magnitude faster
10:41.45likewisekoen: ok, will try >= 0.32
10:41.58koen'seconds' versus 'hours'
10:42.58koenlikewise: and get a new db snapshot, since the format change to accomodate some cached info (the one that makes log and annotate faster)
10:55.39CIA-1103likewise 07org.oe.dev * r42e4a37b... 10/ (1 classes/image.bbclass): image.bbclass: Removed wildcard rm as it broke building multiple rootfs image types.
11:01.36*** join/#oe Kristoffer (i=Kristoff@h207n1fls306o1049.telia.com)
11:16.35*** join/#oe wbx (n=wbx@gprs-pool-1-016.eplus-online.de)
11:19.22*** join/#oe timtimred (n=On3@62-31-181-7.cable.ubr02.chel.blueyonder.co.uk)
11:22.41*** join/#oe mr_nice (n=mr_nice@p54a9d43e.dip.t-dialin.net)
11:22.42mr_nicehi all
11:24.07mr_nicehow can I say to gtk+_2.10.9.bb that it should use the directory of gtk+-2.10.9 and not a directory called files to get ist patches from? I am running into a patching error saying that it is missing a patch.
11:25.01mr_nicesorry gtk+-directfb_2.10.9.bb not gtk+_2.10.9.bb
11:25.44DerCornyjust remove the ...directfb.bb file
11:27.57mr_niceDerCorny: thx, I will try it
11:28.44DerCornymr_nice: well, it did the job for me - hope it works for you, too
11:33.36mrdatamr_nice: hi, battery status now works with gpe-image also
11:34.11mrdatamr_nice: but i have not using the battery class from hh.org
11:36.30mrdatamr_nice: now i'am ready to search, why does simpad do not suspend
11:48.00*** join/#oe zecke (n=ich@88.134.99.50)
11:48.44*** join/#oe darmou (n=darmou@ppp131-47.lns3.mel6.internode.on.net)
11:48.48mrdatazecke: hi
11:50.33mr_nicemrdata: hi
11:51.04mr_nicemrdata: you was using the apm funktion for it?
11:52.50mrdatamr_nice: yes, i get apm_get_power_status = simpad_apm_get_power_status working
11:53.55mrdatamr_nice: cat /proc/apm gives now correct results
11:54.11mr_nicemrdata: ah, ok also cool to have that. afaik there is no common interface for battery
11:54.21mr_nicemrdata: i think
11:56.12mr_nicemrdata: I am building a Image atm. on next tuesday my holydays starts (2 weeks) so I hope I will find then more time for the simpad stuff.
11:57.16mrdatamr_nice: yes, so i used my own work on ucb1x00-simpad.c and fill with simpad_get_battery function struct simpad_battery_apm
11:58.51mr_nicemrdata: do you know if the driver just shows the status of the battery or is it also responsable for charging stuff?
11:59.31mrdatamr_nice: and in simpad_pm.c i use simpad_apm_get_power_status -> simpad_get_battery
11:59.50mrdatamr_nice: the whole stuff
12:00.31mr_nicemrdata: so it could overload the battery?
12:00.37mr_nicemrdata: I wonder how they calculated the less then 8.5 volt = no power supply for cl4 and less 12 v for sl4
12:00.54mrdatamr_nice: the whole struct apm_power_info() is correct now
12:01.07mr_nicemrdata: hehe, ah ok :) thats nice
12:01.35mr_nicemrdata: apm is an importent thing for that device I think
12:02.07mrdatamr_nice: ucb1x00 -> vcharger tell the voltage for power supply
12:03.48*** join/#oe mwester-laptop (n=mwester@gw.mwester.net)
12:04.13mrdatamr_nice: if power supply on, than vcharger > 12000, if power supply off vcharger = 800 or so
12:05.51mrdatamr_nice: witch voltage have your power supply for cl4?
12:06.25mr_nicemrdata: I wondered because my 2 power suplys (sl4, t-sinus) are identicaly
12:06.34mrdatamr_nice: you told me, that you have two SIMpads
12:06.37mr_nicemrdata: 12v
12:06.51mr_nicemrdata: 3300mA
12:07.30mr_nicemrdata: they are exactly the same
12:08.06mr_nicemrdata: I don't know if there exists a different one for cl4 or swisscom wp50
12:08.18mrdatamr_nice: than i understand, you have two V4415-Z35-X11
12:09.10mr_nicemrdata: yes
12:09.28mr_nicemrdata: interesting http://lkml.org/lkml/2007/2/2/217
12:10.47mrdatamr_nice: yes, have also found and reading that
12:12.05*** join/#oe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net)
12:12.13mrdatamr_nice: you must only change MIN_SUPPLY from 8500 to 12000 for your SMALL_BATTERY
12:12.57mr_nicemrdata: do you think 8.5 V is used by cl4 or wp50?
12:13.47mr_nicemrdata: would be good to know
12:14.25mrdatamr_nice: yes, but i have no cl4 or wp50
12:14.43meisterhi$
12:15.30mrdatamr_nice: you could also change -> CALIBRATE_BATTERY(a)   ((((a + 3)*12610)/860) + 170)
12:16.03mrdatamr_nice: this gives the right vbatt voltage for akku
12:18.47mr_nicemrdata: hm, so we need at least 3 kinds of precompiled modules?
12:19.33mr_nicemrdata: we should consider about getting the type of the bat as an argument to the module end exclude it from the kernel
12:19.40mrdatamr_nice: the battery could not be overload by us, because the charge circuit for it works without us
12:19.55mr_nicemrdata: thats very nice!
12:20.56mr_nicemrdata: I will rewrite the battery module that way that you can define the battery and power supply stuff at modules.conf
12:21.56mrdatamr_nice: when vcharger >= 8500, the power supply is definedly on line, i think
12:23.31mr_nicemrdata: you are the electrical guy ;) I will trust you
12:23.36mrdatamr_nice: charging tell us icharger, when vcharger >= 8500
12:23.56mr_nicemrdata: 8300 is the level of a big size battery
12:24.31mrdatamr_nice: i have wrote this to you, it's my job
12:24.41mr_nicemrdata:hehe yes
12:24.59mr_nicemrdata: so I will exclude it from the config
12:25.16mr_nicemrdata: and only ask about the battery type
12:26.31mrdatamr_nice: i have set BATT_FULL to 8100, because when the charging ends, vbatt = 8425 or so
12:28.02mr_nicemrdata: for the big bat?
12:28.12mrdatamr_nice: but when power supply offline, vbatt drop to lower value, because SIMpad is on
12:28.34mrdatamr_nice: and backlight dains the akku down
12:28.48mr_nicemrdata: ah, good to know
12:29.38mrdatamr_nice: yes, small or big akku is not that thing, both have li-ion akku and there max. voltage is 8.4
12:30.36mr_nicemrdata: what is the charging led level thing good for?
12:31.18mrdatamr_nice: it is also a voltage, which represent the current for charging li-ion akku
12:32.00mrdatamr_nice: li-ion charging works with constant current, and than with constant voltage to fullfill the akku
12:32.36mrdatamr_nice: the last current was lower and lower
12:33.31mrdatamr_nice: and when icharger is 27 or 28 (becaus of ADC error from ucb1300), than charging is done, and akku full
12:34.53mr_nicemrdata: do you know if it is save to not use the fuse on a rebuild accu as it is described here(http://opensimpad.org/index.php/Accu_replacement_with_cheap_OEM_cells)?
12:35.06mrdatamr_nice: the charging LED from SIMpad is independently from us
12:36.14mr_nicemrdata: ah. hm, have to think about that. do you think we need two different definations for the two kinds of batterys?
12:36.18mrdatamr_nice: fuse is neccessary, wrong work with li-ion akku is dangerous
12:36.37mr_nicemrdata: do you know where to get the fuse?
12:37.18mr_nicemrdata: I think the difference is to de- and resolder it without destroying it
12:37.42mr_nicemrdata: I will change the article and add a warning about the fuse
12:37.43mrdatamr_nice: no, i have to reuse that whole circuit, when i have rebuild my akku-pack
12:39.09mrdatamr_nice: it's not only a fuse, i think, it saves against over temperature while charging
12:39.44mr_nicemrdata: yes. I also think so so it is quite difficult to resolder without destroying it
12:40.56mrdatamr_nice: no, it is very easy i think, you must desolder tha pins on the circuit-pcb
12:41.35mr_nicemrdata: good idea
12:41.37mrdatamr_nice: then you can remove the black-plastic savely
12:41.39*** join/#oe zecke (n=ich@88.134.99.50)
12:42.24mrdatamr_nice: the fuse was under the black-plastic, hold with tape
12:42.55mr_nicemrdata: do you know if it is the same circut board for the small and the big battery?
12:44.30mrdatamr_nice: i dont now, and i dont know how the different charging current for the akku-pack is handelt
12:44.44mr_nicemrdata: hm, well better not play with that stuff.
12:45.03*** join/#oe TheCan (n=thecan@dslb-084-056-179-103.pools.arcor-ip.net)
12:45.13mr_nicemrdata: I thougt about pimping the t-sinus accu as well
12:45.38mrdatamr_nice: yes, but the akku-pack for my linux SIMpad was damaged
12:45.58mr_nicemrdata: and you know what you are doing
12:46.15mrdatamr_nice: i hope so, i must do the repair myself
12:46.41mrdatamr_nice: and it's working again ;:))
12:47.06mr_nicemrdata: mine is also demaged. I hope it will work for me, too
12:47.49mrdatamr_nice: a real problem, no one will sell my new li-ion akku cells
12:48.22mrdatamr_nice: i got it only from ebay
12:48.44*** join/#oe dion (n=dion@inhex.net)
12:48.54mrdatamr_nice: and she was used before
12:49.50mr_nicemrdata: you can buy them realy cheap at pollin.de 2 ? each for new ones!
12:49.52mrdatamr_nice: and from the production on, after 2 years she could be damaged
12:50.40mrdatamr_nice: the pollin.de one, are also not new, i think
12:51.13mr_nicemrdata: hm, could be
12:52.51mrdatamr_nice: i have reading, pollin.de buy this from iomega (a mp3 player), and remove the akku-cells
12:53.54mr_nicemrdata: hm, could be
12:54.35mr_nicemrdata: sometimes there are new simpad accus on ebay but you nearly can buy a new simpad for the price of them
12:54.53mrdatamr_nice: for the first try, i have destroy a akku-pack from lifebook-notebook
12:55.52mrdatamr_nice: there are 6 li-ion cells inside, but also damaged
12:56.16mrdatamr_nice: new simpad accus are not possible
12:56.33mr_nicemrdata: they are to old you think?
12:56.54mr_nicemrdata: so they are not worth the money?
12:57.16mrdatamr_nice: yes, accus damaged over the time, also when not in use
12:58.05mrdatamr_nice: i have reading a lot article about that stuff
12:58.17mr_nicemrdata: what do you think about the accu cell mod (http://opensimpad.org/index.php/Simpad-Accu_replacement_with_cheap_mobile_accus). I also heared that this could be dangerous
12:59.49mrdatamr_nice: yes and no, the overtemperature circuit sould build inside the mobile-akku
13:00.39mr_nicemrdata: so if there is a overtemperature circuit inside the mobile accu it is save?
13:00.40mrdatamr_nice: but i have no idea, was the cuircuit-pcb inside the original siemens accu-pack does
13:01.07mr_nicemrdata: ah, so better do not risk it?
13:01.53mrdatamr_nice: the problem is, each li-ion accu cell have max. 4.2V
13:02.31mrdatamr_nice: we build a pack with two (or two * two)
13:03.26mrdatamr_nice: the end voltage from this pack is max 8.4V
13:04.00mr_nicemrdata: and that is to high?
13:04.49mrdatamr_nice: no, but each cell must controlled seperatly for voltage < max. 4,2V
13:05.22mrdatamr_nice: better for lifetime is max. 4,1V
13:06.05mrdatamr_nice: a charging circuit is therfore neccessary, to do this job
13:06.32mr_nicemrdata: ok I will give up that then
13:08.08mrdatamr_nice: have a view of the accu-pack from simpad, two cells parallel together, and then two "in reihe"
13:10.03mrdatamr_nice: the pack have 3 pins routed to the circuit-pcb, i have meassured this, and found 2x 4,1V separeted
13:11.48mrdatamr_nice: and 1x 8,2V, so all was okay, the circuit now know each cell (better 2 parallel for correctnes)
13:12.59mr_nicemrdata: hopefully I will be able to do the mod with the oem cells
13:13.02mrdatamr_nice: for surely complete control, she had to do also load-balacing with the 2 cells in parallel
13:14.09mrdatamr_nice: i have buy 12 one from ebay, 4 one are in use now, so i have 8 over
13:14.34mrdatamr_nice: i could also do the job for you, when you will
13:15.10mr_nicemrdata: I have 6 from pollin. big thx for your offer - I have to think about it.
13:16.44mrdatamr_nice: no problem, but please have a look to make no short-cut to your cells
13:17.48mrdatamr_nice: li-ion cells are explosive with the wrong handling, this is the reason, why no one will you sell new cells
13:18.45mrdatamr_nice: you could only buy new sampled accu-packs
13:19.22mr_nicemrdata: yes, I will be carefuly. thx for the warnings.
13:20.15mr_nicemrdata: I found an article on the net on how to replace laptop accus and there where the safety things mentioned
13:20.16mrdatamr_nice: is okay, then wish you good luck for "modding"
13:20.24mr_nicemrdata: thx
13:20.44*** join/#oe |dion| (n=dion@inhex.net)
13:20.54mrdatamr_nice: the article from england
13:21.37mr_nicemrdata: I should better take now some care to my girfriend before she drops the simpad out of the window *g. See you later and many thx!
13:22.10mrdatamr_nice: also, bye for now
13:27.08*** join/#oe koen (n=koen@212.41.157.237)
13:41.38*** join/#oe wbx (n=wbx@gprs-pool-1-027.eplus-online.de)
13:49.22zeckekoen: is bitbake still claiming that the preferred provider is not set?
13:49.32koenzecke: no idea
13:49.50koenzecke: I'm internetting over GPRS now, so ssh is too painfull
13:50.07zeckekoen: I would look into the issue now, if it wasn't fixed by someone elese yesterday
13:50.49koenyou were the one seeing the bug :)
13:51.18zeckehehe
13:56.46*** join/#oe joshin_ (n=josh@unaffiliated/joshin)
14:08.53zeckeRP: ping
14:09.02zeckeRP: http://rafb.net/p/PNjHfg85.html which is not correct but more correct than before
14:09.35zeckeRP: we search RPROVIDERs for item (e.g. gdk-pixbuf-jpg)
14:10.39zeckeRP: now we see search for PREFERRED_PROVIDER_gtk+-2.10.0 and if PREFERRED_PROVIDER is the one we currently iterate over... which is bogus :)
14:11.32zeckeRP: I think we should resolve RPROVIDERS by collection eligible, then looking at PREFERRED_PROVIDER_xyz and then resolve that again
14:12.05zeckeRP: PREFERRED_PROVIDER_xyz could be virtual/foo, we indirectly do this today with the loop...
14:13.15zeckeRP: NOTE: multiple preferred providers are available for runtime gnome-vfs-plugin-file (gnome-vfs, gnome-vfs, gnome-vfs, gnome-vfs, gnome-vfs, gnome-vfs, gnome-vfs, gnome-vfs, gnome-vfs, gnome-vfs); hehe
14:24.40*** join/#oe redguy (n=mati@unaffiliated/redguy)
14:26.04*** join/#oe jager (n=jag@12-214-107-171.client.mchsi.com)
14:27.40koenheh
14:28.38zeckekoen: this comes from all the different versions :)
14:31.13zeckekoen: OT: can cups handle bluetooth printers?
14:31.19koenusing a gprs link exposes all the GUIs that block on IO
14:31.19zeckebluetooth print profile that is
14:31.29koene.g. all of OSX
14:31.34koenzecke: sort of
14:32.00koenzecke: bluez-utils_3.8.bb:#  --enable-cups           install CUPS backend support
14:32.06koenbluezutils builds a cups plugin for that
14:33.36koenhmmm
14:33.59koendrat, that's still local diff
14:34.59zeckehehe
14:35.07koenzecke: http://www.angstrom-distribution.org/repo/?action=details&pnm=bluez-cups-backend
14:35.55zeckeah good
14:42.21*** join/#oe koen|away (i=koen@dominion.kabel.utwente.nl)
14:42.37koenah, internet works again
14:42.56CIA-1103koen 07org.oe.dev * rb884b1b9... 10/ (4 files in 2 dirs): bluez-utils: enable cups backend and package it seperately so only bluez-cups-backend depends on cups at runtime
14:43.44*** join/#oe koen_ (n=koen@dominion.kabel.utwente.nl)
14:57.05koenzecke: happy now?
14:57.57likewisekoen: so the switch was switched?
14:58.47koenit seems that way
14:59.13koen10 hours and 8 minutes ago
14:59.30zeckekoen: does it include a OpenMoko GUI? ;)
14:59.49koenzecke: hand me some php bindings :[
14:59.56koens/[/p/
15:00.12zeckekoen: hehe, well
15:01.15likewiseThis seems incorrect, can someone agree on that?
15:01.16likewiseconf/bitbake.conf:201:IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ."
15:01.18likewiseconf/bitbake.conf:202:IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ."
15:01.19likewiseconf/bitbake.conf:203:IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 .
15:01.21likewise"
15:01.39koennow we have tar.bz2, yes
15:01.57likewiseThe "tar" image type does bzip2 compression and "tar.bz2" does too.
15:02.01koenwe used to compress 'tar' to gz and switched it to bz2 a few years ago
15:02.26koenlikewise: could you send a mail about that?
15:02.43likewisekoen: sorry, yes
15:02.44koenI suspect some people/images/distros rely on the (wrong) behaviour
15:03.27likewisekoen: yes, there are assumptions built in (my latest checkin fixed the assumption that someone only builds 1 image type).
15:15.27*** join/#oe jager (n=jag@12-214-107-171.client.mchsi.com)
15:15.55sirfredWhat is the *.rootfs.jffs2.summary file supposed to be?
15:16.29likewisesirfred: some JFFS2 extension to speed-up mounting.
15:16.48sirfredlikewise: So, it's a replacement for rootfs.jffs2 file?
15:17.11likewisesirfred: JFFS2 does not scale well if flash is big. I dunno, it could be the JFFS2 fs with this extension enabled.
15:17.35sirfredlikewise: I see it's generated using sumtool on the regular jffs2 image.
15:18.21zeckekoen: the runtime 'fix' breaks other things :)
15:18.36likewisesirfred: http://www.inf.u-szeged.hu/jffs2/mount.php
15:18.43zeckekoen: I will need to chat with RP about it
15:18.43sirfredI'm running into trouble flashing jffs2 images lately. Looking at distro/include/zaurus-clamshell.conf I see that the mkfs.jffs2 command is not being passed the --eraseblock arg
15:18.56sirfredI wonder if that's the reason of the error.
15:19.02sirfredlikewise: Thanks, I'm going to take a look
15:19.04likewisesirfred: you need summary option enabled in the kernel
15:19.11*** join/#oe jag__ (n=jag@12-214-107-171.client.mchsi.com)
15:19.17koensirfred: jffs doesn't store the inode tree, it needs to rebuild it at every mount, the summary images include one
15:19.34koenwhich is why jffs2 takes so much RAM
15:19.37sirfredkoen: Thanks.
15:20.08sirfredkoen: So. is reasonably to call mkfs.jffs2 without the --eraseblock arg ?
15:20.18koenlikewise: logfs ftw!
15:20.26koensirfred: I don't know
15:20.32koensirfred: you'd have to ask RP or hrw
15:20.39sirfredkoen: OK. Thanks.
15:22.24sirfredHmmm, kernel for c7x0 is compiled with CONFIG_JFFS2_SUMMARY=y, so, it seems that summary images are supported.
15:22.25meisterkoen, do you know if florian will connect here today ?
15:22.47sirfredBut last time I tried to flash one of those images, I got a panic: kernel was not finding init
15:22.51*** join/#oe stevenh (n=lews@65.167.23.2)
15:23.21likewisesirfred: what kind of errors/problem do you get?
15:23.35likewisesirfred: sorry, missed your last line
15:23.38sirfredlikewise: Using the non summary image, a lot of magic number issues.
15:23.58likewisesirfred: are you sure you did an erase of the flash
15:24.10sirfredlikewise: As if the rootfs.jffs2 was not valid. Using the summary image, no magic number issues, but init was not found.
15:24.22sirfredlikewise: I assume that updater.sh does that job, doesn't it?
15:24.36likewisesirfred: dunno where updater.sh comes from
15:24.59sirfredlikewise: It's the script used to flash rootfs and kernel into c7x0 machines.
15:25.22sirfredlikewise: It used to work in the recent past.
15:25.28koenyes, updater.sh erases the flash
15:26.05sirfred2.6.20 doesn't seem to recognize my SD slot either.
15:34.26sirfredWell, I'm going to flash again, using 2.6.20 and rootfs.jffs2.summary
15:37.13*** join/#oe greentux (n=lemke@195.227.105.180)
15:37.47*** join/#oe csmanx (n=csman@190.42.168.230)
15:38.59*** join/#oe rob_w (n=bob@p213.54.16.100.tisdip.tiscali.de)
15:42.03*** join/#oe dkey (n=dkey@d86-33-241-242.cust.tele2.at)
15:44.40Laibsch~seen justinip
15:45.17ibotLaibsch: i haven't seen 'justinip'
15:45.17Laibsch~seen JustinP
15:45.21ibotjustinp <n=papercra@c-69-181-11-251.hsd1.ca.comcast.net> was last seen on IRC in channel #openzaurus, 19h 3m 57s ago, saying: 'Laibsch: rmmod, insmod, modprobe'.
15:50.35*** join/#oe empty_mind (n=matrix@59.176.111.177)
15:53.50*** join/#oe joshin (n=joshin@VDSL-130-13-8-245.PHNX.QWEST.NET)
15:54.43*** part/#oe joshin_ (n=josh@unaffiliated/joshin)
15:58.10*** join/#oe ScytheBlade1 (n=Death@about/pxe/ScytheBlade1)
16:02.54zeckeRP: http://rafb.net/p/547NVr52.html one problem left...
16:04.00mr_niceif I use a svn as file fetcher do I need to use the rev or date option or does it uses the latest revision wihthout ?
16:04.16zeckeRP: alternatively we declare the PREFERRED_PROVIDER_gdk-pixbuf-png = "gtk+" a wrong construct
16:12.15*** join/#oe Kristoffer (i=Kristoff@h207n1fls306o1049.telia.com)
16:22.35*** join/#oe benlau (n=benlau@221.125.13.148)
16:31.32koenmr_nice: it checks out the version in svn present at last midnight
16:35.04mr_nicekoen: thx. I will switch the simpad patches and defconfig to the slackpad svn then.
16:36.09koenzecke: did you know that some RH market droid promised 7 years of support for one of their distros?
16:36.40zeckekoen: no, why did they do it? Why should I care?
16:37.01koenas a response to oracle
16:37.24koenas marcel said "I refuse to fix kernel 2.2"
16:38.03chouimatkoen a lot of company in the US except 5 to 7 years of support for a product ...
16:38.23zeckelater guys
16:38.26chouimats/except/expect
16:38.43koenchouimat: for a physical product I'd expect it
16:38.58koenchouimat: but for a single release of a linux distro?
16:39.04zeckekoen: RH was boxed 7 years ago :)
16:40.03chouimatkoen if M$ is able to do it why we can ... it's expensive for a mid-sized company to change (not update) softwares every year ... and going from 2.0 or 2.2 to 2.6 is a change not an update
16:40.50koenchouimat: the difference is that MS doesn't release a new windows kernel every 2 months
16:41.18*** join/#oe obergix[work] (n=olivier@mag77-1-82-238-13-91.fbx.proxad.net)
16:41.46chouimatkoen you but 2.6.18 to 2.6.19 can be viewed as an update ... but 2.2.12 to 2.6.20 is more like a huge move (lot of stuff will break)
16:41.56koenright
16:42.00koenan in 7 years...
16:42.10koens/an/and/
16:42.17koennow they have git and stuff
16:42.29koen2.6.0 to 2.6.20 is a huge move as well
16:44.15chouimatkoen true but far more easier than 2.2 to 2.6 ... another example going from freeBSD 4.x to 5.x/6.x is another huge move (ok somewhat easier because you can always install the libc.so for the old version) but it's scary for manager who doesn't understand anything ... they got burned by M$ with dos and winblows :)
16:45.10koenI wonder how to prepare for such support
16:45.34koenI'd start by putting a complete buildbox + tapes in a safe place
16:45.57chouimatkoen the best you can ... I still have to support a floppy based firewall I created in 2000/2001 ...
16:46.18RPzecke: Interesting patch. I need to think about it :}
16:46.39chouimatkoen this depends on how much the "contract" will pay ...
16:46.47Croftonbring on the flat tax!
16:46.56chouimatCrofton hehe
16:47.42chouimatCrofton even easier bring the flat tax and send me the bill once a year ( they have all the information about me anyway)
16:53.31*** join/#oe Beg_ (n=beg@ws-63.elvis.ru)
16:53.49*** join/#oe Beg (n=chatzill@80.92.96.55)
17:00.44mr_nicezecke: the gpio_keys driver already has a SA1100 definition ( include/asm/arch/gpio.h ) :).  it compiled well but I can't see anything in /proc/bus/input/devices
17:02.31zeckemr_nice: well, did you register the platform data? is the other part of the driver compiled in
17:02.40zeckeRP: well
17:03.23zeckeRP: the issue is that we do not find a PREFERRED_PROVIDER for gdk-pixbuf-* unless we would define PREFERRED_PROVIDER_gtk+ = "gtk+" (if I understand the code)
17:03.45zeckeRP: and PREFERRED_PROVIDER_gdk-pixbuf-gif = "gtk+" makes a lot more sense from OE's pov
17:05.32*** join/#oe ssvb (n=user@87.252.225.64)
17:05.46RPzecke: It does imply that you have to make a defition for every virtual package though which isn't sometimes possibl
17:05.47RPe
17:06.13RPPREFERRED_PROVIDER_gtk+ = "gtk+" should be assumed unless its set to something else
17:06.33zeckeRP: well, the current code needs to stay to keep the kernel-modules happy :}
17:07.06zeckeRP: but logically: If I want to have RDEPEND gdk-pixbuf-gif it looks right to look into PREFERRED_PROVIDER_gdk-pixbuf-gif
17:07.21zeckebrb
17:08.15RPzecke: I'm not sure that is logically correct, it should really be PREFERRED_RPROVIDER and I think that the PREFERRED_RPROVIDERS should be worked out from the PREFERRED_PROVIDERs
17:08.52RPI specifically remember deciding not to add PREFERRED_RPROVIDERS as we could work out everything we needed without them
17:09.44mr_nicezecke: this one? http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=include/asm-arm/arch-sa1100/gpio.h;h=da7575b0e5d0f2f00ca58b09cc4aeaa22635f93a;hb=5b7e42b2d38e4c4d0cb105a2ad83d43f6957f59e
17:10.53*** join/#oe lrg (n=liam@lrg.demon.co.uk)
17:16.03CoreDump|homeCould anyone please explain to me the reason why a svn:// SRC_URI requires me to set (a valid!)  rev= even when I'm checking out a fixed TAG? Is there a dummy rev= to always use the latest rev?
17:17.39Jin^eLDCoreDump|home: if you always want the latest you can set SRCDATE = "now" in your .bb file and also add ;proto=svn;date=now" to your svn SRC_URI
17:18.42Jin^eLDand I do not have a rev= in that url
17:19.12CoreDump|homeJin^eLD: I'll try that, thanks. It kinda defeats the pupose of a TAG IMO tho ;)
17:19.28*** join/#oe csmanx (n=csman@190.42.168.230)
17:19.34Jin^eLDwell, svn does not have tags... at least as I understand :)
17:19.46Jin^eLDI think a "tag" in that sense is just a copy
17:19.57Jin^eLDbecause you could actually simply remember the revision to check out a "tag"
17:20.31Jin^eLDI know that was different in CVS...
17:20.51*** join/#oe tkp (n=tom@62-64-195-125.dynamic.dial.as9105.com)
17:21.03CoreDump|homeJin^eLD: you are of course right. SVN handles tags and branches by creating a snapshot in a subfolder
17:23.03zeckemr_nice: no the keyboard driver
17:23.18zeckemr_nice: generic GPIO keyboard driver uses gpio.h  and data supplied by the machine
17:24.15zeckeRP: PREFERRED_PROVIDER == PREFERRED_PROVIDERS (at least ...)
17:25.35zeckeRP: The question is. If both Gtk+-X11 and Gtk+-DirectFB can build gdk packages
17:26.00zeckeRP: and when you need a gdk module at runtime, how to select between X11 and DirectFB?
17:26.27RPPREFERRED_PROVIDER_gtk+ = "gtk+"
17:26.33zeckeRP: the current RDEPENDS code can't, the old one failed differently and people don't notice
17:27.30zeckeRP: do you think that is intuitive, or is this a code is law thing?
17:28.16RPzecke: Its not a code is law thing, I think its the only solution that makes sense
17:29.30RPzecke: I think we should only have one mechanism for selecting which package out of a given selection should be choosen. If we allow  PREFERRED_PROVIDER_gdk-pixbuf-gif = "gtk+-directfb" and I also set  PREFERRED_PROVIDER_gtk+ = "gtk+" what should happen?
17:29.31zeckeRP: If we accept this (I need to make up my mind) we have two issues to solve
17:30.24zeckeRP: if we would only fo gor the gdk-pixbuf-gif, we would have to write tons of PREFERRED_PROVIDER_kernel-module-foo = "virtual/kernel" somewhere
17:30.39RPRight, that isn't an option
17:31.03zeckeokay back to the issue: gtk+ should provide gtk+ and gtk+-directfb should provide gtk+ as well?
17:31.28zeckeRP: if we set PREFFERRED_PROVIDER_gtk+ = "gtk+-directfb" what else will be break? what else in BitBake?
17:32.19RPzecke: Is directfb designed to replace the standard gtk?
17:33.18zeckeRP: they are API compatible (at least they should be)
17:33.56*** join/#oe summatusmentis (n=summatus@72.168.202.219)
17:33.57zecke~botmail koen your gdk providers are wrong :)
17:34.20summatusmentisdoes bitbake need to build the package before the source is available?
17:34.41koenzecke: they are?
17:34.48RPzecke: In that case it should provide gtk+ and setting the PREFERRED_PROVIDER you mention should work
17:34.55zeckekoen: PREFERRED_PROVIDER_gtk+ = "gtk+"
17:35.23RPzecke: I think the code might be backfireing as the assumed  PREFERRED_PROVIDER_gtk+ = "gtk+" isn't being assumed properly
17:35.47RPzecke: You shouldn't have to set that, it should default to it in my opinion - would you agree?
17:36.39CIA-1103coredump2 07org.oe.dev * ra86f5851... 10/ (8 files in 5 dirs): altboot: Replace rev= with proto=svn.... and update altboot_0.0.0.bb to latest svn
17:37.17koenRP: didn't we agree to that at OEDEM already?
17:37.50RPkoen: Yes, and I thought it was fixed but it appears to break for runtime providers for some reason
17:38.04koenah, ok, I wasn't sure
17:38.32RPkoen: That doesn't mean we shouldn't check our decision now either though, lets make sure we got it right :)
17:38.49koenright :)
17:43.59mr_nicezecke: ah platform_device struct. can be defined in simpad.c?
17:44.34*** join/#oe greentux (n=lemke@195.227.105.180)
17:45.22zeckesorry need to run :}
17:45.29zeckemy mon returned and I need to leave...
18:04.40koenI wish OSX would error out on printer/spool error
18:05.00koeninstead of stating the job was completed
18:06.31*** join/#oe csmanx (n=csman@190.42.168.230)
18:08.33*** join/#oe greentux (n=lemke@Z7e1c.z.pppool.de)
18:10.04summatusmentiskoen: why?
18:10.22koenso I know which documents to print again
18:10.35summatusmentisI see
18:14.12*** join/#oe lazy_marmot (n=lazy_mar@85.233.43.112.static.cablesurf.de)
18:15.31*** join/#oe pleemans (n=peter@d51A5E76A.access.telenet.be)
18:16.57CIA-1103rpurdie * r802 10bitbake/lib/bb/ (cache.py cooker.py providers.py utils.py): Fix PE handling to use strings and update showVersions to add PE support (closes #2027)
18:19.46koenRP: thanks for fixing bitbake -s
18:21.48RPkoen: np, its good to catch these kind of problems so thanks for testing trunk :)
18:22.08NAiLkoen: I can't get gcc-cross 4.1.1 to compile with uclibc. It bombs out with some c++-stuff. Could you take a look at it? :)
18:22.11NAiLhttp://pastebin.ca/408247
18:22.34*** join/#oe csmanx (n=csman@190.42.168.230)
18:23.03koenNAiL: no idea, sorry
18:23.03koenyou could try 4.1.2
18:23.18NAiLis there a gcc-cross_4.1.2?
18:23.26koensince a few days, yes :)
18:23.35NAiLah, I'm working off of an svn repo
18:23.41NAiLuntil stuff actually works ;)
18:24.25NAiLoooh
18:28.45*** join/#oe ggilbert (n=ggilbert@tinman.treke.net)
18:29.56*** join/#oe Sleep_Walker (n=Sleep@195.22.44.103.adsl.nextra.cz)
18:33.35*** join/#oe meister (n=meister@82.244.212.29)
18:33.51likewiseERROR: Nothing provides dependency glib-2.0
18:33.53NAiLkoen: is nptl ready?
18:33.53likewiseERROR: dependency glib-2.0 (for avahi) not satisfied
18:33.55likewiseERROR: No buildable providers for runtime avahi-daemon
18:34.12likewisewhoops
18:34.28koenNAiL: CSL and MV claim it is
18:34.36NAiLkoen: I know they won't actually commit it until 0.9.29 has been released. But if it's workable, I'm ok with that ;)
18:35.26NAiLkoen: No idea who CSL and MV is, but I assume they have some authoritae.
18:36.34koenCodesourcery and montavista
18:36.46koenmv hired csl to do the nptl port
18:36.59NAiLaha
18:39.26*** join/#oe Timelord (n=TL@16.8c.d12c.cidr.airmail.net)
18:50.26*** join/#oe csmanx (n=csman@190.42.168.230)
19:04.37*** join/#oe woglinde (i=woglinde@e178117169.adsl.alicedsl.de)
19:07.23*** join/#oe meister (n=meister@82.244.212.29)
19:25.03*** join/#oe dion (n=dion@inhex.net)
19:29.59mrdatawoglinde: hi
19:32.52*** join/#oe csmanx (n=csman@190.42.168.230)
19:33.34mrdatamicky|working: hi, can i ask you one or two questions about a kernel Internal error: Oops - bad syscall problem
19:34.27mickey|workingI'm sorry, but I'm not exactly a kernel guy.
19:34.52mickey|workingmixing ABIs?
19:35.02mickey|workingor calling a syscall that doesn't exist?
19:35.37mrdatamicky|working: then sorry, when simpad should do suspend with apm --suspend
19:35.43*** join/#oe pgfeller (n=pgfeller@215.134.79.83.cust.bluewin.ch)
19:36.16mickey|workingyour better audience would be zecke, schurig, pb_, RP, pH5, ...
19:36.25koenmickey|working: honda, fic, something else?
19:36.42mrdatamicky|working: apmd try apmd_suspend()
19:36.53mickey|workingkoen: honda. it's a nightmare. they given me an API update which I need to catch up with :/ on monday integration starts on-site :(
19:37.02koenouch
19:37.15mickey|workingnow i have ~30 hours left to add the missing functionality
19:37.23mickey|working*sigh*
19:38.29mrdatamicky|working: thx!, i will ask the others
19:39.42mickey|workinghehe
19:40.24koenmickey|working: I can start asking OM related questions on tuesday?
19:40.53koenmake that wednesday, I'm away for work on tuesday
19:41.15koenexam on wednesday....
19:41.19koennevermind...
19:41.22mickey|workingsounds good. I'm working the whole next week on-site for Honda, but wednesday should be ok. note that I have no internet access there, so i'll be present from 19:00 onwards
19:43.00koen<PROTECTED>
19:43.03koen114% ....
19:47.12koenmickey|working: 29 hours even with the summertime kicking in tonight
19:47.12NAiLkoen: that's nothing. I've seen "ps" use 120% ;)
19:49.38koenroot@fic-gta01:~$ uptime
19:49.38koen<PROTECTED>
19:49.42koenstill fairly stable
20:21.05JustinPLaibsch: yes?
20:23.04koenheh, I speed up matlab by giving the VM more RAM
20:23.19koen~lart windows
20:23.19ibotdoes a little 'dpkg -P windows' action
20:24.54koen~hail parallels coherence mode
20:25.01ibotACTION bows down to parallels coherence mode and chants, "I'M NOT WORTHY!!"
20:25.49*** join/#oe dion (n=dion@inhex.net)
20:35.03*** join/#oe mr_nice (n=mr_nice@p54A9F565.dip.t-dialin.net)
20:35.41mr_nicenick mr_nice|scummvm
20:40.58IfaistosNAiL : According to this -> http://bugs.busybox.net/bug_view_advanced_page.php?bug_id=925 this is fixed in svn
20:41.36NAiLIfaistos: according to me, it ain't. I'm building from svn.
20:41.41NAiL;)
20:43.29NAiLA fix went in svn last year. I'm using svn from a few days ago
20:43.41koenmaybe they broke it again
20:44.10koenat times like this I usually put some more buildroot/crosstool patches to gcc in OE
20:44.41NAiLyeah
20:44.52NAiLI suspect it might work with 4.2, from what I've been readin
20:45.01koen4.2 isn't out yet....
20:45.16NAiLno, but buildroot has patches for 4.2-patches
20:46.48koenyou could try adding a newer version of gcc-cross_4.2-20060513.bb
20:47.28Ifaistosi am finding some weird stuff also for which i have no explanation till now.
20:47.47*** join/#oe hwtechnik (n=hwtechni@80.78.234.14)
20:48.01Ifaistosi had boa (the web server) build prior to the last changes to gcc and it was working fine
20:48.18Ifaistosrebuild it and it just won't run
20:48.40Ifaistossame with apache2
20:48.56Ifaistossigfaults on ppc405
20:48.57koencherokee ftw!
20:49.48Ifaistosperl complains about some library files not been correct
20:50.12Ifaistosin general there is something wrong... haven't figured it out
20:50.58Ifaistosnot sure if its a host problem, a tool chain or my stupidity problem ;)
20:53.41Ifaistosenough ranting for tonight ;)
20:53.48Ifaistosnight everyone
20:57.56koen'night Ifaistos
22:05.23CIA-1103koen 07org.oe.dev * r6ca0327e... 10/ (1 conf/distro/angstrom-2007.1.conf): angstrom: add a provider for gtk+ on Holgers advice
22:15.17*** join/#oe mmp (n=mmp@thewide.ubyt.sdjls.uniba.sk)
22:29.34*** join/#oe umop3plsdn (n=Hodi@cpe-76-179-85-181.maine.res.rr.com)
22:33.54*** join/#oe ken (n=ken@h207n1fls306o1049.telia.com)
23:04.30*** join/#oe luke-jr (n=luke-jr@2002:1891:f663:0:20e:a6ff:fec4:4e5d)
23:18.57*** join/#oe csmanx (n=csman@190.42.168.230)
23:20.38*** join/#oe rob_w (n=bob@p213.54.16.100.tisdip.tiscali.de)
23:21.22timtimredhi, say i have a lot of files in different i want to include in a package with FILES is there some easy way to do it recursively
23:22.13timtimredso i dont have to list a whole lotta files individually
23:22.32NAiL(and he's talking about a *lot* of files) ;-)
23:31.08timtimredahh i got it
23:31.20timtimredthat was like, too easy
23:31.23NAiLheh
23:31.29NAiLhow? :)
23:32.05timtimrede.g. FILES_${PN} += "/whackdir"

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.