[09:47] <persia> Noisi: Hey.  Did you not get an answer about your mysqlclient question yesterday?
[09:49] <Noisi> only go to #sql , but i got no answer there
[09:50] <persia> Bother.
[09:50] <persia> Sorry I didn't answer you then: I ended up falling asleep.
[09:50] <persia> So my memory is that you had a cross-compile environment but you wanted to try binaries without needing to compile them, is that correct?
[09:54] <mikeul> ogra, it looks like you made all the necessary changes to RootfsFromScratch that we discussed yesterday.
[09:54] <ogra> mikeul, yes, sorry, i didnt want users to run into problems
[09:54] <mikeul> no problem, that makes sense.
[09:55] <mikeul> I'll just have to find another problem I guess.
[09:56] <persia> mikeul: What kind of problem do you like?
[09:57] <mikeul> I'm not really looking for problems, they usually find me.
[09:59] <persia> OK.  I usually have a reserve of issues available if you're looking for something :)
[10:00] <persia> Also, we're having a mini-sprint on Thumb2 porting in about an hour, if you'd like to participate.
[10:58] <asac> o/
[10:59] <ogra> hmm, all languages are gone from our images again
[10:59] <ogra> that wasnt the plan :/
[11:01] <ogra> * Languages: es xh pt de fr bn
[11:01] <ogra> * language-pack-${Languages} [i386 amd64 powerpc]
[11:01] <ogra> oh, sigh
[11:01] <dyfet> hmm...yea...
[11:02] <ogra> StevenK, ^^^ can you change that post freeze ?
[11:03] <asac> ok ... X is crashing badly on me :/
[11:03] <asac> on x86 luckily ;)
[11:03] <ogra> on armel or x86 ?
[11:04] <ogra> ah
[11:04] <ogra> in what way ?
[11:04] <asac> i hit ctrl+enter -> boom
[11:04] <asac> but only sometimes
[11:04] <ogra> weird
[11:04]  * asac upgrades and hopes there was a fix
[11:05] <dmart> Hi guys
[11:05] <ogra> hrm, a rootstock build of ubuntu-netbook hangs reliably in "unpacking iso-codes"
[11:05] <asac> hey dmart
[11:05]  * ogra wonders why that is
[11:05] <ogra> hi dmart
[11:06] <dmart> Hi there, sorry I'm late--- got sucked into a discussion about gdb
[11:06] <asac> ogra: did we figure why ooo is pulled in for us now?
[11:06] <ogra> all fixed and gone :)
[11:06] <asac> cooool
[11:06] <ogra> seems someone added language-support-$lang for all languages and all arches above
[11:07] <ogra> the -support packages pull in thesaurus and packages that in turn pull in oo.o
[11:07] <asac> hmm
[11:07] <lool> dmart: You mean you hanged in a discussion with gdb
[11:07] <ogra> usually we only have -pack and -pack-gnome
[11:07] <asac> lol
[11:08] <dmart> lool: ?
[11:08] <lool> dmart: hanging... gdb...
[11:08] <lool> oh well
[11:08] <dmart> lool: well, segfaulting
[11:08]  * lool tried to do silly jokes
[11:08] <lool> I suspect asac has pity for my jokes
[11:09]  * dmart was slow on the uptake
[11:09] <dmart> Anyone ready to take a look at https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList
[11:09] <dyfet> we can step you through it...
[11:10] <asac> so ...
[11:10] <asac> i think it would be time to add a column for the current status there
[11:10] <asac> or move all the fixed/invalid bugs to a separate table
[11:10] <lool> Just drop them?
[11:11] <lool> There's wiki history, we don't need to clutter the page for fixed bugs do we
[11:11] <asac> not sure
[11:11] <lool> dmart: Got blocked on the gcc atomic builtins qemu changes by their ppc maintainer who objects to using them in general, and for ppc in particular; need to redo the patch to only use these for arm/thumb    :-(
[11:12] <asac> having a page that shows what was done isnt that bad either
[11:12] <asac> are there instructions how to do that without gcc atomics? ... /me checks
[11:13] <dmart> I added some info on https://wiki.ubuntu.com/ARM/Thumb2PortingHowto
[11:14] <dmart> Still a bit high-level, but better than nothing (hopefully)
[11:14] <lool> << On ARMv7, there is a DMB instruction which performs this operation. There is also an MCR p15, ... operation which is backwards-compatible the earlier architecture versions.  >>
[11:14] <lool> Frankly, I much prefer getting the code to use atomic builtins in, even if only for arm/thumb in my case
[11:15] <dmart> If you use the atomics, you shouldn't need to use these low-level barriers.
[11:15] <dmart> ...which are obviously totally arch-specific and non-portable.
[11:15] <lool> I think it would help portability to use them by default, but apparently the ppc qemu maintainer prefers holding to comments from 2005 to judge of their usefulness
[11:15] <dmart> Did you understand why the qemu guys were resistant>?
[11:15] <lool> dmart: Yeah we're on the same line
[11:15] <lool> dmart: No; let me find the thred
[11:16] <lool> http://lists.gnu.org/archive/html/qemu-devel/2010-02/msg01142.html
[11:16] <dmart> Also, it's easier to write buggy atomics code than almost any other sort of code... so the KISS principle definitely applies ;)
[11:16] <lool> I checked with another qemu maintainer what he thought of it, and that's the person who suggested I should ask for benchmarks
[11:17] <lool> dmart: I'm also pretty sure the code is getting abused in the case of qemu
[11:17] <dmart> What are atomics used for in qemu anyway?
[11:17] <lool> Heck, I could have proposed a patch to use pthread mutxes, that would have been fun
[11:17] <lool> dmart: locks
[11:17] <lool> Which actually sucks
[11:17] <StevenK> ogra: That's a silly change, sigh
[11:18] <dmart> Does qemu use multithreading to emulate high-level processes, or something?
[11:18] <ogra> StevenK, yeah, agreed
[11:18] <lool> dmart: Hmm good question, it can emulate two CPUs though
[11:18] <lool> I suppose that's only possible with threading or multiple processes, but suspect they use something closer to threading to share memory
[11:19] <lool> (it actually uses multiple hosts CPUs when emulating multiple guests CPUs)
[11:19] <dmart> Right.  Well, you can certainly implement fast spinlocks using exclusives and barriers if it's really needed, but that's probably in issue to worry about when the spinlocks are found to be a bottleneck?
[11:19] <lool> dmart: Interestingly, the gcc atomics doc recommends not to use them for spinlocks
[11:20] <dmart> Really, I missed that
[11:20] <asac> to not use what? the gcc built ins
[11:20]  * dmart looks
[11:20] <asac> ?
[11:20] <lool> Hmm actually I can't find that reference any more
[11:20] <asac> ;)
[11:20] <dmart> Certainly you should use __sync_lock_* for spinlocks (and not the other funcs)
[11:21] <asac> lool: he seems to be fine to use those for thumb2 ... so whats the problem?
[11:21] <lool> dmart: Sorry, got confused by this comment http://sourceware.org/ml/libc-alpha/2005-06/msg00132.html
[11:21] <dmart> They (can) have reduced barriers which make them less of an overhead.
[11:22] <lool> dmart: ack, that's what I used
[11:22] <lool> dmart: There's no technical problem here, it's mostly politics
[11:22] <lool> the ppc maintainer didn't even say which part of the 2005 discussion he was referring to
[11:22] <asac> right.
[11:22] <asac> but do we care about ppc
[11:22] <lool> i.e. performance, should be in libc or whatever
[11:22] <asac> they seem to be fine if we submit that for arm
[11:22] <dmart> Not sure about the comment there--- certainly if you try to take a spinlock and find it's contended, then you can't just loop, because the kernel does not know to schedule the lock holder.
[11:22] <lool> asac: Yes, only choice I have for that bug
[11:23] <asac> i dont see that beging a problem
[11:23] <asac> if folks are happy with their current ppc solution etc.
[11:23] <dmart> You need to do a thread yield (and even that's inefficient--- the kernel still doesn't know what to schedule next)
[11:23] <asac> then let them keep that
[11:24] <dmart> If we can use the GCC atomics for arm as a first step, that's probably the best approach.  They can be optimised later if this looks like a significant benefit.
[11:24] <dmart> This is certainly no worse than arch-specific implementations in general.
[11:25] <lool> I wonder whether they would accept a configure flag to use them
[11:25] <dmart> #ifdef __arm__ ?
[11:26] <lool> I was thinking #ifdef ppc, use_gcc_atomics=no
[11:26] <lool> :-)
[11:26] <lool> Anyway, it's politics; I will eventually sort it out with upstream
[11:26] <dmart> Maybe.  The other arches might have a view on this though.
[11:26] <lool> there's no complexity here
[11:26] <dmart> ok
[11:26] <lool> I wanted to share the discussion with you because of the comments on gcc atomics
[11:26] <dmart> Sure, that's useful, thanks.
[11:27] <dmart> The main reason for emphasising the atomics is we want to quickly port to an implementation which works with v7 and Thumb-2, without everyone needing to understand the low-level details (which make my brain hurt a bit ;) )
[11:28] <dmart> But anything can be optimised in the future
[11:28] <dmart> ...
[11:29] <dmart> asac, all: Should we review through the status of items on https://wiki.ubuntu.com/ARM/Thumb2PackageReviewList ?
[11:29] <dmart> We should identify unfixed or blocked packages.
[11:29] <asac> yes
[11:29] <asac> so erlang
[11:30] <asac> is TODO
[11:30] <asac> and gmp still
[11:30] <asac> dyfet: ^^
[11:30] <asac> we already discussed gmp last time, so we dont need to do that
[11:30] <asac> not sure if we want to go through ffmpeg
[11:31] <asac> maybe that would make sense
[11:31] <persia> erlang has code-generation.  As does parrot.  That might be an interesting set of topics.
[11:31] <asac> libmad is another candidate
[11:31] <dmart> ffmpeg has optimised assembler, but that was already dealt with
[11:31] <asac> ffmpeg is done?
[11:31] <asac> oh right
[11:32] <asac> its in the last column
[11:32] <dmart> It would be good to note on this page whenever something is resolved
[11:32] <asac> 12:10 < asac> i think it would be time to add a column for the current status there
[11:32] <asac> 12:10 < asac> or move all the fixed/invalid bugs to a separate table
[11:33] <asac> so yes
[11:33] <dmart> Would it make sense to trawl quickly through the issues with bugs raised to classify them?
[11:33] <dmart> I can add a resolved column
[11:33] <asac> yes
[11:33] <asac> ok i can cancel my edit
[11:33] <dmart> Oh, ok
[11:33] <asac> either you say which packages are still not resolved
[11:33] <asac> or the other way around ;)
[11:33] <dmart> Shall we work through?  Probably won't take long.
[11:34] <asac> ok boost*
[11:34] <asac> is done
[11:34]  * asac updates the wiki if thats ok
[11:34] <dmart> ok, if you want
[11:34] <asac> cacao-source?
[11:34] <asac> thats still open
[11:34] <dmart> hang on
[11:34] <asac> bugwise
[11:34] <persia> cacao was recently removed in Debian.  Do we need it?
[11:34] <dmart>  boost1.38 is not resolved, what happened to that?
[11:35] <persia> Should have been dropped from the archive.
[11:35] <dmart> Also, the boost1.41 source package was not changed (or this isn't documented in the bug)
[11:35] <asac> dmart: its not in the archive anymore
[11:35] <asac> https://edge.launchpad.net/ubuntu/+source/boost1.41/+changelog
[11:35] <asac> boost is fixed
[11:36] <asac> except 1.38 ... but thats not in the archive anymore (too old)
[11:36] <dyfet> 38 was dropped, 40/41 was patched
[11:36] <dmart> Ah, ok, I didn't scroll far enough up the bug.
[11:36] <dmart> asac, can you note those?
[11:36] <asac> yes
[11:36] <asac> already done ;)
[11:37] <dmart> ok, thanks!
[11:37] <asac> djvulibre
[11:37] <asac> -> done (we checked that last week and evven added a safety belt)
[11:37] <asac> erlang
[11:37] <asac> -> not done
[11:37] <asac> evolution-data-server -> done
[11:38] <asac> ffmpeg resolved
[11:39] <asac> gcc-4.4 -> was never considered an issue, e.g. is probably right (
[11:39] <dmart> gcc-4.4 is under continuous maintenance, so we can mark that an not needing specific action here.
[11:39] <asac> ack
[11:39] <asac> glib2.0 -> done (atomics by dmart ;))
[11:39] <dmart> hmmm, I remember now
[11:40] <asac> gmp -> not yet done ... discussed last time; dyfet is on it and i was told he bumped prioritiy now
[11:40] <dyfet> there is an upstream issue with configure tests...
[11:40] <asac> for glib?
[11:40] <dyfet> gmp
[11:40] <asac> ah
[11:40] <dmart> politics or technical? ;)
[11:41] <dyfet> yeah...
[11:41] <dyfet> they want never to do try_compile tests, and use the tripplet to identify archs only...
[11:41] <asac> they are dumb ;)
[11:41] <dyfet> of course armv7/thumb2 is still "arm" as far as target arch's go...
[11:41] <asac> try_compile isnt that bad
[11:41] <asac> try_run is bad
[11:41] <dmart> Hmmm, that only works on x86 where the triplet identifes the arch version...
[11:41] <dyfet> a bit like lool's issue in qemu ;)
[11:42] <asac> i dont see that we can do it without try_compile, can we?
[11:43] <dmart> Just checking the GCC version number might be considered adequate.  But try_compile felt more reliable...
[11:43] <asac> i agree with dmart
[11:43] <dyfet> me too
[11:43] <asac> dmart: what version number is lower bound?
[11:43] <asac> 4.1.0?
[11:43] <dmart> I'm assuming lucid GCC is the bound (i.e. 4.4.3)
[11:44] <dmart> This is not quite true, but it's a reasonable approximation
[11:44] <asac> hmm
[11:44] <asac> anyway.
[11:44] <asac> i think we can use try_compile and just patch it
[11:44] <asac> push it to debian
[11:44] <asac> and let democracy decide at some point
[11:45] <asac> most likely other distros will pick it up too and then upstream is alone ;)
[11:45] <dmart> (by "reasonable approximation" I mean "safe approximation")
[11:45] <dyfet> okay
[11:45] <dmart> You might also run nm on libgcc.a.  But there's no guarantee the functions won't turn fully into builtins in the future...
[11:46] <asac> dyfet: lets just get the work done first and then care about politics
[11:46] <asac> also CC me on upstream discussion ;)
[11:46] <dyfet> well, we need to know in this case if we are thumb2 or not otherwise we break debian on armv4, etc...
[11:46] <dyfet> so try_compile seems the safest way by far
[11:46] <asac_> right
[11:46] <asac_> reconnect ;)
[11:47] <dmart> ok, so gmp is in progress
[11:47] <asac_> dyfet: so you have the patch?
[11:47] <dyfet> I did not do a try_compile patch, but I can do so quickly after the sprint
[11:47] <asac_> give it to me ... also forward me upstream discussion you had so far ... so i can poke them too ;)
[11:47] <asac_> ok
[11:47] <asac_> seems gmp will be fixed today
[11:48] <asac_> i think the next two are all not-for-us (klibc, libgc)
[11:48] <asac_> then we have libmad
[11:48] <asac_> which isnt fixed
[11:49] <asac_> and llvm
[11:49] <asac_> both not fixed
[11:49] <dmart> Who is handling klibc?
[11:49] <asac_> dmart: i thought it was toolchain/kernel folks
[11:50] <asac_> actually i thought there are no real issues there.
[11:50]  * asac_ grabs the filtered files
[11:51] <dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:    mov     pc, lr
[11:51] <dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:    mov     pc, lr
[11:51] <dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:    mov     pc, lr
[11:51] <dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/setjmp.S:1:  mov     pc, r3
[11:51] <dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S:     mov     pc, lr
[11:51] <dmart>  ./klibc-1.5.15/usr/klibc/arch/arm/vfork.S:     mov     pc, lr
[11:51] <dmart> I'd need to look at the source package to see whether that matters.
[11:52] <asac> yeah
[11:52] <asac> i think it matters
[11:53] <dmart> Probably we should raise a bug on this one.
[11:53] <asac> we should use BX lr
[11:53] <asac> unless i am mistaken ;)
[11:53] <asac> dmart: right
[11:54] <dmart> Yes... though I also see #ifndef __thumb__ ... #ifdef __thumb__ ; I don't know which one is actually built
[11:54] <dmart> (in setjmp.S)
[11:55] <asac> hmm
[11:55] <asac> bug 527720
[11:55] <ubot4> Launchpad bug 527720 in klibc (Ubuntu) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [Undecided,New] https://launchpad.net/bugs/527720
[11:57] <asac_> dmart: even for thumb it uses #else /* __thumb__ */
[11:57] <asac_> mov pc, lr
[11:57] <asac_> line 78
[11:58] <dmart> Yes, that's probably bad (actually, worse than using it in ARM)
[11:58] <asac_> feels like its safe to use bx lr there
[11:59] <dmart> Probably yes.  I'm wondering whether anyone builds this for Thumb-1
[11:59] <dmart> duh
[11:59] <dmart> that doesn't matter, ignore me ;)
[11:59] <asac_> mov     pc, r3
[11:59] <asac_> thats just bx r3?
[11:59] <asac_> dmart: ?
[12:00] <persia> Yes.
[12:00] <dmart> Providing r3 is derived from a return address
[12:00] <dmart> (I think that's the case here)
[12:00] <saeed> latest lucid-netbook-armel+dove doesn't aultomatically login, any idea which user&password should I use?
[12:00] <asac_> ok let me do the patch then
[12:00] <lool> saeed: ubuntu no password
[12:00] <persia> dmart: Why wouldn't bx r3 work for an arbitrary branch address?
[12:01] <saeed> lool: thanks
[12:01] <dmart> persia: generally, yes.  But if the address is detemined by some arithmetic or something the thumb bit (0) might not be set correctly
[12:02] <persia> Aha.  Thanks for the explanation.
[12:02] <asac_> http://launchpadlibrarian.net/39762158/klibc-thumb.patch
[12:02] <asac_> attached to bug 527720
[12:03] <ubot4> Launchpad bug 527720 in klibc (Ubuntu Lucid) (and 1 other project) "thumb2 porting issues identified: klibc uses mov.*pc (affects: 1)" [High,Triaged] https://launchpad.net/bugs/527720
[12:03] <dmart> We still need to check this code isn't built with -marm
[12:04]  * dmart greps for -marm
[12:04] <dmart> not found, probably OK
[12:04] <dmart> ...
[12:04] <asac_> dmart: the patch only touched ifdef __thumb__
[12:04] <dmart> Ah, actually there is a problem
[12:05] <asac_> so it should be safe even if we build with -marm ;)
[12:05] <asac_> dmart: what problem ?
[12:05] <dmart> The assembler always defaults to ARM
[12:05] <asac_> right
[12:05] <asac_> so we build with arm here ;)
[12:05] <asac_> but we could build with __thumb__ now
[12:06] <asac_> using this fix
[12:06] <dmart> This is preprocessed assembler, to __thumb__ will be defined (by the GCC defaults)
[12:06] <dmart> *so
[12:06] <dmart> So I think we're OK
[12:06] <dmart> Actually the functions will get assembled as Thumb because they both have the .thumb_func firective.
[12:06] <dmart> *directive
[12:07] <dmart> So this is probably fine.
[12:07] <asac> ok
[12:07] <asac> so ... i think we are set with this patch?
[12:07]  * asac thinks someone should try that out
[12:07] <dmart> vfork.S needs patching too
[12:08] <asac> dmart: i patched that ;)
[12:08] <asac> check the patch
[12:08] <asac> 13:02 < asac_> http://launchpadlibrarian.net/39762158/klibc-thumb.patch
[12:08] <asac> oh
[12:08] <asac> i even failed ;)
[12:09] <dmart> -er- I mean setjmp.S needs patching
[12:09] <asac> yes
[12:10] <asac> i just failed to produce a patch ;)
[12:10] <asac> new patch attached
[12:10] <asac> http://launchpadlibrarian.net/39762270/klibc-thumb.patch
[12:10] <dmart> Yes I think that looks OK.
[12:11] <persia> Um, not all the changes in vfork.S from the first patch appear in the second patch.
[12:11] <asac_> persia: ?
[12:11] <dmart> I think the second half of the first patch is a headerless non-unified diff of setjmp.S (or something)
[12:11] <asac_> persia: forget the first patch ... not sure why it was busted
[12:11] <asac_> right ... what dmart said
[12:12] <asac_> i am sure i had >> for the second part
[12:12] <asac_> but apparently i missed -u
[12:12]  * dmart is just making it up really
[12:12] <persia> Ah.
[12:12] <persia> Yes, that does look right (if confusing)
[12:13] <asac_> so lets continue (i marked it as "has patch" in table
[12:13] <asac_> libgc is next
[12:13] <asac_> that one is doko business
[12:13] <asac_> doko: fixed in 6.8-1.2ubuntu1
[12:14] <asac_> so now to libmad
[12:14] <asac_> what are the hits?
[12:14]  * asac_ checks filtered files
[12:15] <dmart> Looks like an attempt to address an inline data or jump table -- should be a simple fix
[12:15] <dmart>  ./libmad-0.15.1b/imdct_l_arm.S:    add     r2, pc, #(imdct36_long_karray-.-8)
[12:15]  * asac_ looks at porting page
[12:16] <asac_> so just adr r2, pc ?
[12:16] <asac_> hmm
[12:16] <asac_> nope
[12:16] <asac_> adr r2, imdct36_long_karray-.-8
[12:16] <asac_> err
[12:16] <asac_> adr r2, imdct36_long_karray
[12:16] <dmart> The trouble is that the pc is a bit unpredictable depending on the code alignment
[12:17] <persia> And this is likely to be an alignment issue, right?
[12:17] <dmart> Search the porting page for "getting the address of local data in the text section"
[12:17] <asac_> right
[12:17] <asac_> i think we already discussed that last week ... and i remembered that adr is the right way ;)
[12:18] <dmart> Looking at it though, I don't know what the data is doing in .text
[12:18] <dmart> Maybe it would be better to push it into .rodata
[12:18] <dmart> (it's not code)
[12:19] <asac_> #define K14  0x0cb19346
[12:19] <asac_> if thats used it means we have preprocessed assembler?
[12:19] <asac_> e.g. we can use #ifdef __thumb__ ?
[12:20] <dmart> This is really a cleanup change, so we probably don't even need that: we just want to switch from a less portable to a more portable way of addressing the data.
[12:21] <asac_> are we sure the data isnt modified?
[12:21] <dmart> I don't think it will be.  It's in .text which is not usually made writable
[12:22] <dmart> My guess is this is a table of precomputed data to speed up the imdct calculation.
[12:22] <asac_> right
[12:22] <dmart> The simplest option is to leave it where it is and use adr to address it.
[12:23] <asac_> heh ;)
[12:23] <asac_> would be interested in how to do it with rodata though too
[12:23] <asac_> anyway let me do the patch ... one moment
[12:24] <asac_> oh .. adr is #ifdef __thumb__ or > armv4t ?
[12:24] <asac_> dmart: ?
[12:24] <dmart> I suggest no #ifdef.  adr really is the same instruction (just via a pseudo op which makes sure it's really correct)
[12:25] <dmart> Oh, hang on a minute... this code is built as ARM (as default behaviour again)
[12:25] <dmart> I suggest to do the adr patch anyway; it's cleaner
[12:26] <asac_> yeah
[12:26] <dmart> Or if you want we could try building it in Thumb with
[12:26] <asac_> ok
[12:26] <asac_> one sec
[12:26] <dmart> #ifdef __thumb__
[12:26] <dmart> .code 16
[12:26] <dmart> #endif
[12:26] <asac_> .code 16?
[12:26] <dmart> (Or .thumb, it's a synonym)
[12:26] <asac_> ah
[12:26] <asac_> let me first do the adr patch
[12:27] <asac_> dmart: adr exists since a certain gcc/assembler version or what?
[12:27] <dmart> I'll work on the other, since I did not explain myself well...
[12:27] <asac_> http://pastebin.com/M6V3aqiW
[12:27] <asac_> that would be the libmad adr patch
[12:27] <asac_>  ;)
[12:28] <asac_> let me attach that to the bug unless you shout
[12:28] <dmart> asac_: I think adr has been there for a long time; unless someone is using really ancient tools it should work
[12:28] <asac_> yeah
[12:29] <asac_> cool
[12:29] <asac_> ok attached
[12:30] <asac_> next is llvm
[12:30]  * asac_ goes and greps
[12:30] <asac_> hmm. that seems to be more extensive ;)
[12:30] <dmart> There is an ongoing bug thread conversation for this one.  Basically, the jumping in/out of JITted is not interworking aware.
[12:30] <asac_> http://paste.ubuntu.com/383646/
[12:31] <asac_> :/
[12:31] <asac_> ok ... so is on the poirting page what to do for this kind of jump in/out from arm to thumb and vv.
[12:31] <asac_> ?
[12:32] <dmart> I think so; I pointed Xerxes Rånby at this, but I haven't had feedback yet.
[12:32] <dmart> Probably modifications are only needed in a few places, but it will take someone familiar with llvm to know where
[12:33] <asac_> hmm
[12:34] <dmart> Probably best to label this as under discussion for now.
[12:34] <dmart> Do we know the priority of llvm?  Does much depend on it?
[12:35] <asac_> so
[12:35] <asac_> needs investigation; potential code gen; doko: only used in openjdk-6-jre-zero when using shark
[12:35] <asac_> thats the comment
[12:35] <asac_> doko seems to think its ok
[12:35] <asac_> oh
[12:35] <asac_> well not sure if one can interpret that out of the comment
[12:36] <dmart> I think it's not used for openjdk-6 by default (some separate, Thumb EE based JIT is now contributed)
[12:36] <dmart> ...in openjdk-6
[12:36] <asac_> according to our table llvm has zero rdepends
[12:36] <asac_> (priority)
[12:38] <asac_> i think we can move on and come back to llvm later
[12:38] <asac_> mono ... i have the cherry pick staged on my disk
[12:39] <asac_> the one we discussed the other day ... besides that we found to be fine?
[12:39] <asac_> or still "needs more investigation" ?
[12:41] <dmart> I can't remember the discussion now... was there interworking stuff to fix (in addition to the atomics)?
[12:42] <asac> dmart: we had discussion in #mono ... with vargez ... from what i recall we found one more patch
[12:42] <asac> but besides from that the outcome was that it should be ok wrt to interworking
[12:42] <dmart> oh yeah, I'd forgotten that was about the same topic...  yes I agree
[12:42] <asac> i have that patch locally ... waiting for a3 freeze to be lifted
[12:43] <asac> that hd isnt wired up, so i can show it right now
[12:45] <dmart> OK, I'm happy to wait :)
[12:45] <dmart> Next package?
[12:46] <asac_> 15:43 < dmart> <vargaz>Ihttp://lists.ximian.com/pipermail/mono-patches/2010-February/166945.html
[12:46] <asac_> thats the patch ;)
[12:46] <asac_> yes
[12:46] <asac_> bug 514232
[12:46] <ubot4> Launchpad bug 514232 in newlib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514232
[12:46] <asac_> " investigate if its used - affected code is on places like crt0.S where it may not be a problem (dmart)"
[12:47]  * asac_ apt-get source newlib
[12:48] <asac_> dmart: why do you think its not used?
[12:48] <asac_> oh
[12:48] <asac_> seems that it uses ifdef _-thumb__
[12:48] <asac_> like:
[12:48] <asac_> #if defined(__thumb__) || defined(__thumb2__) blx   r3
[12:48] <asac_> #else mov     lr, pc mov     pc, r3
[12:48] <asac_> #endif
[12:48] <asac_> .LC24:
[12:48] <asac_> in ./libgloss/arm/crt0.S for example
[12:48] <asac_> so ./libgloss/arm/crt0.S definitly is fine ... checked all uses of mov
[12:49] <dmart> Yes, this package generally looks like Thumb-2 was thought about by someone.
[12:49] <asac_> then we have ./libgloss/arm/redboot-crt0.S: ... which probably is marm
[12:49] <asac_> but even that has thumb ifdefs
[12:49] <asac_> so ... cool. lets scratch it
[12:49]  * asac_ marks it invalid and drops comment in bug
[12:50] <dmart> OK
[12:50] <asac_> next is ocaml
[12:50] <asac_> bug 514235
[12:50] <ubot4> Launchpad bug 514235 in ocaml (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] https://launchpad.net/bugs/514235
[12:50] <asac_> i marked that as invalid already
[12:51] <asac_> so the assembly isnt used it seems
[12:51] <asac_> i think i checkd build system and also even added bogus code to the asembly that would trigger a build failure ... to no result
[12:51] <dmart> ok
[12:51] <ogra> did you note that a full new ocaml eneterd from debian yesterday ?
[12:51] <ogra> *entered
[12:51] <asac_> ogra: new upstream?
[12:52] <ogra> bug #526073
[12:52]  * ogra checks
[12:52] <ubot4> Launchpad bug 526073 in xstr (Ubuntu) (and 51 other projects) "[OCaml 3.11.2 transition][round 3/6] Please rebuild packages involved in OCaml transition (universe) (affects: 1)" [Undecided,Fix released] https://launchpad.net/bugs/526073
[12:52] <asac_> they do a transition during freeze?
[12:52] <asac_> thtas annoying
[12:53] <ogra> ah
[12:53] <ogra> its the same ocaml
[12:53] <asac_> ok ;)
[12:53] <ogra> just the depending packages
[12:53] <persia> Please check with sgnb about that.
[12:53] <ogra> sorry for the noise :)
[12:53] <persia> It's on hold right now.  james_w is expecting to do the next round of syncs once the freeze lifts.
[12:53] <asac_> ocaml-3.11.2$ find | xargs grep arm.S
[12:53] <asac_> ./asmrun/arm.S:/* $Id: arm.S 8823 2008-02-29 14:21:22Z doligez $ */
[12:54] <asac_> so there is no match for that arm.S file that has the code
[12:54] <asac_> not sure if i am missing something
[12:54] <ogra> oh, wait, i'm wrong
[12:54] <ogra> a new ocaml came in of feb 15th
[12:54] <ogra> silly version numbers
[12:54] <persia> And the transition is in process, and the transition team is working to make sure it builds on armel.
[12:54] <asac_> dmart: do you see any way that arm.S could be used in that project?
[12:54] <ogra> 3.11.1-2 to 3.11.2-1
[12:55] <asac_> persia: they do thumb2 porting ;)? i doubt that
[12:55] <asac_> most stuff doesnt fail to build
[12:55] <ogra> well, i think the new ocaml at least deserves a new grep run on the new package
[12:56] <asac_> i did now
[12:56] <persia> asac_: They are testing against qemu-arm-static and lool's qemu, so they should notice breakage as well.
[12:56] <asac_> also i did the last run last week
[12:56] <dmart> I guess so.  Probably there has been no change relevant to us...
[12:56] <ogra> i think its unlikely something changed but you never know
[12:56] <asac_> the grep above is from the current lucid
[12:56] <asac_> 13:53 < asac_> ocaml-3.11.2$ find | xargs grep arm.S
[12:56] <asac_> 13:53 < asac_> ./asmrun/arm.S:/* $Id: arm.S 8823 2008-02-29 14:21:22Z doligez $ */
[12:56] <asac_> ok ... moving on.
[12:56] <asac_> openssl
[12:56] <asac_> we didnt create a bug for that because:
[12:56] <asac_> "seems ok - only armv4 files affected - verify that those are not used for modern arm "
[12:57] <asac_> so we should double check that now to scratch it forever
[12:57]  * asac_ apt-get source openssl
[12:57] <asac_> we have a .pl file with assembly :) ...
[12:58] <asac_> ./openssl-0.9.8k/crypto/aes/asm/aes-armv4.pl:	mov	pc,lr			@ return
[12:58] <asac_> i think that file is used
[12:59] <asac_> there is no other arm file in aes/asm
[12:59]  * asac_ looks at build log
[12:59] <asac_> https://edge.launchpad.net/ubuntu/+source/openssl/0.9.8k-7ubuntu6/+build/1492868
[12:59] <asac_> http://launchpadlibrarian.net/38924017/buildlog_ubuntu-lucid-armel.openssl_0.9.8k-7ubuntu6_FULLYBUILT.txt.gz
[13:00] <asac_> hmm ... dont see that armv4 is used somewhere
[13:00] <asac_> http://paste.ubuntu.com/383659/
[13:00] <asac_> thats the grep
[13:01] <asac_> any idea how those .pl files are used in that build system?
[13:04] <asac_> next one would be pixman
[13:04] <asac_> bug 514237
[13:04] <ubot4> Launchpad bug 514237 in pixman (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Invalid] https://launchpad.net/bugs/514237
[13:04] <asac_> seems i marked it as invalid
[13:05] <asac_> "Checked this. Its a false positive. the mov isn't used in combination with pc etc. ... the only use of it is in a ifdef _MSC_VER block ... e.g. windows only."
[13:05] <asac_> so its a MS thing
[13:05] <asac_> dmart: ^^
[13:05] <asac_> ?
[13:05] <dmart> I think so; pixman is actively developed against Thumb-2 anyway I think.
[13:06] <asac_> postgresql-8.4 -> is fixed in bzr or even uploaded in archive already
[13:06] <asac_> was just atomics
[13:06] <asac_> qemu-kvm -> not sure ... bug 514252
[13:06] <ubot4> Launchpad bug 514252 in qemu-kvm (Ubuntu) "[arm] (might) need porting to thumb2 (affects: 1)" [Low,In progress] https://launchpad.net/bugs/514252
[13:06] <asac_> lool: ?
[13:06] <ogra> i think lool is on that ?
[13:06] <asac_> did you do the swp atomics?
[13:07] <asac_> or do you need help? or is this the issue we talked about above?
[13:07] <asac_> ok seems it has a patch
[13:07] <asac_> http://launchpadlibrarian.net/39067738/0001-Detect-and-use-GCC-atomic-builtins-for-locking.patch
[13:07] <asac_> lool: planning to upload that?
[13:07] <dmart> ^^ For openssl, some nasty hacks are used to enable compatibility with interworking, but the hacks look like they should work
[13:08] <asac_> dmart: do you understand the .pl files and how they are used?
[13:08] <asac_> lool: qemu-kvm just uses atomics for resetlock and testandset ?
[13:09] <asac_> or is the patch just a first revision?
[13:10] <persia> The .pl files for openssl are neither used in the build system nor installed int he package, and there seems to be a sufficiently comprehensive test suite that we'd notice an issue.
[13:10] <asac_> persia: we wont notice mov.*pc style things unless we are using smp afaiu
[13:11] <asac_> we could add some bogus syntax stuff and see if it causes some failure
[13:11] <persia> Ugh, so we'd have to run the test suite on SMP to know if it's an issue?
[13:11] <asac_> no ... we have to read the code ;)
[13:11] <asac_> and find out if its run
[13:11] <asac_> if its run its an issue ... if not, its not
[13:12] <dmart> The mov pc issues will show up independently of SMP
[13:12] <asac_> dmart: how will it show up?
[13:12] <dmart> crashes
[13:12] <dmart> The issue for SMP is the atomics
[13:12] <asac_> hmm ok
[13:12] <persia> Then I'm *really* confident that openssl is just fine.
[13:12] <asac_> isnt openssl testsuite run during build?
[13:12] <persia> That's a massive test suite.
[13:12] <asac_> yeah
[13:13] <asac_> so its not run? /me would think security would be damn hard about having that enabled
[13:13] <dmart> openssl looks OK to me (if a bit nasty)
[13:13] <asac_> dmart: where do you see the nasty bits? (just for education)
[13:13] <persia> asac_: It is run during build, and it succeeded in http://launchpadlibrarian.net/38924017/buildlog_ubuntu-lucid-armel.openssl_0.9.8k-7ubuntu6_FULLYBUILT.txt.gz for all four runs.
[13:13] <asac_> like you said there was interworking ... where do you spot that?
[13:13] <asac_> persia: nice
[13:13] <asac_> so yeah. openssl is off our list then
[13:14] <asac_> postgres is covered, qemu-kvm seems to be in progress (lets wait for lool)
[13:14] <asac_> next would be qt4-x11
[13:14] <asac_> is commented to have a webkit copy
[13:14] <asac_> webkit is invalid i found: bug 490371
[13:14] <ubot4> Launchpad bug 490371 in qt4-x11 (Ubuntu) "Atomic operations not safe for ARMv7,Thumb-2 and multicore (affects: 2)" [Medium,Triaged] https://launchpad.net/bugs/490371
[13:14] <asac_> bug 514255
[13:14] <ubot4> Launchpad bug 514255 in webkit (Ubuntu) "[arm] needs porting to thumb2 (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/514255
[13:14] <asac_> ok so webkit part is invalid (we can check that when we come to webkit)
[13:14] <asac_> and qt4-x11 needs atomics
[13:15] <asac_> though odd that it builds
[13:15] <asac_> NCommander: qt4-x11 builds?
[13:15] <asac_> NCommander: e.g. is bug 490371 a none issue?
[13:16] <asac_> "In debian/rules Set DEB_HOST_ARCH and DEB_HOST_ARCH_OS. Configure with "-arch armv6" option on ARM"
[13:16] <asac_> seems its built using armv6?
[13:16]  * asac_ waits for qt4-x11 sources to arrive
[13:16] <ogra> i think there was a bug cjwatson worked on
[13:16] <ogra> which he could only solve by switching to v6
[13:17] <asac_> from v5?
[13:17] <asac_> or v7?
[13:17] <ogra> from using the default (v7)
[13:17] <dmart> I think this uses LDREX/STREX, if building for ARMv6.  Originally the build system did not recognise ARMv7 and fell back to the older SWP code causing ftbfs
[13:18] <dmart> This was since bodged to lie to the build system about the architecture version so the v6 code is used, IIRC
[13:18] <asac_> oh
[13:18] <asac_> right
[13:18] <asac_> so we might want to fix the build system
[13:18] <asac_> or leave it as it is
[13:18] <asac_> NCommander: can you fix the buildsystem of qt4-x11 to understand v7?
[13:19] <NCommander> asac_: its on my TODO behind OOo
[13:19] <asac_> NCommander: arent you idle all the time witing for ooo to build?
[13:19] <NCommander> asac_: no, because i don't do full builds
[13:19] <asac_> NCommander: also i think that ooo is not higher priority than thumb2 ... its same priority
[13:19]  * NCommander just rebuilds the libraries I need, and wait at most 30 minutes for a full rebuild
[13:19] <ogra> qt4-x11 (4:4.6.0-1ubuntu2) lucid; urgency=low
[13:19] <ogra>   * Make libqt4-dev depend on libx11-dev
[13:19] <ogra>   * In debian/rules Set DEB_HOST_ARCH and DEB_HOST_ARCH_OS. Configure with "-arch armv6" option on ARM
[13:19] <ogra>  -- Jonathan Riddell < jriddell@ubuntu.com>   Tue, 08 Dec 2009 13:30:39 +0000
[13:19] <ogra> there we go
[13:19] <NCommander> asac_: I was informed otherwise by davidm
[13:20] <asac_> NCommander: but you wait 30 minutes ;)
[13:20] <dmart> asac_, NCommander: we should probably note down qt4-x11 for a SMP safety review
[13:20] <asac_> you can surely work on something ;)
[13:20] <asac_> anywway
[13:20] <asac_> dmart: wouldnt that show up in our greps?
[13:20]  * ogra goes to look for Riddell 
[13:21] <NCommander> dmart: if you have a few minutes, can you help me grok the C++ ABI?
[13:21]  * NCommander has found where OOo blows up
[13:21] <asac_> ok i have a call in 10 ... so i think we are over
[13:21] <asac_> we are down to four packages or so
[13:21] <dmart> Not really - this is about whether barriers are used correctly.  It's mainly an issue for packages which have their own hand-crafted atomics using the ARMv6+ primitives (LDREX/STREX) where SMP may not have been fully tested
[13:21] <asac_> out of which most are fixed
[13:21] <asac_> dmart: oh ok
[13:22] <asac_> so anything using ldrex etc. is subject to review
[13:22] <dmart> Ideally
[13:22] <asac_> but afaik we grepped for ldrex
[13:22] <dmart> Oh, yes.
[13:22] <dmart> I mean grep can't tell us if it's wrong; but it does identify what's worth looking at.
[13:23] <asac_> bug 451553
[13:23] <ubot4> Launchpad bug 451553 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "Lots of errors during install on dove (affects: 2) (dups: 1)" [Medium,Confirmed] https://launchpad.net/bugs/451553
[13:23] <asac_> dmart: right. thats what i meant
[13:23] <dmart> I forgot we grepped for that too
[13:24] <dmart> ok, I guess we are pretty much done
[13:24] <dmart> Unless people have questions
[13:25] <asac_> the rest is: thunderbird -> fixed
[13:25] <asac_> upx-ucl -> i think in invalidated that
[13:25] <asac_> bug 514254
[13:25] <ubot4> Launchpad bug 514254 in upx-ucl (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514254
[13:25] <asac_> oh no ;)
[13:25] <asac_> but webkit:
[13:25] <asac_> bug 514255
[13:25] <ubot4> Launchpad bug 514255 in webkit (Ubuntu) "[arm] needs porting to thumb2 (affects: 1)" [Undecided,Invalid] https://launchpad.net/bugs/514255
[13:25] <asac_> bug 514257
[13:25] <ubot4> Launchpad bug 514257 in xine-lib (Ubuntu Lucid) (and 1 other project) "[arm] needs porting to thumb2 (affects: 1)" [High,Triaged] https://launchpad.net/bugs/514257
[13:26] <asac_> so upx-ucl and xine-lib are still todo for main/important
[13:26] <asac_> and the qt4-x11 smp review
[13:26] <asac_> wiki page should be more or less up-to-date
[13:26] <asac_> ok me prepares for a call ;)
[13:26] <dmart> OK, thanks
[13:26] <NCommander> dmart: if your around in about an hour, I need to pick your brain on unwind tables, and the fun of ARM C++ exception handling :-)
[13:27] <asac_> thanks dmart for your time again
 Riddell, in qt4-x11 4:4.6.0-1ubuntu2 you set -arch armv6, do you remember the reason for that ?
 I did?
 where?
