[01:49] <ddecator> micahg: any idea on a time-frame for getting java to work properly with firefox in lucid?
[01:50] <micahg> ddecator: should be end of beta 2 for sure...don't know what the issue is offhand, I'll debug more when I upgrade over the weekeend
[01:51] <ddecator> micahg: sounds good, it was just asked in ubuntu+1
[01:55]  * micahg shouldn't promise for sure...
[01:56] <ddecator> micahg: i guess it's just a sys link issue according to yofel
[01:57] <micahg> ddecator: the question is why, which I'll check after I upgrade
[01:57] <ddecator> micahg: fair enough. i'm going to try to figure out this sqlite problem with songbird, i may need your help with it later if i can find the cause...
[01:58] <micahg> ddecator: did you disable-system-sqlite in the rules
[01:58] <ddecator> micahg: yup. it's looking for it in a folder but it's not in there. it happened at 3am the other day so i haven't really looked into it yet, haha
[02:01] <ddecator> micahg: i guess the firefox issue is java moving from xulrunner-addons/plugins to mozilla/plugins so it just needs to be updated to look in the right area (according to yofel, i haven't looked myself)
[02:01] <micahg> ddecator: that location should be fine...we might be missing a symlink in firefox
[02:01] <ddecator> micahg: right, that's the problem
[02:03] <ddecator> micahg: or i guess yofel talked about it with asac?
[02:03] <yofel> bug 532174 actually
[02:04] <ddecator> whoa, hey yofel haha
[02:04] <yofel> ddecator: I usually idle around in here :P
[02:05] <yofel> micahg: update-alternatives just creates a link in /usr/lib/xulrunner-addons/plugins but not in /usr/lib/mozilla/plugins so firefox doesn't seem to find it anymore
[02:09] <yofel> note: the linking is done by the sun-java6-plugins postinst script with a list of plugin folders defined in debian/rules, that's why I say that the rules file needs to be fixed
[02:10] <yofel> s/6-plugins/6-plugin/
[02:10] <micahg> yofel: yes, but in 3,5 we looked in that dir, maybe we should for 3.6 as well
[02:11] <ddecator> i think i need to figure out what the vendor equivalent of libsqlite3.a.a is...
[02:11] <yofel> micahg: well, that would fix it too certainly, this was caused by the change how firefox uses xulrunner I guess
[02:12] <micahg> yofel: right, I'll ask asac in the morning about it
[02:23] <ddecator> micahg: it looks like i need to change a file so debuild looks for sqlite in the vendor folder, but i don't know what the vendor equivalent would be for libsqlite3.a.a
[02:23] <micahg> ddecator: songbird should know how to build its own copy of sqlite
[02:24] <ddecator> micahg: http://pastebin.ubuntu.com/396569/
[02:24] <ddecator> line 73
[02:27] <micahg> ddecator: did you comment out the if/else block for system sqlite except for the disable flag in debian/rules?
[02:28] <ddecator> micahg: no, should i try that?
[02:28] <micahg> ddecator: yes
[02:28] <ddecator> micahg: alright, thanks
[03:03] <micahg> chrisccoulson: I think I fixed the gcc-4.4 issue
[03:05] <ddecator> micahg: same issue. this is how i have the system sqlite section in debian/rules: http://pastebin.ubuntu.com/397587/
[03:06] <micahg> ddecator: that should work
[03:06] <micahg> ddecator: what happens if you comment that line out too?
[03:07] <micahg> ddecator: oh, did you restart the build from scratch after you did that?
[03:07] <micahg> the configure file needs updating
[03:07] <ddecator> micahg: yup
[03:07] <ddecator> micahg: idk how to resume a build, haha, i always restart it...
[03:07] <micahg> ddecator: debuild -nc resumes
[03:08] <micahg> more or less
[03:08] <ddecator> micahg: very good to know. what config file needs updating?
[03:08] <micahg> try commenting the disable line out as well
[03:08] <ddecator> micahg: alright. can i use -nc or should i restart from scratch?
[03:09] <micahg> ddecator: start frmo scratch
[03:09] <ddecator> micahg: sure thing
[03:10] <ddecator> this has been a really good learning experience
[03:43] <ddecator> micahg: same problem...
[03:54] <ddecator> micahg: any other ideas?
[03:56] <micahg> ddecator: no
[03:56] <ddecator> well this should be fun...
[04:33] <ddecator> this is making no sense...
[04:38] <ddecator> micahg: is there a way to run a build and have the entire log saved to a file?
[04:39] <micahg> debuild -b 2>&1 | tee /path/to/file
[04:39] <ddecator> micahg: ty
[05:23] <ddecator> micahg: i guess the issue is sqlite not being properly pulled from svn
[05:23] <micahg> ddecator: :)
[05:25] <ddecator> micahg: now the hard part is figuring out how to change the rules file so it pulls correctly...
[05:25] <micahg> ddecator: yep :)
[05:26] <ddecator> and the people on the songbird channel are very helpful =)
[05:27] <Mook> we try :)  we might not always be able to respond quickly though, especially for things like patching.
[05:27] <micahg> indeed
[05:27] <micahg> hi Mook
[05:27] <Mook> hi micahg
[05:27] <micahg> Mook: I never got around to it so ddecator volunteered to give it a shot
[05:27] <Mook> (feel free to poke me, at least if you need help)
[05:28] <ddecator> what can i say, i'm going through songbird withdrawl =p
[05:28] <Mook> heh, nice :)  don't feel bad or anything, time is always limited when doing things like these.
[05:35] <micahg> Mook: any plans on building with system xulrunner for 1.8.0?
[05:36] <Mook> micahg: nothing on the table yet; there has been effort to at least get us to 1.9.2, though
[05:36] <micahg> Mook: yeah, I saw that
[05:36] <Mook> (I would assume that's a prereq to getting merged upstream, since they don't do CVS checkins anymore... XD )
[05:37] <micahg> Mook: k :)
[05:41] <ddecator> oh, the rules file is pulling from vendor instead of vendor-binaries...
[05:41] <micahg> ddecator: no binaries :)
[05:42] <ddecator> micahg: except it's looking for the files included with vendor-binaries
[05:42] <Mook> yeah, in which case you need to either 1) build sqlite as well, or 2) hack components/dbengine to understand system sqlite
[05:42] <micahg> Mook: we want to try to build your sqlite
[05:42] <micahg> see if it fixes the build
[05:43] <Mook> (I think when things started, sqlite just lived in dbengine directly, which was arguably even worse; at least it's now properly sitting in vendor/)
[05:44] <ddecator> so if the libsqlite3.a file that debuild looks for is in vendor-binaries, but we're not pulling from there...
[05:45] <ddecator> not sure what i need to change to get it to build
[05:47] <Mook> is the debian/rules somewhere I can see online? I don't have a copy of it locally.
[05:47] <ddecator> Mook: let me pastebin it a sec
[05:48] <micahg> ddecator: Mook: http://bazaar.launchpad.net/%7Emozillateam/songbird/songbird.head/annotate/head%3A/debian/rules
[05:48] <ddecator> or that...
[05:48] <Mook> thanks!
[05:49] <ddecator> Mook: except the "use system sqlite" block has been commented out and "sqlite \" was added to the "dependencies we need" list
[05:50] <Mook> given system gstreamer, that sounds about right.
[05:51] <ddecator> it pulls all of the files from the vendor svn
[05:51] <ddecator> but somewhere a makefile wants the files from vendor-binaries
[05:52] <ddecator> is there a file in the vendor svn that we can point to instead of libsqlite3.a?
[05:54] <Mook> no, you have to build libsqlite3.a - https://wiki.songbirdnest.com/Build_Release/Building_the_vendor_repository
[05:55] <Mook> do it the way taglib does (xulrunner too special to copy from)
[05:55] <ddecator> Mook: ty
[06:00] <ddecator> Mook: just want to make sure i understand right. i should add to the rules file so sqlite builds the same way taglib does?
[06:01] <ddecator> and building it that way will create the directory that is missing and causing the current build fail?
[06:08] <ddecator> ...i'm going to assume yes and get to work
[06:12] <Mook> err, yes. sorry, was distracted doing other things.
[06:13] <ddecator> no problem, already getting things setup =)
[06:21] <ddecator> alright, lets try it...
[06:28] <ddecator> so yah, i definitely want to help maintain the packaging and bug work for songbird =)
[06:29] <micahg> ddecator: to get bugs, it needs to be in teh archive :)
[06:29] <ddecator> micahg: right, which is what the goal is =)
[06:30] <ddecator> for 10.10
[06:30] <micahg> ddecator: well, that depends if we can get it to build with libxul-sdk or not
[06:30] <micahg> we're not going to have 4 copies of xulrunner in archive, that's for sure
[06:31] <ddecator> makes sense
[06:31] <micahg> ok, I shouldn't say that's for sure...
[06:31] <micahg> but TB and SM are already in archive
[06:31] <micahg> and FF we needed to do
[06:31] <ddecator> they all use different versions of xul?
[06:32] <micahg> ddecator: they each have their own copy
[06:32] <ddecator> micahg: huh, i thought they all ran on the same version...although i guess that makes sense that they don't all update at the same time
[06:32] <micahg> ddecator: they do update at the same time :)
[06:33] <micahg> but still they have their own copy...they're working on making TB build from system xul
[06:33] <ddecator> micahg: oh, you mean they build their own copy, not that they have their own system copy?
[06:33] <micahg> SM if people want it with system xul
[06:33] <micahg> ddecator: right
[06:33] <ddecator> micahg: ah, that makes a lot more sense
[06:34] <micahg> trying to build the new google-gagdets now
[06:34] <micahg> *gadgets
[06:35] <ddecator> haha, no wonder you guys didn't have time to update songbird
[06:36] <micahg> ddecator: I'm trying ot update all rdepends on xul191 to xul192 so we can drop xul191 from Lucid
[06:36] <ddecator> micahg: that'd be nice
[06:37] <micahg> ddecator: necessary is more like it, no way we can keep xul191 patched for 3 years
[06:37] <micahg> probably won't even be able to keep xul192 patched...
[06:38] <ddecator> very true, xul193 is coming up pretty quickly
[06:39] <ddecator> i need to figure out what is causing prism to not work properly for me...
[06:40] <ddecator> or prism-google-mail to be specific...prism-google-calendar works fine, same add-ons and everything
[06:42] <micahg> ddecator: new version next week
[06:42] <micahg> beta 3 will be in lucid
[06:43] <ddecator> micahg: sounds good, i'll wait to see if that fixes it then
[06:48] <ddecator> getting there...
[06:53] <ddecator> didn't build right -_-
[06:56] <ddecator> alright, lets try this
[07:00] <vish> hmm , what does this mean > (firefox-bin:24007): Gdk-WARNING **: XID collision, trouble ahead
[07:00] <vish> i notice a lot of this in my .xsession-errors
[07:00] <micahg> vish: I think it's a problem with flash
[07:00] <ddecator> yah, that happens a lot
[07:00] <vish> ah , flash
[07:00] <vish> micahg: thanks
[08:47] <BUGabundo_remote> bRoas
[10:18] <asac> ccheney: ok cool
[10:18] <asac> so the crash ... do you have a backtrace?
[10:19] <asac> what do we need from intltool?
[10:20] <asac> once we hav ethe crashes fixed we have one more thing to do
[14:50] <lfaraone> Hey, I adapted a patch from bug 123713 into Ubufox, and proposed a merge into lp:~ubuntu-core-dev/ubufox/ubuntu, with ~ubuntu-core-dev as the reviewer. Is that the proper workflow?
[15:24] <micahg> asac: around?
[15:24] <asac> break atm
[15:25] <asac> after release meeting i have a few minutes
[15:25] <micahg> asac: k, so maybe in 2 hrs or so?
[15:35] <BUGabundo_remote> pff
[16:28] <micahg> chrisccoulson_: can I ping you this weekend for uploads?
[16:28] <chrisccoulson_> micahg - yeah, that should be ok
[16:30] <micahg> chrisccoulson_: after the archive opens, I want to get xul192-ubuntu2 in ,then prism and fennec
[18:49] <[reed]> asac: http://www.ubuntu.com/testing/lucid/beta1
[18:49] <[reed]> "Mozilla
[18:49] <[reed]> Default search engine has been changed to Yahoo! The default Home Page will use either Google or Yahoo! depending on user setting."
[18:49] <[reed]> uh, what is "Mozilla"?
[18:56] <micahg> [reed]: do you want to file a bug? https://bugs.edge.launchpad.net/ubuntu-release-notes/+bugs
[19:01] <[reed]> micahg: yes, I will
[19:01] <micahg> [reed]: also, about the symlink breakage in firefox, do you think we might be able to go for a linux first solution then the other OSs?
[19:02] <[reed]> what's the bug # again?
[19:02] <micahg> mozilla 551152
[19:03] <[reed]> how big of a problem is this for you?
[19:04] <micahg> [reed]: bug 518422
[19:04] <[reed]> then you should request blocking and say so
[19:04] <[reed]> otherwise, it'll be treated as any other bug
[19:05] <micahg> [reed]: big problem, I've been testing Mike's patch and it seems to work...
[19:05] <micahg> [reed]: that it should block 3.6.3?
[19:05] <[reed]> yes
[19:05] <micahg> [reed]: k, thanks
[19:05] <[reed]> micahg: request both blocking1.9.2 and blocking1.9.3
[19:06] <[reed]> and explain fully
[19:07] <micahg> [reed]: can I also dupe the various addon bugs that seem related to that bug?
[19:20] <[reed]> micahg: hmm, if you're 100% sure, then yes
[19:21] <micahg> [reed]: if I'm not sure, I'll ask in each of the bugs
[19:28] <[reed]> micahg: filed bug 542141
[19:28] <[reed]> anything else I need to do to make sure somebody sees that and fixes it?
[19:29] <micahg> [reed]: if it's really urgent, you can hop in #ubuntu-release, otherwise, the release team was notified when you opened the bug
[19:45] <asac> [reed]: yeah. thats a bug in the announcement
[19:45] <asac> micahg: i am now here for a bit
[19:45] <[reed]> micahg: ok, thanks
[19:46] <micahg> asac: k, 1st I guess, is there anything you need me to do for the Seamonkey 1.1.19 release?
[20:08] <asac> micahg: did you tell #ubuntu-release about the bug?
[20:08] <asac> i would suggest to do that
[20:09] <micahg> asac: which bug?
[20:09] <asac> the announcement bug
[20:09] <asac> if not i can do that
[20:09] <micahg> asac: no, but they got notified by subscription through LP
[20:10] <asac> well ... thats not likely to be seen soon enough to change ;)
[20:10] <asac> let me do that
[20:10] <micahg> asac: k, here's the bug #: 542141
[20:10] <asac> got it
[20:11] <asac> cool
[20:11] <asac> micahg: so whats up ;)
[20:11] <asac> ccheney`: are you here?
[20:11] <ccheney`> asac: yea
[20:11] <asac> cool
[20:11] <asac> so ... do you have a backtrace?
[20:11] <micahg> asac: well, I found a few more packages made it into debian with xul192 support, so I started working on merges
[20:11] <asac> or core dumb?
[20:11] <asac> micahg: packages that we didnt port yet?
[20:11] <micahg> asac: I was going to bug the release team on Monday
[20:12] <asac> about what?
[20:12] <micahg> asac: yep, google-gadgets is one
[20:12] <micahg> asac: FFes
[20:12] <ccheney`> asac: not atm i can get one, how do i build an individual package with the symbols? i know i can use the special repo for official packages but wasn't sure how to do it for ppa stuff
[20:12] <asac> micahg: are those new upstream releases?
[20:12] <micahg> asac: yes
[20:12] <asac> or xul 192 ports?
[20:12] <ccheney`> asac: do i just turn off dh_strip?
[20:12] <asac> ccheney`: some packages already ship a -dbg package on their own
[20:13] <micahg> asac: new upstream releases for stuff I haven't ported or had issues with
[20:13] <asac> ccheney`: if not, disabling dh_strip is good ... with seom luck DEB_BUILD_OPTIONS=noopt works
[20:13] <asac> micahg: if its bug only releases we don tneed a FFe
[20:13] <ccheney`> asac: ok
[20:13] <ccheney`> asac: will grab a bt then let you know
[20:13] <asac> micahg: please file bugs asap ... and give rational ... but first test if it really works/runs ;)
[20:14] <asac> ccheney`: great.
[20:14] <micahg> asac: ok, i'll check if it's bug fix only on them...I've been testing some of the stuff...new google gadgets looks good
[20:15] <micahg> asac: I'll do more due diligence on the changelogs for the upstream versions over the weekend
[20:15] <asac> micahg: yeah. take care that debian has other approach to libmozjs.so ... so we need to properly merge what we did
[20:15] <asac> micahg: ok.
[20:15] <asac> micahg: how does the insecure list look like?
[20:15] <micahg> almost done I think,, let me check
[20:15] <asac> micahg: try to focus on hardy etc. ports then
[20:16] <asac> a few merges are probably ok ... but chrisccoulson should do most i think
[20:16] <asac> ;)
[20:16] <micahg> asac: I should hand off the merges to chrisccoulson if I find them?
[20:16] <asac> yeah. so you can concentrate to get all insecure ready on all releases
[20:16] <asac> we need to roll out soonish ;)
[20:16] <micahg> asac: I have to reedit the list...I started doing testing of stuff that built and some of it's broke
[20:17] <asac> ok
[20:17] <asac> yeah. so prioritize that
[20:17] <micahg> asac: well, insecure should be good till end of April with 1.9.0.19 on march 30
[20:17] <asac> and if you see merge targets ask chris to do that
[20:17] <micahg> asac: got it
[20:17] <asac> micahg: yeah. but still ;) ... i prefer to have things now - there probably are a few issues we need to do crazy stuff for
[20:18] <micahg> asac: understood
[20:18] <fta> BUGabundo, wrt your snaps, are you using nvidia-current?
[20:18] <asac> want to know about tough things asap ;)
[20:18] <asac> so we can really do code work on those if neded
[20:18] <micahg> asac: stefansld is merging new gears with xul192 support
[20:18] <micahg> asac: well now that upstream are adding xul192, I can go grab the patches to speed porting on older releases
[20:18] <asac> if nothing happens till mid next week we should take that over
[20:19] <asac> e.g. chrisccoulson should ;)
[20:19] <asac> micahg: right. thats good
[20:19] <micahg> asac: he filed the bug last night, I grabbed it, and he said he was working on it :)
[20:19] <asac> and often helps ;)
[20:19] <micahg> asac: I'm also loving pkg-config :)
[20:19] <asac> yeah. giuve him the weekend
[20:19] <BUGabundo> fta: yep
[20:19] <asac> then we shouldnt wait if we have cycles idling that could be spend on that
[20:19] <BUGabundo> and still getting some random snaps
[20:19] <micahg> asac: I'm assuming it's ok to add pkg-config to stuff for flags?
[20:20] <BUGabundo> dinner
[20:20] <BUGabundo> back later
[20:20] <asac> micahg: well. usually we should stick to whatever upstream uses for the backports
[20:20] <asac> micahg: for future things we can try to convince upstream to move to pkg-config
[20:20] <asac> however, often thats not feasible, especially if upstream wants to be buildable with non-distro xulrunner/firefox builds
[20:21] <micahg> asac: so if they have the libs and cflags hard coded, I should do that rather than submitting a patch upstream to switch to pkg-config?
[20:21] <asac> as those are usually not coming wiht proper .pc
[20:21] <asac> so often upstream has --with-mozilla-dir ... or something
[20:21] <asac> micahg: depends ;)
[20:21] <asac> some packages have really rotten old build system stuff
[20:21] <micahg> asac: well, I was working on edbrowse and that's still dh4 compatible
[20:22] <asac> thats fine
[20:22] <micahg> having trouble linking libmozjs...I'll ping you sunday if I can't get it solved
[20:22] <asac> i dont think we should upgrade dh here in ubuntu
[20:22] <asac> rather in debian ... otherwise its a painful diff to merge all the time
[20:22] <micahg> asac: I didn't, I was tempted to use dh_xul :
[20:22] <micahg> :)
[20:22] <asac> heh
[20:22] <asac> well dh_xul is good, but submit it upstream ;)
[20:22] <asac> micahg: libmozjs? right. thats not the same as in debian
[20:23] <asac> as we are not shipping it as top level lib
[20:23] <asac> you need -Lxuldir
[20:23] <asac> and set LD_LIBRARY_PATH=...
[20:23] <asac> properly
[20:23] <fta> could someone please try this with chromium: http://people.ubuntu.com/~fta/text-canvas.html and tell me if it's readable
[20:23] <micahg> asac: LD_LIBRARY_PATH gets set in rules?
[20:23] <asac> fta: can read it  here
[20:23] <asac> fta: is that about the armel bug?
[20:23] <fta> nope
[20:24] <asac> micahg: or upstream build system
[20:24] <asac> depends
[20:24] <asac> rules proably is easier
[20:24] <fta> asac, is it the same in ff? it's not for me: http://people.ubuntu.com/~fta/fonts.png
[20:24] <asac> fta: i can read everything up to bold 14px...
[20:24] <asac> fta: yes, chromium is ugly. but i can read it ;)
[20:25] <micahg> asac: I was trying to use the mozilla-js.pc file to get libs and cflags...so I guess I was just missing LD_LIBRARY_PATH
[20:25] <asac> yeah firefox looks better
[20:25] <asac> micahg: we ship mozilla-js.pc?
[20:25] <micahg> asac: yep, I think so
[20:25] <fta> asac, you don't have the mstt fonts, do you?
[20:25] <micahg> asac: in the -dev pacakge
[20:26] <asac> fta: hmm you mstcore...?
[20:26] <asac> un  msttcorefonts
[20:26] <asac> so no
[20:26] <asac> that thing is not installed ;)
[20:26] <fta> ok, me neither
[20:26] <asac> micahg: ok. yeah i think LD_LIBRARY_PATH
[20:26] <fta> upstream says it's looking good for them :P
[20:27] <micahg> asac: I'll try sat night, I was thinking to upgrade to lucid sat night so I can dogfood this stuff better
[20:27] <asac> yeah with their nonfree arial stuff ;)
[20:27] <asac> micahg: right.
[20:27] <micahg> asac: also if archive is open again, could you or chrisccoulson push xul192-0ubuntu2 to archive please?
[20:27] <micahg> it's tagged
[20:28] <micahg> then I'll do final tests on fennec and prism and we can push those over the weekend or monday
[20:28] <asac__> we can push xul even if archive isnt open
[20:28] <asac__> it will auto get in when freeze is lifted
[20:28] <micahg> asac__: k
[20:29] <micahg> asac__: I'm assuming we are trying to remove xul191 from lucid before release, right?
[20:29] <asac__> chrisccoulson: we really need to go for latest nspr/nss soon
[20:29] <asac__> ;)
[20:29] <asac__> micahg: removing that is the plan
[20:30] <asac__> i had beta2 in mind for killing it
[20:30] <micahg> asac__:
[20:30] <asac__> together with everything that isnt ported by then
[20:30] <asac__> actually 1 week before beta2 ;)
[20:30] <asac__> which probably isnt that far ;)
[20:30] <ccheney`> wow my internet access is slow today will take a while to update my packages in my hardy vm
[20:30] <micahg> asac__: so, I've got about a week...ok :)
[20:31] <micahg> I'll try to get a full status per package on the wiki by the end of the weekend so we know where we stand
[20:31] <asac__> that would be great
[20:31] <ccheney`> moving made it go a bit faster :)
[20:31] <asac__> so we can prioritize what is important to keep
[20:31] <asac__> and what can go
[20:31] <asac__> ccheney`: so thats wifi ;)
[20:31] <asac__> reset your AP
[20:31] <asac__> and dsl modem or something
[20:32] <asac__> that often gives me huge throughput improvements
[20:32] <ccheney`> asac__: yea, working from a library today so it would be quieter :)
[20:33] <ccheney`> the gigantic webkit dbg package it taking a while to update, heh
[20:33] <asac> yeah. thats the prob always
[20:33] <asac> ccheney`: what do you see on the console when it crashes?
[20:33] <asac> just segfault?
[20:33] <asac> or any warnings/criticals etc.?
[20:34] <asac> ccheney`: so if you want to produce -dbgsym locally you can also just install pkg-dbgsym package
[20:35] <asac> and then build it with debuild -b or dpkg-buildpackage -rfakeroot
[20:35] <asac> it will just gen the same the archive gens  ;)
[20:35] <ccheney`> will pastebin it
[20:36] <ccheney`> ah found a better ap that is much faster :)
[20:37] <ccheney`> http://pastenbin.ubuntu.com/397983
[20:38] <asac> ccheney`: doesnt work
[20:38] <ccheney`> it crashes when clicking into the url bar after debian.org website loads
[20:38] <ccheney`> http://pastebin.ubuntu.com/397983
[20:38] <ccheney`> typo
[20:38] <asac> heh
[20:38] <ccheney`> i'm updating to what is in the ppa now should be done in a few min
[20:38] <ccheney`> its unpacking now
[20:39] <asac> yeah those warnings need to be fixed ;)
[20:39] <asac> EphyLocationEntry isnt GtkActivatable
[20:40] <ccheney`> yea but not sure why, i have GtkActivatable in the backport
[20:40] <ccheney`> from what i recall anyway
[20:40] <ccheney`> well or it wouldn't build, heh
[20:41] <ccheney`> should i be able to just run gdb /usr/bin/epiphany-browser then bt after it crashes?
[20:42] <ccheney`> its either running really slow or something is wrong when i try launching it from gdb
[20:42] <asac> gdb is usually slow
[20:42] <ccheney`> yea i see disk access so just slow it seems
[20:42] <asac> but i am sure we need to fix the stuff fiurst ;)
[20:43] <asac> it cant survive with such errors
[20:43] <asac> e.g. EphyLocationEntry' to `GtkActivatable'
[20:43] <asac> if you click on that it means its getting activated
[20:43] <asac> since whatever deals with that click event cannot cast, it will crash
[20:43] <ccheney`> got a backtrace but i need an unstripped epiphany i think
[20:44] <asac> ccheney`: so check the EphyLOcationEntry code
[20:44] <asac> that should implement the GtkActivatable interface
[20:44] <asac> if you post me the .c file i can check
[20:44] <asac> ccheney`: install pkg-dbgsym and rebuild epiphany if we dont have -dbg packages
[20:44] <asac> but for now do the .c file first
[20:44] <ccheney`> http://pastebin.ubuntu.com/397988
[20:45] <asac> yea
[20:45] <asac> lets focus on the warning/criticals first
[20:45] <asac> the casts have to work
[20:45] <asac> otherwise everything is unpredictable
[20:45] <asac> and a backtrace like this can easily happen
[20:46] <ccheney`> i wonder if i messed up something with the way i did the marshal backport stuff
[20:46] <asac> usually not
[20:46] <asac> but we can check that too
[20:46] <asac> lets first look at the obvious things
[20:46] <asac> EphyLOcationEntry
[20:46] <ccheney`> i might have done something wrong with that bit since it required messing with the rebuild
[20:46] <asac> -> post the .c file
[20:46] <ccheney`> er code generation at build time i mean
[20:46] <asac> could be.
[20:46] <asac> but lets go through this step by step
[20:46] <asac> with any of the warnings we see there it will not survive i am sure ;)
[20:47] <ccheney`> which c file should i post, i think i missed that part
[20:47] <asac> ccheney`: te file that implements EphyLOcationEntry
[20:47] <ccheney`> oh ok
[20:47] <asac> if that derives from something that should implement the activatable we can look at that ( i suspect our ported gtkentry thing could be a problem too)
[20:48] <asac> "IA__g_object_class_override_property: Can't find property to override for 'EphyGtkEntry::editing-canceled'"
[20:48] <ccheney`> ok patching the epiphany-browser source so i can post the built c file
[20:48] <asac> this makes me think that our EphyGtkEntry doesnt implement GtkActivatable ... but should
[20:48] <asac> ccheney`: cool
[20:48] <asac> also post the EphyGtkEntry thing ;)
[20:48] <asac> paste == post ;)
[20:49] <ccheney`> yea :)
[20:49] <ccheney`> its too big to paste directly into pastebin easily but i can put in on my people site
[20:49] <ccheney`> hmm is ppa.launchpad.net down
[20:50] <asac>  ccheney` cat file | pastebinit
[20:50] <asac> install pastebinit
[20:50] <ccheney`> ah :)
[20:50] <ccheney`> cool thanks for the tip :)
[20:50]  * ccheney` curses at his computer
[20:51] <ccheney`> oh i know whats wrong, stupid chroot
[20:52] <ccheney`> it had a stale resolv.conf
[20:52] <asac> heh
[20:52] <asac> you should add a post netup script t copy that to all chroots ;)
[20:52] <asac> i dont have that either ;)
[20:54] <ccheney`> yea, i never did that before because i forgot it changes, heh
[20:54] <ccheney`> i'm not sure how this was the first time i've ever been bitten by it
[20:56] <asac_the_2nd> if you are at home you usually have your AP as nameserver
[20:56] <asac_the_2nd> which doesnt change
[20:56] <asac_the_2nd> only when moving to library ;)
[20:57] <asac_the_2nd> or roam
[20:57] <asac_the_2nd> in general .. so at conferences/sprints ;)
[20:58] <ccheney`> yea i've used it at conferences before maybe it just happens to line up with them
[21:02] <ccheney`> http://pastebin.com/tT53wg9n  http://pastebin.com/kyyhHC3p
[21:02] <ccheney`> that is ephy-location-entry.[ch]
[21:03] <ccheney`> http://pastebin.com/CA4Hunga http://pastebin.com/nkyQMGCv
[21:03] <ccheney`> that is the EphyGtkEntry c/h
[21:04] <asac> hmm
[21:04] <asac> let me check something
[21:06] <asac> hmm ... what is AtkImplementorIface
[21:06] <asac> that is referred to in doc but isnt documented
[21:06] <ccheney`> not sure
[21:06] <ccheney`> probably accessibility
[21:07] <ccheney`> brb, gotta run to the restroom
[21:09] <ccheney`> back
[21:10] <ccheney`> iirc i just copied gtkentry verbatim from gtk and then fixed it up to work in epiphany
[21:10] <asac_the_2nd> ok
[21:10] <asac_the_2nd> so ...
[21:10] <ccheney`> so not sure about the Atk bits
[21:10] <asac_the_2nd> where is the upstream gtk tarball of the hardy version?
[21:10] <asac_the_2nd> ;)
[21:11] <asac_the_2nd> is hat 2.12?
[21:11] <ccheney`> launchpad.net/ubuntu/+source/gtk+2.0/ yea 2.12.9-3ubuntu5 apparently
[21:12] <ccheney`> https://launchpad.net/ubuntu/+archive/primary/+files/gtk+2.0_2.12.9.orig.tar.gz
[21:12] <asac_the_2nd> good
[21:12] <asac_the_2nd> just found that git.gnome.org doesnt offer tarball exports for tag
[21:12] <ccheney`> ah
[21:13] <asac> ccheney`: did you do something for GtkAccessible in general?
[21:13] <ccheney`> no
[21:13] <asac> or just copy the interface code?
[21:13] <asac> or nothing at all?
[21:14] <ccheney`> nothing at all
[21:14] <ccheney`> i didn't see any failures relating to it
[21:14] <ccheney`> so if that is the culprit it was silently failing while backporting i guess
[21:15] <ccheney`> or do you mean GtkActivatable?
[21:15] <ccheney`> i do have copies of GtkActivatable
[21:15] <asac> man you are so right ;)
[21:15]  * asac  had a brain mixup ;)
[21:16] <ccheney`> ok so i will pastebin that stuff too
[21:16] <micahg> asac: should I hand off hardy -> lucid ff upgrade bugs to chrisccoulson?
[21:16] <ccheney`> http://pastebin.com/ABSr6kSG http://pastebin.com/S0uBzVLS
[21:17] <ccheney`> asac: it appears that GtkActivatable did not exist in hardy gtk
[21:18] <ccheney`> i do see one reference to it only as a comment so i am not sure what was going on with that
[21:18] <ccheney`>  /* --- GtkActivatable glue --- */
[21:18] <asac_the_2nd> micahg: i would say so
[21:18] <asac_the_2nd> unless you know whats going on directly
[21:18] <ccheney`> under /usr/include/gtk-2.0/gtk/gtkaccelgroup.h
[21:19] <micahg> asac_the_2nd: will you be available on sunday at all?
[21:19] <asac_the_2nd> ccheney`: is there anything in epiphany referring to GtkActivatable?
[21:20] <ccheney`> let me see
[21:21] <asac_the_2nd> or did you add anything in your backport referring to GtkActivatable?
[21:21] <asac_the_2nd> e.g. in gtk/soup
[21:21] <ccheney`> not the classname itself, let me see about function calls
[21:22] <ccheney`> i don't recall seeing it outside of epiphany though
[21:22] <ccheney`> yea its in several files in epiphany
[21:23] <ccheney`> lib/egg/egg-editable-toolbar.c
[21:23] <ccheney`> src/bookmarks/ephy-bookmarks-ui.c
[21:23] <ccheney`> src/bookmarks/ephy-topic-action.c
[21:23] <ccheney`> src/ephy-location-action.c
[21:23] <ccheney`> src/ephy-window.c
[21:24] <ccheney`> hmm i wonder if lib/egg/egg-editable-toolbar.c is the culprit somehow
[21:24] <ccheney`> it has weird gtk checks around calls to it, the others didn't and i included the header for those other ones
[21:25] <ccheney`> the lib/egg/egg-editable-toolbar.c code looks like this:
[21:25] <ccheney`> #if GTK_CHECK_VERSION (2, 16, 0) action = gtk_activatable_get_related_action (GTK_ACTIVATABLE (widget));
[21:25] <ccheney`> #else action = gtk_widget_get_action (widget);
[21:25] <ccheney`> #endif
[21:25] <ccheney`> hmm should be a link break after 0)
[21:25] <ccheney`> and the after the #else
[21:25] <ccheney`> http://pastebin.com/2M3gfnbn
[21:25] <ccheney`> that has the whole thing hopefully non-corrupted
[21:26] <ccheney`> if that file is the problem it should be relatively easy to fix :)
[21:31] <ccheney`> asac_the_2nd: still here?
[21:32] <asac_the_2nd> yeah
[21:32] <ccheney`> asac_the_2nd: ok
[21:32] <asac_the_2nd> ccheney`: let me get the epiphany source
[21:33] <ccheney`> ok
[21:34] <ccheney`> they are going to close the library in about 20m, so after that i will head home and will be back online around 22:20 UTC
[21:34] <ccheney`> but i will be here until they close
[21:36] <asac_the_2nd> ccheney`: can you please export G_DEBUG=fatal-warnings
[21:37] <asac_the_2nd> and then run it under gdb and get a backtrace where it breaks?
[21:38] <asac_the_2nd> oh its fatal_warnings
[21:38] <asac_the_2nd> ccheney`: ^
[21:38] <ccheney`> ok will do
[21:38] <asac_the_2nd> e.g. see here
[21:38] <asac_the_2nd> http://library.gnome.org/devel/glib/unstable/glib-running.html
[21:43] <ccheney`> http://pastebin.ubuntu.com/398011/
[21:44] <ccheney`> iirc before i patched that to be EphyGtkEntry it collided with GtkEntry
[21:47] <ccheney`> the actual terminal output it gave was:
[21:47] <ccheney`> GLib-GObject-WARNING **: IA__g_object_class_override_property: Can't find property to override for 'EphyGtkEntry::editing-canceled'
[21:47] <asac> yeah
[21:48] <asac> ccheney`: and you get that when you click on the url?
[21:48] <asac> or right on startup ( i guess the latter)
[21:48] <ccheney`> i think right on startup
[21:48] <ccheney`> i don't recall it coming up all the way this time
[21:48] <ccheney`> trying again to be sure
[21:49] <ccheney`> it pops up a recover dialog
[21:49] <ccheney`> i click don't recover
[21:49] <ccheney`> then it crashes
[21:49] <ccheney`> with the debug option set
[21:49] <asac> yeah
[21:49] <asac> and without it takes till activation/click?
[21:49] <ccheney`> yea
[21:50]  * ccheney` seeing how far i can get with it
[21:51] <ccheney`> i can use the menu, if i click on the url it crashes, or if i click on go->location it hangs
[21:51] <ccheney`> looks like the same crash
[21:51] <asac> ok
[21:51] <ccheney`> it just hanged because i was in gdb
[21:51] <asac> let me check something quick
[21:52] <ccheney`> gotta leave the library now, should be back within 20-30m
[21:53] <asac> ccheney`: ok one quick thing:
[21:53] <asac> http://pastebin.com/jPJuFMU2
[21:53] <asac> ccheney`: that one shows that ACTIVATABLE is only used for get_related_action
[21:53] <asac> and set_related_action
[21:53] <asac> that needs to be ported to the old funcs that are called
[21:54] <asac> gtk_action_connect_proxy
[21:54] <asac> (for set_related_action - take care the arguments are flipped here)
[21:54] <asac> and gtk_widget_get_action
[21:54] <asac> for gtk_accessible_get_related_action
[21:54] <asac> then you change the GTK_ACCESSIBLE cast to GTK_WIDGET
[21:55] <asac> and can drop all the impl/header parts you added for GtkActivatable
[21:55] <asac> ccheney`: ^
[21:55] <asac> anyway. lets talk in 40 min
[22:07] <asac> [reed]: can we trade this against s/Ubuntu Linux/Ubuntu/ on mozilla.org? ;)
[22:07] <asac> and mozilla.com ;)
[22:11] <ccheney`> back
[22:17] <[reed]> asac: where?
[22:24] <ccheney`> asac: so revert the gtkactivatable part of the patch and switch the parts that use it over to the other code and see how that goes?
[22:24] <ccheney`> asac: what about the crash on startup with the debug enabled?
[22:26] <asac> [reed]: http://www.google.com/search?q=site%3Amozilla.org+%22Ubuntu+Linux%22&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:en-US:unofficial&client=firefox
[22:27] <[reed]> eh
[22:27] <asac> ccheney`: yeah. write a patch for epiphany ;)
[22:27] <asac> ccheney`: that uses the old action api
[22:27] <asac> like i described
[22:27] <[reed]> there's nothing there that's in one particular place or anything super-official
[22:28] <asac> [reed]: yes, the trade isnt ment seriously (at least from me)
[22:28] <asac> anyway, http://www.google.com/search?hl=en&safe=off&client=firefox&hs=CFl&rls=com.ubuntu:en-US:unofficial&q=site:mozilla.com+%22Ubuntu+Linux%22&start=40&sa=N
[22:28] <asac> also on mozilla.com
[22:28] <asac> i think we should check whta is from more or less official places
[22:28] <asac> some might be in there
[22:29] <ccheney`> ok
[22:29] <[reed]> those are forum threads
[22:30] <ccheney`> asac: the editing-canceled part seems to be in gtkentry so reverting gtkactivatable bits will help with that i guess?
[22:31] <asac> [reed]: there are some that arent: http://support.mozilla.com/cs/kb/Setting+Firefox+as+the+default+browser+does+not+work
[22:32] <asac> ccheney`: not sure about that one. just looked for Activatable ting in general
[22:32] <asac> ccheney`: editing-canceled seems to be related to GtkCellRenderer
[22:32] <asac> but lets first do the accessible and then see
[22:32] <asac> let me look at th ecanceled in the meantime
[22:33] <ccheney`> ok
[22:35] <asac> so its only used by GtkCellRendererText
[22:35] <asac> let me check what was done in 2.12
[22:35] <ccheney`> ok
[22:38] <asac> ccheney`: yeah. i think you can just drop that property definition
[22:38] <asac> from the patch
[22:39] <asac> isnt used anyway, and the rest still accesses the old private field: editing_cancelled
[22:39] <asac> err
[22:39] <asac> editing_canceled
[22:40]  * asac checks what other warnings we have
[22:41] <asac> cool. seems thats all the warnings we see before the current crash
[22:41] <asac> might see new ones after that
[22:42] <asac> let me know if you havent fixed it in 10 ;)
[22:44] <ccheney`> heh ok
[22:51] <ccheney`> asac: what do i do with the set_activatable functions, etc?
[22:51] <ccheney`> asac: eg ephy_gtk_entry_set_icon_activatable
[22:52] <asac_the_2nd> ccheney`: those dont exist?
[22:52] <asac_the_2nd> i would think you can keep them
[22:52] <asac_the_2nd> let me check the impl
[22:52] <ccheney`> ok yea it looks like they don't actually use GtkActivatable for some reason
[22:52] <ccheney`> maybe i am confused, heh
[22:53] <ccheney`> maybe its a reuse of a word that makes me confused, heh
[22:54] <ccheney`> ok yea i don't see where gtkentry is using GtkActivatable at all
[22:54] <ccheney`> so maybe its just reuse of the term
[22:54] <asac> ccheney`: dont think its a problem to keep those
[22:54] <asac> they dont refer to GtkActivatable
[22:54] <asac> yes.
[22:54] <asac> lets hope its confusing reuse
[22:54] <asac> seems to just set a special icon for activatables ;)
[22:55] <asac> which are probably all that have a action ;)
[22:55] <ccheney`> ok
[22:57] <ccheney`> i think i removed the GtkActivatable bits from my patch now to convert the remaining references to it and rebuild
[22:58] <asac> good
[22:58] <asac> ccheney`: instructions are clear for the two cases?
[23:00] <asac_the_2nd> ccheney`: so for first get_related_action in
[23:01] <asac_the_2nd> ephy-location-action.c
[23:01] <asac_the_2nd> use
[23:01] <asac_the_2nd>         action = gtk_activatable_get_related_action (GTK_ACTIVATABLE (proxy));
[23:01] <asac_the_2nd>         action = gtk_widget_get_action (GTK_WIDGET (proxy));
[23:01] <asac_the_2nd> e.g. replace the first with the second
[23:01] <asac> hmm
[23:02] <ccheney`> ok
[23:02] <ccheney`> that looks pretty simple
[23:03] <asac> ccheney`: well that place is odd
[23:03] <asac> because it gets related_action from an action
[23:03] <asac> the other matches look more straight forward
[23:03] <asac> like i said
[23:04] <asac> err
[23:04] <asac> i think that func signature is just wrong ;)
[23:04] <asac> should be entry_activate_cb ... GtkWidget *proxy
[23:04] <asac> so yeah do i there too
[23:04] <asac> most likely the cast is fine
[23:06] <asac> yeah. the function signature is wrong ;)
[23:06] <asac> heh
[23:07] <asac> proxy is a Widget ;)
[23:07] <asac> not a EphyLocationAction
[23:08] <ccheney`> so is it the same for this one? src/bookmarks/ephy-topic-action.c:              active_action = (EphyTopicAction*)gtk_activatable_get_related_action (GTK_ACTIVATABLE (ancestor));
[23:08] <ccheney`> just turn it into (EphyTopicAction*)gtk_widget_get_action (GTK_WIDGET (ancestor)); ?
[23:09] <ccheney`> if its safe i can just search replace them all :)
[23:22] <asac> ccheney`: it should be the same for every match
[23:22] <asac> yes.
[23:23] <asac> so a smart replace should work ;)
[23:24] <asac_the_2nd> so seems no "set_related" is used in ephy code
[23:24] <asac_the_2nd> so that might be all
[23:24] <asac_the_2nd> otherwise we would use gtk_action_connect_proxy
[23:25] <asac_the_2nd> with flipped parameters
[23:27] <asac> ccheney`: all done ;)
[23:27] <asac> ?
[23:27] <ccheney`> yea doing a build now
[23:27] <asac> cool
[23:27] <ccheney`> i nuked the gtkactivatable files and did a replace on the code using it and started the build
[23:27] <asac> yeah
[23:28] <asac> ccheney`: did you also already drop the editing-canceled property override?
[23:28] <asac> (and its implementation to make it clean)
[23:28] <ccheney`> oh i forgot to drop that part yet
[23:28] <asac> yeah. shouldnt be a problem
[23:28] <asac> dont stop the build for that ;)
[23:28] <ccheney`> ok will add that once i test the activatable bits
[23:29] <asac> yes, we want to see what warnings we get now
[23:29] <asac> and fix those
[23:29] <asac> and so on ;)
[23:29] <ccheney`> ok
[23:30] <ccheney`> wow that built fast, /me hugs ccache
[23:30] <asac> heh
[23:30] <asac> lets hope that does the right thing 100% ;)
[23:30] <ccheney`> i enable ccache by default in chroot since i rebuild so often, heh
[23:30] <asac> yeah
[23:31] <asac_the_2nd> ccheney`: paste ;)
[23:31]  * asac_the_2nd goes offline because thats too confusing ;)
[23:31] <asac> so here only now
[23:33] <asac> ccheney`: what happened ;)
[23:33] <asac> ?
[23:33] <ccheney`> didn't crash until i started typing in the bar now :)
[23:33] <asac> paste console
[23:34] <ccheney`> http://pastebin.ubuntu.com/398059/
[23:34] <asac> state-changed
[23:35] <ccheney`> yea
[23:35] <ccheney`> thats in gtkentry and ephy-bookmarks
[23:36] <asac> ccheney`: drop the editing-canceled so we can fail for warning
[23:36] <asac> and can get a backtrace
[23:36] <asac> hmm
[23:36] <asac> gtkentry?
[23:37] <ccheney`> lib/gtk-gtkentry (the EphyGtkEntry backport file)
[23:38] <ccheney`> to drop editing-canceled do i just remove the code that refers to it on these lines?
[23:38] <ccheney`> lib/widgets/ephy-node-view.c:           g_signal_connect (renderer, "editing-canceled",
[23:38] <ccheney`> lib/gtk-gtkentry.c:                                    "editing-canceled");
[23:38] <ccheney`> or leave it in lib/widgets/ephy-node-view.c and remove it from lib/gtk-gtkentry.c ?
[23:44] <ccheney`> asac: still here?
[23:44] <asac> ccheney`: not sure.
[23:44] <ccheney`> asac: ah ok
[23:44] <asac> i think from the patch for sure
[23:44] <ccheney`> ok i can try just removing it there and see what happens
[23:44] <asac> yeah
[23:45] <asac> ccheney`: the one is a signal
[23:45] <asac> ccheney`: the other is aproperty
[23:45] <asac> just the properly doesnt exist ... and thats in the patch
[23:45] <asac> ;)
[23:45] <asac> (now i remembered what why i said that above ;))
[23:45] <asac> so yeah. just the gtk-gtkentry.c ... as that is property_override
[23:46] <asac> also drop the PROP_EDITING_CANCELLED
[23:46] <asac> and the code that deals with that in set_ and get_property
[23:46] <asac> so +  PROP_IM_MODULE,
[23:46] <asac> +  PROP_EDITING_CANCELED
[23:46] <asac> +};
[23:46] <asac> +    case PROP_EDITING_CANCELED:
[23:46] <asac> +      entry->editing_canceled = g_value_get_boolean (value);
[23:46] <asac> +      break;
[23:46] <asac> +
[23:47] <asac> +    case PROP_EDITING_CANCELED:
[23:47] <asac> +      g_value_set_boolean (value,
[23:47] <asac> +                           entry->editing_canceled);
[23:47] <asac> +      break;
[23:47] <asac> +
[23:47] <asac> ccheney`: ^^ drop those from the patch too
[23:47] <asac> e.g. from enum and from the "case ..."
[23:47] <ccheney`> rebuilding
[23:47] <asac> keep the build ;)
[23:47] <asac> and make it incremental ;) ... thats faster
[23:47] <ccheney`> ah i forgot the EDITING part
[23:47] <ccheney`> will redo that now
[23:48] <asac> yeah
[23:48] <asac> that has to go too
[23:48] <asac> its not used code otherwise
[23:49] <ccheney`> is it safe to leave it in the enum, just remove the code references, or should it all go?
[23:50] <asac> ccheney`: all go
[23:50] <asac> also the enum
[23:50] <asac> imo
[23:50] <ccheney`> ok
[23:50] <ccheney`> i'm just commenting it out atm in case we need it for some reason later
[23:51] <ccheney`> ok building now
[23:53] <ccheney`> built, installing now and testing
[23:53] <asac> i think the state-changed connect we can remove too .... have to check if there is some other way to implement the caps lock feature
[23:53] <asac> otherwise thats just missing ;)
[23:54] <ccheney`> getting somewhere now
[23:54] <ccheney`> different crash
[23:55] <ccheney`> http://pastebin.ubuntu.com/398067
[23:56] <asac> yeah
[23:56] <asac> ccheney`: so state-changed we can implement later with GDK_LOCK_MASK
[23:56] <ccheney`> i don't see any references to GTK_IS_ENTRY or regular GtkEntry in our code
[23:56] <asac> gdk_event
[23:57] <asac> ccheney`: please run with G_DEBUG=critical_fatal
[23:57] <ccheney`> ok
[23:57] <asac> ccheney`: fatal_criticals
[23:57] <asac> sorry
[23:58] <asac> we want to see where that is called
[23:58] <asac> seems the callback goes into the GTK_ENTRY
[23:58] <ccheney`> running now
[23:58] <asac> rather than in ours
[23:58] <ccheney`> doh i forgot to build epiphany with symbols again :(
[23:58] <ccheney`> but i do have the dbg part installed i think
[23:59] <ccheney`> oh no forgot that to, retrying now