**** BEGIN LOGGING AT Sat Mar 24 02:59:57 2007 Mar 24 09:29:11 03koen 07org.oe.dev * rb0b98bec... 10/ (1 packages/mplayer/mplayer_svn.bb): mplayer: add optimizations for a780 and hx4700 Mar 24 09:33:39 did someone forget to check in a no-xwc.patch ? Mar 24 09:34:21 03koen 07org.oe.dev * r183ae1b2... 10/ (1 packages/gsm/files/default): gsm: add default 'default' file Mar 24 09:34:57 rwhitby: that or checked in a wrong SRC_URI Mar 24 09:35:06 rwhitby: but if you get that message, you hit a bug Mar 24 09:35:26 (I'm not aware you have a machine that uses directFB) Mar 24 09:40:09 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 :-) Mar 24 09:40:38 or when they finally deprecate their svn Mar 24 10:05:32 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 Mar 24 10:08:00 what base distro/gcc version do people use here . Mar 24 10:08:31 I have two gentoo based system and only one of them is capable of compiling gcc Mar 24 10:08:55 (that is the oe gcc) of course gentoo is able to compile any gcc version Mar 24 10:14:24 on this machine I keep hitting this message CROSS COMPILE Badness: /usr/include in INCLUDEPATH: /usr/include/libffi Mar 24 10:15:06 keesj: what are you building? (hoi) Mar 24 10:16:11 I am trying to build nano , but the error comes from gcc-cross-initial-4.1.1 Mar 24 10:16:52 I have my machine set to smdk2440 and my DISTRO set to generic. Mar 24 10:17:38 I tried different tastes Mar 24 10:18:23 koen__: good morning Mar 24 10:19:31 hey likewise Mar 24 10:19:45 * koen wonders why it takes the ISP 12 hours to reboot a switch Mar 24 10:22:57 NAiL: You're using uclibc svn for ARM? Mar 24 10:23:45 keesj: my nano seems not to depend on libffi Mar 24 10:24:03 koen: I'm trying ;) Mar 24 10:24:45 NAiL: Isn't uclibc almost unmaintained currently? Mar 24 10:24:56 NAiL: Sorry, the SVN tree I mean. Mar 24 10:25:11 likewise I guess that anything I try to build will fail , perhas I must try the task-base first? Mar 24 10:25:36 likewise: I don't know. But I get further with the svn tree than 0.9.28 Mar 24 10:25:53 keesj: in theory no, dependencies should be respected Mar 24 10:26:58 likewise: CSL and others are waiting for the .29 release to merge their stuff Mar 24 10:27:19 so proper development is halted till Erik does 'make dist' Mar 24 10:27:39 koen: yup, that would be a nice point to jump in on uclibc again. Mar 24 10:28:07 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 Mar 24 10:28:11 the release was supposed to happen shortly after fosdem Mar 24 10:35:47 koen was it nice in recife, I did not see much coverage Mar 24 10:36:06 keesj: very nice! Mar 24 10:37:49 great Mar 24 10:39:07 Laibsch: morning! Mar 24 10:39:15 good morning likewise Mar 24 10:39:25 good morning everyone Mar 24 10:40:09 whooo, mtn annotate takes it easy... Mar 24 10:40:43 likewise: mtn >= 0.32? Mar 24 10:41:20 I would expect the annotate algorithm to work backwards until all lines are covered, instead of going through 13k revisions... mtn == 0.31 Mar 24 10:41:31 right, 0.31 is slow Mar 24 10:41:44 0.32 is a few orders of magnitude faster Mar 24 10:41:45 koen: ok, will try >= 0.32 Mar 24 10:41:58 'seconds' versus 'hours' Mar 24 10:42:59 likewise: and get a new db snapshot, since the format change to accomodate some cached info (the one that makes log and annotate faster) Mar 24 10:55:39 03likewise 07org.oe.dev * r42e4a37b... 10/ (1 classes/image.bbclass): image.bbclass: Removed wildcard rm as it broke building multiple rootfs image types. Mar 24 11:22:42 hi all Mar 24 11:24:08 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. Mar 24 11:25:01 sorry gtk+-directfb_2.10.9.bb not gtk+_2.10.9.bb Mar 24 11:25:44 just remove the ...directfb.bb file Mar 24 11:27:57 DerCorny: thx, I will try it Mar 24 11:28:44 mr_nice: well, it did the job for me - hope it works for you, too Mar 24 11:33:36 mr_nice: hi, battery status now works with gpe-image also Mar 24 11:34:11 mr_nice: but i have not using the battery class from hh.org Mar 24 11:36:31 mr_nice: now i'am ready to search, why does simpad do not suspend Mar 24 11:48:48 zecke: hi Mar 24 11:50:33 mrdata: hi Mar 24 11:51:04 mrdata: you was using the apm funktion for it? Mar 24 11:52:50 mr_nice: yes, i get apm_get_power_status = simpad_apm_get_power_status working Mar 24 11:53:55 mr_nice: cat /proc/apm gives now correct results Mar 24 11:54:12 mrdata: ah, ok also cool to have that. afaik there is no common interface for battery Mar 24 11:54:21 mrdata: i think Mar 24 11:56:12 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. Mar 24 11:57:16 mr_nice: yes, so i used my own work on ucb1x00-simpad.c and fill with simpad_get_battery function struct simpad_battery_apm Mar 24 11:58:51 mrdata: do you know if the driver just shows the status of the battery or is it also responsable for charging stuff? Mar 24 11:59:31 mr_nice: and in simpad_pm.c i use simpad_apm_get_power_status -> simpad_get_battery Mar 24 11:59:50 mr_nice: the whole stuff Mar 24 12:00:31 mrdata: so it could overload the battery? Mar 24 12:00:38 mrdata: I wonder how they calculated the less then 8.5 volt = no power supply for cl4 and less 12 v for sl4 Mar 24 12:00:55 mr_nice: the whole struct apm_power_info() is correct now Mar 24 12:01:07 mrdata: hehe, ah ok :) thats nice Mar 24 12:01:35 mrdata: apm is an importent thing for that device I think Mar 24 12:02:07 mr_nice: ucb1x00 -> vcharger tell the voltage for power supply Mar 24 12:04:13 mr_nice: if power supply on, than vcharger > 12000, if power supply off vcharger = 800 or so Mar 24 12:05:52 mr_nice: witch voltage have your power supply for cl4? Mar 24 12:06:25 mrdata: I wondered because my 2 power suplys (sl4, t-sinus) are identicaly Mar 24 12:06:34 mr_nice: you told me, that you have two SIMpads Mar 24 12:06:37 mrdata: 12v Mar 24 12:06:51 mrdata: 3300mA Mar 24 12:07:31 mrdata: they are exactly the same Mar 24 12:08:06 mrdata: I don't know if there exists a different one for cl4 or swisscom wp50 Mar 24 12:08:18 mr_nice: than i understand, you have two V4415-Z35-X11 Mar 24 12:09:10 mrdata: yes Mar 24 12:09:28 mrdata: interesting http://lkml.org/lkml/2007/2/2/217 Mar 24 12:10:47 mr_nice: yes, have also found and reading that Mar 24 12:12:14 mr_nice: you must only change MIN_SUPPLY from 8500 to 12000 for your SMALL_BATTERY Mar 24 12:12:57 mrdata: do you think 8.5 V is used by cl4 or wp50? Mar 24 12:13:47 mrdata: would be good to know Mar 24 12:14:25 mr_nice: yes, but i have no cl4 or wp50 Mar 24 12:14:43 hi$ Mar 24 12:15:30 mr_nice: you could also change -> CALIBRATE_BATTERY(a) ((((a + 3)*12610)/860) + 170) Mar 24 12:16:04 mr_nice: this gives the right vbatt voltage for akku Mar 24 12:18:48 mrdata: hm, so we need at least 3 kinds of precompiled modules? Mar 24 12:19:34 mrdata: we should consider about getting the type of the bat as an argument to the module end exclude it from the kernel Mar 24 12:19:40 mr_nice: the battery could not be overload by us, because the charge circuit for it works without us Mar 24 12:19:56 mrdata: thats very nice! Mar 24 12:20:57 mrdata: I will rewrite the battery module that way that you can define the battery and power supply stuff at modules.conf Mar 24 12:21:56 mr_nice: when vcharger >= 8500, the power supply is definedly on line, i think Mar 24 12:23:26 mrdata: you are the electrical guy ;) I will trust you Mar 24 12:23:36 mr_nice: charging tell us icharger, when vcharger >= 8500 Mar 24 12:23:57 mrdata: 8300 is the level of a big size battery Mar 24 12:24:31 mr_nice: i have wrote this to you, it's my job Mar 24 12:24:41 mrdata:hehe yes Mar 24 12:24:59 mrdata: so I will exclude it from the config Mar 24 12:25:16 mrdata: and only ask about the battery type Mar 24 12:26:32 mr_nice: i have set BATT_FULL to 8100, because when the charging ends, vbatt = 8425 or so Mar 24 12:28:03 mrdata: for the big bat? Mar 24 12:28:12 mr_nice: but when power supply offline, vbatt drop to lower value, because SIMpad is on Mar 24 12:28:34 mr_nice: and backlight dains the akku down Mar 24 12:28:48 mrdata: ah, good to know Mar 24 12:29:38 mr_nice: yes, small or big akku is not that thing, both have li-ion akku and there max. voltage is 8.4 Mar 24 12:30:36 mrdata: what is the charging led level thing good for? Mar 24 12:31:18 mr_nice: it is also a voltage, which represent the current for charging li-ion akku Mar 24 12:32:00 mr_nice: li-ion charging works with constant current, and than with constant voltage to fullfill the akku Mar 24 12:32:36 mr_nice: the last current was lower and lower Mar 24 12:33:31 mr_nice: and when icharger is 27 or 28 (becaus of ADC error from ucb1300), than charging is done, and akku full Mar 24 12:34:53 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)? Mar 24 12:35:06 mr_nice: the charging LED from SIMpad is independently from us Mar 24 12:36:14 mrdata: ah. hm, have to think about that. do you think we need two different definations for the two kinds of batterys? Mar 24 12:36:18 mr_nice: fuse is neccessary, wrong work with li-ion akku is dangerous Mar 24 12:36:37 mrdata: do you know where to get the fuse? Mar 24 12:37:18 mrdata: I think the difference is to de- and resolder it without destroying it Mar 24 12:37:42 mrdata: I will change the article and add a warning about the fuse Mar 24 12:37:43 mr_nice: no, i have to reuse that whole circuit, when i have rebuild my akku-pack Mar 24 12:39:09 mr_nice: it's not only a fuse, i think, it saves against over temperature while charging Mar 24 12:39:44 mrdata: yes. I also think so so it is quite difficult to resolder without destroying it Mar 24 12:40:56 mr_nice: no, it is very easy i think, you must desolder tha pins on the circuit-pcb Mar 24 12:41:35 mrdata: good idea Mar 24 12:41:37 mr_nice: then you can remove the black-plastic savely Mar 24 12:42:24 mr_nice: the fuse was under the black-plastic, hold with tape Mar 24 12:42:55 mrdata: do you know if it is the same circut board for the small and the big battery? Mar 24 12:44:31 mr_nice: i dont now, and i dont know how the different charging current for the akku-pack is handelt Mar 24 12:44:44 mrdata: hm, well better not play with that stuff. Mar 24 12:45:14 mrdata: I thougt about pimping the t-sinus accu as well Mar 24 12:45:38 mr_nice: yes, but the akku-pack for my linux SIMpad was damaged Mar 24 12:45:58 mrdata: and you know what you are doing Mar 24 12:46:16 mr_nice: i hope so, i must do the repair myself Mar 24 12:46:41 mr_nice: and it's working again ;:)) Mar 24 12:47:06 mrdata: mine is also demaged. I hope it will work for me, too Mar 24 12:47:49 mr_nice: a real problem, no one will sell my new li-ion akku cells Mar 24 12:48:23 mr_nice: i got it only from ebay Mar 24 12:48:54 mr_nice: and she was used before Mar 24 12:49:50 mrdata: you can buy them realy cheap at pollin.de 2 ? each for new ones! Mar 24 12:49:52 mr_nice: and from the production on, after 2 years she could be damaged Mar 24 12:50:40 mr_nice: the pollin.de one, are also not new, i think Mar 24 12:51:14 mrdata: hm, could be Mar 24 12:52:51 mr_nice: i have reading, pollin.de buy this from iomega (a mp3 player), and remove the akku-cells Mar 24 12:53:55 mrdata: hm, could be Mar 24 12:54:35 mrdata: sometimes there are new simpad accus on ebay but you nearly can buy a new simpad for the price of them Mar 24 12:54:53 mr_nice: for the first try, i have destroy a akku-pack from lifebook-notebook Mar 24 12:55:52 mr_nice: there are 6 li-ion cells inside, but also damaged Mar 24 12:56:16 mr_nice: new simpad accus are not possible Mar 24 12:56:33 mrdata: they are to old you think? Mar 24 12:56:54 mrdata: so they are not worth the money? Mar 24 12:57:16 mr_nice: yes, accus damaged over the time, also when not in use Mar 24 12:58:05 mr_nice: i have reading a lot article about that stuff Mar 24 12:58:17 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 Mar 24 12:59:50 mr_nice: yes and no, the overtemperature circuit sould build inside the mobile-akku Mar 24 13:00:39 mrdata: so if there is a overtemperature circuit inside the mobile accu it is save? Mar 24 13:00:41 mr_nice: but i have no idea, was the cuircuit-pcb inside the original siemens accu-pack does Mar 24 13:01:07 mrdata: ah, so better do not risk it? Mar 24 13:01:53 mr_nice: the problem is, each li-ion accu cell have max. 4.2V Mar 24 13:02:31 mr_nice: we build a pack with two (or two * two) Mar 24 13:03:27 mr_nice: the end voltage from this pack is max 8.4V Mar 24 13:04:00 mrdata: and that is to high? Mar 24 13:04:49 mr_nice: no, but each cell must controlled seperatly for voltage < max. 4,2V Mar 24 13:05:22 mr_nice: better for lifetime is max. 4,1V Mar 24 13:06:05 mr_nice: a charging circuit is therfore neccessary, to do this job Mar 24 13:06:32 mrdata: ok I will give up that then Mar 24 13:08:08 mr_nice: have a view of the accu-pack from simpad, two cells parallel together, and then two "in reihe" Mar 24 13:10:03 mr_nice: the pack have 3 pins routed to the circuit-pcb, i have meassured this, and found 2x 4,1V separeted Mar 24 13:11:48 mr_nice: and 1x 8,2V, so all was okay, the circuit now know each cell (better 2 parallel for correctnes) Mar 24 13:12:59 mrdata: hopefully I will be able to do the mod with the oem cells Mar 24 13:13:02 mr_nice: for surely complete control, she had to do also load-balacing with the 2 cells in parallel Mar 24 13:14:10 mr_nice: i have buy 12 one from ebay, 4 one are in use now, so i have 8 over Mar 24 13:14:34 mr_nice: i could also do the job for you, when you will Mar 24 13:15:11 mrdata: I have 6 from pollin. big thx for your offer - I have to think about it. Mar 24 13:16:44 mr_nice: no problem, but please have a look to make no short-cut to your cells Mar 24 13:17:48 mr_nice: li-ion cells are explosive with the wrong handling, this is the reason, why no one will you sell new cells Mar 24 13:18:45 mr_nice: you could only buy new sampled accu-packs Mar 24 13:19:23 mrdata: yes, I will be carefuly. thx for the warnings. Mar 24 13:20:15 mrdata: I found an article on the net on how to replace laptop accus and there where the safety things mentioned Mar 24 13:20:16 mr_nice: is okay, then wish you good luck for "modding" Mar 24 13:20:25 mrdata: thx Mar 24 13:20:54 mr_nice: the article from england Mar 24 13:21:37 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! Mar 24 13:22:10 mr_nice: also, bye for now Mar 24 13:49:23 koen: is bitbake still claiming that the preferred provider is not set? Mar 24 13:49:32 zecke: no idea Mar 24 13:49:50 zecke: I'm internetting over GPRS now, so ssh is too painfull Mar 24 13:50:07 koen: I would look into the issue now, if it wasn't fixed by someone elese yesterday Mar 24 13:50:49 you were the one seeing the bug :) Mar 24 13:51:18 hehe Mar 24 14:08:53 RP: ping Mar 24 14:09:02 RP: http://rafb.net/p/PNjHfg85.html which is not correct but more correct than before Mar 24 14:09:35 RP: we search RPROVIDERs for item (e.g. gdk-pixbuf-jpg) Mar 24 14:10:39 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 :) Mar 24 14:11:32 RP: I think we should resolve RPROVIDERS by collection eligible, then looking at PREFERRED_PROVIDER_xyz and then resolve that again Mar 24 14:12:05 RP: PREFERRED_PROVIDER_xyz could be virtual/foo, we indirectly do this today with the loop... Mar 24 14:13:15 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 Mar 24 14:27:39 heh Mar 24 14:28:38 koen: this comes from all the different versions :) Mar 24 14:31:13 koen: OT: can cups handle bluetooth printers? Mar 24 14:31:19 using a gprs link exposes all the GUIs that block on IO Mar 24 14:31:19 bluetooth print profile that is Mar 24 14:31:29 e.g. all of OSX Mar 24 14:31:34 zecke: sort of Mar 24 14:31:59 zecke: bluez-utils_3.8.bb:# --enable-cups install CUPS backend support Mar 24 14:32:06 bluezutils builds a cups plugin for that Mar 24 14:33:36 hmmm Mar 24 14:33:59 drat, that's still local diff Mar 24 14:34:59 hehe Mar 24 14:35:06 zecke: http://www.angstrom-distribution.org/repo/?action=details&pnm=bluez-cups-backend Mar 24 14:35:55 ah good Mar 24 14:36:49 * zecke recognizes he doesn't feel $HOME at home :} Mar 24 14:42:37 ah, internet works again Mar 24 14:42:56 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 Mar 24 14:57:05 zecke: happy now? Mar 24 14:57:57 koen: so the switch was switched? Mar 24 14:58:47 it seems that way Mar 24 14:59:07 * koen looks when the disconnect happened Mar 24 14:59:13 10 hours and 8 minutes ago Mar 24 14:59:30 koen: does it include a OpenMoko GUI? ;) Mar 24 14:59:49 zecke: hand me some php bindings :[ Mar 24 14:59:56 s/[/p/ Mar 24 15:00:12 koen: hehe, well Mar 24 15:01:15 This seems incorrect, can someone agree on that? Mar 24 15:01:17 conf/bitbake.conf:201:IMAGE_CMD_tar = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 ." Mar 24 15:01:18 conf/bitbake.conf:202:IMAGE_CMD_tar.gz = "cd ${IMAGE_ROOTFS} && tar -zcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.gz ." Mar 24 15:01:20 conf/bitbake.conf:203:IMAGE_CMD_tar.bz2 = "cd ${IMAGE_ROOTFS} && tar -jcvf ${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}.rootfs.tar.bz2 . Mar 24 15:01:21 " Mar 24 15:01:39 now we have tar.bz2, yes Mar 24 15:01:57 The "tar" image type does bzip2 compression and "tar.bz2" does too. Mar 24 15:02:01 we used to compress 'tar' to gz and switched it to bz2 a few years ago Mar 24 15:02:26 likewise: could you send a mail about that? Mar 24 15:02:43 koen: sorry, yes Mar 24 15:02:44 I suspect some people/images/distros rely on the (wrong) behaviour Mar 24 15:03:27 koen: yes, there are assumptions built in (my latest checkin fixed the assumption that someone only builds 1 image type). Mar 24 15:15:55 What is the *.rootfs.jffs2.summary file supposed to be? Mar 24 15:16:29 sirfred: some JFFS2 extension to speed-up mounting. Mar 24 15:16:48 likewise: So, it's a replacement for rootfs.jffs2 file? Mar 24 15:17:11 sirfred: JFFS2 does not scale well if flash is big. I dunno, it could be the JFFS2 fs with this extension enabled. Mar 24 15:17:35 likewise: I see it's generated using sumtool on the regular jffs2 image. Mar 24 15:18:21 koen: the runtime 'fix' breaks other things :) Mar 24 15:18:36 sirfred: http://www.inf.u-szeged.hu/jffs2/mount.php Mar 24 15:18:43 koen: I will need to chat with RP about it Mar 24 15:18:43 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 Mar 24 15:18:56 I wonder if that's the reason of the error. Mar 24 15:19:02 likewise: Thanks, I'm going to take a look Mar 24 15:19:04 sirfred: you need summary option enabled in the kernel Mar 24 15:19:17 sirfred: jffs doesn't store the inode tree, it needs to rebuild it at every mount, the summary images include one Mar 24 15:19:34 which is why jffs2 takes so much RAM Mar 24 15:19:37 koen: Thanks. Mar 24 15:19:50 * likewise mumbles logfs Mar 24 15:20:08 koen: So. is reasonably to call mkfs.jffs2 without the --eraseblock arg ? Mar 24 15:20:18 likewise: logfs ftw! Mar 24 15:20:26 sirfred: I don't know Mar 24 15:20:32 sirfred: you'd have to ask RP or hrw Mar 24 15:20:39 koen: OK. Thanks. Mar 24 15:22:24 Hmmm, kernel for c7x0 is compiled with CONFIG_JFFS2_SUMMARY=y, so, it seems that summary images are supported. Mar 24 15:22:25 koen, do you know if florian will connect here today ? Mar 24 15:22:47 But last time I tried to flash one of those images, I got a panic: kernel was not finding init Mar 24 15:23:21 sirfred: what kind of errors/problem do you get? Mar 24 15:23:34 sirfred: sorry, missed your last line Mar 24 15:23:38 likewise: Using the non summary image, a lot of magic number issues. Mar 24 15:23:56 * koen reads http://www.fiftythree.org.nyud.net:8080/etherkiller/ Mar 24 15:23:58 sirfred: are you sure you did an erase of the flash Mar 24 15:24:10 likewise: As if the rootfs.jffs2 was not valid. Using the summary image, no magic number issues, but init was not found. Mar 24 15:24:22 likewise: I assume that updater.sh does that job, doesn't it? Mar 24 15:24:36 sirfred: dunno where updater.sh comes from Mar 24 15:24:59 likewise: It's the script used to flash rootfs and kernel into c7x0 machines. Mar 24 15:25:22 likewise: It used to work in the recent past. Mar 24 15:25:28 yes, updater.sh erases the flash Mar 24 15:26:05 2.6.20 doesn't seem to recognize my SD slot either. Mar 24 15:34:26 Well, I'm going to flash again, using 2.6.20 and rootfs.jffs2.summary Mar 24 15:44:40 ~seen justinip Mar 24 15:44:44 ~seen JustinP Mar 24 15:45:18 Laibsch: i haven't seen 'justinip' Mar 24 15:45:21 justinp was last seen on IRC in channel #openzaurus, 19h 3m 57s ago, saying: 'Laibsch: rmmod, insmod, modprobe'. Mar 24 16:02:54 RP: http://rafb.net/p/547NVr52.html one problem left... Mar 24 16:04:01 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 ? Mar 24 16:04:16 RP: alternatively we declare the PREFERRED_PROVIDER_gdk-pixbuf-png = "gtk+" a wrong construct Mar 24 16:31:32 mr_nice: it checks out the version in svn present at last midnight Mar 24 16:35:04 koen: thx. I will switch the simpad patches and defconfig to the slackpad svn then. Mar 24 16:36:08 zecke: did you know that some RH market droid promised 7 years of support for one of their distros? Mar 24 16:36:40 koen: no, why did they do it? Why should I care? Mar 24 16:37:01 as a response to oracle Mar 24 16:37:23 as marcel said "I refuse to fix kernel 2.2" Mar 24 16:38:03 koen a lot of company in the US except 5 to 7 years of support for a product ... Mar 24 16:38:23 later guys Mar 24 16:38:26 s/except/expect Mar 24 16:38:43 chouimat: for a physical product I'd expect it Mar 24 16:38:58 chouimat: but for a single release of a linux distro? Mar 24 16:39:04 koen: RH was boxed 7 years ago :) Mar 24 16:40:03 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 Mar 24 16:40:50 chouimat: the difference is that MS doesn't release a new windows kernel every 2 months Mar 24 16:41:46 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) Mar 24 16:41:56 right Mar 24 16:42:00 an in 7 years... Mar 24 16:42:10 s/an/and/ Mar 24 16:42:17 now they have git and stuff Mar 24 16:42:29 2.6.0 to 2.6.20 is a huge move as well Mar 24 16:44:15 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 :) Mar 24 16:45:10 I wonder how to prepare for such support Mar 24 16:45:34 I'd start by putting a complete buildbox + tapes in a safe place Mar 24 16:45:57 koen the best you can ... I still have to support a floppy based firewall I created in 2000/2001 ... Mar 24 16:46:18 zecke: Interesting patch. I need to think about it :} Mar 24 16:46:39 * Crofton detests calculating his taxes Mar 24 16:46:39 koen this depends on how much the "contract" will pay ... Mar 24 16:46:47 bring on the flat tax! Mar 24 16:46:48 * chouimat too ... Mar 24 16:46:56 Crofton hehe Mar 24 16:47:42 Crofton even easier bring the flat tax and send me the bill once a year ( they have all the information about me anyway) Mar 24 17:00:45 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 Mar 24 17:02:31 mr_nice: well, did you register the platform data? is the other part of the driver compiled in Mar 24 17:02:40 RP: well Mar 24 17:03:23 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) Mar 24 17:03:45 RP: and PREFERRED_PROVIDER_gdk-pixbuf-gif = "gtk+" makes a lot more sense from OE's pov Mar 24 17:05:46 zecke: It does imply that you have to make a defition for every virtual package though which isn't sometimes possibl Mar 24 17:05:47 e Mar 24 17:06:13 PREFERRED_PROVIDER_gtk+ = "gtk+" should be assumed unless its set to something else Mar 24 17:06:33 RP: well, the current code needs to stay to keep the kernel-modules happy :} Mar 24 17:07:06 RP: but logically: If I want to have RDEPEND gdk-pixbuf-gif it looks right to look into PREFERRED_PROVIDER_gdk-pixbuf-gif Mar 24 17:07:21 brb Mar 24 17:08:15 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 Mar 24 17:08:52 I specifically remember deciding not to add PREFERRED_RPROVIDERS as we could work out everything we needed without them Mar 24 17:09:44 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 Mar 24 17:16:03 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? Mar 24 17:17:39 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 Mar 24 17:18:42 and I do not have a rev= in that url Mar 24 17:19:12 Jin^eLD: I'll try that, thanks. It kinda defeats the pupose of a TAG IMO tho ;) Mar 24 17:19:34 well, svn does not have tags... at least as I understand :) Mar 24 17:19:45 I think a "tag" in that sense is just a copy Mar 24 17:19:57 because you could actually simply remember the revision to check out a "tag" Mar 24 17:20:31 I know that was different in CVS... Mar 24 17:21:03 Jin^eLD: you are of course right. SVN handles tags and branches by creating a snapshot in a subfolder Mar 24 17:23:03 mr_nice: no the keyboard driver Mar 24 17:23:18 mr_nice: generic GPIO keyboard driver uses gpio.h and data supplied by the machine Mar 24 17:24:15 RP: PREFERRED_PROVIDER == PREFERRED_PROVIDERS (at least ...) Mar 24 17:25:35 RP: The question is. If both Gtk+-X11 and Gtk+-DirectFB can build gdk packages Mar 24 17:26:00 RP: and when you need a gdk module at runtime, how to select between X11 and DirectFB? Mar 24 17:26:26 PREFERRED_PROVIDER_gtk+ = "gtk+" Mar 24 17:26:33 RP: the current RDEPENDS code can't, the old one failed differently and people don't notice Mar 24 17:27:30 RP: do you think that is intuitive, or is this a code is law thing? Mar 24 17:28:16 zecke: Its not a code is law thing, I think its the only solution that makes sense Mar 24 17:29:30 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? Mar 24 17:29:31 RP: If we accept this (I need to make up my mind) we have two issues to solve Mar 24 17:30:24 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 Mar 24 17:30:39 Right, that isn't an option Mar 24 17:31:03 okay back to the issue: gtk+ should provide gtk+ and gtk+-directfb should provide gtk+ as well? Mar 24 17:31:28 RP: if we set PREFFERRED_PROVIDER_gtk+ = "gtk+-directfb" what else will be break? what else in BitBake? Mar 24 17:32:19 zecke: Is directfb designed to replace the standard gtk? Mar 24 17:33:18 RP: they are API compatible (at least they should be) Mar 24 17:33:57 ~botmail koen your gdk providers are wrong :) Mar 24 17:34:20 does bitbake need to build the package before the source is available? Mar 24 17:34:41 zecke: they are? Mar 24 17:34:48 zecke: In that case it should provide gtk+ and setting the PREFERRED_PROVIDER you mention should work Mar 24 17:34:54 koen: PREFERRED_PROVIDER_gtk+ = "gtk+" Mar 24 17:35:23 zecke: I think the code might be backfireing as the assumed PREFERRED_PROVIDER_gtk+ = "gtk+" isn't being assumed properly Mar 24 17:35:47 zecke: You shouldn't have to set that, it should default to it in my opinion - would you agree? Mar 24 17:36:39 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 Mar 24 17:37:17 RP: didn't we agree to that at OEDEM already? Mar 24 17:37:50 koen: Yes, and I thought it was fixed but it appears to break for runtime providers for some reason Mar 24 17:38:04 ah, ok, I wasn't sure Mar 24 17:38:32 koen: That doesn't mean we shouldn't check our decision now either though, lets make sure we got it right :) Mar 24 17:38:49 right :) Mar 24 17:43:59 zecke: ah platform_device struct. can be defined in simpad.c? Mar 24 17:45:22 sorry need to run :} Mar 24 17:45:29 my mon returned and I need to leave... Mar 24 18:04:40 I wish OSX would error out on printer/spool error Mar 24 18:04:59 instead of stating the job was completed Mar 24 18:10:04 koen: why? Mar 24 18:10:22 so I know which documents to print again Mar 24 18:10:36 I see Mar 24 18:16:55 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) Mar 24 18:19:46 RP: thanks for fixing bitbake -s Mar 24 18:21:48 koen: np, its good to catch these kind of problems so thanks for testing trunk :) Mar 24 18:22:08 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? :) Mar 24 18:22:11 http://pastebin.ca/408247 Mar 24 18:22:52 NAiL: no idea, sorry Mar 24 18:22:55 you could try 4.1.2 Mar 24 18:23:18 is there a gcc-cross_4.1.2? Mar 24 18:23:26 since a few days, yes :) Mar 24 18:23:35 ah, I'm working off of an svn repo Mar 24 18:23:40 until stuff actually works ;) Mar 24 18:24:25 oooh Mar 24 18:24:50 * NAiL thinks this might be related to the simple fact that uclibc won't have nptl until after 0.9.29 Mar 24 18:30:44 * koen is tempted to add a svn snapshot + nptl patch Mar 24 18:33:52 ERROR: Nothing provides dependency glib-2.0 Mar 24 18:33:52 koen: is nptl ready? Mar 24 18:33:53 ERROR: dependency glib-2.0 (for avahi) not satisfied Mar 24 18:33:55 ERROR: No buildable providers for runtime avahi-daemon Mar 24 18:34:12 whoops Mar 24 18:34:28 NAiL: CSL and MV claim it is Mar 24 18:34:36 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 ;) Mar 24 18:35:26 koen: No idea who CSL and MV is, but I assume they have some authoritae. Mar 24 18:36:34 Codesourcery and montavista Mar 24 18:36:46 mv hired csl to do the nptl port Mar 24 18:36:59 aha Mar 24 19:30:00 woglinde: hi Mar 24 19:33:34 micky|working: hi, can i ask you one or two questions about a kernel Internal error: Oops - bad syscall problem Mar 24 19:34:27 I'm sorry, but I'm not exactly a kernel guy. Mar 24 19:34:52 mixing ABIs? Mar 24 19:35:02 or calling a syscall that doesn't exist? Mar 24 19:35:38 micky|working: then sorry, when simpad should do suspend with apm --suspend Mar 24 19:36:16 your better audience would be zecke, schurig, pb_, RP, pH5, ... Mar 24 19:36:25 mickey|working: honda, fic, something else? Mar 24 19:36:43 micky|working: apmd try apmd_suspend() Mar 24 19:36:53 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 :( Mar 24 19:37:01 ouch Mar 24 19:37:16 now i have ~30 hours left to add the missing functionality Mar 24 19:37:23 *sigh* Mar 24 19:38:29 micky|working: thx!, i will ask the others Mar 24 19:38:59 * koen switches mickey|working to 36 hours/day Mar 24 19:39:42 hehe Mar 24 19:39:50 * chouimat sends a cargo of coffee to mickey|working Mar 24 19:40:24 mickey|working: I can start asking OM related questions on tuesday? Mar 24 19:40:53 make that wednesday, I'm away for work on tuesday Mar 24 19:41:06 * koen checks schedule Mar 24 19:41:15 exam on wednesday.... Mar 24 19:41:19 nevermind... Mar 24 19:41:23 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 Mar 24 19:43:00 5021 root 25 0 169m 25m 9300 D 114 2.6 144:52.25 Xorg Mar 24 19:43:03 114% .... Mar 24 19:47:12 mickey|working: 29 hours even with the summertime kicking in tonight Mar 24 19:47:12 koen: that's nothing. I've seen "ps" use 120% ;) Mar 24 19:49:38 root@fic-gta01:~$ uptime Mar 24 19:49:38 19:49:46 up 4 days, 5:37, 3 users, load average: 1.02, 1.03, 1.00 Mar 24 19:49:42 still fairly stable Mar 24 20:21:05 Laibsch: yes? Mar 24 20:23:04 heh, I speed up matlab by giving the VM more RAM Mar 24 20:23:19 ~lart windows Mar 24 20:23:19 * ibot does a little 'dpkg -P windows' action Mar 24 20:24:54 ~hail parallels coherence mode Mar 24 20:25:02 * ibot bows down to parallels coherence mode and chants, "I'M NOT WORTHY!!" Mar 24 20:35:41 nick mr_nice|scummvm Mar 24 20:40:58 NAiL : According to this -> http://bugs.busybox.net/bug_view_advanced_page.php?bug_id=925 this is fixed in svn Mar 24 20:41:36 Ifaistos: according to me, it ain't. I'm building from svn. Mar 24 20:41:40 ;) Mar 24 20:43:29 A fix went in svn last year. I'm using svn from a few days ago Mar 24 20:43:41 maybe they broke it again Mar 24 20:44:10 at times like this I usually put some more buildroot/crosstool patches to gcc in OE Mar 24 20:44:40 yeah Mar 24 20:44:52 I suspect it might work with 4.2, from what I've been readin Mar 24 20:45:00 4.2 isn't out yet.... Mar 24 20:45:16 no, but buildroot has patches for 4.2-patches Mar 24 20:46:30 * Ifaistos wonders why it has to be so difficult to have a working toolchain Mar 24 20:46:47 you could try adding a newer version of gcc-cross_4.2-20060513.bb Mar 24 20:47:28 i am finding some weird stuff also for which i have no explanation till now. Mar 24 20:48:01 i had boa (the web server) build prior to the last changes to gcc and it was working fine Mar 24 20:48:17 rebuild it and it just won't run Mar 24 20:48:40 same with apache2 Mar 24 20:48:56 sigfaults on ppc405 Mar 24 20:48:57 cherokee ftw! Mar 24 20:49:48 perl complains about some library files not been correct Mar 24 20:50:12 in general there is something wrong... haven't figured it out Mar 24 20:50:58 not sure if its a host problem, a tool chain or my stupidity problem ;) Mar 24 20:53:41 enough ranting for tonight ;) Mar 24 20:53:48 night everyone Mar 24 20:57:56 'night Ifaistos Mar 24 22:05:22 03koen 07org.oe.dev * r6ca0327e... 10/ (1 conf/distro/angstrom-2007.1.conf): angstrom: add a provider for gtk+ on Holgers advice Mar 24 23:21:23 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 Mar 24 23:22:14 so i dont have to list a whole lotta files individually Mar 24 23:22:32 (and he's talking about a *lot* of files) ;-) Mar 24 23:31:08 ahh i got it Mar 24 23:31:20 that was like, too easy Mar 24 23:31:23 heh Mar 24 23:31:29 how? :) Mar 24 23:32:05 e.g. FILES_${PN} += "/whackdir" **** ENDING LOGGING AT Sun Mar 25 03:01:03 2007