[00:08] <fta> my netbook is usable again! at last
[00:09] <BUGabundo> YAY
[00:10] <fta> same problem as for audio (wrong perms) but with the video card :P
[00:10] <fta> udev-extras was missing from UNR
[00:12] <fta> http://www.itrmanager.com/articles/92695/internet-acces-mobile-continue-gagner-terrain.html
[00:12] <fta> 0.4%
[00:13] <fta> d'oh! (firefox-3.6:9299): Gdk-WARNING **: XID collision, trouble ahead
[00:19] <BUGabundo> eeh
[00:19] <BUGabundo> I know
[00:19] <BUGabundo> I told you about those
[00:19] <BUGabundo> when I loose keyboard
[00:26] <asac> hmm. libxcb bug?
[00:26] <asac> (collision?)
[00:29] <asac> Add diagnostics for XID collisions
[00:29] <asac> This should help with diagnosing crashes caused by over-eager XID
[00:29] <asac> reuse in Xlib, see bug 581526.
[00:29] <asac> gnome bug 581526
[00:31] <asac> mozilla bug 467744
[00:33] <asac> http://git.gnome.org/cgit/gtk+/commit/?id=339298b638ae76c546717f2136970b93438295a9
[01:02] <fta> it's when hovering flash
[01:02] <fta> menus
[01:03] <BUGabundo> not for me
[01:03] <BUGabundo> but then again, I haven't tested it much
[01:03] <fta> in the url i pasted above
[01:07] <asac> yeah. can happen randomly
[01:07] <asac> whever xids are created for windows
[02:58]  * BUGabundo $ bed ; echo command not found. please try apt-get install sleepdisorder 
[09:14] <asac> hi
[09:47] <asac>  Launchpad will be going offline for maintenance in 14 minutes.
[09:47] <asac> ;)
[12:31] <asac> fta: ffox rc3 build2
[12:46] <asac> !info xulrunner
[13:15] <asac> gwibber from karmic crashes
[13:52]  * asac lunch
[14:14] <asac> transition started https://edge.launchpad.net/~mozillateam/+archive/ffox35
[14:14] <asac> now lunch
[14:23] <fta2> grr
[14:23] <fta2> [181607.641134] scim-bridge[21407]: segfault at 10 ip 00007f5413f949c6 sp 00007fff810e7e18 error 4 in libscim-1.0.so.8.2.3[7f5413f27000+d6000]
[14:23] <fta2> [182087.850012] evolution[32523]: segfault at 71233c20 ip 00007f9392f14e59 sp 00007fffcbbde6d0 error 4 in libgtk-x11-2.0.so.0.1702.0[7f9392e5f000+43e000]
[14:23] <fta2> [182719.297984] evolution[2317] general protection ip:7f6a8159d335 sp:7fff7ed8a710 error:0 in libc-2.9.so[7f6a81523000+168000]
[14:24] <fta2> http://paste.ubuntu.com/202881/
[15:09] <psyke83> hi folks, the art team are planning on shipping an incremental update to the Human theme in Karmic, but the use of a non-zero trough border in the Murrine engine seems to be causing a problem. Can someone with a free minute take a look at the report? https://bugs.launchpad.net/libgtk/+bug/327863
[15:10] <psyke83> I've tested the latest 3.5rc2 build in the repository and the issue still exists. No other applications exhibit problems like this, so it's most likely a xulrunner/firefox issue
[15:59] <asac> psyke83: let me check
[16:01] <psyke83> asac: thanks. The theme update isn't in the repository yet, I can give you a link to a tarball (installable via gnome-appearances-properties) if you wish to test
[16:04] <asac> psyke83: is that ffox 3.5 only?
[16:04] <psyke83> asac, nope, it's reproducible with firefox 3.0.x as well
[16:04] <asac> can i see the problem without installing the new stuff?
[16:04] <asac> ah ok.
[16:04] <psyke83> asac, nope
[16:04] <asac> hmm so this was reported on 1st jan
[16:05] <asac> why cant i see that with the current stuff then?
[16:05] <asac> psyke83: so yes, please gimme a link
[16:05] <psyke83> asac: kwwii hasn't uploaded it yet, one sec
[16:08] <psyke83> asac: if you're logged into ubuntuforums: http://ubuntuforums.org/attachment.php?attachmentid=118788&d=1245856072
[16:08] <psyke83> otherwise: http://connogriofa.googlepages.com/Humanity_v0.8.tar.gz
[16:08] <asac> thoughti can drag that onto the preferences dialog :/
[16:09] <psyke83> asac: the Install button should do the trick
[16:09] <psyke83> I didn't test drag'n'drop, may be a bug
[16:10] <psyke83> note that the theme is renamed to "Humanity" in that tarball
[16:12] <asac> install button crashes the dialog :(
[16:13] <asac> psyke83: it installed it sucessfully, but i dont see any humanity now
[16:14] <asac> oh found it
[16:14] <asac> its greyed out
[16:14] <psyke83> odd, works fine here on Karmic. If you have problems: sudo mv ~/.themes/Humanity /usr/share/themes
[16:15] <asac> yes it works
[16:15] <asac> i see the problem
[16:16] <asac> psyke83: what does "through-border" mean?
[16:17] <psyke83> asac, the trough-border is a property of the GtkRange widget - in other words, the spacing around the scrollbar
[16:17] <psyke83> trough as-in, pig trough ;)
[16:18] <asac> psyke83: the space between the throbber and the border?
[16:19] <asac> throbber == grip
[16:19] <psyke83> asac: yes, that's
[16:19] <psyke83> *that's it
[16:19] <asac> hmm
[16:19] <asac> but the main problem is below the listbox
[16:20] <asac> here https://bug471789.bugzilla.mozilla.org/attachment.cgi?id=355041
[16:20] <asac> there is the CC List:
[16:20] <asac> if you look here: https://bugzilla.mozilla.org/show_bug.cgi?id=471789
[16:20] <asac> there are not CC folks filled in
[16:20] <asac> there is the scrollbar
[16:20] <psyke83> asac: yes, but those gtkentry boxes sometimes have horizantal scrollbars when the text overflows, so I think that an "invisible" scrollbar is getting drawn
[16:20] <asac> and the listbox with all the CCed names
[16:20] <asac> the main problem is below that listbox and not the scrollbar
[16:21] <asac> ah
[16:21] <psyke83> asac, an example: http://ubuntuforums.org/showthread.php?s=c5d40fe278ee41a121e651ac3ee607b4&t=1130582
[16:21] <psyke83> reduce your firefox window to a smaller size and pay attention to the CODE boxes
[16:21] <asac> i have never seen a horizontal scrollbar in the comment box though
[16:22] <asac> i dont see it on the vertical side where a scrollbar would be
[16:22] <asac> CODE boxes?
[16:22] <asac> where is that?
[16:23] <psyke83> sorry, the window size isn't important. Look at "Part C", at the code boxes
[16:23] <psyke83> the code box underneath "i386 users:" and "amd64 users" where the text scrolls
[16:24] <psyke83> contrast that to the other code boxes which do not need a horizontal scrollbar - it seems that the trough-border is being drawn in the cases where a scrollbar isn't necessary (in code boxes with short lines)
[16:26] <asac> psyke83: do you refer to this screenshot: https://bug471789.bugzilla.mozilla.org/attachment.cgi?id=355040 ?
[16:26]  * asac looked at the bugzilla one
[16:27] <psyke83> asac: I didn't file the bug, so that's not my testcase. I'll navigate to that site and test
[16:27] <asac> psyke83: just say me where you are looking at ;)
[16:28] <psyke83> asac: here: http://ubuntuforums.org/showthread.php?s=c5d40fe278ee41a121e651ac3ee607b4&t=1130582
[16:28] <psyke83> skip to "Part C"
[16:28] <psyke83> (of post #1)
[16:28] <asac> oh ... ok ;)
[16:28] <psyke83> sorry, I though I sent the link ;)
[16:28] <psyke83> *thought
[16:28] <asac> not sure if you did. maybe further above ;)
[16:29] <psyke83> the testcase image isn't appropriate, because that website requires a login to display the affected elements. At least this forum post can be seen by both of us easily enough
[16:39] <asac> psyke83: do you only see this on horizontal scroolbars?
[16:40] <psyke83> asac: it appears so, yes
[16:45] <psyke83> asac: since this is a quirk only in Firefox, I was going to add a hack to the gtkrc (setting the trough-border to 0 for GtkEntry cases in Firefox); unfortunately, you can't change the GtkRange properties in Firefox without changing *all* the elements (including the actual browser scrollbars)
[16:48] <psyke83> *I meant GtkRange cases in Firefox
[19:02] <asac> hmm. thought we had a bug for ubufox being broken in ffox 3.5
[19:02] <asac> ah bug 347972
[19:02] <asac> so tell me why launchpad doesnt find it if i search for 3.5 in ubufox package
[19:02] <asac> pfft
[19:07] <fta> my public tab is empty in gwibber :(
[19:07] <asac> yes everything is empty here
[19:07] <asac> (karmic version)
[19:07] <asac> also it crashes
[19:07] <asac> ;)
[19:07] <asac> guess its webkit or something
[19:07] <asac> fta: bug 391735
[19:08] <asac> i cant believe it, do you see the same?
[19:08] <asac> this is really annoying ;)
[19:09] <asac> tse
[19:09] <asac> i get bug 308397
[19:09] <fta> 1 hit: bug 308397
[19:09] <asac> but on that bug there isnt even any 3.5
[19:44] <fta> BUGabundo, is your public tab empty in gwibber?
[19:45] <BUGabundo> nope
[19:45] <BUGabundo> but I haven't fecthed the last updates fta
[19:45] <fta> it's empty since it 1st appeared
[19:46] <BUGabundo> let me check for update
[19:51] <fta> asac, d'oh! http://launchpadlibrarian.net/28293831/buildlog_ubuntu-intrepid-amd64.xulrunner-1.9.2_1.9.2~a1~hg20090624r29543%2Bnobinonly-0ubuntu1~umd1~intrepid_FAILEDTOBUILD.txt.gz
[19:53] <asac> fta: which commit did this?
[19:54] <fta> r29543
[19:54] <fta> ~ mozilla 427715
[19:56] <asac> fta: guess they are on it given that their trees are burning ;) http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox
[19:56] <fta> yep, i didn't even bother trying to patch it
[19:57] <fta> i 1st thought it was our system nss, but it's different this time
[20:05] <BUGabundo> asac: fta: did you guys know http://mozillaca.com/ ?
[20:05] <BUGabundo> a laconica for mozilla devs
[20:06] <fta> nope
[20:06] <fta> but i have enough with identi.ca
[20:07] <fta> your last dent appeared while i was fragging a bunch of aliens, making me lag and die
[20:10] <BUGabundo> err back
[20:10] <BUGabundo> so did you ?
[20:24] <psyke83> asac: re bug #327863, do you think that this issue will get resolved in Karmic without upstream intervention?
[20:24] <asac> psyke83: please dont hide it. I will escalate it
[20:24] <asac> e.g. dont work around
[20:25] <asac> if you know a workaround keep that in mind and maybe comment in the bug how that can be done, but hiding that now, will remove the pressure from us fixing it upstream
[20:26] <psyke83> asac: I'm not going to add any hacks to the gtkrc, don't worry. I think that Ken Wimer may be apprehensive to use the theme update as-is if it exposes this bug...
[20:26] <psyke83> asac: I would like for the theme to be pushed into the repository as-is, and having the bug exposed will encourage the bugfix to come quicker ;).
[20:27] <psyke83> if it's not fixed by release, we can push an update to the theme that sets the trough border back to 0 (the current default for the older version of the theme)
[20:28] <asac> psyke83: yes. thats what i would think is best. i will check with kwwii if you want
[20:28] <psyke83> asac: I'll send him an excerpt of this log so he's kept informed
[20:28] <psyke83> thanks for taking a look at this issue, I appreciate it
[20:29] <asac> psyke83: yeah. ping me in case you have problems getting this theme update in
[20:31] <psyke83> asac: will do, thanks
[20:35] <fta> hm, FIREFOX_3_5rc3_RELEASE
[20:35] <NCommander> asac, fta ping?
[20:35] <fta> and SEAMONKEY_2_0a3_RELEASE..
[20:35] <asac> fta: didnt you get my ping earlier today?
[20:35] <fta> NCommander, yep?
[20:35] <fta> asac, not sure, i was busy with work
[20:35] <NCommander> fta, asac, care to look at the new TB backtrace :-/
[20:35] <asac> 13:31 < asac> fta: ffox rc3 build2
[20:36] <NCommander> (we have a memory corruption issue in fontconfig thats been kludged around ATM)
[20:36] <asac> NCommander: yes
[20:36] <asac> i am eager ;)
[20:36] <NCommander> https://bugs.edge.launchpad.net/ubuntu/+source/thunderbird/+bug/385325
[20:36] <NCommander> asac, BTW, where was that se of fontconfig patches again, maybe I can get lucky and someone else has alrady fixed fontconfig for me
[20:37] <asac> NCommander: you mean the behdad tree?
[20:37] <BUGabundo> asac: ahhah
[20:37] <asac> NCommander: http://cgit.freedesktop.org/~behdad/fontconfig/
[20:37] <NCommander> asac, thats it; I figure its a worthwhile shot to see if if that fixes it
[20:37] <asac> NCommander: try tag 2.6.99.behdad.20090601
[20:37] <asac> yes definitly worth a try (doesnt cost much to spin that somewhere i guess)
[20:37] <NCommander> asac, thanks, hopefully I'll get lucky
[20:38] <asac> http://cgit.freedesktop.org/~behdad/fontconfig/snapshot/fontconfig-2.6.99.behdad.20090601.tar.gz
[20:38] <NCommander> asac, as it stands, we now have a issue in the JS library
[20:38] <asac> is a tarball ... not sure if the packaging needs a dist-tarball though
[20:38] <NCommander> asac, nope, but I can work with this
[20:42] <fta> http://isthetreegreen.com/
[20:44] <BUGabundo>    Your browser doesn't support cross-domain  XMLHttpRequests. :-(
[20:44] <BUGabundo> LOLOL
[20:44] <BUGabundo> actualy its running noscript
[20:44] <BUGabundo> LOL
[20:45] <asac> argh
[20:45] <asac> launchpad search
[20:45] <asac> its soooo annoying ;)
[20:45] <BUGabundo> lol
[20:45] <BUGabundo> use google
[20:46] <fta> Mook_sb, http://launchpadlibrarian.net/28299655/buildlog_ubuntu-hardy-i386.songbird_1.3.0~a~svn20090624r14060-0ubuntu1~usd1~hardy_FAILEDTOBUILD.txt.gz
[20:46] <asac> bug 291760
[20:46] <fta> Mook_sb, only on hardy
[20:46] <Mook_sb> fta: thanks, looking
[20:46] <NCommander> asac, so any ideas?
[20:46] <fta> system gstreamer too old?
[20:46] <asac> NCommander: i am not there yet ;)
[20:47] <NCommander> asac, ah ;-)
[20:47] <asac> chatting on three fronts besides this one
[20:47] <Mook_sb> fta: sounds like it
[20:48] <asac> NCommander: hmm #2 0x40a64cf0 in FcPatternObjectAddString (p=0x0, object=1, s=<value optimized out>) at fcpat.c:664
[20:48] <asac> still optimized out
[20:48] <Mook_sb> google finds http://lists.kde.org/?l=kde-multimedia&m=121380268225018&w=2 which says added in -base 0.10.20
[20:48] <NCommander> asac, no, not that backtrace
[20:48] <NCommander> asac, the one after it :-P
[20:48] <Mook_sb> fta: so your claim of base >= 0.10.7 probably isn't going to be happy :)
[20:49] <NCommander> (fontconfig got built with optimization by accident on that run)
[20:50] <fta> Mook_sb, hardy has 0.10.18
[20:50] <Mook_sb> fta: yeah, that's what it appeared to install; so you're right, too old
[20:50] <fta> damn
[20:51] <asac> ah good you made the debugging printfs
[20:52] <NCommander> asac, that's what fixed it unfortunately
[20:52] <NCommander> asac, which suggests either race condition or memory corruption
[20:53] <micahg1> asac: another crazy FF discussion bug 387822
[20:53] <asac> NCommander: so now that backtrace is reproducible?
[20:54] <NCommander> asac, hrm?
[20:54] <NCommander> asac, the new one is, which is what I got when I added debug printf *sigh*
[20:54] <asac> NCommander: yes. but did you run it multiple times?
[20:54] <asac> NCommander: or just once?
[20:55] <NCommander> Oh, yes
[20:55] <NCommander> Its reproducable, hangs in the same spot
[20:55] <NCommander> asac, the behdad fontconfig causes the old trace to be reproduced
[20:56] <asac> NCommander: +    print ("Encountered an FcTypeVoid\n");
[20:56] <asac> did it actually built?
[20:56] <NCommander> Yes, it did
[20:57] <NCommander> Eek
[20:57] <NCommander> How it did is a different question
[20:57] <NCommander> you can see some of the printf's in the trace I put
[20:57] <asac> yes. i think there is something busted. try to do it again ;)
[20:57] <asac> hmm
[20:57] <NCommander> print() must be defined somewhere
[20:58] <asac> where do you see the output?
[20:58] <asac> or which print are you seeing ?
[20:59] <asac> returning
[20:59] <NCommander> The value of the pointer returned
[20:59] <NCommander> Yeah
[20:59] <NCommander> I should probably make my printfs a little clearer
[20:59] <NCommander> but I didn't plan to post the patch
[21:00] <asac> yeah. so i guess after fixing the printf ;) .... and it still crashing there a valgrind might give more hints
[21:01] <NCommander> asac, no valgrind on ARM
[21:01] <NCommander> :-)
[21:01] <NCommander> don' you love this architecture?
[21:03] <asac> NCommander: you use gcc-4.4 i guess?
[21:03] <NCommander> asac, mostly, I remember I ended up building bits with 4.3 (of TB) due to a broken compiler
[21:04] <asac> desparate try, but maybe gcc 4.3 is better
[21:04] <NCommander> for fontconfig?
[21:04] <asac> for all tbird
[21:04]  * NCommander wants to find a good place to hurl
[21:04] <asac> NCommander: did you do a clean respin?
[21:04] <asac> (after switching to gcc-4.3)?
[21:04] <NCommander> asac, not yet, that takes hours
[21:04] <NCommander> I was going to let it run overnight
[21:04] <asac> there are odd warnings
[21:05] <NCommander> asac, why do you think 4.4. is responsible?
[21:06] <asac> i dont thihnk. just want to rule out that some 4.4 regression kills us here (and that you have a half 4.4 half 4.3 build)
[21:07] <asac> ###!!! ASSERTION: id differs from id in atom table!: 'd_val == idval', file xpcwrappednativejsops.cpp, line 1046
[21:07] <asac> things like that look kind of odd to me
[21:07] <NCommander> asac, I was able to find someone else who was able ot trip a similar assertion
[21:07] <asac> "This is pretty much always bad. It usually means that native code is
[21:07] <asac> making a callback to an interface implemented in JavaScript, but the
[21:07] <asac> document where the JS object was created has already been cleared and the
[21:07] <asac> global properties of that document's window are *gone*. Generally this
[21:08] <asac> indicates a problem that should be addressed in the design and use of the
[21:08] <asac> callback code.K"
[21:08] <NCommander> asac, http://groups.google.com/group/mozilla.dev.general/browse_thread/thread/afdae3bc27a25eeb
[21:13] <asac> mozilla bug 426563,
[21:13] <asac> mozilla bug 426563
[21:13] <asac> "Using GCC 4.2, the assembly generated from the arm xptc stubs doesn't
[21:13] <asac> necessarily have any code emitted before the SharedStub symbol, causing it to
[21:13] <asac> end up in the wrong section -- often the debug section, which doesn't get
[21:14] <asac> mapped and so causes a segfault.
[21:14] <asac> "
[21:14] <asac> NCommander: does that patch apply to tbird?
[21:14] <NCommander> It applied fuzzy
[21:14] <NCommander> Testbuilding now
[21:14] <asac> mozilla bug 476903
[21:15]  * asac searches for ARM fixes in xpcom
[21:15] <asac> oh
[21:15] <asac> mozilla bug 476903
[21:15] <asac> ubottu: wake up
[21:15] <asac> mozilla bug 476903
[21:15] <asac> mozilla bug 339783
[21:16] <NCommander> ugh
[21:16] <NCommander> I think I'm going to have to take a look at that handwritten ASM
[21:16] <NCommander> It might be an OABI/EABI issue again
[21:16] <asac> mozilla bug 476903
[21:17] <asac> wake up ;)
[21:17] <asac> ah ;)
[21:17] <asac> strange
[21:17] <asac> the commit says: "summary:     b=476903; additional ARM xptc marshalling fixes (avoid unsigned char dependency); r=bsmedberg"
[21:17] <asac> so take that patch too if it applies
[21:17] <asac> NCommander: ^^
[21:17] <asac> there are two patches actually
[21:18] <asac> yay. how much i love xptcinvoke ;)
[21:18] <asac> but i really think this could be it ;)
[21:18] <asac> having bad xptcinvoke will cause massive corruption most likely ;)
[21:19] <asac> so: https://bug476903.bugzilla.mozilla.org/attachment.cgi?id=363974 https://bug476903.bugzilla.mozilla.org/attachment.cgi?id=368529
[21:19] <asac> NCommander: ^^
[21:19] <asac> take those two on top of what you applied above
[21:22] <NCommander> 368529 does not apply
[21:22] <NCommander> neither apply
[21:23] <asac> ok lest see what landed before that in bonsai
[21:23] <asac> hg history doesnt go back to branchpoint of 3.0
[21:24] <NCommander> asac, this is TB2, remember
[21:24] <NCommander> TB3 is known to work fortunately
[21:24] <NCommander> God help us if we had to port the entire stack
[21:24] <asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=mozilla%2Fxpcom%2Freflect%2Fxptcall%2Fsrc%2Fmd%2Funix%2Fxptcinvoke_arm.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
[21:24] <asac> NCommander: right
[21:24] <asac> thats why we have to look in bonsai
[21:24] <asac> the branch for ffox 3 was done long ago and isnt in mercurial
[21:25] <asac> so look what isnt applied from the list on that link
[21:25] <asac> and apply all that ;)
[21:25] <asac> then continue with the patches from above
[21:25] <asac> (this MUST make them apply)
[21:25] <NCommander> 2006-12-05 19:00 looks promising
[21:25] <NCommander> Ugh, that sounds like overkill
[21:25] <NCommander> When was TB2 branched?!
[21:25] <NCommander> (i.e, I don't know if I need code from say 1999 ;-))
[21:25] <asac> NCommander: the branch was created for ffox 1.5
[21:25] <asac> NCommander: there are just a few commits
[21:25] <asac> let me check
[21:26] <NCommander> I just want a time line to work again
[21:27] <asac> NCommander: http://bonsai.mozilla.org/cvsgraph.cgi?file=mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp&rev=1.13
[21:27] <asac> so seems 1.8 was the first commit
[21:27] <asac> that didnt go directly in the tbird 2 branch
[21:28] <asac> http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=&file=mozilla%2Fxpcom%2Freflect%2Fxptcall%2Fsrc%2Fmd%2Funix%2Fxptcinvoke_arm.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
[21:28] <asac> thats what happened on tbird 2 branch (after the branching)
[21:28] <asac> so that matches
[21:28] <asac> that everything after 1.7 from the first line isnt in yet
[21:29] <asac> seems 1.8 was cherry picked to 1.8 branch too
[21:29]  * NCommander feels like puking
[21:29] <asac> so everything after that is a candidate
[21:30] <NCommander> I don't like playing grope the patches
[21:30] <NCommander> That's how we got sidetracked with the NSPR patch
[21:30] <asac> so mozilla bug 322806
[21:31] <asac> and mozilla bug 339783
[21:31] <asac> hmm
[21:31] <asac> that bug sounds wrong :(
[21:32] <NCommander> asac, to my knowledge, TB2 works fine on old ABI ARM systems
[21:32] <NCommander> (Debian port arm)
[21:32] <asac> what a mess. wrong bug id in commit
[21:32] <asac> NCommander: yeah
[21:32] <NCommander> Ugh
[21:32] <asac> so look at http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=mozilla%2Fxpcom%2Freflect%2Fxptcall%2Fsrc%2Fmd%2Funix%2Fxptcinvoke_arm.cpp&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
[21:32] <NCommander> Who the heck makes a library platform specific
[21:32] <asac> and pick the commit 1.9
[21:32] <NCommander> Its like
[21:32] <asac> and 1.13
[21:33] <asac> i think 1.10 is not relevant for tbird 2 ... seems to be a follow up commit on some more general changes they did to 1.9 branch
[21:33] <NCommander> I hate to be dense, but why do you think its an xpcom issue, it looks like its a JS issue
[21:33]  * NCommander knows more about Mozillas underpinnings than I care to, but not so much on the relationship
[21:33] <NCommander> ^ between modules
[21:34] <asac> NCommander: well. if xpt is broken you are doomed to get bad corruption
[21:34] <NCommander> point very well taken
[21:34] <asac> because thats basically implementing how functions are called
[21:34] <asac> so before xpt is known to work well, it doesnt make much sense to look furthre
[21:34] <NCommander> Is there an xpt test suite
[21:34] <NCommander> Or can I keep dreaming?
[21:35] <asac> also almost all arm specific (and other minority arch) fixes i saw were either alignment or xpt issues
[21:36] <asac> so if you look at current arm patch we have its:
[21:36] <asac> xulrunner/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_arm.cpp
[21:36] <asac> and xulrunner/xpcom/reflect/xptcall/src/md/unix/xptcstubs_arm.cpp
[21:37] <asac> and looking at the commit messages from bonsai it sounds really like there are issues ;)
[21:38] <asac> so i would think applying:
[21:38] <asac> http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/reflect/xptcall/src/md/unix&command=DIFF_FRAMESET&file=xptcinvoke_arm.cpp&rev1=1.8&rev2=1.9&root=/cvsroot
[21:38] <asac> and http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/reflect/xptcall/src/md/unix&command=DIFF_FRAMESET&file=xptcinvoke_arm.cpp&rev1=1.12&rev2=1.13&root=/cvsroot
[21:38] <Mook_sb> yes, there is a series of xptcall tests
[21:38] <asac> not sure if http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/reflect/xptcall/src/md/unix&command=DIFF_FRAMESET&file=xptcinvoke_arm.cpp&rev1=1.9&rev2=1.10&root=/cvsroot is 1.9 specific
[21:38] <NCommander> I wonder if I could just take xptcinvoke_arm.cpp from TB3, plot it into TB2 and hope for the best
[21:39] <NCommander> *plop
[21:39] <asac> NCommander: i wouldnt think you can. they probably changed a bit of api or something
[21:39] <Mook_sb> though I thought there was more than http://mxr.mozilla.org/seamonkey/source/xpcom/reflect/xptcall/tests/
[21:40] <asac> NCommander: 1.10 commit was: Bug 361533  arm port is broken XPTC_PUBLIC_API / XPTC_InvokeByIndex weren't updated for arm
[21:40] <asac> patch by romaxa@gmail.com r=timeless moa=timeless (this is ports only)
[21:40] <asac> that suggests that there were changes on 1.9 that probably touched more than just that file
[21:40] <NCommander> grumble
[21:40] <asac> NCommander: does ffox 3.0 work?
[21:40] <Mook_sb> there was an XPTC_Invoke change, yes
[21:40] <asac> if so, really try just these two:
[21:40] <asac> Bug 361533  arm port is broken XPTC_PUBLIC_API / XPTC_InvokeByIndex weren't updated for arm
[21:40] <asac> oops
[21:40] <asac> 22:38 < asac> http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/reflect/xptcall/src/md/unix&command=DIFF_FRAMESET&file=xptcinvoke_arm.cpp&rev1=1.8&rev2=1.9&root=/cvsroot
[21:41] <asac> 22:38 < asac> and
[21:41] <asac> http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/xpcom/reflect/xptcall/src/md/unix&command=DIFF_FRAMESET&file=xptcinvoke_arm.cpp&rev1=1.12&rev2=1.13&root=/cvsroot
[21:41] <asac> they seem to not touch API
[21:41] <asac> Mook_sb: thanks!
[21:41] <NCommander> asac, yes
[21:42] <asac> NCommander: maybe together with the one you already fuzzily applied from 1.9.1 branch (but i dont see it here in 1.9 branch so its probably not neeeded)
[21:42] <fta> asac, xul didn't fail on karmic, seems it's nss after all :P
[21:42] <NCommander> asac, well the one that was fuzzy broke gdb
[21:42] <NCommander> :-/
[21:42] <NCommander> Mook_sb, got a guide on how to run the tests?
[21:43] <asac> the test situation on 1.8 branch wasnt really great
[21:43] <Mook_sb> NCommander: IIRC, I just ran the executable via run-mozilla.sh
[21:43] <asac> NCommander: yeah. you might want to build with --enable-tests
[21:43] <asac> (i think there is --disable-tests in rules)
[21:43] <Mook_sb> oh, you probably want to build --enable-debug :p
[21:43] <NCommander> Mook_sb, that I got
[21:43] <asac> he alread did that ;)
[21:44] <NCommander> asac, why do I have that feeling I should run in F-E-A-R when the testsuite is run
[21:44] <Mook_sb> yeah, shouldn't be getting the Components object went away warning otherwise :)
[21:46] <asac> NCommander: enable tests doesnt run them automatically afaik
[21:46] <asac> just builds it
[21:46] <asac> so you can run some xpcom tests ;)
[21:46] <asac> and see it crashing (hopefully)
[21:46] <NCommander> I feel like I probably should hurl
[21:46] <asac> NCommander: just hack the version in tbird 3 ;)
[21:46] <asac> nobody will notice ;)
[21:47] <NCommander> asac, well, we don't have TB3 in archive yet
[21:48] <asac> was kidding
[21:50] <asac> armin76: do you guys have tbird 2 working on armel?
[21:50] <asac> (hi)
[21:52] <NCommander> so gcc-4.4 currently ICEs
[21:53] <asac> ICEs?
[21:53] <NCommander> Internal Compiler Error when building TB2
[21:53] <asac> yeah. and i really think that building half tbird with a different compiler calls for troubles
[21:53] <asac> NCommander: or is that because of the new arm patches?
[21:53] <NCommander> asac, no, it was doing this before
[21:53] <NCommander> asac, I'm going to do a make clean and force GCC 4.3
[21:54] <NCommander> 8sigh*
[21:54] <NCommander> What a nightmare
[21:54] <asac> NCommander: i think you better reconfigure with GCC 4.3
[21:54] <micahg> asac: could gcc 4.4 be why karmic users are having trouble with FF?
[21:55] <asac> micahg: what kind of troubles?
[21:55] <micahg> I've been seeing a lot of crash reports
[21:55] <micahg> on alpha2
[21:55] <micahg> I've been sick, so I haven;t had time to look at them all yet
[21:56] <asac> maybe apport was enabled now?
[21:56] <NCommander> asac, I am
[21:56] <micahg> asac: should I expect a flood of reports?
[22:00] <asac> micahg: we usually get quite a few during development cycle. the more users upgrade, the more crashes you get
[22:00] <micahg> ok
[22:00] <asac> most are invalid as it seems
[22:00] <micahg> are there any additional tips I should know about
[22:01] <asac> with just a few having a readable trace
[22:01] <micahg> if retrace fails, I should mark invalid?
[22:01] <asac> micahg: yes. invalid and open bug up after removing coredump (e.g. unprivate)
[22:01] <micahg> ok
[22:02] <asac> micahg: i think i gave you a script for that?
[22:02] <micahg> I still need to look through remainging files for private info, right?
[22:02] <micahg> yes
[22:02] <asac> ok
[22:02] <micahg> I haven't ahd time to look at them yet?
[22:02] <micahg> ...
[22:02] <asac> the invalid-crash.sh script is it
[22:02] <asac> ah ok
[22:02] <asac> well. look into it
[22:02] <micahg> ok
[22:02] <asac> for invalidating crashes its reawlly handy
[22:02] <asac> because removing coredump and opening up is time consuming
[22:03] <micahg> but do I still need to look at the other attchments?
[22:03] <micahg> to make sure there is no proviate data?
[22:03] <asac> you just need to change to your name in the script
[22:03] <asac> and create a cookies txt somehow
[22:03] <asac> micahg: if the stacktrace is bad like here:
[22:03] <asac> bug 391648
[22:03] <asac> you just remove coredump and open up and invalidate
[22:04] <asac> there is not much sensitive stuff in the other extensions
[22:04] <asac> err file attachments ;)
[22:04] <asac> (not extensions)
[22:04] <micahg> ok
[22:04] <micahg> will do
[22:04] <micahg> that should help a lot
[22:04] <asac> so running the script will just do it right
[22:04] <micahg> should be able to clean a lot up sat night them
[22:04] <micahg> *then
[22:04] <micahg> I'm hosting my first loco event on Sunday
[22:04] <asac> thanks
[22:04] <asac> great!! very cool
[22:05] <asac> where?
[22:05] <micahg> Chicago
[22:05] <asac> nice ;)
[22:06] <micahg> was I right about bug 387822
[22:15] <asac> micahg: yes
[22:22] <asac> micahg: hmm. seems the scripts are broken now
[22:22] <asac> guess need to write them using launchpadlib
[22:23] <micahg> ok
[22:52] <fta> asac_, asac: what has to be done to package a plugin with nspluginwrapper?
[23:22] <fta> ripps, i'm thinking about adding support for additionnal build-deps in my bot, both globally and per package/arch, like lintian and binutils-gold in this example: http://paste.ubuntu.com/203183/
[23:22] <ripps> fta: how do plan to implement it, something like autoppa uses with control.in?
[23:23] <fta> nope, the bot will just add those to control, no need to touch the packaging branch
[23:23] <ripps> oh, i see, it will inject the new build-dep into the control before upload
[23:23] <fta> yes
[23:24] <ripps> sounds good
[23:25] <ripps> I see there's two build-deps fields, one distro specific, and one universal
[23:25] <fta> the idea is to put there build-deps that are good to have in ppas (like lintian) but not in the real archive, or builds deps needed for backports
[23:25] <ripps> Is the universal necesary, since the debian branch should contain the universal control?
[23:26] <ripps> okay, i see, less work for making official packages
[23:26] <fta> yes
[23:27] <fta> the global 'all' could be any package name instead, it applies to all arches.
[23:27] <fta> while in the package section, it's possible to target one or more dists and arches
[23:28] <ripps> fta: is their going to be field for package versions, or do I just append (>= version) to the package string?
[23:28] <fta> like 'build-deps' => { 'karmic' => 'binutils-gold [!amd64]' }
[23:28] <fta> like 'build-deps' => { 'karmic' => 'binutils-gold (>= 1.2.3)' }
[23:28] <fta> it's a list of strings
[23:29] <ripps> cool, sounds like a plan.
[23:29] <fta> like 'build-deps' => { 'karmic' => 'binutils-gold (>= 1.2.3), foo | bar' }
[23:29] <fta> something like that
[23:30] <fta> i need to see if we need the same thing for Depends
[23:30] <fta> probably
[23:31] <ripps> hmm... of course it depends on the package, but I don't see how it would hurt to modify Depends while we're messing with the control
[23:32] <fta> ${shlibs:Depends} will take care of most cases but not always
[23:32] <BUGabundo> fta: http://lifehacker.com/5045164/google-chromes-full-list-of-special-about-pages
[23:33] <ripps> some programs, such as mpd, need to extra depends, such as adduser, because it creates a root service that uses it's own user
[23:33] <BUGabundo> why don't the Chrome commands pages work on Chromium?
[23:35] <fta> BUGabundo, good question, read the code Luke
[23:35] <fta> ripps, but aren't those depends already in the packaging branch?
[23:35]  * BUGabundo wonders who the heck is Luke, since I don't do code
[23:36] <ripps> fta: yes, but I was just giving an example :P
[23:36] <fta> oh, ok
[23:47] <fta> BUGabundo, you don't know Luke?
[23:47] <fta> BUGabundo, "use the Force Luke"
[23:48] <BUGabundo> that I know
[23:48] <BUGabundo> but _he_ didn't code eiher
[23:52] <asac> so NM 0.7.1 with modemmanager is now ready i would think for early adopters ;)
[23:52] <asac> https://edge.launchpad.net/~modemmanager/+archive/ppa
[23:52] <asac> BUGabundo: wanna check ;)?
[23:53] <ripps> What's modemmanager?
[23:53] <BUGabundo> asac: what the heck
[23:54] <BUGabundo> if it fails I can always knock on your doors
[23:54] <asac> ripps: a separate daemon optimized for 3G modems ... so you get advanced features
[23:54] <BUGabundo> so if you don't see me here tomorrow, grab me at the airport
[23:54] <ripps> oh, don't use 3g, so I don't need it :)
[23:54] <asac> NM uses it to handle 3g connections (and later maybe even plain modems, if someone steps up)
[23:54] <BUGabundo> so now I get signal streng?
[23:54] <asac> yes
[23:55] <asac> and network type (e.g. HSDPA, GPRS, etc)
[23:55] <asac> also you can scan
[23:55] <asac> and change pin ;)
[23:55] <asac> i think even SMS for some modems (but no UI in NM for that - naturally)
[23:55] <BUGabundo> ohoohhhh
[23:55] <BUGabundo> YAY
[23:56] <BUGabundo> sed source.list
[23:56] <asac> ;)
[23:56] <BUGabundo> so ha++y I typed my pass wrong 2 times
[23:56] <asac> yeah. i think you should disable NM ppa for that
[23:56] <BUGabundo> so does it replace NM ?
[23:56] <asac> (not sure if i took the needed care)
[23:57] <asac> BUGabundo: it upgrades it
[23:57] <BUGabundo> I don't have the NM ppa
[23:57] <BUGabundo> I think...
[23:57] <BUGabundo> better check
[23:57] <BUGabundo> # deb http://ppa.launchpad.net/network-manager/ppa/ubuntu karmic
[23:57] <asac> so you get mm-enabled-network-manager + mm-enabled-applet + mm
[23:57] <asac> yeah
[23:57] <asac> so its disabled.
[23:57] <BUGabundo> yep
[23:57] <asac> is nothing new in there for karmic anyway
[23:57] <BUGabundo> does it have anything not in karmic archive?
[23:57] <BUGabundo> ah ok
[23:58] <BUGabundo> that's what I though
[23:58] <asac> BUGabundo: oh. until tomorrow you might need to downgrade the applet (we need to bump it to 0.7.1 final stil ... but thats not a difference for most things)
[23:58] <BUGabundo> aptitude should take care of tha
[23:58] <BUGabundo> *that
[23:58] <BUGabundo> let me just email gnomefreak
[23:58] <asac> about what?
[23:58] <BUGabundo> *before* I test this
[23:58] <BUGabundo> just wondering how he is
[23:59] <asac> good .. wish him quick cure from me ;)