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