**** BEGIN LOGGING AT Tue Jan 23 02:59:59 2007 Jan 23 04:10:04 * rwhitby completes the IXP4XX_MACHINE_ENDIAN changes ... Jan 23 05:25:57 From #openmoko: 03:20 it is the one true way to build things for embedded linux. when god builds things, he uses something similar to oe. Jan 23 06:11:05 mickey|zzZZzz: http://tieguy.org/blog/2007/01/22/i-want-linux-in-my-pocket-asap-kthxbye/ Jan 23 06:17:08 :) Jan 23 06:17:24 hey koen Jan 23 06:18:02 koen: I have the commits ready to go - just testing that the slugos and unslung images boot before pushing them. Jan 23 06:19:26 nice Jan 23 06:31:00 koen: there is *no* python code in machine/include/ixp4xx.conf now :-) Jan 23 07:23:03 morning Jan 23 07:23:15 hrw: morning Jan 23 07:23:35 * rwhitby pushes ixp4xx rewrite ... Jan 23 07:35:40 morning all Jan 23 07:51:52 03rwhitby 07org.oe.dev * r43b96271... 10/ (1 conf/machine/include/tune-thumb.conf): Jan 23 07:51:52 tune-thumb.conf: Default thumb interworking to on, fix the overrides definition Jan 23 07:51:52 (do not want a space in there), explicitly turn off thumb and interworking Jan 23 07:51:52 options when not requested, explicitly turn off interworking for the kernel. Jan 23 07:51:56 03rwhitby 07org.oe.dev * r943bd4e5... 10/ (1 conf/machine/include/tune-xscale.conf): tune-xscale.conf: Set TARGET_CC_KERNEL_ARCH correctly Jan 23 07:51:59 03rwhitby 07org.oe.dev * r49ba0c69... 10/ (1 packages/madwifi/madwifi-ng_r.inc): madwifi: Replaced the slugos-specific oemake override with machine-endianness-specific overrides Jan 23 07:52:03 03rwhitby 07org.oe.dev * rffff82ac... 10/ (1 packages/apex/apex_1.4.11.bb packages/apex/apex_1.4.7.bb): apex: Changed ixp4xx-specific ARCH_BYTE_SEX variable usage into generic CONFIG_SITE based endianness checks Jan 23 07:52:07 03rwhitby 07org.oe.dev * r3d4277cf... 10/ (3 files in 2 dirs): ixp4xx-npe: Removed unused instances of slugos-specific ARCH_BYTE_SEX variable. Jan 23 07:52:11 03rwhitby 07org.oe.dev * rf9fc6690... 10/ (28 files in 9 dirs): Jan 23 07:52:11 ixp4xx (and related ixp4xx-specific files): Change all usage of ARCH_BYTE_SEX to Jan 23 07:52:11 IXP4XX_MACHINE_ENDIAN (and ensure COMPATIBLE_MACHINE is in effect whereever it Jan 23 07:52:13 is used). Add the nslu2le and nslu2be machines. Change include/ixp4xx.conf to Jan 23 07:52:15 use tune-xscale and tune-thumb. Remove slugos-specific variables that had Jan 23 07:52:17 global OE equivalents. Deprecate ixp4xx.conf and nslu2.conf in favour of Jan 23 07:52:19 endian-specific replacements. Jan 23 07:52:21 03rwhitby 07org.oe.dev * r77582b02... 10/ (1 packages/linux/ixp4xx-kernel.inc): ixp4xx-kernel: Remove superfluous anonymous python check on SLUGOS_IMAGESEX. Jan 23 07:52:26 03rwhitby 07org.oe.dev * rf521b6a6... 10/ (12 files in 4 dirs): nslu2-kernel: Moved to obsolete - replaced long ago by ixp4xx-kernel. Jan 23 07:52:29 03rwhitby 07org.oe.dev * r9efcb95a... 10/ (1 conf/distro/include/slugos.inc): ixp4xx-kernel: set default to 2.6.19 Jan 23 07:52:32 03rwhitby 07org.oe.dev * rb65424e3... 10/ (3 files in 2 dirs): ixp4xx-kernel: Updated 2.6.19 and 2.6.20-rc4 to the latest svn repository patches Jan 23 07:52:37 03rwhitby 07org.oe.dev * r2eb5baae... 10/ (20 files in 4 dirs): nslu2-linksys-kernel: subsumed into unslung-kernel Jan 23 07:52:40 03rwhitby 07org.oe.dev * radda6046... 10/ (1 conf/distro/unslung.conf): unslung.conf: Force the use of unslung-kernel (instead of the default ixp4xx-kernel) Jan 23 07:52:45 03rwhitby 07org.oe.dev * r850a38fa... 10/ (3 files in 3 dirs): unslung-kernel: Delete the obsolete nslu2-linksys-kernel defconfig Jan 23 07:53:15 rwhitby: nice set Jan 23 08:10:37 cu Jan 23 08:32:21 morning Jan 23 08:32:49 XorA: good morning Jan 23 08:32:59 ssvb: pxa270 appears to be planar yuv Jan 23 08:34:45 XorA: ok, so some changes to the JIT scaler will need to be added, but performance should be pretty much the same Jan 23 08:35:14 XorA: I posted some information in the forum: http://www.oesf.org/forums/index.php?showtopic=22280&view=findpost&p=152090 Jan 23 08:35:54 ssvb: it can display 420 so there is no need to convert to 422 Jan 23 08:36:25 ssvb: ah I missed that is scales as well Jan 23 08:38:27 ssvb: if I read that benchmark right thats an impressive feat Jan 23 08:40:16 re Jan 23 08:40:28 hey hrw|work Jan 23 09:07:47 yet another nasty day at disconnecto.net Jan 23 09:17:06 hello Jan 23 09:47:10 hi zecke Jan 23 09:47:33 master Jan 23 09:51:27 *yawn* Jan 23 09:51:31 morning Jan 23 09:52:59 moin Jan 23 09:55:15 hi mickeyl zecke pb Jan 23 09:56:51 morning all Jan 23 09:57:13 hi RP Jan 23 09:58:28 hail mickeyl Jan 23 09:58:30 hi hrw|work Jan 23 09:58:32 hi rp Jan 23 10:30:08 hey RP Jan 23 10:40:55 hi, all! Jan 23 10:41:12 how is thumb tuning is inended to be used? Jan 23 10:41:54 I have several packages for which I don't want to use thumb, but for others I want thumb code. Jan 23 10:46:53 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND Jan 23 10:46:53 4132 hrw 23 0 1175m 1.0g 5760 R 68.9 79.9 41:10.01 firefox-bin Jan 23 10:58:04 ~seen schurig Jan 23 10:58:09 !seen prplague Jan 23 10:58:10 hrw|work, I don't remember seeing prplague. Jan 23 10:58:13 ~seen prplague Jan 23 10:58:25 schurig was last seen on IRC in channel #oe, 8d 18h 2m 38s ago, saying: 'zecke: Hi and merry new year, BTW'. Jan 23 10:58:30 prplague <~billybob@72.22.128.187> was last seen on IRC in channel #elinux, 615d 21h 1m 29s ago, saying: 'it is'. Jan 23 11:02:15 do anybody have tslib experience? Jan 23 11:03:51 slapin_nb: just ask your question and see if anyone is skilled enough to answer Jan 23 11:04:40 I see strange behaveour with Angstrom/gpe - touchscreen touches generate mouse move events, but not "clicks" Jan 23 11:05:07 which handle should I tune? I sue default ts.conf Jan 23 11:05:12 *use Jan 23 11:05:29 which device is that? Jan 23 11:05:59 <_law_> are there no device specific patches in the linux-handhelds kernels? Jan 23 11:06:03 Zire 72 Jan 23 11:06:21 slapin_nb: this is not in OpenEmbedded?! Jan 23 11:06:48 I making it there. Jan 23 11:06:54 see bug 1811 Jan 23 11:07:02 slapin_nb: I assume you should fix your touchscreen driver, ts_print, ts_print_raw and ts_test are your friends Jan 23 11:07:47 zecke, it is wm9712. where these belong to - tslib? Jan 23 11:07:47 slapin_nb: I get same behaviour on smdk2440 board Jan 23 11:12:34 XorA: slapin_nb : but ts_test works alright? Jan 23 11:13:03 yeah Jan 23 11:13:10 and calibration Jan 23 11:13:35 _law_: linux-handhelds is device specific itself Jan 23 11:13:38 zecke: yes, and same here, calibration works as well Jan 23 11:14:02 zecke: I am not looking at this at the moment as ts doesnt help me with audio Jan 23 11:14:03 _law_: it contain big amount of patches when you compare it to mainline version Jan 23 11:14:49 <_law_> hrw|work, i know but the new axim x51v patches arent in the kernel.... Jan 23 11:14:57 <_law_> currently Jan 23 11:15:52 _law_: in handhelds.org one? Jan 23 11:16:13 <_law_> hrw|work, right so i have to add it via OR Jan 23 11:16:17 <_law_> s/OR/OE Jan 23 11:17:07 _law_: axim x51v is maintained in hh.org or not at all? Jan 23 11:17:32 _law_: if not at all I would rather go via same way as RP did with Zaurus kernels or even add into linux-rp Jan 23 11:17:34 <_law_> hrw|work, will be, i think in the next few days Jan 23 11:17:51 <_law_> aha ok Jan 23 11:19:21 is oe site down ? Jan 23 11:20:36 ~lart alsa for being a pile of poo Jan 23 11:20:36 * ibot shoots alsa in his sleep for being a pile of poo Jan 23 11:20:40 basiliscus: maybe, or just the dns Jan 23 11:23:07 what insane person allowed this junk in the kernel Jan 23 11:23:39 XorA: and why it has so braindead mixers... Jan 23 11:24:14 hrw|work: thats what pissing me off at the moment, I add word switch to mixer name, it disapears, not make a mute/unmute button like its supposed to Jan 23 11:24:18 XorA: to configure sblive you need to read sblive datasheet atleast twice to know how to change volume and speaker arrangement Jan 23 11:24:46 hrw|work: alsa-scenario will fix that, but I doubt lrg will ever get time to finish it Jan 23 11:25:01 XorA: switch is done by 'Switch' in name??? not by parametr? Jan 23 11:25:28 hrw|work: Swtich, Playback, Capture and probably some more are all magic words Jan 23 11:28:31 morons created it? Jan 23 11:28:59 morning Jan 23 11:29:22 * XorA is wasteing time trying to guess at the magic string combo that he oculd do with coding Jan 23 11:46:50 hi all Jan 23 11:47:19 hi florian Jan 23 11:53:43 kergoth: ping Jan 23 12:13:51 florian: any idea whats happened to openembedded.org? Jan 23 12:16:04 polyonymous: mickeyl mentioned problems as well, but it works fine for me. Jan 23 12:16:28 make a whois openembedded.org Jan 23 12:18:40 "...Registrant Name:Christopher Larson" Jan 23 12:18:59 I wonder what Jan 23 12:19:03 I can't reach it either Jan 23 12:19:03 same as dns and http - everything working fine here. Jan 23 12:19:05 Status:CLIENT HOLD means Jan 23 12:19:37 sounds like he didn't pay the bill Jan 23 12:19:38 heh Jan 23 12:19:43 Last Updated On:23-Jan-2007 10:16:33 UTC Jan 23 12:19:49 florian: you probably have it in your /etc/hosts Jan 23 12:20:47 hmm all four easydns servers are able to resolve www.openembedded.org Jan 23 12:20:57 CLIENT HOLD typically denotes non-payment, expiration, or a domain subject to a legal dispute. Jan 23 12:21:04 no Jan 23 12:21:20 I guess we have to wait for kergoth to wake up Jan 23 12:21:21 (to mickeyl) Jan 23 12:22:04 what do they charge for the domain that it is that hard to pay these bills? Jan 23 12:22:26 that does sound unfriendly Jan 23 12:23:14 the email address looks like a former employer, I think Jan 23 12:23:21 he may not have received the notice Jan 23 12:24:33 any plans to finally create OE Organization which will hold domain and pay it in advance? Jan 23 12:25:17 :} Jan 23 12:25:46 hrw|work: we still need evaluate the possibilities Jan 23 12:37:19 ok, guys I have a problem Jan 23 12:37:49 my public defense is on 22th of February Jan 23 12:38:04 which means I won't have much time to organize our FOSDEM appearance Jan 23 12:38:13 someone needs to take the wheel for that, please Jan 23 12:40:21 mickeyl: someone is suing you or your on a jury? Jan 23 12:41:04 XorA: no no, it's just the final oral examination for my thesis Jan 23 12:41:07 "just" Jan 23 12:41:21 i planned to have that mid march Jan 23 12:41:27 but now 22.2 is the only option Jan 23 12:42:43 mickeyl: ah, I had images of you in jail, well knock em dead then Jan 23 12:42:57 hehe Jan 23 12:42:58 thanks Jan 23 12:43:00 will try Jan 23 12:43:08 it's not that someone really can fall through Jan 23 12:43:39 but i have stirred a lot of expectations among the profs Jan 23 12:43:41 *sigh* Jan 23 12:43:53 and i dunno whether i can live up to that :D Jan 23 12:46:35 take a booth babe with you Jan 23 12:46:48 * XorA wonders who the OE booth babes are Jan 23 12:49:01 mickeyl: take your time! focus on it Jan 23 12:49:50 will do, thanks. Jan 23 12:51:14 food time Jan 23 12:51:48 ~bon appetit Jan 23 12:51:57 well, bon appetit is smacznego. Guten Appetit. Eet Smakelijk. God Appetitt. Buon Appetito. Buen apetito Bom Apetite. buen apetito Smaklig måltid!. Hyvää ruokahalua. Bo Proveito Jan 23 13:15:27 rwhitby: great work! Jan 23 13:22:05 zecke: its not meant to be unfriendly, don't take me too serious :-) Jan 23 13:36:26 heh, kergoth does have a long and distinguished track record of not paying his domain registration fees. Jan 23 13:40:50 someone check the mailing list archive and see if this is exactly x years later :-) Jan 23 13:41:43 heh Jan 23 14:05:23 I cannot resolve openembedded.org or monotone.openembedded.org Jan 23 14:05:27 Is this known? Jan 23 14:05:46 (dns resolve; cannot reach either the website nor update OE) Jan 23 14:06:01 yes, it's known. Some dns issue Jan 23 14:06:47 * CM only repeats what has previously been said in #oe Jan 23 14:07:42 is the server up? I have some small problems and I'd like to update. I could simply add it to my /etc/hosts Jan 23 14:07:56 If someone would know the IP Jan 23 14:08:17 85.214.40.226 www.openembedded.org Jan 23 14:08:34 Nice bot :) Jan 23 14:08:38 :P Jan 23 14:08:53 I haven't tried that, still at work, but it was mentioned in #openmoko Jan 23 14:09:02 sorry :D Jan 23 14:09:06 Hehe Jan 23 14:09:09 thought you were an extremely good bot Jan 23 14:09:09 lol Jan 23 14:09:31 I'm just a bored consultant at work ;) Jan 23 14:10:00 ahh well, what's the difference :) Jan 23 14:11:01 updating works again :) Jan 23 14:11:05 nice fast server :D Jan 23 14:12:44 i'm not a server, i'm a gremlin in your router Jan 23 15:27:40 Anyone here that can recommend any good books on x86 assembly? Jan 23 15:36:38 NAiL: LinuxBIOS assembly hacking? :-) Jan 23 15:54:05 rehi, all! Jan 23 15:54:24 do anybody have tslib documentation link to share? Jan 23 16:00:01 uf. looks like I got bitbake 1.6 GPLv2ized Jan 23 16:00:28 hehe Jan 23 16:01:00 fsck. kdiff merged in reverse way... Jan 23 16:01:44 could anybody explain need for pthres module of tslib? Jan 23 16:02:06 I mean what it actually do Jan 23 16:02:13 argh Jan 23 16:02:26 ant what pmin=1 does in default ts.conf Jan 23 16:02:30 *and Jan 23 16:10:03 zecke: lib/parse/parse_c/ should be removed from 1.6 branch - right? Jan 23 16:10:15 yes Jan 23 16:10:42 ok Jan 23 16:12:08 bother Jan 23 16:12:20 monotone.oe.org isn't resolving .... Jan 23 16:13:25 85.214.40.226 monotone.openembedded.org openembedded.org Jan 23 16:13:29 >> into your /etc/hosts Jan 23 16:13:48 zecke: 29 files changed, 481 insertions(+), 471 deletions(-) Jan 23 16:14:17 who needs dns anyway Jan 23 16:19:54 * XorA suggests adding the dns info the the wiki :-D Jan 23 16:23:20 CIA-19: wakeup Jan 23 16:23:26 03hrw 07bitbake-1.6 * r747 10/ (29 files in 7 dirs): Jan 23 16:23:26 Add proper GPLv2 headers to all BitBake files (from trunk) Jan 23 16:23:26 - BitBake trunk is now GPLv2 only, no mix of MIT, FreeBSD License is left. Jan 23 16:23:26 - Update GPL headers to point to the correct address of the FSF Jan 23 16:23:26 - Update the list of authors. Uli Luckas, Seb Frankengul and Tim Amsell Jan 23 16:23:27 contributed to the sourcecode as well Jan 23 16:25:09 03hrw 07bitbake-1.6 * r748 10/lib/bb/build.py: Jan 23 16:25:09 lib/bb/build.py: Put LC_ALL=C on os.system call Jan 23 16:25:09 For our french and strange friends place LC_ALL=C in all task calls. Jan 23 16:25:09 This should give us english log messages. Jan 23 16:27:04 cu Jan 23 17:00:26 hrw|gone: 748 looks familiar to me Jan 23 17:07:05 eh, forcing LC_ALL=C inside bitbake sounds rather bogus. Jan 23 17:07:42 pb__: does it? Jan 23 17:08:22 it does to me, yeah. Jan 23 17:08:36 if I had requested some other localisation then I would find it offensive that bitbake insisted on using US English for everything. Jan 23 17:09:01 pb__: I was sick of our french dudes posting logs files in a language I don't understand :) Jan 23 17:09:34 not least because C isn't even a utf-8 locale, so any non ascii characters are likely to end up hopelessly mangled and undisplayable. Jan 23 17:09:58 pb__: that is kind of an argument Jan 23 17:10:40 but also because I would find it annoying, for example, to suddenly have all my dates coming out backwards. Jan 23 17:11:03 pb__: normally you don't see the compile logs bitbake is generating Jan 23 17:11:18 pb__: it is set to LC_ALL for patch, make, etc. and this has two reasons Jan 23 17:11:36 pb__: if people paste log files we use a common language (which is not named esperanto) Jan 23 17:11:52 pb__: and broken buildsystem parsing english output will work Jan 23 17:12:16 mm, I find those arguments weak. Jan 23 17:12:23 broken build systems should, almost by definition, be fixed. Jan 23 17:12:40 pb__: and french guy should learn a sane language? :) Jan 23 17:13:12 pb__: okay, will reconsider the usage of LC_ALL then Jan 23 17:13:26 and as for the logfiles, if the user is looking at them then he is probably trying to understand them, and would prefer to have them in his own language. Jan 23 17:13:53 so, by putting them in french you will probably reduce the chance that your hypothetical french user needs to post to the mailing list at all. Jan 23 17:14:19 pb__: hmm actually not. I hate the german translation of most of the GNU tools. And most people blindly copy their log into pastebin without looking at it Jan 23 17:14:47 pb__: and as to broken build systems, you need to findout that they are broken :} Jan 23 17:14:55 zecke: if you hate the german translations then I guess you don't have LANG=de_DE set in your environment in the first place Jan 23 17:15:08 ;) Jan 23 17:15:36 so, for you there is no benefit to setting LC_ALL=C. conversely, people who _do_ have LANG=de_DE are probably doing that because they do prefer to see german. Jan 23 17:15:46 pb__: I'm willing to reconsider, I'm playing the "I'm busy card" Jan 23 17:15:58 heh, fair enough Jan 23 17:16:14 pb__: I might set it for GNOME on my desktop, but do I want it for GNU make, or GNU CC (dev tools) Jan 23 17:16:44 I guess my other point is that bitbake's behaviour should not be driven primarily by the narrow interest of oe, and particularly not by the even narrower interest of the mailing list. Jan 23 17:17:03 if you consider the wider community which bitbake strives to reach, most of those people probably do not want LC_ALL=C either. Jan 23 17:17:50 pb__: My two reasons were: People blindly pasting log files and forcing me to look at weird languages. Trying to create a deterministic task executor should start with same input/output Jan 23 17:18:15 hrw|gone: please revert this backport (and backports go through the bug tracker anyway) Jan 23 17:36:18 zecke: how about setting LC_ALL=C in the sample local.conf and let people who know what they are doing mangle it to their hearts content. Jan 23 17:36:37 * hvontres|poodle should check out the german GNU translations some time Jan 23 17:41:43 * pb__ go home Jan 23 17:41:51 later all Jan 23 17:42:04 hvontres|poodle: these people can read their error logs :} Jan 23 17:42:20 or at least can call LC_ALL=C bitbake Jan 23 17:44:25 zecke: we could always pick something nice and neutral... like norwegian or sweedish for the default.. or even swedish chef Jan 23 17:55:37 bork bork Jan 23 17:55:43 default to Finnish Jan 23 17:56:07 back in the "Good Old Days" Linux made us all change the keyboard setup to US :) Jan 23 17:56:11 from Finnish Jan 23 18:00:07 kergoth, you awake yet? Jan 23 18:10:58 somewhat Jan 23 18:12:22 kergoth, time to pay the oe.org bill :) Jan 23 18:12:38 just did :P Jan 23 18:12:47 excellent! Jan 23 18:20:19 hi kergoth Jan 23 18:23:03 re Jan 23 18:23:18 g'day kergoth Jan 23 18:23:54 pb_: wb Jan 23 18:25:07 could anybody look at bug 1811 - Palm Zire 72 support? Jan 23 18:30:42 kergoth: should we collect for the DNS bill? Jan 23 18:59:47 zecke: nslu2-linux.org would be happy to donate the registration fee for oe.org Jan 23 19:00:05 (assuming it's in the tens of dollars range) Jan 23 19:01:16 rwhitby: I think anyone would be happy to donate Jan 23 19:01:32 rwhitby: it is up to chris to decide up on these offers Jan 23 19:03:06 ok. nslu2-linux.org has just raised USD$1200 in our latest donation drive, and since 75% of the nslu2-linux downloads are built with openembedded we felt we could save a step and just give one donation (which covers lots of users). Jan 23 19:50:24 03hrw 07bitbake-1.6 * r749 10/lib/bb/build.py: build.py: revert setting LC_ALL=C due to IRC discussion Jan 23 19:51:06 re Jan 23 19:54:04 zecke: r727 from trunk would be nice to have in 1.6 Jan 23 19:57:23 hi :) Jan 23 19:59:16 zecke: where do we have 'backport this and that to 1.6.x' bug in OE? Jan 23 20:00:33 zecke: r721, r723, r727 Jan 23 20:00:37 bugs.openembedded.org Jan 23 20:00:49 it is called backport 1.x bug iirc Jan 23 20:01:44 'Meta-Bug: Bitbake "It could suck more" 1.x.y' one? Jan 23 20:01:52 !oebug 829 Jan 23 20:01:54 * * Bug 829, Status: NEW, Created: 2006-04-10 10:42 Jan 23 20:01:55 * * freyther(AT)inf.fu-berlin.de: Meta-Bug: Bitbake "It could suck more" 1.x.y Jan 23 20:01:56 * * http://bugs.openembedded.org/show_bug.cgi?id=829 Jan 23 20:02:07 yes Jan 23 20:02:20 ok Jan 23 20:04:28 03hrw 07bitbake-1.6 * r750 10/lib/bb/parse/parse_c/: Jan 23 20:04:28 Remove the first attempt to integrate Marc's flex/lemon (like in trunk) Jan 23 20:04:28 Remove the first C implementation. I'm too lazy to create proper license Jan 23 20:04:28 headers for what will be replaced with the bitbake-parser code soon(tm). Jan 23 20:05:25 * rwhitby breathes a sigh of relief that his big ixp4xx patch doesn't seem to have broken anything overnight ... Jan 23 20:08:14 rwhitby: Its always nice when they work out :) Jan 23 20:08:42 RP, zecke: prefered way of noticing which things would be good to have in 1.6 is comment in #829 or adding bugs? Jan 23 20:08:58 03justinp 07org.oe.oz354x * rd575563c... 10/ (3 files in 2 dirs): glurp: downgrade to 0.11.3, 0.11.6 doesn't seem to exist Jan 23 20:09:03 03justinp 07org.oe.oz354x * rd3d0d9aa... 10/ (1 packages/musicpd/mpc_0.12.0.bb): mpc: add newer version Jan 23 20:09:08 03justinp 07org.oe.oz354x * r38c8bcdf... 10/ (1 packages/musicpd/mpd_svn.bb): mpd: add svn version as 0.21.x releases have autoreconf problems Jan 23 20:09:13 03justinp 07org.oe.oz354x * r493c8c37... 10/ (1 packages/musicpd/libmpd_svn.bb): libmpd: add libmpd Jan 23 20:09:16 03justinp 07org.oe.oz354x * r34ba545a... 10/ (1 packages/musicpd/py-libmpdclient_0.10.0.bb): py-libmpdclient: add py-libmpdclient Jan 23 20:09:25 03justinp 07org.oe.dev * r821236cd... 10/ (1 packages/gob2 packages/gob2/gob2_2.0.14.bb): gob2: add gob2, a GObject support package Jan 23 20:09:32 03justinp 07org.oe.dev * rba3eb29b... 10/ (1 packages/musicpd/mpd_svn.bb): mpd: add mpd_svn as 0.12.x releases have problems with autoreconf Jan 23 20:09:47 03justinp 07org.oe.dev * re1ee4232... 10/ (3 files in 2 dirs): glurp: downgrade from 0.11.6 to 0.11.3 as higher releases don't seem to exist Jan 23 20:09:55 03justinp 07org.oe.dev * r0543c3bb... 10/ (3 files in 2 dirs): gmpc: add newer versions Jan 23 20:10:03 03justinp 07org.oe.dev * rccb9ba8c... 10/ (1 packages/musicpd/libmpd_svn.bb): libmpd: add libmpd Jan 23 20:10:06 hrw: There was a backport specific bug for 1.6 somewhere. I think it was closed as we did all the backports Jan 23 20:10:09 03justinp 07org.oe.dev * re316166e... 10/ (1 packages/musicpd/py-libmpdclient_0.10.0.bb): py-libmpdclient: add py-libmpdclient Jan 23 20:10:39 hrw: What were r721, r723, r727? :) Jan 23 20:11:00 RP: trunk ones Jan 23 20:11:18 727: BBINCLUDELOGS_LINES Jan 23 20:11:29 721: svn fetcher: Don't have a date in the filename for specific svn revisions Jan 23 20:11:48 723 is in 1.6 already Jan 23 20:12:29 hrw: comments, attach patch, get some one from [mickeyl,kergoth,pb,RP,me] to ack and then commit Jan 23 20:12:31 723/trunk is 724 in 1.6 Jan 23 20:12:36 ok Jan 23 20:13:05 looking at my schedule I will be mostly unavailable until the 12th of feb Jan 23 20:13:39 ok Jan 23 20:19:33 RP: can you look at #829 and comment? Jan 23 20:29:11 hrw: I'm really uneasy about that patch, I don't like os.system calls Jan 23 20:29:56 ok, so we will skip it Jan 23 20:30:51 hrw: If we're prepared to read the file into memory, we could use readlines() and slice it... Jan 23 20:32:18 RP: can you comment in #829 or #97? I will rewrite then it later Jan 23 20:32:50 hrw: Will do, I'm just trying to think of a good way to do it first :) Jan 23 20:32:57 ok Jan 23 20:35:59 03Sergey 07org.oe.dev * r76159c97... 10/ (1 conf/machine/zire72.conf): zire72: added machine config - close part of #1811 Jan 23 20:36:03 03Sergey 07org.oe.dev * re21cb2e5... 10/ (4 files in 4 dirs): linux-hackndev: added Palm Zire72 kernel config from #1811 Jan 23 20:36:06 03hrw 07org.oe.dev * rc79f60c5... 10/ (1 conf/machine/zire72.conf conf/machine/palmz72.conf): zire72: rename to palmz72 like it was submitted Jan 23 20:37:03 psokolovsky: can you look at #1812-1814? Jan 23 20:44:14 wow i just read a oe list mail from march 2006 where one fried 2 zaurus in the attempt to replace 3.7" with 4" .. scary Jan 23 20:44:27 .. Jan 23 20:44:50 "fried" is highly doubtful, the oz install has never been dangerous Jan 23 20:45:32 i reads that he fried them electricly Jan 23 20:46:06 I killed my 5500 with a non-surge-protected lighter cable Jan 23 20:47:05 morning all Jan 23 20:47:30 best to keep your 5500 away from lighters of all descriptions, I'd have thought. Jan 23 20:48:09 kergoth: When replacing an LCD, I suspect its possible to properly fry one. I've fried a backlight controller in a c760 easily enough :-/ Jan 23 20:48:17 hrw: I commented on bug 97 Jan 23 20:48:36 pb_: lighter jack car power adapter Jan 23 20:49:37 * RP ponders what a 1972 car's electrics would do to modern electronics... Jan 23 20:51:25 RP: thx Jan 23 20:52:01 RP: I remember your panic when you fried it Jan 23 20:52:58 Initially, I thought it was totally dead... Jan 23 20:53:34 do13: and new job nice? Jan 23 20:54:02 hi Dirk! Jan 23 20:54:06 greentux: next week Jan 23 20:54:11 hi Richard Jan 23 20:54:36 hrw new job, do13 new job. I should think about changing ... Jan 23 20:54:48 hm. fetchers in trunk differ a lot when compared to 1.6 Jan 23 20:54:50 greentux: ;) Jan 23 20:54:53 hi Dirk Jan 23 20:55:01 hrw: I rewrote bits of them... Jan 23 20:55:04 hi Marcin Jan 23 20:56:05 RP: I think that fix to #1781 is quite easy in 1.6 but for trunk I will need more checking Jan 23 20:56:06 greentux: work switzerland :) Jan 23 20:56:33 do13: yes we have a dependance there... Jan 23 20:56:50 hrw: It shouldn't be too bad in trunk either Jan 23 20:56:57 greentux: yep. I know this. Jan 23 20:57:19 hrw: In fact, trunk might just work Jan 23 20:58:19 greentux: still working on the Konnektor :) Jan 23 21:00:47 03hrw 07org.oe.oz354x * r11e16c06... 10/ (1 packages/tin/tin.inc packages/tin/tin_1.9.1.bb): tin: it is BSD licensed not GPL - close #1807 (from .dev) Jan 23 21:00:54 03hrw 07org.oe.dev * r8b03aaa8... 10/ (1 packages/tin/tin.inc packages/tin/tin_1.9.1.bb): tin: it is BSD licensed not GPL - close #1807 Jan 23 21:01:43 do13: yes and it looks that we come in business with your 2old" company. Jan 23 21:02:38 hrw, Hi! yes, I'm going to look at them within next few days. too busy now with real life. If you have time, feel free to process them yourself, but I'd be really happy to save your time on them ;-) Jan 23 21:03:03 greentux: is your Konnektor also x86 based? Jan 23 21:03:10 psokolovsky: they are hh.org machines so I prefer to push it by you Jan 23 21:03:37 ~lart Crofton uni for lack of anonymous SVN Jan 23 21:03:38 * ibot whacks Crofton uni with the cluebat for lack of anonymous SVN Jan 23 21:03:43 * chouimat is back Jan 23 21:03:59 CMD: /usr/bin/env svn co -r {20070123} https://oe@ossie-dev.mprg.org/repos/ossie/ossie/trunk/ossie ossie Jan 23 21:04:12 and this ask for hrw password instead of oe.. Jan 23 21:04:12 ? Jan 23 21:04:13 do13: its not my project. I dont know much about it. Jan 23 21:04:23 ah Jan 23 21:04:24 Crofton__: ossie/*_svn.bb Jan 23 21:04:35 hrw, feel free to beat the uni lawyer Jan 23 21:04:58 bb fetcher is ignoring the username/password setting Jan 23 21:05:10 Crofton__: subversion is ignoring it too Jan 23 21:05:21 Crofton__: I'm doing another attempt to fix it Jan 23 21:05:32 ah Jan 23 21:05:42 greentux: Last week I have seen the S...ens Konnektor. It's a nice small PC. Perfect for VDR:) Jan 23 21:05:49 22:35 hrw@home:tmp$ svn co https://oe@ossie-dev.mprg.org/repos/ossie/ossie/trunk/ossie ossie Jan 23 21:05:57 Password 'hrw': Jan 23 21:06:09 do13: yes seen that too. and is it cheap (it must be!) Jan 23 21:07:38 Crofton__: 22:38 hrw@home:tmp$ echo "t\noe\noe\n"|svn co https://ossie-dev.mprg.org/repos/ossie/ossie/trunk/ossie ossie Jan 23 21:07:58 Crofton__: this works but this is so UGLY that I do not even want to comment it Jan 23 21:09:53 so you can feed to svn command the username.pw ok? Jan 23 21:10:18 Crofton__: and will need 'ssl=selfsigned' addon to SRC_URI line? ARGH Jan 23 21:10:53 hrw: How about --username and --password? Jan 23 21:11:07 I guess this is testing the rare cases Jan 23 21:12:05 hrw,psokolovsky : could one of you guys take a look at #1806 and let me know if you want any of the patches fixed? thanks Jan 23 21:13:46 hvontres|poodle, if you can test that stuff, why not. Jan 23 21:13:49 RP: good point Jan 23 21:15:33 psokolovsky: well, I built them against the .354x branch and they work on poodle.... I guess I should add that as a comment :) Jan 23 21:16:46 hvontres|poodle, what about "gpsd.inc patch to use latest dbus"? is that for GPE's usage only? Jan 23 21:18:30 psokolovsky: the old gpsd.inc wanted an ancient looking version of dbus, so I tried to build against the latest (1.0xx) in .oz354x and it worked :) Jan 23 21:18:52 NOTE: package ossiecf-0.0.0+svn20070123-r0: task do_fetch: completed Jan 23 21:19:07 hvontres|poodle, well, excuse my cluelessness, but does OPIE use dbus? Jan 23 21:19:13 psokolovsky: and qpegps 0.9.3 now uses the 2.3x gpsd interface Jan 23 21:19:43 psokolovsky: not sure... you might want to ping mickeyl on that, since he originaly wrote that recipie. Jan 23 21:19:51 psokolovsky: opie does not use dbus Jan 23 21:20:06 psokolovsky: but opie does not use gpsd also. Jan 23 21:20:12 psokolovsky: gpsd can use dbus to communicate Jan 23 21:20:20 hrw: qpegps uses gpsd.. Jan 23 21:20:29 hvontres|poodle, hrw, yep, that's what I thought, and why I'm concerned about that comment in ticket Jan 23 21:20:59 RP: http://pastebin.ca/326144 - patch for bitbake trunk Jan 23 21:21:30 hvontres|poodle, so, before I'd commit those patches, I would check what new/weird dependencies it brings to OPIE... Jan 23 21:21:53 hrw: Looks good to me Jan 23 21:22:00 hrw, how much trouble is the self signed certificate? Jan 23 21:22:09 not that I can afford a signed one ... Jan 23 21:22:36 Crofton__: make it CACert signed? Jan 23 21:22:40 Crofton__: change to bitbake.conf to change svn commands from 'svn THIS' to 'echo t|svn THIS' Jan 23 21:23:12 psokolovsky: ok. Is there an easy bitbake command I can use? Jan 23 21:23:36 hvontres|poodle, for what? Jan 23 21:24:16 zecke: CACert is also not trusted yet ;( Jan 23 21:24:26 psokolovsky: I think there was one to just get a listing of the dependancies instead of actually building everyting. my build system at home is kinda slow Jan 23 21:24:57 zecke: btw - are you CACert trusted? Jan 23 21:25:11 hrw: I should be almost CACert trusted Jan 23 21:25:27 zecke: almost? <100 points or more? Jan 23 21:25:46 hrw: I would need to count, I signed TheCount which should bring me somewhere Jan 23 21:26:19 zecke: remind itself on fosdem so I will sign you Jan 23 21:27:07 hvontres|poodle, well, you can use -n -v. anyway, if you have tested it to work, that's good reason to commit it... I just told you what *I*'d check about it ;-) Jan 23 21:29:58 RP: ok to commit into trunk? Jan 23 21:30:31 hrw: yes Jan 23 21:32:30 03hrw * r751 10bitbake/lib/bb/fetch/svn.py: Jan 23 21:32:30 fetch/svn.py: use username/password when provided in SRC_URI - close OE#1781 Jan 23 21:32:30 Subversion will still ask if self-signed SSL certificate will be used. Jan 23 21:32:38 now 751 to 1.6... Jan 23 21:34:10 hrw, I think you only have to accept it once Jan 23 21:34:15 then it does not ask again Jan 23 21:34:17 p Jan 23 21:35:01 I know Jan 23 21:50:30 * rwhitby has 150 cacert points Jan 23 21:50:52 but that's only helpful to people in south australia :- Jan 23 21:51:01 * hrw has 102 Jan 23 21:51:24 hrw: I got 150 straight up by doing a thawte notary status transfer. Jan 23 21:51:51 rwhitby: I got 102 on one event - 3x35 + 2 Jan 23 21:52:29 each assurent can give 35 by signing you. you can get 100 points in this way Jan 23 21:55:41 I am almost a thawte notary Jan 23 21:59:55 RP: still here? Jan 23 22:00:26 RP: http://pastebin.ca/326179 - version for 1.6 Jan 23 22:00:30 ugh....| configure: error: C preprocessor "arm-linux-gcc -E" fails sanity check Jan 23 22:00:53 hrw, thanks for fixing the svn account stuff the fethcer Jan 23 22:02:06 Crofton__: 1.6 bitbake is not ready yet Jan 23 22:03:06 but it will be one day :) Jan 23 22:03:33 what do I need to do to get my spectrum 24 wireless card to show up at wlan0 instead of eth0 in OZ? Jan 23 22:04:01 summatusmentis: this card is orinoco driver and will be Jan 23 22:04:04 eth0 Jan 23 22:04:30 hrw: is there any way to change that? Jan 23 22:06:31 summatusmentis: why you want to change it? Jan 23 22:07:42 hrw: scanning, iwlist won't scan if it's eth0 Jan 23 22:08:16 summatusmentis: renaming interface does not help Jan 23 22:08:39 later Jan 23 22:08:42 hrw: oh really? so it's the card itself that won't scan? Jan 23 22:08:49 that's annoying Jan 23 22:17:26 hello Jan 23 22:17:42 hi Bernardo, B_Lizzard Jan 23 22:18:40 How does bitbake see if a package has been configured or compiled? Jan 23 22:18:47 And skips the step Jan 23 22:18:57 B_Lizzard: tmp/stamps Jan 23 22:19:35 I went in there, and created *exactly* what it needed, and it still insists on running "configure" Jan 23 22:21:19 OE failed on making a package, so i built it manually outside of OE Jan 23 22:21:40 then I replaced the workdir's sources with my completed ones Jan 23 22:21:57 And I want OE to think that it already did it itself Jan 23 22:22:14 But tmp/stamps does nothing Jan 23 22:25:23 I only created do_configure and do_compile Jan 23 22:25:35 Must I make anything else? Jan 23 22:28:02 Not as far as I know.. Jan 23 22:29:21 Hmmmm Jan 23 22:29:30 I'll modify the bb file then Jan 23 22:29:38 Thanks a lot, NAbyss Jan 23 22:30:18 np Jan 23 22:31:39 hrw: I'm not sure how to ask without sounding demanding, would you rebuild the e-wm package in the 3.5.4.1 feeds? Jan 23 22:31:52 summatusmentis: rather not Jan 23 22:32:10 mm... ok Jan 23 22:32:37 I prefer to concentrate on getting 3.5.5 more ready Jan 23 22:33:00 hrw: ok, I didn't know that was happening soon Jan 23 22:33:27 soon mean March probably Jan 23 22:33:43 well, ok, soon-ish Jan 23 22:33:56 I guess I'll play with bitbake some more, see if I can't get that working Jan 23 22:43:39 hrw: 1.6 patch looks ok although it changes a bit more than just the backport ;-) Jan 23 22:44:09 RP: it fix some annoying behaviour Jan 23 22:44:38 hrw: ok, just mention what exactly it fixes in the commit Jan 23 22:46:12 RP: look at line 43 in patch Jan 23 22:46:47 RP: 43-50 lines destroy result of line 42 and bitbake.conf setting Jan 23 22:47:15 hrw: Yes, but it did that for a long time... Jan 23 22:47:44 hrw: I'm ok with the patch, I just worry about breaking 1.6 Jan 23 22:48:02 RP: this removal is needed to get 1781 fixed in 1.6 Jan 23 22:48:37 hrw: ok Jan 23 22:48:46 RP: otherwise SVNCOOPTS are ignored Jan 23 22:49:25 RP: checked ossie (user/pass svn) and mplayer (anonymous) recipes Jan 23 22:49:47 hrw: ok, good :) Jan 23 22:53:18 03pb 07org.oe.dev * r0deac718... 10/ (1 packages/tasks/task-mythfront.bb): task-mythfront: add some drivers for epia Jan 23 22:56:28 good morning all Jan 23 22:57:07 gm Jan 23 22:57:33 "smoking aces" is almost disturbingly violent Jan 23 22:59:11 If you love gun fights and brutal action then the shooting scenes will astound you! Jan 23 22:59:56 it was in the sneak preview we went to today Jan 23 23:00:07 * koen_ suspects likewise is ordering beer now Jan 23 23:00:17 heh Jan 23 23:00:24 for you? Jan 23 23:00:27 nope Jan 23 23:00:30 * koen_ go zzzz now Jan 23 23:00:37 gn Jan 23 23:00:39 'night all Jan 23 23:01:24 rory gallagher? Jan 23 23:03:12 03hrw 07bitbake-1.6 * r752 10/lib/bb/fetch/svn.py: (log message trimmed) Jan 23 23:03:14 fetch/svn.py: use username/password when provided in SRC_URI - close OE#1781 Jan 23 23:03:18 - subversion will still ask if self-signed SSL certificate will be used. Jan 23 23:03:20 - patch looks very intrusive but some of changes were needed to be done Jan 23 23:03:22 to get it working properly: Jan 23 23:03:24 svncmd = "svn co -r {%s} %s://%s/%s" % (date, proto, svnroot, module) Jan 23 23:03:26 and next (now removed) lines makes BitBake ignore SVNCOOPTS which now Jan 23 23:14:20 so bitbake 1.6.4 soon Jan 23 23:19:15 I appear to be having some troubles with bitbake - my rootfs is not being populated. What is the best way to track down why this is? bitbake -i? Jan 23 23:19:47 look into log.do_rootfs Jan 23 23:20:04 bradbev: add BBINCLUDELOGS = "1" in local.conf Jan 23 23:20:42 * hrw goes sleep Jan 23 23:20:43 cu Jan 23 23:20:49 thanks hrw Jan 23 23:20:50 Seeyas Jan 23 23:21:19 INCLUDELOGS = 1 or = "yes"? Jan 23 23:23:00 I somehow happen to have no *do_rootfs* files **** ENDING LOGGING AT Wed Jan 24 02:59:58 2007