**** BEGIN LOGGING AT Fri Feb 12 02:59:56 2010 Feb 12 07:09:48 anybody use cavium ARM CPUs? or know of products using them? Feb 12 07:25:16 therealgalen: I think the cavium arm cpus arr very new products, so not many users yet Feb 12 07:25:45 they're not that new i don't think Feb 12 07:25:45 i Feb 12 07:25:53 i see the product announcement in like... 2008 Feb 12 09:01:42 suihkulokki (and anyone else around): do you know much about GCC? I might have a lead on the OOo breakage Feb 12 09:02:46 https://bugs.edge.launchpad.net/ubuntu/+source/openoffice.org/+bug/417009/comments/55 Feb 12 09:02:49 Launchpad bug 417009 in openoffice.org (Ubuntu Karmic) (and 3 other projects) "all openoffice apps die in 'com::sun::star::ucb::InteractiveAugmentedIOException' on armel in karmic (affects: 1)" [Low,Won't fix] Feb 12 13:41:26 dmart: get me a mwc2010 pass! Feb 12 13:45:50 armin76: not wanting to be rude, but I don't know who you are and am not in a position to get anyone passes for anything... Feb 12 13:50:39 dmart: armin76 is our uber-excited gentoo developper trying to get as much hardware and invites as he can ;-) Feb 12 13:51:23 ah... I will enquire, but I don't even know how the mwc invitees are determined ... Feb 12 13:51:53 dmart: Do reserve the invites to ubuntu devs, not gentoo devs though! ;) Feb 12 13:51:55 armin76: apologies if I sounded suspicious! /whois didn't give me any info to go on. Feb 12 13:52:13 http://armin762.wordpress.com/about/ Feb 12 13:52:21 wont tell you much more though Feb 12 13:53:44 thanks Feb 12 13:57:28 :D Feb 12 13:57:48 dmart: nah, thats okay Feb 12 13:58:03 dmart: just remember that i'm better than lool! Feb 12 13:58:09 sorry, we hadn't been introduced Feb 12 14:02:11 armin76: Are you still working with the EfiKa MX? How stable do you find that? Feb 12 14:03:12 Hostname: efikamx - OS: Linux 2.6.31-ER1/armv7l - Distro: Gentoo 1.12.13 - CPU: ARMv7 rev 1 (v7l) - Processes: 118 - Uptime: 49d 17h 46m - Users: 4 - Load Average: 0.00 - Memory Usage: 72.32MB/470.49MB (15.37%) - Disk Usage: 30.55GB/461.23GB (6.62%) Feb 12 14:03:30 no crash so far as you can see Feb 12 14:03:31 49 days? Do you use this as a build machine? Feb 12 14:03:35 yep Feb 12 14:04:09 USB disk, or am I reading the spec wrong (it only says 4GB SSD) Feb 12 14:04:20 usb disk, yes Feb 12 14:04:27 i'm not using the ssd Feb 12 14:04:38 It boots from USB? Feb 12 14:05:04 We got to 99 days on some boards (no crash though, just rebooted to solve an NFS screwup. This was using SD/NFS, not USB) Feb 12 14:05:21 hrm...why wouldn't it? Feb 12 14:05:35 atm i'm booting using the kernel on the ssd Feb 12 14:05:58 but thats it, init=/bin/sdb1 Feb 12 14:06:04 Oh, booting from SSD, with filesystem on USB. That makes sense. I was hoping for a raw boot from USB :) Feb 12 14:06:05 err Feb 12 14:06:16 root=/dev/sdb1 Feb 12 14:06:39 well, i haven't looked into that, tbh Feb 12 14:06:56 is that a tapeout 2? Feb 12 14:07:01 but the sheevaplug does, why this shouldn't do? Feb 12 14:07:04 amitk: y Feb 12 14:07:19 so NEON is broken? Feb 12 14:07:48 broken how? i haven't tried neon at all Feb 12 14:08:13 armin76: can you cat /proc/cpuinfo? Feb 12 14:08:37 There's a "Revision" line Feb 12 14:09:08 http://dpaste.com/157892/ Feb 12 14:09:17 http://dev.gentoo.org/~armin76/arm/efikamx/v3boot.log <- bootlog Feb 12 14:09:40 2.5 Feb 12 15:42:20 ogra: any more work item to scratch for rootstock? ;) Feb 12 15:51:37 asac, not today, sorry Feb 12 15:51:46 ncommander not here? Feb 12 15:51:53 anyone knows status of qt4-x11? Feb 12 15:51:58 nope Feb 12 15:52:20 afaik he did only work on likewise and since yesterady he digs around in openoffice Feb 12 15:52:34 asac: What about qt4-x11? Feb 12 15:53:35 i thought michael worked on that for a reason i cant remember Feb 12 15:53:39 its on our thumb2 porting list Feb 12 15:53:43 thats why it came back to my mind Feb 12 15:53:54 Ah. He did work on it some time back. Feb 12 15:54:15 he was supposed to make it build, scottk asked for it last release meeting Feb 12 15:54:26 It built. Feb 12 15:54:40 right, not on ftbfs anymore Feb 12 15:54:50 didnt you work with him on that ? Feb 12 15:54:57 i saw some chatter about sip Feb 12 15:57:54 Not in great detail. Feb 12 16:01:42 dyfet: So, I was looking at Thumb2 porting for lwp, and the only instruction that appears to be suspicious is in src/process.S : am I correct that we don't need to do anything because this will end up being ARM code? Feb 12 16:04:26 Let me look at that one...hold on... Feb 12 16:05:10 ./src/process.S:738: mov pc, r0 Feb 12 16:06:25 Even if the assembler blocks are arm code, will it be potentially called from thumb2 code? Feb 12 16:06:44 That's the sort of thing I don't know :) Feb 12 16:07:09 If so, then yes, this should be changed to bx r0, because otherwise you cannot switch instruction modes Feb 12 16:07:26 This seems to be a function return call, but I'm kinda guessing Feb 12 16:08:01 And do I care about all the mov ip, sp stuff? Feb 12 16:08:34 It is, but it might be only back into it's own code...this is an interesting example :) Feb 12 16:09:08 Heh. So, how would I go about trying to figure out whether it needs switching? Feb 12 16:09:43 * persia isn't doing so well picking packages: the first was a false-positive, and the second is "interesting" Feb 12 16:10:32 Well, we have to go a little further back, and understand what this is. I think it is a pesudo-context-thread start routine. I think we cannot be certain what is ran after.. Feb 12 16:10:52 I see lots of savecontext() calls in various .c files, so I'm thinking it's likely being called from Thumb2 code. Feb 12 16:11:26 I think so too Feb 12 16:11:33 https://wiki.ubuntu.com/MobileTeam/ReleaseStatus/Lucid Feb 12 16:11:57 dyfet: ogra: persia: plars: GrueMaster: StevenK: JamieBennett:^ Feb 12 16:12:39 seems we get an earlier slot ... please check quickly ;) Feb 12 16:12:41 asac: Do you still care about "main and office webservice specs landing" post-Alpha3? Feb 12 16:12:55 I thought I saw chatter in -devel about that from rickspencer3 a few days back. Feb 12 16:12:58 asac, bug 507416 is fixed for uboot since a long time Feb 12 16:13:00 Launchpad bug 507416 in uboot-imx (Ubuntu Karmic) (and 5 other projects) "CONFIG_NEON=y causes platform lockups with certain application/platform combinations (affects: 2)" [Undecided,New] https://launchpad.net/bugs/507416 Feb 12 16:13:33 another thing to look at is stmfd...gcc expects the stack to be 64 bit aligned Feb 12 16:13:47 kk Feb 12 16:13:58 persia: yes i care about that Feb 12 16:14:00 why? Feb 12 16:14:19 Just wanted to make sure it wasn't leftovers. Feb 12 16:14:31 ogra: is redboot ready? Feb 12 16:14:34 for the NEON thing Feb 12 16:14:42 persia: no ... it was an addition. thanks Feb 12 16:14:44 sure Feb 12 16:14:52 redboot was always ready :) Feb 12 16:14:57 for NEON ... cool Feb 12 16:14:58 asac: the two bugs mentioned under bugs with fix available are the same bug Feb 12 16:15:06 plars: but differnt package? Feb 12 16:15:19 asac: yes, just a separate task for each kernel Feb 12 16:15:19 oh Feb 12 16:15:24 persia: I think lwp is a good example, actually Feb 12 16:15:58 dyfet: Good. Maybe I can use this to build confidence for the next one :) Feb 12 16:16:25 dyfet: So I want to change line 738 of process.c ? Feb 12 16:16:29 And that ought do it? Feb 12 16:16:56 Since the assembly is inline in C, we can also use the C preprocessor....well, we need to look at the rest, but that seems the most clear issue, yes Feb 12 16:18:45 Is this inline? It's in a .S file. Feb 12 16:19:12 I thought that meant it was an external function. Feb 12 16:20:41 It is still being processed in c, lets look at the Makefile, though... Feb 12 16:22:03 .S.o: Feb 12 16:22:03 $(COMPILE) -DPIC -fPIC -c $< Feb 12 16:22:34 And COMPILE in the Makefile is defined as using $(CC)... Feb 12 16:22:35 # Needed for mips, hopefully doesn't affect other platforms Feb 12 16:23:04 Would it not instead call .S.lo: ? Feb 12 16:23:13 Mind you, it's still $(CC) Feb 12 16:23:40 Yes...it's a libtool archive presumably, and yes, still calling $(COMPILE), which brings us to the c compiler. Feb 12 16:24:25 It's actually a hacked rule for libtool/automake to treat the .S as a .c source for the purpose of building it. Feb 12 16:24:26 So anything done by gcc is "inline" even if in separated files? Feb 12 16:25:53 well, normally a .s file is the assembler generated output of a c source, so I am guessing they originally wrote a c function, used gcc to create an assembler source, and then hacked that as needed. Feb 12 16:26:30 which explains the special discussion in PORTING Feb 12 16:26:51 And why they commented out the original C code in it Feb 12 16:26:59 So I'd just change that to bx r0 in a patch, and expect it to work? Feb 12 16:27:32 Yes, it still uses the c pre-processor, so we can use the patch suggested in the porting guide directly Feb 12 16:28:09 OK. Now, this doesn't seem to be architecture-specific code. Does "bx r0" work for arbitrary architectures? Feb 12 16:28:36 JamieBennett: there? Feb 12 16:29:32 It is arm specific, each processor has it's own unique instruction set Feb 12 16:30:04 the most commonly encountered one is the x86 instruction set(s), which I think are rather feature poor, but that is another topic :) Feb 12 16:30:33 nice ... seems there is porting work going on ;) Feb 12 16:30:57 dyfet: one question. what happened to boost1.40 ... did i fail to sponsor that? Feb 12 16:31:01 dyfet: Ah, I see it now: "#if defined(__arm32__) || defined(__arm__)" : so this is just safe to patch away, right? Feb 12 16:31:13 (sorry if i already asked ... was busy with release team and preparations") Feb 12 16:31:18 asac: good question, did you fail to? :) Feb 12 16:31:32 dyfet: if you gave me a good debdiff then yes. do you have that still ;)? Feb 12 16:31:34 persia: yes, welcome to arm porting :) Feb 12 16:31:44 asac: let me look Feb 12 16:31:47 thanks Feb 12 16:32:06 asac: I also recall i did it slightly different in 1.41... Feb 12 16:32:12 right Feb 12 16:32:18 dyfet: the build system, right? Feb 12 16:32:33 yes...let me look at that quickly... Feb 12 16:33:39 asac: I also recall, it was not a clean patch, from something I broke when first experimenting with quilt... Feb 12 16:34:07 I could quickly redo it... Feb 12 16:40:16 dyfet: So, does http://paste.ubuntu.com/374832/ look right to you? Feb 12 16:41:19 Well...going back to the excellent arm porting wiki page https://wiki.ubuntu.com/ARM/Thumb2PortingHowto... Feb 12 16:41:49 It should be conditional on armv5 or later... Feb 12 16:41:55 Ah, I should be wrapping it in an ifdef Feb 12 16:41:57 * persia fixes Feb 12 16:43:06 well, it is the correct thing to do for our debian upstream, which is built armv4 Feb 12 16:44:02 It's QA maintained, so I'd be looking at fixing that next :) Feb 12 16:45:18 Does http://paste.ubuntu.com/374837/ look like the right contents of 02-thumb2-porting.patch ? Feb 12 16:46:21 yes Feb 12 16:47:16 Excellent. I'll push this then. Do you have any suggestions for a good candidate for my net attempt? Feb 12 16:47:32 Or maybe you could do one and explain along the way? Feb 12 16:48:03 I can shortly, I am quickly getting a patch ready for asac :) Feb 12 16:48:12 OK. No rush :) Feb 12 16:56:00 suihkulokki: Just to verify, is there any reason that one *wouldn't* want to apply something like http://paste.ubuntu.com/374837/ in Debian? Feb 12 17:01:57 asac, "mobile-lucid-arm-lightweightbrowser: decision pending" what's the current trend? Feb 12 17:03:01 fta, wait for google to commit some kind of release cycle Feb 12 17:03:23 else security team will block Feb 12 17:04:00 ogra, it's pretty clear as it is now Feb 12 17:04:24 you mean that they wont do releases ? Feb 12 17:04:33 they do Feb 12 17:04:34 linux,dev,5.0.307.5 Feb 12 17:04:34 linux,beta,5.0.307.7 Feb 12 17:04:34 linux,stable,0.0.0.0 Feb 12 17:04:48 beta just jumped today Feb 12 17:04:55 no stable yet Feb 12 17:04:59 right Feb 12 17:05:03 i think thats the prob Feb 12 17:05:47 but asac might know more, i'm just echoing what i heard in the release tema meeting 30min ago Feb 12 17:05:52 *team Feb 12 17:06:06 ok Feb 12 17:59:33 asac: http://pastebin.com/f4207b842 Feb 12 18:11:55 dyfet: So, what's the next package? Feb 12 18:13:09 persia: looks sensible, but preferrably apply via upstream Feb 12 18:13:41 suihkulokki: So I should't look to a QA upload, but instead send it upstream directly? Feb 12 18:15:26 oh, lwp is orphaned. just go for QA upload then. Feb 12 18:16:23 And I presume I'll also add the patch to the BTS, and then forward that upstream when wearing a QA hat? Feb 12 18:17:16 You can forward it wearing any hat your prefer, but yes :) Feb 12 18:17:50 heh, OK. Thanks for the guidance. Feb 12 18:20:08 hi guy Feb 12 18:20:09 s Feb 12 18:21:08 Hey Hoonse Feb 12 18:30:51 does anyone know how to setup wifi via the terminal? i think the network-manager hates me... and the vi editor hates me too... Feb 12 18:37:03 NCommander: haven't tried ooo on arm Feb 12 18:37:09 i didn't know it built Feb 12 18:37:23 * persia pokes dyfet again in hopes of more Thumb2 porting stuff Feb 12 18:37:23 could try if you want... Feb 12 18:37:45 armin76: Could you? Most of it builds, except this little pesky bit :) Feb 12 18:38:18 armin76: Works fine in Debian and in Jaunty, but we started having issues in karmic when the toolchain changed to support more modern CPUs. Feb 12 18:38:36 armin76: http://www.youtube.com/watch?v=J6Z__mepK-Y Feb 12 18:38:55 persia: no, its broken on Debian with gcc 4.4 Feb 12 18:39:53 NCommander: It is? Ugh. Feb 12 18:40:11 * persia has seen so many Debian demos that it seemed inevitable that it would keep working Feb 12 18:40:14 should i try with gcc-4.4 i guess? Feb 12 18:40:27 armin76: yes please Feb 12 18:40:40 armin76: it takes upwards of two days to build on an imx51 board though Feb 12 18:40:53 its okay, i have the efika doing nothing Feb 12 18:40:56 on thecus it takes a week =) Feb 12 18:41:09 and plenty of space Feb 12 18:41:12 On an NSLU, it would take a lifetime :-) Feb 12 18:50:40 persia: where did we leave off? Feb 12 18:51:35 dyfet: You were grabbing a package and I was going to follow along Feb 12 18:51:48 I was? okay, let me look at the list... Feb 12 18:53:16 Although it was done, and a patch was submitted, since I just updated that, lets look at boost for a minute... Feb 12 18:54:05 Could we look at a new one? As much as I'd like to learn, I'd rather be productive while learning :) Feb 12 18:54:13 okay Feb 12 18:55:22 pixman is listed as needs to be checked... Feb 12 18:56:13 its not clear if it has an issue or is simply suspected, lets take a look... Feb 12 18:59:16 whats up with pixman? Feb 12 18:59:37 armin76: it was on the https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList Feb 12 19:00:00 armin76: It's suspected of having assembly routines that may not be safe for context switching and internetworking Feb 12 19:00:53 ok :) Feb 12 19:01:13 it may take a bit longer, though...it's suspected, but not clearly identified Feb 12 19:01:23 armin76: Feel free to jump in if you'd like to help. I'm sure the patches could be interesting for some of your stuff as well (and we'd certainly appreciate them) Feb 12 19:01:49 i remember a gentoo user having issues with running non-neon kernel and latest pixman... Feb 12 19:02:14 well, i don't think i can't be of much help, but if somethings rings a bell i'll say it Feb 12 19:02:15 That's probably a different issue, unless they also compiled with -mthumb2 Feb 12 19:02:30 yeah, definitely Feb 12 19:02:44 but is something to keep in mind for dove Feb 12 19:02:47 armin76: Depends on your time of course, but dyfet seems to be an expert, and at least I'm learning mostly from scratch Feb 12 19:03:49 This one may not be a great pick, though, it will take a little time to see what specific issues it may have Feb 12 19:04:25 dyfet: The note says something about mov, so I've started with `grep -rn mov *` Feb 12 19:04:52 Yeah, but that is not a lot to go on :) Feb 12 19:05:35 I have a feeling that pixman/piman-cpu contains the bulk of the data for investigation. But thre's also pixman-arm-simd Feb 12 19:06:08 lets compare with https://wiki.ubuntu.com/ARM/Thumb2PortingHowto to see if anything stands out... Feb 12 19:06:11 Oh, and arm-neon, but are we using that? Feb 12 19:06:51 That is controlled by USE_ARM_NEON in the Makefile, from configure... Feb 12 19:07:31 There is also a --disable-arm-simd in configure and --disable-arm-neon... Feb 12 19:07:47 Let's look at the debian rules to see what is enabled... Feb 12 19:07:51 Which makes me think we mostly care about pixman-cpu Feb 12 19:08:18 No special --enable or --disable. Feb 12 19:08:30 nope... Feb 12 19:08:43 So that means enabled-by-default, right? Feb 12 19:09:42 No...there is configure tests... Feb 12 19:10:07 Let's look at the debian rules to see what is enabled...and a couple of try compile flags Feb 12 19:10:28 it might well enable neon build by default if gcc allows it Feb 12 19:11:13 persia: dyfet: ssvb may be interested in what you have to say wrt pixman Feb 12 19:11:24 he's the one who has been doing the arm stuff upstream Feb 12 19:12:20 armin76: we probably should ask him. I suggest, for expediancy, we punt on pixman for this session for now and pick another from the list Feb 12 19:12:33 haha Feb 12 19:12:51 well, lots of things that require time to look at :) Feb 12 19:13:06 dyfet: Works for me :) Feb 12 19:13:21 * persia likes simple examples to learn stuff that can then be applied easily. Feb 12 19:13:37 well, I am appearently not great at picking simple ones either :) Feb 12 19:14:27 How about parrot? At least that has a clear comment. Feb 12 19:14:34 hmm.... Feb 12 19:14:44 yes it does Feb 12 19:14:49 this should be very quick Feb 12 19:15:08 That's what I thought. I'm hoping you'll run through it and it will match my expectations. Feb 12 19:15:15 Then I can probably fix that class of stuff easily. Feb 12 19:15:22 okay :) Feb 12 19:15:25 (and I'll ask you about the next class if I run out) Feb 12 19:15:34 dyfet: if you could tell me what you think is wrong with pixman, that would be a great help Feb 12 19:16:57 dyfet: btw, what is your target hardware? if it is Coretex-A8 r1pX, it has a lot of thumb related problems which need workarounds Feb 12 19:16:58 * persia is happy to wait on other examples to let pixman be investigated Feb 12 19:17:18 ssvb: We're trying to be fairly generic, although ARMv7 and Thumb2 Feb 12 19:18:32 dyfet: look at the comment i posted on the boost1.40 bug ... i adjusted your debdiff a bit ... but now sponsoring Feb 12 19:18:44 just some nit Feb 12 19:18:54 I just want to say, if you are testing thumb/thumb2 code on a hardware which has problems (and no workarounds are applied), you are going to have problems for sure Feb 12 19:19:17 you may be just wasting time looking for bugs in software... Feb 12 19:20:00 ssvb: At this point, we're not really looking for bugs, but for assembly routines we believe to be unsafe with context swtiching and internetworking. Feb 12 19:20:21 Stuff like changing "mov pc, r0" to "bx r0" conditionally for ARMv5+ Feb 12 19:20:24 ssvb: we thought it might be a simple case example :) Feb 12 19:20:30 ah, this should be pretty easy Feb 12 19:21:02 * persia grabs the pixman code again, expecting to learn lots Feb 12 19:21:11 persia: speaking of which, parrot is an interesting special case. It emits assembler as part of it's jit... Feb 12 19:21:36 dyfet: Right. I'll unpick that one then :) Let's do pixman whilst we've ssvb around. Feb 12 19:22:31 okay Feb 12 19:22:34 ssvb: So, I checked before, and I think the majority of candidates for investigation are in pixman-cpu.c, pixman-arm-neon.c, andpixman-arm-simd.c Feb 12 19:23:39 yes... Feb 12 19:24:00 I may be missing something, but thumb interworking is only involved when functions are fully implemented in assembly Feb 12 19:24:15 this basically rules out practically all *.c sources Feb 12 19:24:28 Oh, I thought I saw some inline stuff in those. Feb 12 19:24:30 * persia checks again Feb 12 19:24:43 maybe with the exception of some really weird stuff Feb 12 19:25:20 Yeah, there's deinitely inline assembly in those three files. Feb 12 19:25:54 pixman-cpu seems to be only x86 code though, and appropriately "ifdef'd Feb 12 19:26:34 inline assembly can only have thumb interworking problems if it contains function calls, which almost never happens typically Feb 12 19:26:35 and even that code is limited to cpu detection Feb 12 19:26:59 ssvb: So you think pixman is safe? Feb 12 19:27:35 * persia doesn't see any mov pc lines, but isn't confident that this is enough to be sure Feb 12 19:27:56 It maybe is a false positive Feb 12 19:27:59 I'm not aware of any problems and actually did test it with thumb2 a bit Feb 12 19:28:37 but one can be never sure completely, that's why I was interested to know if you have spotted something :) Feb 12 19:28:43 Right then. I'm glad we did this, as it helps me understand how to decide *not* to patch things. Feb 12 19:29:30 ssvb: not specifically, but since it was on the high priority list, I wanted to make sure we looked at it Feb 12 19:31:15 the only problem I know is that pixman-arm-simd just does not compile for thumb and it is a bit ugly :/ Feb 12 19:31:47 ssvb: ok :)....that seems an apt description :) Feb 12 19:34:22 I have to check another bug for a few minutes Feb 12 19:35:00 I was busy editing the wiki and didn't watch this chat closely... Feb 12 19:35:03 If you want to pick another package in the interum, persia, I am not sure if any of the remaining high priority ones are good picks for training though Feb 12 19:35:33 dyfet: Sure. I'll try to pick one out. Feb 12 19:35:34 dmart: hi :) I saw the chart you added :) Feb 12 19:36:02 The call/return stuff was a bit of a braindump, so hopefully the summary helps a bit Feb 12 19:36:03 dmart: Main interesting things were that we got a fix for lwp, and determined that we didn't think pixman needed a patch. Feb 12 19:36:17 The offending lines we grepped in pixman were: Feb 12 19:36:26 ./pixman-0.16.2/pixman/pixman-arm-detect-win32.asm: mov pc,lr Feb 12 19:36:28 ./pixman-0.16.2/pixman/pixman-arm-detect-win32.asm: mov pc,lr Feb 12 19:37:01 These would need fixing if that file gets built... but "win32" rather suggests is doesn't apply to us. Feb 12 19:37:12 yes, it's windows specific code Feb 12 19:37:26 OK, if it's not build for Linux we don't have to worry about it. Feb 12 19:38:31 It's getting late here, so I will disappear in a minute... Feb 12 19:38:34 dyfet: How about xindy? Feb 12 19:38:40 dmart: Have a good evening. Feb 12 19:38:54 Feel free to add comments on the wiki if you'd like to see something clarified better! Feb 12 19:39:12 (or poke me next week) Feb 12 19:39:40 persia: the review list suggests its a simple issue... Feb 12 19:40:14 dyfet: Well, OK. Go do something hard then, and I'll see if I can do xindy :) Feb 12 19:40:55 well, okay :). I will follow along with what your doing though :) Feb 12 19:40:59 dyfet: How about newlib ? Feb 12 19:41:23 dyfet: I suspect that if I work on xindy and you work on newlib, you can share what you've done, and I can ask questions :) Feb 12 19:42:23 persia: we have nothing depending on newlib...but okay Feb 12 19:43:36 Oh, then I'm just lousy at picking :) You pick one. Feb 12 19:43:47 openssl? Feb 12 19:43:50 okay, but I have one other thing I need to look at first Feb 12 19:43:55 Sure. Feb 12 19:52:35 * persia grumbles at bundled sources : why not use modern clisp Feb 12 19:57:10 NCommander: going to mwc? Feb 12 20:04:26 unlikely ;) Feb 12 20:06:35 asac: going to mwc? Feb 12 20:07:12 wasnt on my radar :( Feb 12 20:07:19 and i am sick anyway Feb 12 20:08:04 ubot4: going to mwc? :D Feb 12 20:08:05 armin76: Error: I am only a bot, please don't think I'm intelligent :) Feb 12 20:12:59 ogra: i have a question about LtSP_CLIENT ... is that an upstream env? Feb 12 20:13:13 e.g. can we commit the applet not starting on LTSP_CLIENT patch upstream? Feb 12 20:13:16 (NM applet) Feb 12 20:30:31 persia: I can't figure out why kdebindings is waiting on okular, it should be installable Feb 12 20:30:50 * persia looks Feb 12 20:30:56 NCommander: install only, not build,right? Feb 12 20:31:06 persia: yeah, its built Feb 12 20:31:32 persia: doing sudo apt-get install libokularcore1 says it needs phonon Feb 12 20:31:48 doing sudo apt-get install libokularcore1 phonon asks if I wish to install packages :-) Feb 12 20:36:19 "E: Couldn't find package kdebindings" with just refreshed apt-cache Feb 12 20:36:26 What am I installing? Feb 12 20:37:10 persia: kdebindings is the source package Feb 12 20:37:30 persia: apt-get build-dep kdebindings :-) Feb 12 20:38:53 That's why I asked "install only, not build, right?" :p Feb 12 20:39:53 persia: huh? Feb 12 20:40:44 I was asking whether you seemed to be stuck on "install", meaning some sort of arch skew, or "build" meaning issues getitng the build-deps sorted. Feb 12 20:41:14 apt-get build-dep kdebindings works for me, with an up-to-date cache, although it will be another half-hour before it finishes installing all the build-deps. Feb 12 20:41:35 persia: right, it did in an installed system Feb 12 20:41:41 persia: clean chroot with main only, it didn't work Feb 12 20:41:53 Aha. I always forget to check that. Feb 12 20:42:07 persia: but everything seems to be in main Feb 12 20:44:23 * persia is writing a script to check, and getting sufficiently annoyed by sed to do it manually. Feb 12 20:57:21 persia: any luck? Feb 12 20:57:55 NCommander: I've stripped to main-only, and managed to replicate your symptom. I'm investigating now. Feb 12 21:02:11 persia: thanks Feb 12 21:03:34 Guest88140: Takes me a while though: I need to set up a mirror some day, or convince someone to mirror p.u.c domestically. Feb 12 21:05:11 argh Feb 12 21:05:39 is it normal that the internet on ubuntu on the beagleboard is really slow? i mean REEEEEALLY slow Feb 12 21:05:56 Hoonse: slow as in firefox, or slow as in using wget? Feb 12 21:07:07 slow that when a desktop pc downloads with 400kb/s the board loads with 1kb/s?!? by apt-get install... Feb 12 21:07:31 Hoonse: oh, apt-get on ARM uses a different server Feb 12 21:07:39 ports.ubuntu.com is in the UK and can sometimes really drag :-) Feb 12 21:07:57 NCommander: This would go faster if qemu supported syscall 335, if you're bored :) Feb 12 21:08:07 oh... i got really wiered trubble with setting up this god dammed wifi... Feb 12 21:08:19 i am almost crying =) Feb 12 21:09:27 loool 2.875 B/s i feel thrown back to the 56k times =) Feb 12 21:10:19 240B/S but this cant be normal!!!!! Feb 12 21:10:28 Hoonse: try another webite Feb 12 21:21:46 this cant be possible!!! the ftp UPLOAD to the board runs at the begining with 2,5 kb/s then a short time with 220kb/s and then it seems like it would freeze?!? why is my wifi on this board so buggy? Feb 12 21:32:27 NCommander: Looks like the schroot issue is related to some hang when building the documentation. Could you run a local build (probably overnight) to see if it ever completes or produces an error? Feb 12 21:32:58 * persia suspects the "solution" is to split the docs into an arch:all package Feb 12 21:33:05 Hoonse: wifi on ARM is virtually untested Feb 12 21:33:10 (under Ubuntu) Feb 12 21:33:21 that means? Feb 12 21:33:45 Hoonse: there may be latent bugs that haven't been found; that being said, there might be issues with the beagle wifi hardware AFAIK Feb 12 21:33:54 Hoonse: That I'm the biggest user, and I run jaunty. Feb 12 21:33:58 persia: I can only use the porters box, no clean chroots. The imx51 board I'm SSH'ed into is grinding away at openoffice for at least another day Feb 12 21:34:34 NCommander: Nevermind then. I'll run it next time I can leave my netwalker plugged in for long enough (as I have pbuilder working there). Feb 12 21:35:06 persia: I just got new imx51 hardware today, but all the stuff I need to set it up is back in Rochester :-) Feb 12 21:35:40 No worries. I'm just both impatient and wanting to take my hardware out and about in a couple hours :) Feb 12 21:37:05 persia: I look forward when I can do ARM porting on my laptop Feb 12 21:37:22 * NCommander might just buy a Dell netbook with one of those ARM chips and force Ubuntu ARM onto it if I could get the specs on the ARM SoC Feb 12 21:37:26 You can do some now: depends on the nature of the issue. Feb 12 21:38:02 But in this case, I'm dealing with a timing issue, which would benefit from real HW. Feb 12 21:38:15 (or at least it *looks* like a timing issue) Feb 12 21:38:46 But I think small servers are better than laptops for that sort of thing anyway, because one likes to suspend a laptop (otherwise I'd be building schroot now) Feb 12 21:39:45 asac: ping? Feb 12 21:39:49 er, wrong channel Feb 12 22:02:32 persia: any ideas on my dep issue? Feb 12 22:06:17 NCommander: Most recent message: "E: Failed to process build dependencies" Feb 12 22:06:26 This is after manually installing phonon and libokular1 Feb 12 22:06:35 Err, libokularcore1 Feb 12 22:09:31 NCommander: I'm running into unexpected mono-related crashes, so I think I can't track it easily. Feb 12 22:09:50 But I'll admit to not understanding it. Feb 12 22:18:40 persia: so do I ping next? Feb 12 22:20:29 NCommander: did you ping me somewhere else too? Feb 12 22:25:43 NCommander: Well, either give me time (I'm not at my best at this time of day unless I've only been awake for <5Ksec), or whine on kubuntu-devel and hope someone can sort it. Personally, I think the main limit here is the relative lack of people with hardware. Feb 12 22:28:00 persia: its not a huge rush thing, I'll look at it more later, but I was wondering who else might know strange resolver bugs Feb 12 22:29:25 mvo is probably the expert, but I'm not sure he has an arm device. Feb 12 22:29:55 But it's mostly a case of just trying different installation combinations, and seeing what doesn't work. **** ENDING LOGGING AT Sat Feb 13 02:59:58 2010