**** BEGIN LOGGING AT Sun Sep 04 02:59:56 2005 Sep 04 03:20:47 NAiLzZz: ping Sep 04 03:21:21 NAiLzZz: it's _virtual/libiconv, not libciconv for in the DEPENDS line Sep 04 03:36:26 Would anybody mind if I committed this: http://bugs.openembedded.org/show_bug.cgi?id=232#c6 Sep 04 04:09:35 pH5: raise teh lsmod point on the mailinglist, and if nobody responds, commit it Sep 04 04:10:52 koen|train: thx Sep 04 04:14:04 koen|train: oe mailinglist? the bug mails goe there already... Sep 04 04:14:14 go there... Sep 04 04:20:19 just set up a bitbake facility Sep 04 04:20:23 Regarding OZ 3.5.4 bitbake targets for C3000 and gpe, would these be : pivotboot-image gpe-image and zImage ? Sep 04 04:20:35 I'd like to take a shot at that Sep 04 04:25:00 perhaps not zImage....perhaps gpe-image takes care of that Sep 04 04:30:10 OSS542, If you have edited the conf files of OE decently (selecting the right machine type and distro in conf/local.conf) bitbake gpe-image should do what you want. Sep 04 05:57:56 pH5: yeah, but I don't want to give people the excuse of 'I don't read bugmail' when they complain about the changes to lsmod Sep 04 05:59:01 :-) Sep 04 07:07:38 pH5: does Chris' mail make any sense? Sep 04 07:09:10 Hello Sep 04 07:09:57 * OSS542 attempts a bitbake.....so far, so good... Sep 04 07:10:04 koen|slug: not very much. we can only have one link per unique basename ('lsmod' in this case) with update-alternatives. Sep 04 07:10:53 and since /sbin/lsmod and /bin/lsmod are always the same the unique basename limitation isn't a problem, right? Sep 04 07:11:27 OSS542: where is the web info on the bitbake? Sep 04 07:11:51 AvengerMoJo: http://oe.handhelds.org/cgi-bin/moin.cgi/GettingStarted Sep 04 07:11:59 OSS542: thanks Sep 04 07:12:50 koen|slug: hm... Chris pointed out correctly that with my change no other package could install /bin/lsmod. It's just not possible to manage more that one lsmod link with update-alternatives. Sep 04 07:13:52 how many packages have /bin/lsmod? Sep 04 07:14:07 not more than 3, right? Sep 04 07:14:30 koen|slug: I only know of busybox, modutils and module-init-tools Sep 04 07:14:33 who is doing OE stuff for C3000 ? Sep 04 07:15:30 mickey|shower, JustinP and RP iirc Sep 04 07:17:13 thanks...:-) Sep 04 07:17:15 koen|slug: and i also can't imagine anything else (besides a rootkit) what would want to install its own lsmod. Sep 04 07:47:01 hi to all Sep 04 08:10:01 03ph5 07org.oe.dev * r123fcae9... 10/packages/matchbox-panel-hacks/ (2 files in 2 dirs): matchbox-panel-hacks: add missing 'fi' in xrandr-panelapp.sh Sep 04 08:10:05 03nail 07org.oe.dev * r656f7d0a... 10/packages/musicpd/mpd_0.11.5.bb: mpd: change DEPENDS from libiconv to virtual/libiconv Sep 04 08:10:09 03nail 07org.oe.dev * rc6f4e1df... 10/files/device_table-openslug.txt: device-table openslug: Make /dev/sda[1-9] instead of [1-4] Sep 04 08:10:13 03koen 07org.oe.dev * rb37fc55f... 10/packages/gaim/gaim_cvs.bb: gaim: add PV to gaim_cvs and prefer the smallscreen version for gpe 2.7 Sep 04 08:37:29 hi koen ... Sep 04 08:37:51 u know what would be the release date for familiar 0.9 ? Sep 04 08:39:49 man-di triestino ? Sep 04 08:40:09 gremlin[it]: what ? Sep 04 08:41:50 sorry ... mandi is a tipical exclamation used in the city of trieste (italy) ... Sep 04 08:45:15 gremlin[it]: 0.9? no idea, but 0.8.3 will be out soon(TM) Sep 04 08:47:20 koen|slug , cause i see some bug of jamey to push kernel 2.6 on ipaqs to release familiar 0.9 with kernel 2.6 Sep 04 09:00:05 hey Sep 04 09:00:51 hi zecke Sep 04 09:02:09 gremlin[it]: what does it mean in trieste ? Sep 04 09:05:06 mhh just a greeting ... as 'Hi' ... or amore italian 'ciao' ... :) Sep 04 09:13:54 mickey|shower: you were kissed by the gcc-csl compiler bug ;) Sep 04 09:15:00 oz is still trying to use the csl compilers? Sep 04 09:16:04 csl ? Sep 04 09:16:05 is hte csl compiler that bad? Sep 04 09:16:43 gb2: it fails to compile apps and causes segfaults in other apps Sep 04 09:17:06 at least the snapshot in OE does Sep 04 09:17:10 ah Sep 04 09:17:29 i've been getting a warning: foo may be used uninitialized in this function" Sep 04 09:17:36 koen|slug: hmm, I've only had troubles compiling abiword with it, I've not seen any segfaults (yet) Sep 04 09:17:50 and the line number is the declaration (with initializer) for the variable Sep 04 09:18:03 lardman: a lot of weird metabugs dissapeared when I switched to a regular gcc Sep 04 09:18:05 but i'm getting that with the csl compiler and the stock compiler Sep 04 09:19:13 koen|slug: Perhaps I'll go for the rebuild then - what's the recommeded version? Sep 04 09:19:30 ehm Sep 04 09:19:45 of GCC? Sep 04 09:19:46 the one in familiar-0.8.3.conf works pretty well for me :) Sep 04 09:20:09 I'll have a look in there then Sep 04 09:20:53 3.4.4 Sep 04 09:20:54 it seems Sep 04 09:20:55 what csl stand for ? Sep 04 09:21:03 code sourcery labs Sep 04 09:21:22 you probably also want to select the non-csl binutils too Sep 04 09:27:56 mhh i'm reading about csl .. but what really it have of usefull except armv6 and thumb (both not usesull for PDA) ... Sep 04 09:28:28 thumb is potentially useful on a pda Sep 04 09:29:16 for space saving ? Sep 04 09:29:20 yeah Sep 04 09:30:37 koen|slug: I now completely lost my ibook to Al... Sep 04 09:30:53 zecke: D'oh Sep 04 09:31:00 zecke: try to bribe her with an ipod Sep 04 09:31:53 koen|slug: got one as well.. Sep 04 09:32:32 koen|slug: and with abiword... she is all set Sep 04 09:32:52 http://www.areamobile.de/news/4104.html <- this concept device runs Opie Sep 04 09:34:41 RP: ping Sep 04 09:36:53 lardman: hi Sep 04 09:37:20 RP: hey. I was looking at the voltages in your kernel code cf those in the Sharp code Sep 04 09:37:42 RP: they're significantly different - is there any reason for this? Sep 04 09:38:12 Lots of reasons :-/ Sep 04 09:38:17 For starters, which Sharp code Sep 04 09:38:19 zecke: cool Sep 04 09:38:37 You have the original 2.4.18 code they wrote. You then have the patches people added to make it more accurate Sep 04 09:39:01 You then have the levels we're currently using which should increase the detail massively Sep 04 09:39:18 RP: accurate as in more steps, or as in changing the voltage levels completely? Sep 04 09:39:36 koen|slug: I try to find better pictures.. Sep 04 09:39:53 RP: It's just that I'd have thought that the hw manufacturers would have an idea of what the levels should be...? Sep 04 09:40:16 RP: Though we are talking about Sharp of course ;) Sep 04 09:40:37 lardman: Feel free to tell me Lineo/Sharp knew what they were doing ;-) Sep 04 09:40:57 RP: http://people.bath.ac.uk/enpsgp/Zaurus/cpufreq/ac.jpg & http://people.bath.ac.uk/enpsgp/Zaurus/cpufreq/battery.jpg Sep 04 09:41:11 RP: I was only wondering as the range has been doubled Sep 04 09:42:10 Basically, I think one of these is valid during charging or after charging. The other curve is accurate if there hasn Sep 04 09:42:18 hasn't bee AC present for a long time Sep 04 09:42:32 Okay. I was wondering if these were the voltage values which were present when the battery full interrupt was generated or something like that Sep 04 09:42:42 (not on the c7x0 of course) Sep 04 09:43:11 lardman: These values do seem to be accurate on my c760 Sep 04 09:43:27 It could come down to the battery - doies you c750 have the big or small battery? Sep 04 09:43:34 small Sep 04 09:45:39 I've left hooks in to make it easy to add the old sharp table bak for corgi Sep 04 09:46:22 I was only wondering how the values had been reached, etc. With the Sharp values, the battery is fully charged 200, while your code goes to 213; I was just wondering how the new top limit for the charging had been reached Sep 04 09:46:40 lardman: Did you graph a dischange of your battery. It would be interesting to plot that against these curves Sep 04 09:47:08 No, I'm not sure I can do that - I was using it last night and it was returning 0 for the voltage & percentage remaining via sysfs Sep 04 09:47:22 which doesn't strike me as being very good Sep 04 09:47:45 the voltage should never reach 0 I don;t think Sep 04 09:48:11 it makes me think something more fundemental is wrong Sep 04 09:48:31 What did it have to say if you set msglevel Sep 04 09:48:43 I didn't get round to that Sep 04 09:48:48 The values in sysfs are averaged - the ones from dmesg are raw Sep 04 09:49:51 was it echo 2 or 3? Sep 04 09:50:07 ANything >= 2 will probably work Sep 04 09:50:23 The end points on those two graphs are not drastically different at low voltages which makes me thing there is something else causing a problem here Sep 04 09:50:33 dmesg says 199 Sep 04 09:51:02 That's 85% on my curves and 100 on sharps Sep 04 09:51:24 Does that sound right? Sep 04 09:51:26 yep, but reported as 0 which means the kernel code must be getting confused Sep 04 09:51:47 Yes, we have a bug... Sep 04 09:51:53 Ac in or out? Sep 04 09:51:56 looks more like 70% actually Sep 04 09:52:01 no ac Sep 04 09:52:54 65% on your curves 100% on Sharp's Sep 04 09:53:12 Which is more likely? (65 or 100) Sep 04 09:53:36 no idea, it was fully charged and then only used for 15min in toto Sep 04 09:54:02 in any case, it shouldn't show 0, that's the priority Sep 04 09:54:16 yes Sep 04 09:54:30 Do you have one of the newer machines which creates an interrupt on full battery? Sep 04 09:54:49 (I presume that happens from reading the source for corgi anyway) Sep 04 09:54:57 Yours should generate an interrupt on full battery... Sep 04 09:55:04 Its only corgi that doesn't Sep 04 09:55:29 Oh, it says that for corgi (I presume the shepherd is a corgi for this stuff) that it doesn't and it has a hack Sep 04 09:55:42 unless I misread the #if stuff Sep 04 09:55:52 Corgi normally means c7x0 except in this case when it really means corgi ;-) Sep 04 09:56:55 hmm Sep 04 09:57:12 hang on, let me open the files up Sep 04 09:57:30 corgi in names of things is generic. corgi in comments means corgi, the c700 Sep 04 09:57:44 Ah, right Sep 04 09:58:40 I did try and make that clear in the comments but evidently failed Sep 04 09:59:18 I only read it quickly, and with a hangover, my fault I imagine Sep 04 10:00:00 RP: so when you going to fix that ;P Sep 04 10:00:08 That's okay then. In which case the battery presumably knows when it's full and generates an interrupt? Sep 04 10:00:17 mithro: fix what? Sep 04 10:00:22 my hangover? Sep 04 10:00:36 lardman: It should do, yes Sep 04 10:00:48 lardman: If you have msglevel set, it will show in the logs Sep 04 10:05:16 RP: Okay, I was just worried for a while that if the max voltage was high & my 'corgi' couldn't generate the interrupt, it might do some damage Sep 04 10:05:59 lardman: These devices have hardware that has final control of the charging anyway so I doubt damage is possible Sep 04 10:06:18 But your hardware does have the charging interrupt Sep 04 10:06:47 RP: Yes, thanks for pointing that out. My next question was going to be as to how intelligent the batteries are Sep 04 10:06:47 I'm just trying to get into a position where I can look at the files here Sep 04 10:07:02 I've lost two disks of data today :-( Sep 04 10:07:11 oh, sorry to hear that Sep 04 10:08:08 Thankfully, I don't think anything I can't recover has gone missing - just most my /usr... Sep 04 10:08:36 which must make doing pretty much anything a bit of a pain Sep 04 10:08:36 Its making getting my remote X sessions going a bit tricky :) Sep 04 10:10:51 I've been working on fixing it since this morning so things are a lot better now. Soon I can pull the dead disks from the machine and see if I can claim on the warranty Sep 04 10:11:05 RP: all the things in the world which don't make sense Sep 04 10:12:20 lardman: Can you pastebin some of the malfunctioning dmesg please? It might give me some clues as to what's wrong Sep 04 10:12:39 I'll have to take a closer look at the Sharp code, but I wonder if the difference between their 100% and yours is to allow for battery wear? Sep 04 10:12:42 lardman: Along with a cat of the sysfs files Sep 04 10:12:54 RP: um, yes, hang on, need to do some CF switching Sep 04 10:13:17 lardman: Theirs is just way too simplified and too low resolution Sep 04 10:13:28 03koen 07org.oe.dev * r13f7ff1f... 10/conf/distro/preferred-gpe-versions-2.7.inc: conf/distro/preferred-gpe-versions-2.7.inc: add poppler and evince Sep 04 10:14:05 RP: resolution is too low of course, I was just wondering about the large difference in voltage @100% - theirs must show 100% for ages before it moves Sep 04 10:14:23 RP: which sysfs files do you want? Sep 04 10:20:44 RP: /sys/devices/platform/corgi-pm: battery_percentage and battery_voltage both =0, msglevel=2 Sep 04 10:21:25 RP: pastebin.ca is unreachable from here, so http://people.bath.ac.uk/enpsgp/Zaurus/cpufreq/dmesg.output Sep 04 10:22:15 RP: All of that dmesg is with no a/c Sep 04 10:23:22 lardman: is the cpufreq patch working? Sep 04 10:24:07 koen|slug: still on the old kernel to track down this power issue. It patched & compiled fine though - I may try it this evening and see what happens Sep 04 10:26:19 03koen 07org.oe.dev * r639befc9... 10/packages/poppler/poppler_0.4.2.bb: poppler: add 0.4.2 Sep 04 10:27:54 Why is chkFatalBatt being called? The voltage appears to exceed the limits for both ac & noac Sep 04 10:28:24 Ah, it's always called I see, back to sleep Sep 04 10:31:46 chk = check - make sure things are ok Sep 04 10:35:21 On l273 of sharpsl_pm.c Sep 04 10:35:53 Is that checking that it is online? If so, where is sharpsl_pm.battstat.mainbat_voltage et al set if it's not? Sep 04 10:37:14 lardman: I think something has to be wrong with the percentage lookup functions Sep 04 10:37:34 RP: so percent <= sharpsl_pm.battstat.mainbat_percent is not true? Sep 04 10:37:49 lardman: If you look at sharpsl_battery_thread(), you can see where there problem has to be Sep 04 10:38:01 lardman: Yes, that has to be the problem Sep 04 10:39:12 RP: Well sharpsl_pm.battstat.mainbat_percent=0 at the moment, so it's going to fail I suppose Sep 04 10:39:50 RP: The code only allows for a falling battery percentage...? Sep 04 10:40:09 lardman: Unless its being charged Sep 04 10:40:37 RP: Yes. However even if it's not being charged, you could get recovery (after stopping using wifi, etc.) Sep 04 10:41:03 When the battery voltage is very low, it starts to increase again - one of the problems with this interface... Sep 04 10:41:14 RP: So that's why it's returning rubbish values, but how did the zeros get in there in the first place Sep 04 10:41:50 I did take this check out for a while but got complaints so put it back Sep 04 10:42:07 the battery percentage only decreasing on? Sep 04 10:42:11 s/on/one Sep 04 10:42:18 Yes Sep 04 10:42:25 The difference was that sharp only did this for low battery voltages. I've now done it for all Sep 04 10:42:41 Is the rise at low voltage a battery effect or to do with the hw? Sep 04 10:42:47 lardman: yes Sep 04 10:42:59 The readings become wildly inaccurate Sep 04 10:43:25 I'd be tempted to re-instate the only-check-at-low-voltage scheme Sep 04 10:43:58 My battery percentage takes a big hit when I use wifi, and it would be nice to see it recover when I stop (IMO) Sep 04 10:44:02 I'd tend to agree Sep 04 10:44:29 but that's only the end effect - the zeros must have been written to mainbat_percent somehow Sep 04 10:45:51 or is it initialised to zero when the kernel starts? so if you start with ac everything's fine, if not, you get zeros? Sep 04 10:45:51 Zeros could get in all too easily Sep 04 10:46:06 Can you do a log whilst you insert, then remove AC Sep 04 10:46:13 I'd guess that will clear it Sep 04 10:46:31 yes, hang on a minute Sep 04 10:46:47 Yes, it could be that. I usually start on AC, addmittedly Sep 04 10:47:05 likewise Sep 04 10:48:52 I'll add a thresh[i].status == APM_BATTERY_STATUS_HIGH in there... Sep 04 10:50:07 http://people.bath.ac.uk/enpsgp/Zaurus/cpufreq/ 3 files - pre, during & post ac Sep 04 10:52:59 It's reporting a full battery with the charger in, but then when it's taken out, it drops down to ~65% Sep 04 10:53:09 55% even Sep 04 10:53:28 that could be my battery dying I suppose Sep 04 10:55:51 What happens if you leave it in charge for a while? Sep 04 10:56:14 Don't trust that is says 100% with the charger in - wait for the charge light to go off... Sep 04 10:56:16 will it charge? it won't just switch off? Sep 04 10:56:38 I'd be interested to know what it does Sep 04 10:56:51 the LED's on atm Sep 04 10:56:57 it's suspended Sep 04 10:57:06 the zaurus that is Sep 04 10:57:06 Then its charging Sep 04 10:57:11 yes Sep 04 10:57:22 THe LED always tells you if its charging or not Sep 04 10:57:24 I was just going by the message from dmesg Sep 04 10:58:02 When you trigger the AC in input, you get a charge full one for good meaaure Sep 04 10:58:23 The software knows about this and times things accordingly Sep 04 10:58:35 Watch the light and let me know what happens... Sep 04 10:58:38 Okay. It says "Turning Charger Off", but that must be when I pulled the plug out - I'll have to look at the code Sep 04 10:59:17 It will sometimes turn the charer off to check the battery temperature/voltage, then put it back on Sep 04 10:59:29 Watch for the charge full messages (when you didn't touch AC) Sep 04 10:59:35 I'm being called way for food - back later Sep 04 10:59:41 yep, I read that bit - it would be cool to have the temperature output in sysfs Sep 04 11:00:00 ok, I'm off home, I'll let you know what happens tomorrow Sep 04 11:06:48 bye everyone Sep 04 11:12:15 03jbowler 07org.oe.dev * r3e9f0494... 10/packages/meta/ucslugc-packages.bb: Sep 04 11:12:15 ucslugc-packages - add glib2.0 back into ucslugc build Sep 04 11:12:15 glib2.0 fails to build sometimes because of the libintl header file Sep 04 11:12:15 problem, but it always builds fine in a clean build. Sep 04 11:15:43 03jbowler 07org.oe.dev * rec3c2433... 10/conf/distro/ucslugc-packages.conf: Sep 04 11:15:43 ucslugc conf - remove slugimage,nslu2-binary,unzip - no longer required Sep 04 11:15:43 The packages were only used for building full ucslugc images, this is no Sep 04 11:15:43 longer necessary with upslug2 Sep 04 11:29:06 hmmm Sep 04 11:29:17 the opie-image for h3600 fails to build too Sep 04 12:01:24 mickey|shower: did you see the reparse patch I submitted for bitbake? Sep 04 12:13:57 JustinP: hey Sep 04 12:14:10 JustinP: I can not see why mickeyl would disagree Sep 04 12:14:31 JustinP: and now he is all wet (showering +1 hour) I frankly do not care for his opinion now ;) Sep 04 12:17:14 mm. I fear that mickey may have dissolved or something. Sep 04 12:17:32 mickey|shower: "Warmduscher"? Sep 04 12:17:43 24+ hours of immersion can't be healthy :) Sep 04 12:18:22 if the simpad would have been waterproof, he could have mailed the emergency to rescue him... Sep 04 12:19:34 :) Sep 04 12:19:48 I think he sold his simpad some months ago, so even that avenue is closed to him. Sep 04 12:20:11 poor guy Sep 04 12:20:27 * zecke creates the Michael 'hot shower' Lauer fund... Sep 04 12:20:33 yeah, it sounds like a bad business. Sep 04 12:28:12 * pb_ fills in for mickeyl by watching some tv Sep 04 13:00:52 03jbowler 07org.oe.dev * r865901d3... 10/packages/upslug/ (upslug2-native_3.bb upslug2.inc upslug2_3.bb): Sep 04 13:00:52 upslug2 - a more robust replacement for upslug Sep 04 13:00:52 this program is used to upgrade the NSLU2 flash, it is nslu2 only. It is Sep 04 13:00:52 functionally equivalent to the current upslug but has, so far, only Sep 04 13:00:52 received limited testing (as of revision upslug2_3). Sep 04 13:04:59 03koen 07org.oe.dev * rff8482df... 10/packages/gnome/gnome-vfs-dbus_2.8.4.4.bb: gnmoe-vfs-dbus: depend on an older samba to fix build Sep 04 13:10:55 mickey|shower: I do not like my BSD Touchscreen code gets tainted with the GPL (rmk's code) Sep 04 13:13:09 zecke: Which BSD code got tainted? Sep 04 13:14:26 zecke: Nothing added to libopie is GPL - only code added to qtelib is tainted as as we already use that under GPL, there is no problem Sep 04 13:14:44 RP: QTsLibHandler is BSD licensed, and I'm sure it was touched Sep 04 13:15:09 zecke: In libqte? Sep 04 13:15:23 RP: yes, and QtE is dual licensed Sep 04 13:15:37 RP: putting GPL only code into it renders the other license useless Sep 04 13:16:10 RP: for example Opera may not provide a QtE only version of your browser anymore - not that they would have Sep 04 13:16:29 I thought it has a commercial licence and GPL. We can only use the GPL? Sep 04 13:16:53 RP: unless you pay trolltech... Sep 04 13:17:47 RP: yes but the code we patch in is not compatible with the commercial license Sep 04 13:18:02 RP: this means commercial apps may not run on top of our distributed QtE anymore Sep 04 13:18:09 03ccsmart 07org.oe.dev * rc1e0c383... 10/packages/bogofilter/ (bogofilter-0.96.0/configure.ac.patch bogofilter_0.96.0.bb): bogofilter: Initial version checkin. Sep 04 13:18:14 03koen 07org.oe.dev * redffa717... 10/packages/tslib/ (tslib/h6300/tslib.sh tslib/ts.conf-h6300 tslib_cvs.bb): tslib: add h6300 support, closes #256, courtesy Mika Laitio Sep 04 13:18:14 RP: I would have expected at least someone to think about it, before comitting Sep 04 13:18:32 zecke: So trolltech can't take that patch and we have to look after it. It doesn't break compatibility Sep 04 13:18:41 I was careful about that... Sep 04 13:18:46 RP: I've not put rmk's code into the QTsLibHandler for a reason Sep 04 13:19:00 RP: NO. We can not run commercial applications on top of QtE anymore Sep 04 13:19:17 zecke: Why not? Sep 04 13:19:49 RP: because our libqte is GPL only (with your patch) Sep 04 13:20:17 Before Patch: Dual/tripple licensed After Patch: Single Licensed Sep 04 13:20:20 see the difference? Sep 04 13:20:47 zecke: I agree its now GPL only. I don't see why that stops you running commercial apps against it Sep 04 13:21:14 RP: people using OE to build their distribution, needs to be informed ;) Sep 04 13:21:22 zecke: I did discuss this with mickeyl Sep 04 13:21:48 We only use the library under gpl before. We can only use it under GPL after. Sep 04 13:21:59 RP: who is 'we'? Sep 04 13:22:06 RP: oe is more than 'opie' Sep 04 13:22:26 suppose sharp would use OE Sep 04 13:22:31 or theKompany Sep 04 13:22:35 RP: people like Siemens could have trouble now Sep 04 13:23:34 RP: for example the qte_2.3.10.bb needs updating Sep 04 13:23:41 RP: it states the wrong licenses Sep 04 13:24:22 RP: please do not get me wrong, I agree with your change (I think I've pointed you to the place anyway) Sep 04 13:24:38 RP: I would have expected a little bit extra care to dual licensed software Sep 04 13:25:02 nothing to see, I move on ;) Sep 04 13:25:38 zecke: It was a considered decision and I did dicuss this with mickeyl. I think we need him around if this is to be dicussed further Sep 04 13:26:12 I did make is explicitly clear in the patch what was going on... Sep 04 13:26:23 RP: right, technically I agree 100% with your changes Sep 04 13:26:51 RP: right, and I'm considering the removal of the extra clause good(tm) Sep 04 13:27:20 RP: we need to update the LICENSE field, and properly even provide an qte-commercial bbfile Sep 04 13:27:25 The code in question isn't copyriight rmk btw - Its actually Doug Lowder :-/ Sep 04 13:27:42 but the last part can be left to others Sep 04 13:28:05 I agree - its easy enough to write a .bb without that patch Sep 04 13:28:08 RP: you just hit a 'bad' spot. We need to clearly state what license our patches have Sep 04 13:28:47 but that is not left to you ;). Are they MIT licensed, GPL, the license of the other software part... Sep 04 13:29:40 its a tricky one, often depending on the patch... Sep 04 13:30:20 right, but for further adoption of OE we need to solve it Sep 04 13:30:37 I agree Sep 04 13:30:47 zecke: did you see epronk's quote? Sep 04 13:32:14 Does anyone have an email address for Douglas Lowder? Sep 04 13:32:29 zecke: it was something like "yes, but OE is easier to use than the mvista tools" Sep 04 13:32:44 I saw that and found it quite pleasing :) Sep 04 13:32:46 koen|slug: no Sep 04 13:33:04 RP: I would have found it quite pleasing as well Sep 04 13:33:25 about philips using OE in an NDA'd project Sep 04 13:34:42 "The GPL is viral" ;) Sep 04 13:35:07 I can not tell why I started using BSD like licenses recently Sep 04 13:35:17 probably because I care less for my software :} Sep 04 13:35:33 woglinde_: wb Sep 04 13:35:38 03freyther 07org.oe.dev * ra73d2242... 10/packages/qte/qte_2.3.10.bb: (log message trimmed) Sep 04 13:35:38 QtE 2.3.10: Sep 04 13:35:38 The touchscreen patch is stated GPL only, update the license Sep 04 13:35:38 to be GPL only! Sep 04 13:35:38 We should consider adding both proprietary and non-proprietary Sep 04 13:35:38 versions of QtE to OE, to avoid further similiar problems. Sep 04 13:35:40 Generally we should clearly state under which conditions patches Sep 04 13:42:49 zecke: I think each file in a SRC_URI is going to need a licence field. We could state that the LICENCE field of a .bb applies to all SRC_URIs unless otherwise detailed Sep 04 13:44:03 RP: LICENCE should be the common denominator of all applied patches Sep 04 13:44:51 zecke: It should summarise the status of the patched code, yes Sep 04 13:45:36 OT: does yelp really suck so much? Sep 04 13:49:55 OT: how can I make 'find' not find '.svn' directories? Sep 04 13:53:29 zecke: -not -name ".svn" ? Sep 04 13:57:40 howdy people Sep 04 13:57:49 hi mithro Sep 04 13:57:54 hey mithro Sep 04 13:58:09 btw the QtE in OE should have ALWAYS been GPL Sep 04 13:59:26 qt should have always been gpl Sep 04 13:59:46 koen|slug: QtE has always been GPL ;) Sep 04 14:00:08 there is no way we can put "proprietary" QtE in OpenEmbedded as we don't have such a license Sep 04 14:00:10 mithro: how so? all the patches I've done are MIT/BSD whatever Sep 04 14:00:26 zecke: the code given to use is not dual licensed Sep 04 14:00:37 the code given to commerical companies is Sep 04 14:00:41 mithro: well it is, but we do not hold another license Sep 04 14:00:58 zecke: as far as we are concerned there is no other license Sep 04 14:01:02 mithro: it is Dual Licensed, but we can only use it under GPL Sep 04 14:01:10 mithro: who is 'we' - again Sep 04 14:01:31 QtE is getting the defacto standard on Embedded Linux Sep 04 14:01:44 so 'we' for OpenEmbedded is a broader audience Sep 04 14:01:51 in contrast to Opie Sep 04 14:02:06 anyone who doesn't have a QtE commercial license Sep 04 14:02:44 RP: thanks I placed the -not at a different spot... Sep 04 14:03:29 if I go and download the code from Troll tech I get a file which has the GPL license in it right? Sep 04 14:04:27 mithro: as one of the licenses it contains Sep 04 14:04:28 mithro: Someone else going to TT and downloading who has a commercial licence gets the other rights Sep 04 14:04:54 if you have a ~/.qt-license you won ;) Sep 04 14:05:21 ~fishslap svn Sep 04 14:05:22 * ibot_ slaps svn up side the head with a wet fish. Sep 04 14:05:45 Any commercial rights holder can compile under the commercial licence rather than GPL. My patch does put a stop to that :). There isn't an issue now we've fixed the LICENCE field Sep 04 14:06:47 RP: your sentance doesn't really make sense :P Sep 04 14:07:21 the license applies to the source Sep 04 14:07:40 mithro: and what you can do with the resulting code Sep 04 14:07:48 yes Sep 04 14:08:45 mithro: WE - The OpenEmbedd project - do not claim anymore that our compiled version of QtE (the result) is available in a GPL incompatible license ;) Sep 04 14:09:01 s/in a/with a/ or even under Sep 04 14:09:24 zecke: that again doesn't make sense, the license applies to the source code Sep 04 14:10:20 the resulting compiled version can be either violate or compile with the conditions set out by the source codes license Sep 04 14:10:22 mithro: GPL applies to distribution ;) (I'm not near being a lawyer) Sep 04 14:11:23 mithro: anyway we have resolved the issue for QtE ;) Sep 04 14:11:25 mithro: and we're saying that the compiled versions are only valid under GPL. In the past the compiled versions could have been valid under the commercial licence to a commercial licence holder Sep 04 14:11:44 so if you distribute a compiled version you can violating the source codes license Sep 04 14:12:27 mithro: right, and as OE is for creating distributions Sep 04 14:12:36 but the "licensing" of the binary is a totally different matter - which is where EULA's etc come into play Sep 04 14:12:41 mithro: our customers could have distributed something illegal Sep 04 14:12:58 mithro: without even knowing, because our meta data was wrong Sep 04 14:13:58 anyway I continue having fun with a broken svn client... Sep 04 14:14:41 zecke: and the only way the meta data could be correct 100% of the time Sep 04 14:14:48 would be to say it was under the GPL Sep 04 14:16:16 mithro: Beforehand it was valid under the commercial licence if you held such a thing. The .bb file was correct to note this. Now its GPL only and the metadata is once again correct thanks to zecke. Sep 04 14:17:40 anyway... Sep 04 14:17:44 mithro: right ;) Sep 04 14:18:13 btw does BSD allow relicensing stuff under a difference license? Sep 04 14:18:28 I think companies using OE should do legal checking, but we can do our best to make it easy Sep 04 14:18:30 mithro: well yes Sep 04 14:18:47 mithro: as long as you keep the two clauses around ;) Sep 04 14:19:00 mithro: e.g KDE panel (kicker) got relicensed to GPL recently Sep 04 14:20:01 zecke: you mean not ship incorrect LICENCE entries Sep 04 14:21:59 koen|slug: yes, and clearly stating what licence our patches have Sep 04 14:22:55 personally I don't see why people don't just turn patches over to the same licenses as the thing you are patching Sep 04 14:23:36 mithro: right, but it needs to be stated somewhere Sep 04 14:23:45 mithro: for now I assume that we did Sep 04 14:25:29 03ph5 07org.oe.dev * r83d78350... 10/packages/avahi/avahi_0.2.bb: Sep 04 14:25:29 avahi-0.2: small postinst/postrm changes Sep 04 14:25:29 - fix avahi system user adding/deleting Sep 04 14:25:29 - force-reload dbus in postinst Sep 04 14:31:36 mithro: I'm not trying to be awkward here - I'm trying to merge two good bits of pre existing code :-/ Sep 04 14:32:37 RP: the question is why didn't the original person just license it under the same as Qt? Sep 04 14:33:23 perhaps because the original person didn't have the rights to alter a commercial licence between two other people? Sep 04 14:33:27 mithro: Because the code was part of another piece of software with a GPL licence Sep 04 14:33:29 (hello btw :) Sep 04 14:38:51 fc-lang fails to link........undefined references to __ctype_b_loc and __ctype_tolower_loc Sep 04 14:39:09 bah licensing sucks Sep 04 14:39:31 licensing ? Sep 04 14:40:30 couldn't we all just be happy and play nice? Sep 04 14:40:55 mithro: Everyone is now happy. Lets leave it at that ;-) Sep 04 14:41:41 mithro: We're nice and happy ;) Sep 04 14:44:03 * koen|slug sometimes doesn't get montone's divergence Sep 04 14:45:11 03koen 07org.oe.dev * r514709e2... 10/packages/tslib/tslib_cvs.bb: tslib: remove beagle support which sneaked in again Sep 04 14:52:26 03mickeyl 07org.oe.dev * r325eef6e... 10/packages/ (6 files in 5 dirs): dbh, ocamlc, qmake, uicmoc: don't use | or / to seperate multiply licensed files, use a space Sep 04 14:52:46 mickey|shower: hey Sep 04 14:53:00 mickey|shower: you survived showering Sep 04 14:54:52 what is gcc-csl? Sep 04 14:55:11 RP: MontaVista simply rotated the touchscreen coordinates in the kernel to suit QtE Sep 04 14:55:13 mithro: broken Sep 04 14:55:18 mithro: CodeSourcery gcc Sep 04 14:55:28 mithro: www.codesourcery.com IIRC Sep 04 14:56:54 zecke: Tricky when you have two drivers using the same touchscreen with different orientation framebuffers :) Sep 04 14:57:06 two devices... Sep 04 14:57:07 fc-lang fails to link........undefined references to __ctype_b_loc and __ctype_tolower_loc Sep 04 14:57:23 anyone seen this recently ? Sep 04 14:57:56 RP: That is MontaVista Sep 04 14:58:09 RP: #ifdef BROKEN #define BREAK_EVEN_MORE #endif ;) Sep 04 14:58:56 I am also seeing things like this: Sep 04 14:58:58 fc-lang.c:53: warning: pointer targets in return differ in signedness Sep 04 14:59:11 so csl is evil? Sep 04 14:59:20 makes me wonder if the build somehow picked up the wrong compiler Sep 04 14:59:25 zecke: I'm used to Lineo code. MontaVista are good by comparision... Sep 04 14:59:49 mithro: the current version in OE is broken Sep 04 14:59:57 RP: do you do C3000 stuff ? Sep 04 15:00:15 mithro: csl is Good Stuff(TM), but we picked a bad apple from the stack Sep 04 15:00:36 OSS542: yes Sep 04 15:01:43 RP: I just picked up a C3000.....I'm trying a gpe-image build for it Sep 04 15:02:50 OSS542: They do work. I've not seen your errors before though I'm afraid Sep 04 15:04:37 RP: I did see some messages that I have normally only seen coming from my gcc 4.0.1 compiler....but that shouldn't have been picked up Sep 04 15:05:05 warnings about differences in "signedness" Sep 04 15:05:29 OSS542: It should be using a gcc 3.4.4 compiler :-/ Sep 04 15:05:48 If you look in the tmp/work directory, which compiler did it build? Sep 04 15:05:59 RP: just a sec Sep 04 15:07:48 RP: l'm seeing references to things like 3.4.3, 3.4.4....trying to pick out the right one Sep 04 15:08:35 OSS542: It will use your native compiler to compile the native tools. Sep 04 15:08:49 Has anyone tried OE with a GCC4 native compiler? Sep 04 15:08:52 RP: my native compiler is gcc 4.0.1 Sep 04 15:09:12 I could switch to 3.4.3 and try again Sep 04 15:09:26 or 3.4.4 for that matter Sep 04 15:10:24 I've just looked and I'm old 3.3.x and 3.2.x compilers for native stuff here! :-/ Sep 04 15:10:30 I wonder if 3.4.3 can be built by 4.0.1....:-) Sep 04 15:10:58 OE should work with a gcc4 compiler. I'm just not sure its been well tested Sep 04 15:11:23 RP: it appears that it doesn't work with 4.0.1.... Sep 04 15:11:51 but then again, you can't build glibc2.3.5 with 4.0.1 either.....glibc bug Sep 04 15:11:52 i'm using debian 4.0.2 for ucslugc Sep 04 15:12:08 OSS542: I'd post the logs in bugzilla Sep 04 15:12:23 you need 3.4.3 to do glibc2.3.5 Sep 04 15:12:53 RP: it just might be worth a try for me to jump back to 3.4.3 or whatever you're using Sep 04 15:13:34 OSS542: I suspect that's easier if you can't see how to fix the problem you're having. File something in bugzilla in case someone who knows what they're doing can though : Sep 04 15:13:35 :) Sep 04 15:14:21 RP: OK....I'll try and puzzle out bugzilla......I've not used it recently.....I tend to avoid it Sep 04 15:14:55 RP: how usable is the 2.6 kernel on the C3K atm - is it still a case of needing the 2.4 kernel (and thus the 2.95.whatever gcc for it)? Sep 04 15:15:23 gridzero: Very usable. USB Client and sound are missing though. Sep 04 15:15:39 2.4 needs the external 2.95.3 toolchain Sep 04 15:16:00 RP: Charging worked fine, but more dmesg goodness for you ;) : http://pastebin.ca/22110 Sep 04 15:16:14 RP: I use gcc4.0.1, only kernel gcc 3.3.* are broken :} Sep 04 15:16:19 RP: voltage=211 percentage=53. hmm...? Sep 04 15:17:58 lardman: That is strange... Sep 04 15:18:31 RP: quite. I've not had a chance to look through the code yet, but as I was online I thought I'd let you know Sep 04 15:18:40 lardman: I think its the last bug again - percentage can't increase... Sep 04 15:19:01 zecke: have you tried a gpe-image build using 4.0.1 ? Sep 04 15:19:26 RP: Perhaps, I thought it was a case of neither the voltage nor percentage being updated though and in this case the voltage looks to be changing Sep 04 15:19:35 lardman: Yes, its quite nice to see the log - the good news is your battery is behaving fine - its just the reporting is screwed up somewhere Sep 04 15:19:52 RP: :) yeah, I was happy to see that too Sep 04 15:19:55 no Sep 04 15:20:34 RP: The more I think about it, the more I (possibly) see why Sharp used their particular voltage-percentage scheme though Sep 04 15:21:11 lardman: Lets get it properly using our new scheme before we condem it ;-) Sep 04 15:21:25 RP: They provide a long period at 100% (which is good for users) and also allow for a lot of battery wear (which I believe reduces the voltage) Sep 04 15:21:25 cya later Sep 04 15:21:33 03freyther 07org.oe.dev * r913ad257... 10/packages/qte/qte_2.3.10.bb: Sep 04 15:21:33 QtE 2.3.10: Sep 04 15:21:33 Add extra space to unbreak build on SIMpad Sep 04 15:22:02 lardman: Everyone I've ever spoken to has hated the sudden 100% to nothing drop Sep 04 15:22:08 RP: No I wasn't condemning it, just wondering whether the output should be able to be adjusted to account for battery wear Sep 04 15:22:26 lardman: in userspace maybe Sep 04 15:22:33 in kernel space, no way. Sep 04 15:22:45 RP: exactly, but in that case, it needs to know at what point the battery decided it was full Sep 04 15:23:11 RP: rather than just a percentage of the nominal total capacity - if that makes sence Sep 04 15:23:13 lardman: I'm fine with new information from the kernel (I want to be rid of apm) Sep 04 15:25:02 back in a bit Sep 04 15:25:15 RP: Cool. I'm sorry if I sound as if I'm ahving a go, it's just that I've obviously jumped in with both feet, not knowing what's already happened Sep 04 15:26:03 lardman: Its ok, I'm just trying to explain why these things are there... Sep 04 15:26:18 I usually have reasons for doing them. Sep 04 15:26:21 RP: yes, and thank you for your patience Sep 04 15:26:29 I just hate the pm code as touch one thing and it all falls to bits Sep 04 15:26:55 :) Sep 04 15:27:00 I'm trying to improve it to mainline standards whilst keeping it working which is no easy job... Sep 04 15:27:24 and improve its feature set like the increased batter scaling Sep 04 15:27:49 Yeah, I can understand that - and it's got to be said that looking at the Sharp code I'm impressed by how much clearer yours is Sep 04 15:27:50 I can see another bug in that piece of code we discussed earlier... Sep 04 15:28:04 What's that? Sep 04 15:28:25 * lardman tries to find the code in question Sep 04 15:28:35 Ah, its not what thought :) Sep 04 15:28:46 It does check AC line status and not charger status Sep 04 15:29:24 AC line means it's connected, but not charging... I need to do some more background reading I think Sep 04 15:29:45 Have you got AC connected when you saw it at 50%? Sep 04 15:30:00 Can you plug it into AC and then remove it, see if the percentage gets corrected? Sep 04 15:30:07 no, I left it charging while suspended, then unplugged and switched on Sep 04 15:30:15 ok, hang on a tick Sep 04 15:31:35 Right, now showing something like 95% Sep 04 15:31:46 after plugging in then unplugging Sep 04 15:32:06 The fix I added earlier will fix this problem as well then Sep 04 15:32:13 and 95% sounds quite nice :) Sep 04 15:32:23 down to 90% - which may be the battery, I'm not sure (showing volt=209) Sep 04 15:32:47 Yes, I think being an older battery will mean you don't see 100% for long... Sep 04 15:32:56 yep Sep 04 15:33:01 Hoepfully it will hold around 80-90... Sep 04 15:33:19 and I don't really see that as an issue as long as its explainined :) Sep 04 15:33:20 I'm not sure how happy the users will be with that - hence my thinking og (userspace) adjustments Sep 04 15:33:30 yes, agreed Sep 04 15:34:21 I'll update my kernel tomorrow with your amendments, then hopefully I can get onto cpufreq Sep 04 15:34:50 You could write an app to work out how damaged the battery is by the voltage drop over a time after a full charge :) Sep 04 15:35:12 Yes, that's an idea Sep 04 15:35:16 I've not commited the patch yet - will try to later on Sep 04 15:35:24 Okay Sep 04 15:36:19 I was wondering about what the users see - ideally they don;t want to see what I just did, but then again, they also don;t want to see 100%-0% in 10min flat Sep 04 15:37:06 In a way, I'd be all for ripping the percentage tables out of the kernel... Sep 04 15:37:16 whether to give them a percentage of their current battery or of the ideal battery, etc... Sep 04 15:37:25 and into userspace Sep 04 15:37:44 Yes, let userspace deal with it - give them a voltage Sep 04 15:38:25 or 4 - current, max, min & max @ battery says it's full Sep 04 15:39:19 Which full indication do you use though? Sep 04 15:39:43 yes quite, but the option should be there Sep 04 15:39:53 You'll notice the code looks for a full indicator, then times how long the next one is in coming. If greater than a certain time, it charges more Sep 04 15:40:04 I think probably use the percentage of the battery's current ability Sep 04 15:40:18 Better, you'd look for the point the charger turned off Sep 04 15:40:36 exactly Sep 04 15:40:56 You can never get a sane idea of what the ability is. You can guess but its userspace's job... Sep 04 15:41:04 yes Sep 04 15:41:26 but it would be easier for the user if battery charged=100% battery Sep 04 15:41:46 even if the battery then lasts a shorter, time, etc. Sep 04 15:42:40 I agree. Its userspace that has to do it though and I don't do userspace ;-) Sep 04 15:43:13 :) don't blame you - far too many choices as to what the users might want! Sep 04 15:43:29 indeed :) Sep 04 15:43:45 I don't have enough time as it is... Sep 04 15:43:54 Too many projects :-/ Sep 04 15:44:15 Yes, you've done an awful lot from what I've seen Sep 04 15:45:28 It seems so simple when you say "ported 2.6 Linux to the c7x0 and cxx00 pdas" :) Sep 04 15:46:40 (there's always someone there giving you some abuse for not having done it quite right ;) ) Sep 04 15:47:07 or breaking it :) Sep 04 15:47:18 yeah, yeah Sep 04 15:47:20 ;) Sep 04 15:47:37 I feel bad about the ipaq hx2750 at the moment. I got so far then kind of stopped and did other things :-/ Sep 04 15:48:11 Just needs lots of polish... :-/ Sep 04 15:48:35 I much prefer my c7x0 and cxx00 devices tbh... Sep 04 15:48:58 Yeah, but it's not bad as it is, only a few rough edges which don't come to light all that often Sep 04 15:50:24 lardman: I meant the hx2750 needing polish Sep 04 15:50:42 c7x0 just needs dusting :) Sep 04 15:50:47 ok Sep 04 15:51:04 Apart from the sound drivers... Sep 04 15:51:28 They're the two bits of code I'm scared of... Sep 04 15:51:37 lol Sep 04 15:51:44 (pm and sound) Sep 04 15:52:15 its not so much the pm as that works nicely - its the blummin battery and charging... Sep 04 15:52:31 I've no idea about sound, but I'll endevour to help with pm if I can Sep 04 15:53:20 I need someone with an idea about sound as I don't know much about it either! :) Sep 04 15:53:21 ...mainly by providing random and difficult cases as proved thus far :) Sep 04 15:53:43 Its always interesting to see what you don't do to the device :) Sep 04 16:07:52 RP: Thanks for your help, I'm hitting the sack now Sep 04 16:07:59 night all Sep 04 16:20:09 Three heads! Sep 04 16:22:33 03rpurdie 07org.oe.dev * r62da1bc1... 10/packages/linux/linux-openzaurus_2.6.13-mm1.bb: linux-oz-2.6: Correct battery status updating under certain circumstances for c7x0, cxx00. Thanks to lardman for helping find the problem Sep 04 16:23:47 Time to reboot and hopefully finally pull those dead disks... Sep 04 16:55:35 hey RP Sep 04 16:56:29 hi all Sep 04 16:59:47 and g'night :)