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.47 | JoseJX | <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.11 | CIA-11 | 03koen 07org.oe.dev * rb0b98bec... 10/ (1 packages/mplayer/mplayer_svn.bb): mplayer: add optimizations for a780 and hx4700 |
09:33.39 | rwhitby | did someone forget to check in a no-xwc.patch ? |
09:34.21 | CIA-11 | 03koen 07org.oe.dev * r183ae1b2... 10/ (1 packages/gsm/files/default): gsm: add default 'default' file |
09:34.57 | koen____ | rwhitby: that or checked in a wrong SRC_URI |
09:35.05 | koen____ | rwhitby: but if you get that message, you hit a bug |
09:35.26 | koen____ | (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.09 | rwhitby | yeah, 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.38 | koen | or 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.32 | CIA-11 | 03koen 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.00 | keesj | what base distro/gcc version do people use here . |
10:08.32 | keesj | I have two gentoo based system and only one of them is capable of compiling gcc |
10:08.55 | keesj | (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.24 | keesj | on this machine I keep hitting this message CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/libffi |
10:15.06 | likewise | keesj: what are you building? (hoi) |
10:16.11 | keesj | I am trying to build nano , but the error comes from gcc-cross-initial-4.1.1 |
10:16.52 | keesj | I have my machine set to smdk2440 and my DISTRO set to generic. |
10:17.38 | keesj | I tried different tastes |
10:18.00 | *** join/#oe koen__ (n=koen@212.41.157.237) |
10:18.23 | likewise | koen__: good morning |
10:19.31 | koen | hey likewise |
10:22.57 | koen | NAiL: You're using uclibc svn for ARM? |
10:23.45 | likewise | keesj: my nano seems not to depend on libffi |
10:24.03 | NAiL | koen: I'm trying ;) |
10:24.45 | likewise | NAiL: Isn't uclibc almost unmaintained currently? |
10:24.56 | likewise | NAiL: Sorry, the SVN tree I mean. |
10:25.12 | keesj | likewise I guess that anything I try to build will fail , perhas I must try the task-base first? |
10:25.36 | NAiL | likewise: I don't know. But I get further with the svn tree than 0.9.28 |
10:25.52 | likewise | keesj: in theory no, dependencies should be respected |
10:26.58 | koen | likewise: CSL and others are waiting for the .29 release to merge their stuff |
10:27.19 | koen | so proper development is halted till Erik does 'make dist' |
10:27.38 | likewise | koen: yup, that would be a nice point to jump in on uclibc again. |
10:28.06 | likewise | keesj: 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.10 | koen | the release was supposed to happen shortly after fosdem |
10:35.47 | keesj | koen was it nice in recife, I did not see much coverage |
10:36.06 | koen | keesj: very nice! |
10:37.49 | keesj | great |
10:38.56 | *** join/#oe Laibsch (n=Laibsch@F733c.f.ppp-pool.de) |
10:39.07 | likewise | Laibsch: morning! |
10:39.15 | Laibsch | good morning likewise |
10:39.25 | Laibsch | good morning everyone |
10:40.09 | likewise | whooo, mtn annotate takes it easy... |
10:40.43 | koen | likewise: mtn >= 0.32? |
10:41.19 | likewise | I would expect the annotate algorithm to work backwards until all lines are covered, instead of going through 13k revisions... mtn == 0.31 |
10:41.32 | koen | right, 0.31 is slow |
10:41.44 | koen | 0.32 is a few orders of magnitude faster |
10:41.45 | likewise | koen: ok, will try >= 0.32 |
10:41.58 | koen | 'seconds' versus 'hours' |
10:42.58 | koen | likewise: 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.39 | CIA-11 | 03likewise 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.42 | mr_nice | hi all |
11:24.07 | mr_nice | how 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.01 | mr_nice | sorry gtk+-directfb_2.10.9.bb not gtk+_2.10.9.bb |
11:25.44 | DerCorny | just remove the ...directfb.bb file |
11:27.57 | mr_nice | DerCorny: thx, I will try it |
11:28.44 | DerCorny | mr_nice: well, it did the job for me - hope it works for you, too |
11:33.36 | mrdata | mr_nice: hi, battery status now works with gpe-image also |
11:34.11 | mrdata | mr_nice: but i have not using the battery class from hh.org |
11:36.30 | mrdata | mr_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.48 | mrdata | zecke: hi |
11:50.33 | mr_nice | mrdata: hi |
11:51.04 | mr_nice | mrdata: you was using the apm funktion for it? |
11:52.50 | mrdata | mr_nice: yes, i get apm_get_power_status = simpad_apm_get_power_status working |
11:53.55 | mrdata | mr_nice: cat /proc/apm gives now correct results |
11:54.11 | mr_nice | mrdata: ah, ok also cool to have that. afaik there is no common interface for battery |
11:54.21 | mr_nice | mrdata: i think |
11:56.12 | mr_nice | mrdata: 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.16 | mrdata | mr_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.51 | mr_nice | mrdata: do you know if the driver just shows the status of the battery or is it also responsable for charging stuff? |
11:59.31 | mrdata | mr_nice: and in simpad_pm.c i use simpad_apm_get_power_status -> simpad_get_battery |
11:59.50 | mrdata | mr_nice: the whole stuff |
12:00.31 | mr_nice | mrdata: so it could overload the battery? |
12:00.37 | mr_nice | mrdata: I wonder how they calculated the less then 8.5 volt = no power supply for cl4 and less 12 v for sl4 |
12:00.54 | mrdata | mr_nice: the whole struct apm_power_info() is correct now |
12:01.07 | mr_nice | mrdata: hehe, ah ok :) thats nice |
12:01.35 | mr_nice | mrdata: apm is an importent thing for that device I think |
12:02.07 | mrdata | mr_nice: ucb1x00 -> vcharger tell the voltage for power supply |
12:03.48 | *** join/#oe mwester-laptop (n=mwester@gw.mwester.net) |
12:04.13 | mrdata | mr_nice: if power supply on, than vcharger > 12000, if power supply off vcharger = 800 or so |
12:05.51 | mrdata | mr_nice: witch voltage have your power supply for cl4? |
12:06.25 | mr_nice | mrdata: I wondered because my 2 power suplys (sl4, t-sinus) are identicaly |
12:06.34 | mrdata | mr_nice: you told me, that you have two SIMpads |
12:06.37 | mr_nice | mrdata: 12v |
12:06.51 | mr_nice | mrdata: 3300mA |
12:07.30 | mr_nice | mrdata: they are exactly the same |
12:08.06 | mr_nice | mrdata: I don't know if there exists a different one for cl4 or swisscom wp50 |
12:08.18 | mrdata | mr_nice: than i understand, you have two V4415-Z35-X11 |
12:09.10 | mr_nice | mrdata: yes |
12:09.28 | mr_nice | mrdata: interesting http://lkml.org/lkml/2007/2/2/217 |
12:10.47 | mrdata | mr_nice: yes, have also found and reading that |
12:12.05 | *** join/#oe Timelord0 (n=TL@16.8c.d12c.cidr.airmail.net) |
12:12.13 | mrdata | mr_nice: you must only change MIN_SUPPLY from 8500 to 12000 for your SMALL_BATTERY |
12:12.57 | mr_nice | mrdata: do you think 8.5 V is used by cl4 or wp50? |
12:13.47 | mr_nice | mrdata: would be good to know |
12:14.25 | mrdata | mr_nice: yes, but i have no cl4 or wp50 |
12:14.43 | meister | hi$ |
12:15.30 | mrdata | mr_nice: you could also change -> CALIBRATE_BATTERY(a) ((((a + 3)*12610)/860) + 170) |
12:16.03 | mrdata | mr_nice: this gives the right vbatt voltage for akku |
12:18.47 | mr_nice | mrdata: hm, so we need at least 3 kinds of precompiled modules? |
12:19.33 | mr_nice | mrdata: we should consider about getting the type of the bat as an argument to the module end exclude it from the kernel |
12:19.40 | mrdata | mr_nice: the battery could not be overload by us, because the charge circuit for it works without us |
12:19.55 | mr_nice | mrdata: thats very nice! |
12:20.56 | mr_nice | mrdata: I will rewrite the battery module that way that you can define the battery and power supply stuff at modules.conf |
12:21.56 | mrdata | mr_nice: when vcharger >= 8500, the power supply is definedly on line, i think |
12:23.31 | mr_nice | mrdata: you are the electrical guy ;) I will trust you |
12:23.36 | mrdata | mr_nice: charging tell us icharger, when vcharger >= 8500 |
12:23.56 | mr_nice | mrdata: 8300 is the level of a big size battery |
12:24.31 | mrdata | mr_nice: i have wrote this to you, it's my job |
12:24.41 | mr_nice | mrdata:hehe yes |
12:24.59 | mr_nice | mrdata: so I will exclude it from the config |
12:25.16 | mr_nice | mrdata: and only ask about the battery type |
12:26.31 | mrdata | mr_nice: i have set BATT_FULL to 8100, because when the charging ends, vbatt = 8425 or so |
12:28.02 | mr_nice | mrdata: for the big bat? |
12:28.12 | mrdata | mr_nice: but when power supply offline, vbatt drop to lower value, because SIMpad is on |
12:28.34 | mrdata | mr_nice: and backlight dains the akku down |
12:28.48 | mr_nice | mrdata: ah, good to know |
12:29.38 | mrdata | mr_nice: yes, small or big akku is not that thing, both have li-ion akku and there max. voltage is 8.4 |
12:30.36 | mr_nice | mrdata: what is the charging led level thing good for? |
12:31.18 | mrdata | mr_nice: it is also a voltage, which represent the current for charging li-ion akku |
12:32.00 | mrdata | mr_nice: li-ion charging works with constant current, and than with constant voltage to fullfill the akku |
12:32.36 | mrdata | mr_nice: the last current was lower and lower |
12:33.31 | mrdata | mr_nice: and when icharger is 27 or 28 (becaus of ADC error from ucb1300), than charging is done, and akku full |
12:34.53 | mr_nice | mrdata: 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.06 | mrdata | mr_nice: the charging LED from SIMpad is independently from us |
12:36.14 | mr_nice | mrdata: ah. hm, have to think about that. do you think we need two different definations for the two kinds of batterys? |
12:36.18 | mrdata | mr_nice: fuse is neccessary, wrong work with li-ion akku is dangerous |
12:36.37 | mr_nice | mrdata: do you know where to get the fuse? |
12:37.18 | mr_nice | mrdata: I think the difference is to de- and resolder it without destroying it |
12:37.42 | mr_nice | mrdata: I will change the article and add a warning about the fuse |
12:37.43 | mrdata | mr_nice: no, i have to reuse that whole circuit, when i have rebuild my akku-pack |
12:39.09 | mrdata | mr_nice: it's not only a fuse, i think, it saves against over temperature while charging |
12:39.44 | mr_nice | mrdata: yes. I also think so so it is quite difficult to resolder without destroying it |
12:40.56 | mrdata | mr_nice: no, it is very easy i think, you must desolder tha pins on the circuit-pcb |
12:41.35 | mr_nice | mrdata: good idea |
12:41.37 | mrdata | mr_nice: then you can remove the black-plastic savely |
12:41.39 | *** join/#oe zecke (n=ich@88.134.99.50) |
12:42.24 | mrdata | mr_nice: the fuse was under the black-plastic, hold with tape |
12:42.55 | mr_nice | mrdata: do you know if it is the same circut board for the small and the big battery? |
12:44.30 | mrdata | mr_nice: i dont now, and i dont know how the different charging current for the akku-pack is handelt |
12:44.44 | mr_nice | mrdata: 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.13 | mr_nice | mrdata: I thougt about pimping the t-sinus accu as well |
12:45.38 | mrdata | mr_nice: yes, but the akku-pack for my linux SIMpad was damaged |
12:45.58 | mr_nice | mrdata: and you know what you are doing |
12:46.15 | mrdata | mr_nice: i hope so, i must do the repair myself |
12:46.41 | mrdata | mr_nice: and it's working again ;:)) |
12:47.06 | mr_nice | mrdata: mine is also demaged. I hope it will work for me, too |
12:47.49 | mrdata | mr_nice: a real problem, no one will sell my new li-ion akku cells |
12:48.22 | mrdata | mr_nice: i got it only from ebay |
12:48.44 | *** join/#oe dion (n=dion@inhex.net) |
12:48.54 | mrdata | mr_nice: and she was used before |
12:49.50 | mr_nice | mrdata: you can buy them realy cheap at pollin.de 2 ? each for new ones! |
12:49.52 | mrdata | mr_nice: and from the production on, after 2 years she could be damaged |
12:50.40 | mrdata | mr_nice: the pollin.de one, are also not new, i think |
12:51.13 | mr_nice | mrdata: hm, could be |
12:52.51 | mrdata | mr_nice: i have reading, pollin.de buy this from iomega (a mp3 player), and remove the akku-cells |
12:53.54 | mr_nice | mrdata: hm, could be |
12:54.35 | mr_nice | mrdata: sometimes there are new simpad accus on ebay but you nearly can buy a new simpad for the price of them |
12:54.53 | mrdata | mr_nice: for the first try, i have destroy a akku-pack from lifebook-notebook |
12:55.52 | mrdata | mr_nice: there are 6 li-ion cells inside, but also damaged |
12:56.16 | mrdata | mr_nice: new simpad accus are not possible |
12:56.33 | mr_nice | mrdata: they are to old you think? |
12:56.54 | mr_nice | mrdata: so they are not worth the money? |
12:57.16 | mrdata | mr_nice: yes, accus damaged over the time, also when not in use |
12:58.05 | mrdata | mr_nice: i have reading a lot article about that stuff |
12:58.17 | mr_nice | mrdata: 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.49 | mrdata | mr_nice: yes and no, the overtemperature circuit sould build inside the mobile-akku |
13:00.39 | mr_nice | mrdata: so if there is a overtemperature circuit inside the mobile accu it is save? |
13:00.40 | mrdata | mr_nice: but i have no idea, was the cuircuit-pcb inside the original siemens accu-pack does |
13:01.07 | mr_nice | mrdata: ah, so better do not risk it? |
13:01.53 | mrdata | mr_nice: the problem is, each li-ion accu cell have max. 4.2V |
13:02.31 | mrdata | mr_nice: we build a pack with two (or two * two) |
13:03.26 | mrdata | mr_nice: the end voltage from this pack is max 8.4V |
13:04.00 | mr_nice | mrdata: and that is to high? |
13:04.49 | mrdata | mr_nice: no, but each cell must controlled seperatly for voltage < max. 4,2V |
13:05.22 | mrdata | mr_nice: better for lifetime is max. 4,1V |
13:06.05 | mrdata | mr_nice: a charging circuit is therfore neccessary, to do this job |
13:06.32 | mr_nice | mrdata: ok I will give up that then |
13:08.08 | mrdata | mr_nice: have a view of the accu-pack from simpad, two cells parallel together, and then two "in reihe" |
13:10.03 | mrdata | mr_nice: the pack have 3 pins routed to the circuit-pcb, i have meassured this, and found 2x 4,1V separeted |
13:11.48 | mrdata | mr_nice: and 1x 8,2V, so all was okay, the circuit now know each cell (better 2 parallel for correctnes) |
13:12.59 | mr_nice | mrdata: hopefully I will be able to do the mod with the oem cells |
13:13.02 | mrdata | mr_nice: for surely complete control, she had to do also load-balacing with the 2 cells in parallel |
13:14.09 | mrdata | mr_nice: i have buy 12 one from ebay, 4 one are in use now, so i have 8 over |
13:14.34 | mrdata | mr_nice: i could also do the job for you, when you will |
13:15.10 | mr_nice | mrdata: I have 6 from pollin. big thx for your offer - I have to think about it. |
13:16.44 | mrdata | mr_nice: no problem, but please have a look to make no short-cut to your cells |
13:17.48 | mrdata | mr_nice: li-ion cells are explosive with the wrong handling, this is the reason, why no one will you sell new cells |
13:18.45 | mrdata | mr_nice: you could only buy new sampled accu-packs |
13:19.22 | mr_nice | mrdata: yes, I will be carefuly. thx for the warnings. |
13:20.15 | mr_nice | mrdata: I found an article on the net on how to replace laptop accus and there where the safety things mentioned |
13:20.16 | mrdata | mr_nice: is okay, then wish you good luck for "modding" |
13:20.24 | mr_nice | mrdata: thx |
13:20.44 | *** join/#oe |dion| (n=dion@inhex.net) |
13:20.54 | mrdata | mr_nice: the article from england |
13:21.37 | mr_nice | mrdata: 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.10 | mrdata | mr_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.22 | zecke | koen: is bitbake still claiming that the preferred provider is not set? |
13:49.32 | koen | zecke: no idea |
13:49.50 | koen | zecke: I'm internetting over GPRS now, so ssh is too painfull |
13:50.07 | zecke | koen: I would look into the issue now, if it wasn't fixed by someone elese yesterday |
13:50.49 | koen | you were the one seeing the bug :) |
13:51.18 | zecke | hehe |
13:56.46 | *** join/#oe joshin_ (n=josh@unaffiliated/joshin) |
14:08.53 | zecke | RP: ping |
14:09.02 | zecke | RP: http://rafb.net/p/PNjHfg85.html which is not correct but more correct than before |
14:09.35 | zecke | RP: we search RPROVIDERs for item (e.g. gdk-pixbuf-jpg) |
14:10.39 | zecke | RP: 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.32 | zecke | RP: I think we should resolve RPROVIDERS by collection eligible, then looking at PREFERRED_PROVIDER_xyz and then resolve that again |
14:12.05 | zecke | RP: PREFERRED_PROVIDER_xyz could be virtual/foo, we indirectly do this today with the loop... |
14:13.15 | zecke | RP: 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.40 | koen | heh |
14:28.38 | zecke | koen: this comes from all the different versions :) |
14:31.13 | zecke | koen: OT: can cups handle bluetooth printers? |
14:31.19 | koen | using a gprs link exposes all the GUIs that block on IO |
14:31.19 | zecke | bluetooth print profile that is |
14:31.29 | koen | e.g. all of OSX |
14:31.34 | koen | zecke: sort of |
14:32.00 | koen | zecke: bluez-utils_3.8.bb:# --enable-cups install CUPS backend support |
14:32.06 | koen | bluezutils builds a cups plugin for that |
14:33.36 | koen | hmmm |
14:33.59 | koen | drat, that's still local diff |
14:34.59 | zecke | hehe |
14:35.07 | koen | zecke: http://www.angstrom-distribution.org/repo/?action=details&pnm=bluez-cups-backend |
14:35.55 | zecke | ah good |
14:42.21 | *** join/#oe koen|away (i=koen@dominion.kabel.utwente.nl) |
14:42.37 | koen | ah, internet works again |
14:42.56 | CIA-11 | 03koen 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.05 | koen | zecke: happy now? |
14:57.57 | likewise | koen: so the switch was switched? |
14:58.47 | koen | it seems that way |
14:59.13 | koen | 10 hours and 8 minutes ago |
14:59.30 | zecke | koen: does it include a OpenMoko GUI? ;) |
14:59.49 | koen | zecke: hand me some php bindings :[ |
14:59.56 | koen | s/[/p/ |
15:00.12 | zecke | koen: hehe, well |
15:01.15 | likewise | This seems incorrect, can someone agree on that? |
15:01.16 | likewise | conf/bitbake.conf:201:IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ." |
15:01.18 | likewise | conf/bitbake.conf:202:IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ." |
15:01.19 | likewise | conf/bitbake.conf:203:IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 . |
15:01.21 | likewise | " |
15:01.39 | koen | now we have tar.bz2, yes |
15:01.57 | likewise | The "tar" image type does bzip2 compression and "tar.bz2" does too. |
15:02.01 | koen | we used to compress 'tar' to gz and switched it to bz2 a few years ago |
15:02.26 | koen | likewise: could you send a mail about that? |
15:02.43 | likewise | koen: sorry, yes |
15:02.44 | koen | I suspect some people/images/distros rely on the (wrong) behaviour |
15:03.27 | likewise | koen: 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.55 | sirfred | What is the *.rootfs.jffs2.summary file supposed to be? |
15:16.29 | likewise | sirfred: some JFFS2 extension to speed-up mounting. |
15:16.48 | sirfred | likewise: So, it's a replacement for rootfs.jffs2 file? |
15:17.11 | likewise | sirfred: JFFS2 does not scale well if flash is big. I dunno, it could be the JFFS2 fs with this extension enabled. |
15:17.35 | sirfred | likewise: I see it's generated using sumtool on the regular jffs2 image. |
15:18.21 | zecke | koen: the runtime 'fix' breaks other things :) |
15:18.36 | likewise | sirfred: http://www.inf.u-szeged.hu/jffs2/mount.php |
15:18.43 | zecke | koen: I will need to chat with RP about it |
15:18.43 | sirfred | I'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.56 | sirfred | I wonder if that's the reason of the error. |
15:19.02 | sirfred | likewise: Thanks, I'm going to take a look |
15:19.04 | likewise | sirfred: 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.17 | koen | sirfred: jffs doesn't store the inode tree, it needs to rebuild it at every mount, the summary images include one |
15:19.34 | koen | which is why jffs2 takes so much RAM |
15:19.37 | sirfred | koen: Thanks. |
15:20.08 | sirfred | koen: So. is reasonably to call mkfs.jffs2 without the --eraseblock arg ? |
15:20.18 | koen | likewise: logfs ftw! |
15:20.26 | koen | sirfred: I don't know |
15:20.32 | koen | sirfred: you'd have to ask RP or hrw |
15:20.39 | sirfred | koen: OK. Thanks. |
15:22.24 | sirfred | Hmmm, kernel for c7x0 is compiled with CONFIG_JFFS2_SUMMARY=y, so, it seems that summary images are supported. |
15:22.25 | meister | koen, do you know if florian will connect here today ? |
15:22.47 | sirfred | But 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.21 | likewise | sirfred: what kind of errors/problem do you get? |
15:23.35 | likewise | sirfred: sorry, missed your last line |
15:23.38 | sirfred | likewise: Using the non summary image, a lot of magic number issues. |
15:23.58 | likewise | sirfred: are you sure you did an erase of the flash |
15:24.10 | sirfred | likewise: As if the rootfs.jffs2 was not valid. Using the summary image, no magic number issues, but init was not found. |
15:24.22 | sirfred | likewise: I assume that updater.sh does that job, doesn't it? |
15:24.36 | likewise | sirfred: dunno where updater.sh comes from |
15:24.59 | sirfred | likewise: It's the script used to flash rootfs and kernel into c7x0 machines. |
15:25.22 | sirfred | likewise: It used to work in the recent past. |
15:25.28 | koen | yes, updater.sh erases the flash |
15:26.05 | sirfred | 2.6.20 doesn't seem to recognize my SD slot either. |
15:34.26 | sirfred | Well, 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.40 | Laibsch | ~seen justinip |
15:45.17 | ibot | Laibsch: i haven't seen 'justinip' |
15:45.17 | Laibsch | ~seen JustinP |
15:45.21 | ibot | justinp <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.54 | zecke | RP: http://rafb.net/p/547NVr52.html one problem left... |
16:04.00 | mr_nice | if 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.16 | zecke | RP: 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.32 | koen | mr_nice: it checks out the version in svn present at last midnight |
16:35.04 | mr_nice | koen: thx. I will switch the simpad patches and defconfig to the slackpad svn then. |
16:36.09 | koen | zecke: did you know that some RH market droid promised 7 years of support for one of their distros? |
16:36.40 | zecke | koen: no, why did they do it? Why should I care? |
16:37.01 | koen | as a response to oracle |
16:37.24 | koen | as marcel said "I refuse to fix kernel 2.2" |
16:38.03 | chouimat | koen a lot of company in the US except 5 to 7 years of support for a product ... |
16:38.23 | zecke | later guys |
16:38.26 | chouimat | s/except/expect |
16:38.43 | koen | chouimat: for a physical product I'd expect it |
16:38.58 | koen | chouimat: but for a single release of a linux distro? |
16:39.04 | zecke | koen: RH was boxed 7 years ago :) |
16:40.03 | chouimat | koen 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.50 | koen | chouimat: 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.46 | chouimat | koen 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.56 | koen | right |
16:42.00 | koen | an in 7 years... |
16:42.10 | koen | s/an/and/ |
16:42.17 | koen | now they have git and stuff |
16:42.29 | koen | 2.6.0 to 2.6.20 is a huge move as well |
16:44.15 | chouimat | koen 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.10 | koen | I wonder how to prepare for such support |
16:45.34 | koen | I'd start by putting a complete buildbox + tapes in a safe place |
16:45.57 | chouimat | koen the best you can ... I still have to support a floppy based firewall I created in 2000/2001 ... |
16:46.18 | RP | zecke: Interesting patch. I need to think about it :} |
16:46.39 | chouimat | koen this depends on how much the "contract" will pay ... |
16:46.47 | Crofton | bring on the flat tax! |
16:46.56 | chouimat | Crofton hehe |
16:47.42 | chouimat | Crofton 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.44 | mr_nice | zecke: 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.31 | zecke | mr_nice: well, did you register the platform data? is the other part of the driver compiled in |
17:02.40 | zecke | RP: well |
17:03.23 | zecke | RP: 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.45 | zecke | RP: 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.46 | RP | zecke: It does imply that you have to make a defition for every virtual package though which isn't sometimes possibl |
17:05.47 | RP | e |
17:06.13 | RP | PREFERRED_PROVIDER_gtk+ = "gtk+" should be assumed unless its set to something else |
17:06.33 | zecke | RP: well, the current code needs to stay to keep the kernel-modules happy :} |
17:07.06 | zecke | RP: but logically: If I want to have RDEPEND gdk-pixbuf-gif it looks right to look into PREFERRED_PROVIDER_gdk-pixbuf-gif |
17:07.21 | zecke | brb |
17:08.15 | RP | zecke: 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.52 | RP | I specifically remember deciding not to add PREFERRED_RPROVIDERS as we could work out everything we needed without them |
17:09.44 | mr_nice | zecke: 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.03 | CoreDump|home | Could 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.39 | Jin^eLD | CoreDump|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.42 | Jin^eLD | and I do not have a rev= in that url |
17:19.12 | CoreDump|home | Jin^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.34 | Jin^eLD | well, svn does not have tags... at least as I understand :) |
17:19.46 | Jin^eLD | I think a "tag" in that sense is just a copy |
17:19.57 | Jin^eLD | because you could actually simply remember the revision to check out a "tag" |
17:20.31 | Jin^eLD | I know that was different in CVS... |
17:20.51 | *** join/#oe tkp (n=tom@62-64-195-125.dynamic.dial.as9105.com) |
17:21.03 | CoreDump|home | Jin^eLD: you are of course right. SVN handles tags and branches by creating a snapshot in a subfolder |
17:23.03 | zecke | mr_nice: no the keyboard driver |
17:23.18 | zecke | mr_nice: generic GPIO keyboard driver uses gpio.h and data supplied by the machine |
17:24.15 | zecke | RP: PREFERRED_PROVIDER == PREFERRED_PROVIDERS (at least ...) |
17:25.35 | zecke | RP: The question is. If both Gtk+-X11 and Gtk+-DirectFB can build gdk packages |
17:26.00 | zecke | RP: and when you need a gdk module at runtime, how to select between X11 and DirectFB? |
17:26.27 | RP | PREFERRED_PROVIDER_gtk+ = "gtk+" |
17:26.33 | zecke | RP: the current RDEPENDS code can't, the old one failed differently and people don't notice |
17:27.30 | zecke | RP: do you think that is intuitive, or is this a code is law thing? |
17:28.16 | RP | zecke: Its not a code is law thing, I think its the only solution that makes sense |
17:29.30 | RP | zecke: 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.31 | zecke | RP: If we accept this (I need to make up my mind) we have two issues to solve |
17:30.24 | zecke | RP: 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.39 | RP | Right, that isn't an option |
17:31.03 | zecke | okay back to the issue: gtk+ should provide gtk+ and gtk+-directfb should provide gtk+ as well? |
17:31.28 | zecke | RP: if we set PREFFERRED_PROVIDER_gtk+ = "gtk+-directfb" what else will be break? what else in BitBake? |
17:32.19 | RP | zecke: Is directfb designed to replace the standard gtk? |
17:33.18 | zecke | RP: they are API compatible (at least they should be) |
17:33.56 | *** join/#oe summatusmentis (n=summatus@72.168.202.219) |
17:33.57 | zecke | ~botmail koen your gdk providers are wrong :) |
17:34.20 | summatusmentis | does bitbake need to build the package before the source is available? |
17:34.41 | koen | zecke: they are? |
17:34.48 | RP | zecke: In that case it should provide gtk+ and setting the PREFERRED_PROVIDER you mention should work |
17:34.55 | zecke | koen: PREFERRED_PROVIDER_gtk+ = "gtk+" |
17:35.23 | RP | zecke: I think the code might be backfireing as the assumed PREFERRED_PROVIDER_gtk+ = "gtk+" isn't being assumed properly |
17:35.47 | RP | zecke: You shouldn't have to set that, it should default to it in my opinion - would you agree? |
17:36.39 | CIA-11 | 03coredump2 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.17 | koen | RP: didn't we agree to that at OEDEM already? |
17:37.50 | RP | koen: Yes, and I thought it was fixed but it appears to break for runtime providers for some reason |
17:38.04 | koen | ah, ok, I wasn't sure |
17:38.32 | RP | koen: That doesn't mean we shouldn't check our decision now either though, lets make sure we got it right :) |
17:38.49 | koen | right :) |
17:43.59 | mr_nice | zecke: ah platform_device struct. can be defined in simpad.c? |
17:44.34 | *** join/#oe greentux (n=lemke@195.227.105.180) |
17:45.22 | zecke | sorry need to run :} |
17:45.29 | zecke | my mon returned and I need to leave... |
18:04.40 | koen | I wish OSX would error out on printer/spool error |
18:05.00 | koen | instead 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.04 | summatusmentis | koen: why? |
18:10.22 | koen | so I know which documents to print again |
18:10.35 | summatusmentis | I 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.57 | CIA-11 | 03rpurdie * 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.46 | koen | RP: thanks for fixing bitbake -s |
18:21.48 | RP | koen: np, its good to catch these kind of problems so thanks for testing trunk :) |
18:22.08 | NAiL | koen: 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.11 | NAiL | http://pastebin.ca/408247 |
18:22.34 | *** join/#oe csmanx (n=csman@190.42.168.230) |
18:23.03 | koen | NAiL: no idea, sorry |
18:23.03 | koen | you could try 4.1.2 |
18:23.18 | NAiL | is there a gcc-cross_4.1.2? |
18:23.26 | koen | since a few days, yes :) |
18:23.35 | NAiL | ah, I'm working off of an svn repo |
18:23.41 | NAiL | until stuff actually works ;) |
18:24.25 | NAiL | oooh |
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.51 | likewise | ERROR: Nothing provides dependency glib-2.0 |
18:33.53 | NAiL | koen: is nptl ready? |
18:33.53 | likewise | ERROR: dependency glib-2.0 (for avahi) not satisfied |
18:33.55 | likewise | ERROR: No buildable providers for runtime avahi-daemon |
18:34.12 | likewise | whoops |
18:34.28 | koen | NAiL: CSL and MV claim it is |
18:34.36 | NAiL | koen: 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.26 | NAiL | koen: No idea who CSL and MV is, but I assume they have some authoritae. |
18:36.34 | koen | Codesourcery and montavista |
18:36.46 | koen | mv hired csl to do the nptl port |
18:36.59 | NAiL | aha |
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.59 | mrdata | woglinde: hi |
19:32.52 | *** join/#oe csmanx (n=csman@190.42.168.230) |
19:33.34 | mrdata | micky|working: hi, can i ask you one or two questions about a kernel Internal error: Oops - bad syscall problem |
19:34.27 | mickey|working | I'm sorry, but I'm not exactly a kernel guy. |
19:34.52 | mickey|working | mixing ABIs? |
19:35.02 | mickey|working | or calling a syscall that doesn't exist? |
19:35.37 | mrdata | micky|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.16 | mickey|working | your better audience would be zecke, schurig, pb_, RP, pH5, ... |
19:36.25 | koen | mickey|working: honda, fic, something else? |
19:36.42 | mrdata | micky|working: apmd try apmd_suspend() |
19:36.53 | mickey|working | koen: 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.02 | koen | ouch |
19:37.15 | mickey|working | now i have ~30 hours left to add the missing functionality |
19:37.23 | mickey|working | *sigh* |
19:38.29 | mrdata | micky|working: thx!, i will ask the others |
19:39.42 | mickey|working | hehe |
19:40.24 | koen | mickey|working: I can start asking OM related questions on tuesday? |
19:40.53 | koen | make that wednesday, I'm away for work on tuesday |
19:41.15 | koen | exam on wednesday.... |
19:41.19 | koen | nevermind... |
19:41.22 | mickey|working | sounds 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.00 | koen | <PROTECTED> |
19:43.03 | koen | 114% .... |
19:47.12 | koen | mickey|working: 29 hours even with the summertime kicking in tonight |
19:47.12 | NAiL | koen: that's nothing. I've seen "ps" use 120% ;) |
19:49.38 | koen | root@fic-gta01:~$ uptime |
19:49.38 | koen | <PROTECTED> |
19:49.42 | koen | still fairly stable |
20:21.05 | JustinP | Laibsch: yes? |
20:23.04 | koen | heh, I speed up matlab by giving the VM more RAM |
20:23.19 | koen | ~lart windows |
20:23.19 | ibot | does a little 'dpkg -P windows' action |
20:24.54 | koen | ~hail parallels coherence mode |
20:25.01 | ibot | ACTION 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.41 | mr_nice | nick mr_nice|scummvm |
20:40.58 | Ifaistos | NAiL : According to this -> http://bugs.busybox.net/bug_view_advanced_page.php?bug_id=925 this is fixed in svn |
20:41.36 | NAiL | Ifaistos: according to me, it ain't. I'm building from svn. |
20:41.41 | NAiL | ;) |
20:43.29 | NAiL | A fix went in svn last year. I'm using svn from a few days ago |
20:43.41 | koen | maybe they broke it again |
20:44.10 | koen | at times like this I usually put some more buildroot/crosstool patches to gcc in OE |
20:44.41 | NAiL | yeah |
20:44.52 | NAiL | I suspect it might work with 4.2, from what I've been readin |
20:45.01 | koen | 4.2 isn't out yet.... |
20:45.16 | NAiL | no, but buildroot has patches for 4.2-patches |
20:46.48 | koen | you could try adding a newer version of gcc-cross_4.2-20060513.bb |
20:47.28 | Ifaistos | i 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.01 | Ifaistos | i had boa (the web server) build prior to the last changes to gcc and it was working fine |
20:48.18 | Ifaistos | rebuild it and it just won't run |
20:48.40 | Ifaistos | same with apache2 |
20:48.56 | Ifaistos | sigfaults on ppc405 |
20:48.57 | koen | cherokee ftw! |
20:49.48 | Ifaistos | perl complains about some library files not been correct |
20:50.12 | Ifaistos | in general there is something wrong... haven't figured it out |
20:50.58 | Ifaistos | not sure if its a host problem, a tool chain or my stupidity problem ;) |
20:53.41 | Ifaistos | enough ranting for tonight ;) |
20:53.48 | Ifaistos | night everyone |
20:57.56 | koen | 'night Ifaistos |
22:05.23 | CIA-11 | 03koen 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.22 | timtimred | hi, 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.13 | timtimred | so i dont have to list a whole lotta files individually |
23:22.32 | NAiL | (and he's talking about a *lot* of files) ;-) |
23:31.08 | timtimred | ahh i got it |
23:31.20 | timtimred | that was like, too easy |
23:31.23 | NAiL | heh |
23:31.29 | NAiL | how? :) |
23:32.05 | timtimred | e.g. FILES_${PN} += "/whackdir" |