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