[07:09] <therealgalen> anybody use cavium ARM CPUs? or know of products using them?
[07:25] <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
[09:01] <NCommander> suihkulokki (and anyone else around): do you know much about GCC? I might have a lead on the OOo breakage
[09:02] <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]
[13:41] <armin76> dmart: get me a mwc2010 pass!
[13:45] <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:50] <lool> dmart: armin76 is our uber-excited gentoo developper trying to get as much hardware and invites as he can   ;-)
[13:51] <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:52] <lool> http://armin762.wordpress.com/about/
[13:52] <lool> wont tell you much more though
[13:53] <dmart> thanks
[13:57] <armin76> :D
[13:57] <armin76> dmart: nah, thats okay
[13:58] <armin76> dmart: just remember that i'm better than lool!
[13:58] <dmart> sorry, we hadn't been introduced
[14:02] <persia> armin76: Are you still working with the EfiKa MX?  How stable do you find that?
[14:03] <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:04] <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:05] <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:06] <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:07] <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:08] <dmart> armin76: can you cat /proc/cpuinfo?
[14:08] <dmart> There's a "Revision" line
[14:09] <armin76>  http://dpaste.com/157892/
[14:09] <armin76> http://dev.gentoo.org/~armin76/arm/efikamx/v3boot.log <- bootlog
[14:09] <dmart> 2.5
[15:42] <asac> ogra: any more work item to scratch for rootstock? ;)
[15:51] <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:52] <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:53] <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:54] <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:57] <persia> Not in great detail.
[16:01] <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:04] <dyfet> Let me look at that one...hold on...
[16:05] <persia> ./src/process.S:738:	mov	pc, r0
[16:06] <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:07] <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:08] <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:09] <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:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:18] <persia> Is this inline?  It's in a .S file.
[16:19] <persia> I thought that meant it was an external function.
[16:20] <dyfet> It is still being processed in c, lets look at the Makefile, though...
[16:22] <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:23] <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:24] <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:25] <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:26] <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:27] <dyfet> Yes, it still uses the c pre-processor, so we can use the patch suggested in the porting guide directly
[16:28] <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:29] <dyfet> It is arm specific, each processor has it's own unique instruction set
[16:30] <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:31] <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:32] <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:33] <dyfet> asac: I also recall, it was not a clean patch, from something I broke when first experimenting with quilt...
[16:34] <dyfet> I could quickly redo it...
[16:40] <persia> dyfet: So, does http://paste.ubuntu.com/374832/ look right to you?
[16:41] <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:43] <dyfet> well, it is the correct thing to do for our debian upstream, which is built armv4
[16:44] <persia> It's QA maintained, so I'd be looking at fixing that next :)
[16:45] <persia> Does http://paste.ubuntu.com/374837/ look like the right contents of 02-thumb2-porting.patch ?
[16:46] <dyfet> yes
[16:47] <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:48] <dyfet> I can shortly, I am quickly getting a patch ready for asac :)
[16:48] <persia> OK.  No rush :)
[16:56] <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?
[17:01] <fta> asac, "mobile-lucid-arm-lightweightbrowser: decision pending"  what's the current trend?
[17:03] <ogra> fta, wait for google to commit some kind of release cycle
[17:03] <ogra> else security team will block
[17:04] <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:05] <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:06] <fta> ok
[17:59] <dyfet> asac: http://pastebin.com/f4207b842
[18:11] <persia> dyfet: So, what's the next package?
[18:13] <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:15] <suihkulokki> oh, lwp is orphaned. just go for QA upload then.
[18:16] <persia> And I presume I'll also add the patch to the BTS, and then forward that upstream when wearing a QA hat?
[18:17] <suihkulokki> You can forward it wearing any hat your prefer, but yes :)
[18:17] <persia> heh, OK.  Thanks for the guidance.
[18:20] <Hoonse> hi guy
[18:20] <Hoonse> s
[18:21] <persia> Hey Hoonse
[18:30] <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:37] <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:38] <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:39] <persia> NCommander: It is?  Ugh.
[18:40]  * 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:41] <armin76> and plenty of space
[18:41] <NCommander> On an NSLU, it would take a lifetime :-)
[18:50] <dyfet> persia: where did we leave off?
[18:51] <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:53] <dyfet> Although it was done, and a patch was submitted, since I just updated that, lets look at boost for a minute...
[18:54] <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:55] <dyfet> pixman is listed as needs to be checked...
[18:56] <dyfet> its not clear if it has an issue or is simply suspected, lets take a look...
[18:59] <armin76> whats up with pixman?
[18:59] <dyfet> armin76: it was on the https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
[19:00] <persia> armin76: It's suspected of having assembly routines that may not be safe for context switching and internetworking
[19:00] <armin76> ok :)
[19:01] <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:02] <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:03] <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:04] <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:05] <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:06] <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:07] <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:08] <persia> No special --enable or --disable.
[19:08] <dyfet> nope...
[19:08] <persia> So that means enabled-by-default, right?
[19:09] <dyfet> No...there is configure tests...
[19:10] <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:11] <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:12] <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:13] <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:14] <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:15] <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:16] <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:17] <persia> ssvb: We're trying to be fairly generic, although ARMv7 and Thumb2
[19:18] <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:19] <ssvb> you may be just wasting time looking for bugs in software...
[19:20] <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:21]  * 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:22] <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:23] <dyfet> yes...
[19:24] <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:25] <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:26] <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:27]  * 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:28] <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:29] <dyfet> ssvb: not specifically, but since it was on the high priority list, I wanted to make sure we looked at it
[19:31] <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:34] <dyfet> I have to check another bug for a few minutes
[19:35] <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:36] <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:37] <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:38] <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:39] <dmart> (or poke me next week)
[19:39] <dyfet> persia: the review list suggests its a simple issue...
[19:40] <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:41] <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:42] <dyfet> persia: we have nothing depending on newlib...but okay
[19:43] <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:52]  * persia grumbles at bundled sources : why not use modern clisp
[19:57] <armin76> NCommander: going to mwc?
[20:04] <asac> unlikely ;)
[20:06] <armin76> asac: going to mwc?
[20:07] <asac> wasnt on my radar :(
[20:07] <asac> and i am sick anyway
[20:08] <armin76> ubot4: going to mwc? :D
[20:08] <ubot4> armin76: Error: I am only a bot, please don't think I'm intelligent :)
[20:12] <asac> ogra: i have a question about LtSP_CLIENT ... is that an upstream env?
[20:13] <asac> e.g. can we commit the applet not starting on LTSP_CLIENT patch upstream?
[20:13] <asac> (NM applet)
[20:30] <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:31] <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:36] <persia> "E: Couldn't find package kdebindings" with just refreshed apt-cache
[20:36] <persia> What am I installing?
[20:37] <NCommander> persia: kdebindings is the source package
[20:37] <NCommander> persia: apt-get build-dep kdebindings :-)
[20:38] <persia> That's why I asked "install only, not build, right?" :p
[20:39] <NCommander> persia: huh?
[20:40] <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:41] <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:42] <NCommander> 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] <NCommander_> persia: any luck?
[20:57] <persia> NCommander: I've stripped to main-only, and managed to replicate your symptom.  I'm investigating now.
[21:02] <Guest88140> persia: thanks
[21:03] <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:05] <Guest88140> argh
[21:05] <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:07] <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:08] <Hoonse> oh... i got really wiered trubble with setting up this god dammed wifi...
[21:08] <Hoonse> i am almost crying =)
[21:09] <Hoonse> loool 2.875 B/s i feel thrown back to the 56k times =)
[21:10] <Hoonse> 240B/S but this cant be normal!!!!!
[21:10] <NCommander> Hoonse: try another webite
[21:21] <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:32] <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:33] <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:34] <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:35] <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:37] <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:38] <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:39] <NCommander> asac: ping?
[21:39] <NCommander> er, wrong channel
[22:02] <NCommander> persia: any ideas on my dep issue?
[22:06] <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:09] <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:18] <NCommander> persia: so do I ping next?
[22:20] <asac> NCommander: did you ping me somewhere else too?
[22:25] <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:28] <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:29] <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.