[13:27] <asac_> and everyone else ;)
 ogra: I do, it was because there was a specific armv6 implementation of some bits
[13:27] <ogra> * sabdfl hat die Verbindung getrennt (Read error: No route to host)
 the default was arm, and wasn't good for armv7
[13:27] <ogra> * sabdfl (~sabdfl@ubuntu/member/sabdfl) hat #ubuntu-devel betreten
[13:27] <asac_> bug 509006
[13:27] <dmart> NCommander: Not something I know too much about, but I'll see if I can draft in someone else
 do you remember if it was assembler ?
[13:27] <ubot4> Launchpad bug 509006 in linux-mvl-dove (Ubuntu) "[dove] hibernation failed to resume (affects: 1)" [High,Confirmed] https://launchpad.net/bugs/509006
 the armv6 code doesn't handle multicore, but is otherwise much better than what was there before
 yes
[13:27] <armin76> spam
[13:28] <asac_> ogra: ... cant you paste tsuch huge pastes in pastebin?
[13:28] <NCommander> dmart: that would be useful
[13:28] <asac_> bug 509006
[13:28] <asac_> bug 451635
[13:28] <ogra> asac_, ah, come on ... 10 lines ...
[13:28] <ubot4> Launchpad bug 451635 in alsa-driver (Ubuntu Karmic) (and 1 other project) "Sound not working on dove Y1 board (affects: 1)" [Medium,New] https://launchpad.net/bugs/451635
[13:28] <asac_> bug 452156
[13:28] <ubot4> Launchpad bug 452156 in linux-mvl-dove (Ubuntu) (and 1 other project) ""Write-error on swap-device" while installing Ubuntu (affects: 1)" [Undecided,New] https://launchpad.net/bugs/452156
[13:28] <ogra> but yes, i'll do in the future
[13:28] <asac_> bug 451553
[13:28] <ubot4> Launchpad bug 451553 in linux-mvl-dove (Ubuntu Karmic) (and 2 other projects) "Lots of errors during install on dove (affects: 2) (dups: 1)" [Medium,Confirmed] https://launchpad.net/bugs/451553
[13:28] <asac_> bug 527148
[13:28] <ubot4> Launchpad bug 527148 in linux-mvl-dove (Ubuntu) "dove fails to shutdown (affects: 2)" [Undecided,New] https://launchpad.net/bugs/527148
[13:28] <asac_> ok that were my 10 ;)
[13:31] <dmart> ogra: OK, I guess if "the armv6 code doesn't handle multicore" it needs looking at, so definitely add this to the SMP safety review table.
[13:31] <ogra> yeah
[13:33] <dmart> Thanks for checking
[13:35] <ogra> added
[13:36] <ogra> (if the wiki ever saves)
[13:36]  * dmart wonders why the wiki is so slow
[13:39] <lool> asac_: I think the gcc atomics patch is uploaded already??
[13:39] <lool> It still FTBFS but not due to thumb/asm
[13:39] <lool> dmart: Suggestions on how to fix the failure are actually welcome
[13:40] <lool> It's float comparisons and gcc logic
[13:40] <dmart> lool: which package is this?
[13:40] <lool> dmart: /build/buildd/qemu-kvm-0.12.2/fpu/softfloat-native.c:373: error: impossible constraint in 'asm'
[13:40] <lool> dmart: qemu-kvm
[13:41] <lool> Oh
[13:41] <lool> it's actually not th eplace I thought it was
[13:41] <lool> I was looking at the wrong function the first time
[13:42] <lool> dmart: http://paste.ubuntu.com/383679/
[13:42] <lool> dmart: probably if defined(__arm__) && !defined(__thumb__)?
[13:57] <lool> dmart: what's rndd/rnddm etc.?  I grepped the ARM asm reference card and the VFP one for "RN" and couldn't find it
[13:57] <lool> Might be some gas syntax
[13:57] <dmart> Hmmm, yes, I was just looking at that
[13:58] <dmart> I think these opcodes (and the "f" asm constraint) are probably related to the obsolete FPA architecture (which is what the netwinder fp emulator code in the kernel emulated)
[13:58] <dmart> This code won't work on any Ubuntu armel release
[14:00] <lool> can't find it in http://sourceware.org/binutils/docs/as/ARM-Opcodes.html#ARM-Opcodes
[14:00] <lool> dmart: Oh, so an older FPU?
[14:00] <dmart> Yes.  Well, an older FP architecture.  I'm not sure whether there was ever much silicon implementing it...
[14:01] <dmart> You can probably make GCC accept the code with -mfpu=fpa or something, but unless this code is being built to run inside qemu (and qemu emulates the instructions) I can't see how it's going to work...
[14:01] <lool> dmart: Bah, I'm wasting our time
[14:01] <lool> the asm was dropped upstream
[14:02] <dmart> ah... good thing too :)
[14:02] <lool> float64 float64_round_to_int( float64 a STATUS_PARAM )
[14:02] <lool> { return rint(a);
[14:02] <lool> }
[14:02] <lool> (can't they just errr call rint()?  :-)
[14:07] <ogra> probably something uses float64_round_to_int in the code ?
[14:07] <ogra> and they were lazy
[14:10] <persia> Or maybe they use this to force a cast somehow?
[14:10] <lool> Nah I just think it's historical
[14:10] <lool> rint is C99 just like qemu
[14:17] <dmart> NCommander: looks like our tools guys aren't available this afternoon.  Would 1500 UTC tomorrow be OK for you?  I can try and grab someone for then.
[14:18] <NCommander> dmart: that would work
[14:20] <dmart> ramana: Hi
[14:20] <dmart> NCommander: Looks like someone is available after all
[14:21] <dmart> Ramana has been working with some of the Ubuntu guys (doko etc.) on the tools
[14:21] <NCommander> hey ramana!
[14:27] <ramana> hi NCommander
[14:27] <NCommander> ramana: how goes your morning
[14:28] <ramana> Ncommander: Not too bad.. it's now afternoon where I'm sitting ... It's not raining and that's a plus :)
[14:29] <ramana> how goes yours ?
[14:29] <NCommander> ramana: early morning conference calls
[14:31] <ramana> NCommander: sounds like fun
[14:33] <NCommander> ramana: I'm dealing with crashing on ARM with OOo with modern toolchains, which is being caused by a direct call to __cxa_throw
[14:33] <ramana> ok
[14:35] <NCommander> ramana: it begins to unwind the stack, and then blows up with a phase2 failure
[14:35] <NCommander> __cxa_throw calls std::terminate
[14:36] <NCommander> ramana: I know there were unwind table changes between jaunty->karmic (gcc 4.3 to 4.4/glibc to eglibc)
[14:38] <ramana> do you know for what frame unwind_phase2 is in ?
[14:39] <NCommander> ramana: not sure how to get that
[14:40] <NCommander> I'm guessing is marked CANTUNWIND that shouldn't, or the inverse
[14:40] <NCommander> ramana: the stack gets completely trashed so the debugger is of limited help
[14:43] <ramana> can you get a backtrace from the point before it hits the throw to see what the frames are ?
[14:45] <NCommander> ramana: I can try. OOo does some very very strange and evil things that make debugging it extremely difficult
[14:46] <ramana> NCommander: The last time I tried looking at this was in September and I was stymied by not knowing enough about OOo.
[14:46] <NCommander> ramana: I think I need to do an entire debug build of the entire stack
[14:46] <NCommander> ramana: thats a multiday love affar :-/
[14:48] <ramana> yes that sounds prudent to have.
[14:48] <NCommander> ramana: unfortunately, since I don't have a small test case for this
[14:50] <ramana> NCommander : Is this the standard OOo in the lucid packages or is this in your PPA ?
[14:50] <NCommander> ramana: I'm working upstream; saner to build
[14:50] <ogra> the std oo.o in lucid uses a jaunty lib that works around that bug
[14:50] <ramana> ok
[14:51] <NCommander> (although sanity in this case is extremely relatively)
[14:51] <NCommander> *relative
[14:56] <ramana> NCommander: is there any place where I or dmart could have a look at your chroot or libraries ? We can try doing some disass on the libraries / binaries ?
[14:56] <NCommander> ramana: I'm just using standarding ubuntu jaunty, karmic, and lucid chroots
[14:56] <ramana> NCommander: and the OO build tree you might have ?
[14:57] <dmart> Presumably that's just apt-get source?
[14:57] <dmart> Or are you working on something not yet in the archive?
[14:57] <ramana> dmart: I think NCommander is working on upstream OOo
[14:57] <dmart> (the bug is old though...)
[15:04] <asac> NCommander: can you tell ramana how to build the package without the jaunty workaround so they can see the actual problem?
[15:04] <asac> ogra: you said doko made packages available for you
[15:04] <NCommander> asac_: that won't be useful without being able to debug it
[15:04] <asac> that have that issue ... did doko als opush source for that?
[15:04] <ogra> asac, yes, on jocote in his home
[15:04] <ogra> not sure about the source
[15:04] <NCommander> ramana: you can cause the issue by going into /usr/lib/ure/lib, and replacing libgcc3_uno.so with libgcc3_uno.so.karmic
[15:04] <asac> NCommander: well. they want a way to reproduce. if you have a better way, then just go for that
[15:05] <ogra> i always only got a bunch of .so's
[15:05] <asac> NCommander: reproduce from source that is
[15:05] <NCommander> asac_: you have to build OOo then from scratch
[15:05] <NCommander> http://wiki.services.openoffice.org/wiki/Documentation/Building_Guide/Building_on_Linux#ccache
[15:05] <lool> asac: IIRC, the two binaries (really built and from jaunty) are installed in the libdir
[15:06] <asac> NCommander: package sounds esaier ,)
[15:06] <asac> debuild -b
[15:06] <asac> wait
[15:06] <asac> wait
[15:06] <asac> ;)
[15:06] <lool> asac: So the current builds of oo.o ship the borken binary in a different path
[15:06] <NCommander> asac_: that won't work because it won't build OOo with debugging
[15:06] <asac> fine if you can reproduce with upstream instrcutions
[16:12]  * ogra kicks and punches qemu so it has dents and wrinkles 
[16:12] <ogra> i dont love you anymore you darn thing !!!
[16:13]  * ogra goes into a corner and sulks
[17:29] <alecrim> i'm with some problem to bootup a minimal ubuntu image with N810. I freezes as you can see here http://pastebin.com/41gRjZuF
[17:29] <alecrim> s/I/it/g
[17:30] <Stskeeps> jaunty?
[17:30] <Stskeeps> out of curiousity, got serial console
[17:30] <Stskeeps> ?
[17:30] <Stskeeps> and you are possibly running into the watchdog
[17:31] <alecrim> Stskeeps, I generated rootfs using this procedure : sudo rootstock --fqdn n810 --login ubuntu --password ubuntu --imagesize 500M
[17:31] <Stskeeps> ok, so lucid?
[17:31] <alecrim> Stskeeps, karmic
[17:32] <Stskeeps> mmk
[17:32] <Stskeeps> and .33 is quite experimental there
[17:33] <alecrim> Stskeeps, maybe the boot finished, but it does not show the serial. Old versions of ubuntu contain a /etc/inittab that I could force a login by serial, but not this one.
[17:33] <Stskeeps> ah
[17:33] <alecrim> Stskeeps, any idea?
[17:33] <Stskeeps> check event.d? should be tty*
[17:34] <alecrim> Stskeeps, thanks! I'll check it. I'll try lucid version, instead of karmic next time. let me see if I can get console
[17:35] <Stskeeps> no, lucid is armv7
[17:35] <Stskeeps> will not work on n810
[17:37] <alecrim> Stskeeps, I didn't know :(
[18:05] <NCommander> ramana: I've tied three babbage boards and one dove board into the OOo build
[18:06] <NCommander> Which shoul dget drastically cut build times down
[18:06] <NCommander> ^- armin76 :-)
[18:08] <ramana> nice :)
[18:10] <NCommander> ramana: the issue is I'm still not sure I'm going to get a proper backtrace
[18:10] <NCommander> ramana: the UNO call pulls CXX exceptions across multiple threads/processors/evil
[18:11] <NCommander> So even having a proper backtrace before the throw might not help
[18:11] <NCommander> And I'm not sure stepping into the _Unwind_* will give me anything I'm going to be able ot grok
[18:11] <ramana> joy
[18:11] <NCommander> (although I'll prepare to do a debug build of libgcc)
[18:14] <NCommander> ramana: is there a good way to debug the _Unwind_* functions and friends?
[18:15] <alecrim> Stskeeps, it's working. http://paste.ubuntu.com/383843/
[18:15] <alecrim> Stskeeps, actually /etc/init/ttyS2.conf is the correct place
[18:15] <Stskeeps> close enough
[18:15]  * DanaG wonders how much power it would take to get a mere Radeon 7500 sort of horsepower in an ARM.
[18:15] <DanaG> Specifically, for the sake of compiz.
[18:16] <Stskeeps> alecrim: does your lcd work?
[18:17] <alecrim> Stskeeps, it's a basic image using linux-omap latest version(2.6.33). I got serial using a special HW from Nokia
[18:18] <Stskeeps> ah, good
[18:18]  * alecrim is a privileged person 
[18:18] <alecrim> hehe
[18:18] <Stskeeps> yeah, i have one too :P
[18:19] <ramana> NCommander: I've never personally done this but I can dig around.
[18:20] <NCommander> ramana: that would help. Google hasn't told me a lot of phase2 unwinder failures except they exist
[18:20] <alecrim> Stskeeps,  I'm gonne work to get version 2.6.33 fully working like 2.6.29 version (http://franciscoalecrim.com/blog/2010/02/05/preparing-mamona-03-sync-with-openembedded-alpha/)
[18:21] <Stskeeps> cool :) even with wifi and dsp?
[18:22] <Stskeeps> i will bookmark
[18:23] <Stskeeps> 2.6.33 on n8x0 would be cool
[18:23] <Stskeeps> you saw the release of MBX 3d drivers too?
[18:23] <Stskeeps> gpl kernel driver
[18:24] <DanaG> MBX?
[18:24] <Stskeeps> omap2 3d accelerator
[18:26] <armin76> NCommander: cheater
[18:26] <NCommander> hehe
[18:26] <Stskeeps> alecrim: you have git tree for kernel somewhere?
[18:26] <Stskeeps> for your patches
[18:30] <NCommander> armin76: there is somethng for being able to simply throw more hardware at a problem
[18:32] <DanaG> what I have is the beagleboard.
[18:33] <ssvb> alecrim: there is user luke-jr on #maemo and #gentoo-embedded channels and he tried to do something with the latest kernels on N810 too (at least he was the last to update http://elinux.org/N800 page)
[18:35]  * armin76 prefers to throw NCommander at the problem and keep the hardware
[18:52] <alecrim> Stskeeps, linux-omap tree. I sent patches with corrections a few weeks ago.
[18:53] <Stskeeps> k
[18:59]  * NCommander sighs
[18:59] <NCommander> trying to build OOo from source is like trying to drive in reverse on I-90 from Boston to Seattle
[19:01] <armin76> thats how is it on arm :)
[19:01] <armin76> you should be glad you don't have to work with a marvell orion and the like
[19:29] <Martyn> *ugh*
[19:29] <Martyn> No, building oOo is rally a pain in the ass
[19:30] <Martyn> I'm still trying to build various MPI applications and libraries for our platform
[19:30] <Martyn> and it's NOT fun
[19:30] <Martyn> Plus I still have no work from Pegatron how the heck I can restore the image on their i.mx51 whitebox ( similar to the genesi box )
[19:32] <DanaG> Pegatron as in split-off-from-ASUS?
[19:32] <DanaG> Pegatron sounds like an el-cheapo brand... it's a bad choice of name, in my opinion.
[19:32] <ojn> Martyn: just boot from external SD card. $20 of hardware saves you how many hours of work?
[19:32] <Martyn> ojn : It's not booting
[19:33] <Martyn> ojn : And I have no debug cable so I can't change the configuration of the u-boot
[19:33] <ojn> Martyn: if you change the switches it'll load u-boot from SD
[19:33] <Martyn> ah!  That's new info
[19:33] <Martyn> 0001?
[19:33] <ojn> Can't remember and I'm not in Austin this week
[19:33] <Martyn> no worries
[19:33] <ojn> My offer of borrowing the debug card also holds, but I guess it's more fun to fumble in the dark. :)
[19:35] <Martyn> I forgot you were in the same city as me :)
[19:35] <Martyn> When you're back, ping me
[19:37] <armin76> ojn: it is!
[19:44] <NCommander> Martyn: well, at least I managed to isolate the crash
[19:44] <NCommander> Fixing it still going to be a real trick
[19:44] <NCommander> Martyn: try using ooo-build, I think it will make it easier
[20:24] <Chocobo> Do any of you know of a good tutorial for interworking ARM and THUMB code?  For example... if I have a bunch of C code I want to compile in ARM and a small ASM routine I want in ASM...  what I need for compile flags
[20:33] <lool> Chocobo: You can get the actual architecture reference manuals from arm.com, if you register and accept the license
[21:01] <ogra> lool, no go with rootstock :( ... installing an ubuntu-netbook task makes qemu hang in iso-codes ... just installing iso-codes works fine though
[21:01]  * ogra wasted the whole day on it and is out of ideas
[21:07] <|nfecteD> qemu is whacky
[21:07] <|nfecteD> locked up here too when i gave it too much to chew on
[21:07] <ogra> it wasnt for the last two releases
[21:09] <|nfecteD> anyway... got it to build my rootfs when i removed lxde and gde from the seed
[21:09] <ogra> right, minimal isnt a problem
[21:09] <|nfecteD> mmhmm
[21:09] <|nfecteD> not that the damn thing wants to boot on my beagleboard
[21:09] <|nfecteD> init: plymouth main process (625) terminated with status 71
[21:09] <|nfecteD> and such
[21:09] <|nfecteD> yay
[21:12] <|nfecteD> guess i'll try another kernel just for hell of it
[23:02] <asac> dyfet: hey
[23:02] <asac> dyfet: so you wanted to discuss mono ;)?
[23:05]  * persia notes that the easiest way to get a high-end GFX card on armel is to find hardware with PCIe slots.
[23:06] <dyfet> yea, I see several different issues
[23:06]  * persia also notes that "Pegatron is a cheap brand" is somewhat tricky to parse, as Pegatron is one of only 5-6 companies that build 96% of laptops shipped worldwide and not the one with the least market share
[23:15] <asac> dyfet: so lets talk ;)
[23:16] <asac> dyfet: where would you start? i thought looking at the failed test cases and then understanding why the fail might be a good way to start
[23:17] <dyfet> I was not aware of the status of that.  But I am also concerned what does it currently block building
[23:17] <asac> dyfet: i dont think it blocks anything from building
[23:17] <asac> only problem is that the runtime behaviour is borked
[23:17] <asac> which makes good chunk of the archive unreliable to use ... which is bad ;)
[23:17] <asac> luckily mono hasn't spread out that muc in the archive, but still there are apps we would like to have working ;)
[23:26] <dyfet> out of curiosity, have the test cases also failed in qemu arm build?
[23:28] <asac> havent tried to build it there yet
[23:29] <dyfet> because it might offer an environment for testing where people don't have hardware, if it reproduces the behavior
[23:35] <dyfet> while pulling down latest which tests do fail?