[00:15] <micahg> chrisccoulson: it's already been promoted to main as well
[00:15] <micahg> asac: yes, tagged also
[00:37] <skipper> asac: using your proposed patch let firefox start
[00:38] <asac> skipper: you mean for the extension stuff?
[00:38] <skipper> asac: yes
[00:38] <asac> very good
[00:38] <asac> ;)
[00:38] <asac> skipper: can you post xpti.dat again ;)
[00:40] <bdrung> asac: http://pastebin.com/kinEcEqP
[00:41] <asac> yeah that looks better
[00:41] <asac> will put that in tomorrow ;)
[00:41] <asac> thanks!
[00:41] <asac> might be upstream wants it upside down (e.g. all normalized) ... but we will see
[00:41] <micahg> asac: can we throw 3.6.2 build 1 in as soon as it's spun or do we have to wait for release (lucid only)
[00:42] <asac> micahg: we need to explicitly label it as "build1" for lucid
[00:42] <micahg> asac: of course :)
[00:42] <micahg> but that means no backbranching :)
[00:42] <asac> thats ok then ... though if we roll it as a security update we usually should stage everything and wait till final
[00:42] <bdrung> asac: you're welcome
[00:42] <asac> micahg: problem is that SPUN isnt the same time a tag show sup
[00:42] <micahg> asac: well, the only "release" it's in is lucid
[00:42] <asac> we have to wait till they officially go into beta
[00:42] <asac> have you heard when that will be?
[00:43] <micahg> asac: well, QA starts tomorrow
[00:43] <asac> right. so in a few days or so
[00:43] <micahg> I haven't seen a plan for beta yet
[00:43] <asac> they usually do pre-QA before naming something build1 ;)
[00:43] <micahg> k
[00:44] <micahg> so, I'll commit changes to the branch assuming we'll spin beta 1 (build 1) to lucid when it's ready?
[00:44] <asac> you can commit on .head
[00:44] <asac> but dont move it to build1 in changelog until there is a build1 ;)
[00:45] <micahg> asac: k
[00:45] <asac> we are still riding a pre build1 in dailies ;)
[00:46] <micahg> asac: do I have to worry about the PPA builds cleaning properly?
[00:46] <asac> micahg: if you see a build you cant fix ask chrisccoulson to look ... so he gets started too ;)
[00:47] <asac> cant fix == time constraint
[00:47] <asac> at least pinging ;)
[00:47] <micahg> asac: k, I asked him to fix openjdk :)
[00:47] <asac> better than having it dying all the time
[00:47] <asac> fta hates us for doing that ;)
[00:47] <micahg> I have no idea what to do with openjdk
[00:47] <micahg> asac: oh, you mean dailies?
[00:47] <chrisccoulson> yeah, i need to check openjdk again against the latest version of llvm
[00:47] <asac> micahg: yes. dailies failing for weeks is bad ;)
[00:47] <chrisccoulson> and then open a bug report if it still fails
[00:47] <asac> we had that ;)
[00:47] <micahg> asac: only daily failures I know why
[00:48] <micahg> 3.6.2 on hardy due to kde patch
[00:48] <asac> openjdk is off the table until doko fixes it
[00:48] <asac> fro mwhat i understand it doesnt build at all atm
[00:48] <micahg> 193 on karmic/lucid due to gcc 4.4 issue
[00:48] <asac> we need to file a bug
[00:48] <micahg> asac: for openjdk?
[00:48] <asac> micahg: thats something we should fix and submit upstream usually
[00:48] <chrisccoulson> asac - i will try another build overnight , since doko updated llvm again
[00:49] <asac> chrisccoulson: ah cool
[00:49] <chrisccoulson> if it still fails, i'll open a bug report in the morning
[00:49] <asac> micahg: yeah. but seems we are making progress ,)
[00:49] <micahg> ah, so, chrisccoulson, you want to look at the failure for xulrunner 1.9.3 in daily PPA?  I filed a bug upstream
[00:49] <asac> just saying we shouldnt invest much time on openjdk when there are still low hanging fruits ;)
[00:49] <chrisccoulson> yeah, can do
[00:49] <micahg> chrisccoulson: mozilla 550823
[00:49] <chrisccoulson> thanks
[00:51] <ccheney> asac: do you happen to know what i should do about getting gtk_marshal bits to work, the new code needs more than what is in the gtk/gtkmarshal.h in hardy
[00:52] <chrisccoulson> asac - there's another issue blocking openjdk now anyway: http://launchpadlibrarian.net/40585661/buildlog_ubuntu-lucid-amd64.llvm_2.7~svn20100308-0ubuntu2_MANUALDEPWAIT.txt.gz
[00:52] <ccheney> asac: it seems to be some sort of weird autogenerated code
[00:52] <chrisccoulson> it seems oprofile needs a MIR
[00:52] <asac> ccheney: yeah
[00:52] <asac> chrisccoulson: there is a text file usually
[00:52] <asac> oops
[00:52] <asac> thats for ccheney
[00:52] <chrisccoulson> heh
[00:52] <asac> so idea is to make a new gtkmarshal_backports.h i guess
[00:52] <asac> or something
[00:52] <ccheney> asac: should i just add the items to the .list files in hardy and rebuild gtk with them?
[00:53] <asac> with the lines added to that .list files in between
[00:53] <asac> ccheney: i would suggest to not do that in gtk
[00:53] <asac> rather in epiphany where you need them
[00:53] <ccheney> asac: oh ok, wasn't sure how to regenerate it properly but i can try just copying what is in the h/c files and see if that works ok
[00:53] <asac> ccheney: beter do it with .list file
[00:53] <asac> ccheney: the tool used in Makefile somewhere is
[00:53] <micahg> asac: chrisccoulson could also work on staging thunderbird 2.0.0.24 for security PPA (release is March 15)
[00:53] <ccheney> ok
[00:54] <asac> glib-genmarshal
[00:54] <asac> ccheney: ^^
[00:54] <asac> you should be able to spot where its used in gtk to update that .h
[00:55] <ccheney> yea i found the Makefile.am snippet to do it
[00:55] <asac> cool
[00:55] <asac> just use some prefix for the marshals
[00:55] <ccheney> ok
[00:55] <asac> and replace them in the copied gtk code ;)
[00:56] <asac> accordingly
[00:56] <asac> that should work well
[00:56] <micahg> asac: also, can we file 1 big FFe bug and then file separate bugs for each of the changes?
[00:57] <asac> micahg: which changes?
[00:57] <asac> which FFe?
[00:57]  * ccheney bbl getting dinner
[00:57] <micahg> asac: well, debdiffs, do we need an FFe for each apckage?
[00:57] <asac> no
[00:57] <asac> those are bugs
[00:58] <asac> if we dont introduce a new upstream version
[00:58] <asac> just file bug: "needs porting to xul 1.9.2"
[00:58] <asac> or
[00:58] <asac> just file bug: "needs porting to xul 1.9.2 or remove from archive ;)"
[00:58] <micahg> asac: k, great, so I don't we need any FFes then except for maybe helix-player if I do it
[00:58] <asac> right
[00:59] <micahg> asac: well, fennec is currently alpha, does that need one for the release?
[00:59] <asac> rule: if you need to pull new upstream -> FFe
[00:59] <asac> if you dont -> just bug
[00:59] <micahg> well, prism beta 3 is bugfix I think
[00:59] <asac> i its bugfix only its not FFe
[00:59] <asac> though moving from final versoin to beta often suggests its not bug fix only ;)
[00:59] <micahg> fennec really changed so I'll file FFe for that one one mozilla-devscripts is in
[00:59] <asac> so we should check what really changed
[00:59] <micahg> asac: prism isn't final
[01:00] <asac> micahg: file a porting bug anyway on fennec
[01:00] <micahg> yes...
[01:00] <asac> its easier to argue that we need it to fix the porting bug
[01:00] <asac> FFe will then be granted more easily
[01:01] <micahg> asac: well, yes, the alpha won't run xul 192 :)
[02:34] <ejat> !ping fta
[02:40] <ejat> bugs 529242
[02:40] <ejat> anyone have the same issues?
[07:10] <ccheney> asac: hmm copying the new stuff over seems to be working but the new gtkentry seems to use signal handling, etc from new gtk as well, looks like it will be copying over a lot more than i had expected
[07:11] <ccheney> i guess those must be inline or something, not sure why it those didn't show up in the symbol search before :-\
[07:14]  * ccheney is seeing some weird private functions with no apparent definitions or macros as well, not sure what is going on with those
[07:14] <ccheney> i'll just copy the declaration and see if it magically works, heh
[07:15] <ccheney> ah i found the definition for that one actually, just weird declaration in a different place
[07:32] <ccheney> asac: i'm getting weird errors about ephy_gtk_entry_parent_class being undeclared, did gtk change how they do parent classes between hardy and lucid?
[08:04]  * ccheney heads off to bed
[08:04] <ccheney> asac: looks like i will have to do something similiar got GtkEntryCompletion as well, they didn't privatize it within Gtk from GtkEntry and it uses its private members
[08:05] <ccheney> s/got/to/
[08:35] <BUGabundo_remote> morning
[10:18] <asac> ccheney: ephy_gtk_entry_parent_class
[10:19] <asac> you usually have to "peek" for the parent_class
[10:19] <asac> maybe you missed a declaration line a bit above or something
[10:19] <maxb> Hi. spidermonkey-bin was removed from lucid yesterday because it was built from xulrunner (1.8). Would it make sense to file a bug asking it to be built by xulrunner-1.9.x, like it is in Debian?
[10:24] <directhex> maxb, if it can be built by 1.9.2..... is there any reason for it to differ in ubuntu compared to debian?
[10:25] <maxb> As far as I can conjecture, it just got forgotten, as part of the delta of using versioned xulrunner source packages in ubuntu
[11:03] <asac> spidermonkey-bin
[11:03] <asac> thats not produced from xulrunner sources
[11:23] <chrisccoulson> heh, python-gtkmozembed nearly caught me out there
[11:56] <bdrung> asac: can you have a look at bug #535544?
[12:03] <asac> we dont want all .js files to go there
[12:04] <asac> what we should do is to guess a name that is alphabetically lower than all other preferences fils
[12:04] <asac> create that and link it to an empty file in /etc/
[12:04] <asac> in that way admins can change the defaults
[12:04] <asac> without loosing ability to reset to package defaults
[12:04] <asac> like the file we have for ubufox
[12:05] <asac> bdrung: we have 000system.js there
[12:05] <asac> thats a link to /etc/...
[12:06] <bdrung> asac: can you write this comment to the bug, please?
[12:06] <asac> feeel free to paste it there
[12:06] <bdrung> asac: what's the best place to put the *.js links?
[12:06] <asac> bdrung: in EXTDIR/defaults/preferences
[12:06] <asac> i think 000system is a good guess
[12:06] <asac> though not perfect
[12:07] <bdrung> asac: what's the best place to put the *.js links in the /etc directory?
[12:07] <asac> if you ask where in /etc
[12:07] <asac> i dont care
[12:07] <asac> its ok to use a /etc/xul-ext/PACKAGE/
[12:07] <bdrung> asac: i ask for your preferences
[12:07] <asac> if we want to have a hierarchy
[12:07] <asac> i like /etc/xul-ext/PACKAGE/pref/
[12:07] <bdrung> asac: so many subdirectories?
[12:08] <asac> bdrung: what do you mean?
[12:08] <asac> the pref/ ?
[12:08] <asac> i dont care
[12:09] <asac> i jus tthink maybe a package needs other config
[12:09] <asac> hmm
[12:09] <asac> but now that i think about ti
[12:09] <asac> we will ship exactly one .js
[12:09] <bdrung> asac: wouldn't /etc/xul-ext/adblock-plus.js -> /usr/share/xul-ext-ablock-plus/defaults/preferences/000system.js enough?
[12:09] <asac> so we can say: /etc/xul-ext/PACKAGE.js
[12:09] <asac> righ t;)
[12:09] <asac> deal
[12:09] <bdrung> great
[12:09] <asac> not sure if we should use /etc/xul-ext/prefs/PACKAGE.js
[12:09] <asac> your choice
[12:10] <asac> i am fine with or without pref
[12:10] <bdrung> asac: is there any possibility to need more in /etc/xul-ext?
[12:10] <asac> i hope not ;)
[12:10] <asac> but you never know up front ;)
[12:11] <asac> for me it feels safer ;)
[12:11] <asac> but just marginally in this case
[12:11] <asac> so i am fine with /etc/xul-ext/PACKAGE.js
[12:11] <asac> if we find stuff later we can create /etc/xul-ext-later/ or transition ;)
[12:12] <bdrung> asac: if we find stuff later we can still create subdirectories in /etc/xul-ext
[12:12] <asac> nice. like the idea to have three levels everywhere: package, system, user config
[12:12] <asac> or that ... yeah ;)
[14:23] <bdrung> asac: your input is needed: bug #535544
[14:34] <asac> didnt you paste what i said ;)?
[14:36] <bdrung> asac: i did, but someone forgot to start you in verbose mode ;)
[14:37] <bdrung> asac: you can talk to dkg directly on #debian-mozext if you want
[14:40] <bdrung> asac: what do you think about http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573250? what's the opinion of upstream about these directories?
[14:43] <asac> checking
[14:44] <asac> bdrung: i think the policy is not accurate
[14:44] <asac> it shouldnt talk about unpacking to common, but linking
[14:45] <asac> also it should make more clear that common is for extensions that only extend xulrunner toolkit ... and that have toolkit@mozilla.org as a install target
[14:45] <bdrung> asac: do we really want a link in common?
[14:45] <asac> only for extensions that have toolkit@mozilla.org as targetApp
[14:45] <bdrung> asac: k
[14:45] <asac> which in theory makes sense.
[14:45] <asac> the rest get linked to the indvidual applications
[14:46] <asac> if the extension author knows about it, he doesnt need to add the individual targets
[14:46] <bdrung> asac: please write this and adjust the policy draft
[14:46] <asac> toolkit@mozilla.org should work on everything toolki8t
[16:00] <micahg> chrisccoulson: you working on anything now?
[16:00] <chrisccoulson> hi micahg - sort of, how come?
[16:01] <chrisccoulson> i'm just about to look at your work for couchdb actually
[16:01] <micahg> chrisccoulson: k, I saw gnome-python-extras was uploaded
[16:01] <chrisccoulson> (it's the last think on the CD pulling in xulrunner-1.9.1)
[16:01] <micahg> oh, I think that's done, it needed to be tested
[16:01] <micahg> from the PPA
[16:01] <micahg> I can file the debdiff and bug
[16:02] <chrisccoulson> micahg - gnome-python-extras nearly caught me out, because it built fine, and applications using python-gtkmozembed still ran ok
[16:02] <chrisccoulson> but then i straced it, and realised it was still loading the old GRE
[16:02] <chrisccoulson> and when i patched it load the new one, it failed miserably ;)
[16:02] <micahg> chrisccoulson: I discovered that with firegpg as well, built fine locally, but code was broke
[16:02] <micahg> so we definitely need to test
[16:03] <directhex> now that xulrunner-dev 1.9.2 is in, should i upload my moon package to the archive, or wait for you guys to do it?
[16:03] <micahg> directhex: if it's tested, you can do it
[16:07] <chrisccoulson> directhex - i'm currently focused on things which are seeded right now, and will start processing other things afterwards. feel free to upload moon if you have some spare time, but if not, I will get round to it eventually :)
[16:08] <micahg> chrisccoulson: I'm filing bugs for the fixes for couchdb
[16:08] <chrisccoulson> micahg - thanks
[16:08] <directhex> chrisccoulson, i'll take care. just takes forever & a day to run "debuild -S" on this machine
[16:08] <chrisccoulson> heh ;)
[16:21] <micahg> chrisccoulson: bug 536737 is everything checks out
[16:22] <chrisccoulson> micahg - excellent, thanks
[16:24] <chrisccoulson> micahg - i asked pitti to add a lucid task to it
[16:24] <micahg> chrisccoulson: yep, he did :)
[16:24] <chrisccoulson> so, it becomes a release blocker now ;)
[16:25] <micahg> chrisccoulson: I'm trying to fix firegpg right now
[16:25] <micahg> chrisccoulson: do you need me to test couchdb or can you do it?
[16:26] <chrisccoulson> it would probably be better if we both test it
[16:26] <chrisccoulson> although, i'm not entirely sure how to test it yet
[16:26] <chrisccoulson> i suppose i could just use gwibber for a bit
[16:26] <micahg> k
[16:26] <micahg> let me fire up lucid
[16:32] <chrisccoulson> micahg - i can actually sponsor couchdb
[16:32] <chrisccoulson> i didn't realise
[16:32] <chrisccoulson> Archive Upload Rights for ubuntu-desktop: package set 'ubuntu-desktop' in lucid
[16:32] <chrisccoulson> cool!
[16:32] <micahg> cool
[16:33] <micahg> let's make sure it works though :)
[16:33] <chrisccoulson> but i will have to get someone else to review the change really
[16:55] <chrisccoulson> micahg - couchdb seems to be working ok here
[16:55] <chrisccoulson> i removed /etc/gre.d/1.9.1.8.system.conf too, and restarted
[16:55] <micahg> chrisccoulson: k, they just use mozjs so I wouldn't expect too much to break
[16:56] <micahg> I haven't got around to testing yeet
[16:56] <chrisccoulson> cool
[16:56] <chrisccoulson> well, i think i'm nearly happy enough to just upload, and i've got an ACK from someone more familiar with couchdb too
[17:00] <chrisccoulson> micahg - couchjs is still loading libmozjs.so from 1.9.1.8 here
[17:00] <chrisccoulson> ah
[17:01] <chrisccoulson> thats because /usr/bin/xulrunner is still symlinked to the 1.9.1 version
[17:01]  * chrisccoulson tries again
[17:01] <chrisccoulson> brb
[17:03] <micahg> chrisccoulson: can you try removing xulrunner191 or redirecting to see if it still works?
[17:03] <chrisccoulson> micahg - i just "sudo update-alternatives --config xulrunner"
[17:03] <chrisccoulson> and selected the right version
[17:03] <micahg> yeah, k
[17:04] <chrisccoulson> hmmm, it still loads 1.9.1.8
[17:05] <chrisccoulson> time for the sledgehammer approach
[17:10] <chrisccoulson> micahg - i removed xulrunner-1.9.1 entirely now, but now when i do "cat /proc/`pidof couchjs`/maps", i get:
[17:10] <chrisccoulson> 7f29165d3000-7f29167d2000 ---p 000b7000 08:01 1840027                    /usr/lib/xulrunner-1.9.1.8/libmozjs.so (deleted)
[17:10] <chrisccoulson> so, it must be hardcoded somewhere :-/
[17:11] <micahg> chrisccoulson: k, I'll check
[17:12] <micahg> chrisccoulson: are you using the version from the PPA?
[17:12] <chrisccoulson> michag - i built it locally using the patch attached to the bug report
[17:12] <micahg> chrisccoulson: yeah, so if you have xulrunner 191 installed when you build, it'll use that for part of it
[17:12] <micahg> I can patch rules to fix that
[17:13] <micahg> chrisccoulson: should I add a new debdiff with that fixed?
[17:13] <chrisccoulson> one second, i'll check the build log
[17:14] <chrisccoulson> micahg - it build with only 1.9.1 installed
[17:14] <micahg> hmm, control says it requires 1.9.2
[17:14] <chrisccoulson> sorry, i meant it built with 1.9.2
[17:14] <chrisccoulson> oops;)
[17:15] <chrisccoulson> brb, i will try a full restart and see what happens
[17:18] <chrisccoulson> michag - it works fine after a restart
[17:19] <micahg> chrisccoulson: yeah, the program probably cached soemthing
[17:19] <chrisccoulson> so, i'm happy with that now
[17:19] <chrisccoulson> i'm ready to upload unless you want to do anything else with it
[17:20] <micahg> well, if you tested an intereface with JS in it, then, ok
[17:20] <micahg> I haven't gotten an app loaded yet, so I haven't tested
[17:22] <micahg> chrisccoulson: lernid seems to be fine, so go for it
[17:27] <chrisccoulson> michag - uploaded
[17:27] <chrisccoulson> i don't have a rejection e-mail yet, so i hope it worked
[17:27] <micahg> chrisccoulson: thanks, k, no next, can you work on gluezilla?
[17:27] <micahg> s/no/so/
[17:27] <chrisccoulson> yeah, i can look at that too
[17:28] <micahg> I'm having trouble with the config system, it seems to run configure during patching which means I can't patch it
[17:29] <chrisccoulson> yeah, sometimes we get weird issues like that if we have patches which touch the build system
[17:29] <micahg> chrisccoulson: I've never seen this before
[17:30] <micahg> chrisccoulson: here's the patch for configure: http://pastebin.com/uKq4rvJk
[17:32] <chrisccoulson> micahg, patching configure.ac might avoid issues
[17:32] <micahg> ah
[17:32] <chrisccoulson> (we just need to make sure that configure is regenerated at build time, or in the source package we upload)
[17:32] <chrisccoulson> i tend to avoid directly patching parts of the build system which should be generated automatically
[17:33] <micahg> chrisccoulson: I guess I missed that before
[17:33] <micahg> I usually patch the .in file, I guess .ac is also one that generates
[17:34] <chrisccoulson> yeah, the ".in" and ".ac" extensions are interchangeable i think
[17:34] <chrisccoulson> i'm sure one of them is meant to be deprecated
[17:34] <chrisccoulson> i'm not sure though
[17:35] <micahg> I should probably start with a clean dir again on that one
[17:35] <chrisccoulson> yeah, might be a good idea
[17:35] <micahg> chrisccoulson: you know about java libs?
[17:36] <chrisccoulson> i don't know much about java libs
[17:36] <micahg> k, I can work on that
[17:38] <micahg> chrisccoulson: do you want to test tuxguitar?
[17:39] <chrisccoulson> yeah, i can look at that
[17:39] <micahg> I'll file the bug
[17:39] <chrisccoulson> heh, that should be interesting to test
[17:42] <micahg> chrisccoulson: bug 536796
[17:42] <chrisccoulson> thanks
[17:44] <bdrung> micahg: how urgend is the release of m-d 0.21?
[17:46] <micahg> well, I need it so that prism and fennec clean the build area when done
[17:47] <bdrung> micahg: should i release it today or can you wait some days?
[17:47] <micahg> bdrung: asac said we can do an upload to ubuntu if you can't push it through debian right now
[17:48] <bdrung> micahg: then do a hotfix to ubuntu and we will sync once we got the other things in
[17:48] <micahg> bdrung: k, do we have a branch for that?
[17:48] <micahg> or do I just do a debdiff?
[17:49] <asac> i think we should do one more sync for md this cycle
[17:49] <asac> you decide when ;)
[17:49] <asac> not after beta2 if possible ;)
[17:50] <micahg> asac: can I push prism/fennec without the clean fix?
[17:53] <asac> sure
[17:53] <asac> if it doenst ftbfs
[17:53] <asac> you can also clean in rules for now
[17:53] <micahg> asac: it won't, it just leaves a messy buld area
[17:53] <micahg> asac: k, then I'll file a bug for all three packages so we fix before release
[17:54] <asac> yes
[17:54] <micahg> asac: if I add a clean target in rules will it still call clean in xulapp.mk?
[17:56] <asac> yes
[17:56] <micahg> k
[18:25] <ccheney> asac: i don't see any reference to peek in the source not sure if the gtk macros themselves changed between versions or what is going on, an example of the code is:   GTK_OBJECT_CLASS (ephy_gtk_entry_parent_class)->destroy (object);
[18:25] <ccheney> with no reference that i can find to ephy_gtk_entry_parent_class
[18:26] <ccheney> so something macro wise must be generating it in the new gtk but doesn't in the old one i guess
[18:26] <micahg> thanks chrisccoulson for tuxguitar
[18:26] <chrisccoulson> michag - no worries
[18:26] <chrisccoulson> oops
[18:26] <ccheney> i'm not sure how to fix it :-\
[18:26] <chrisccoulson> s/michag/micahg
[18:27] <ccheney> i don't think modifying gtk's macros would be a good idea obviously
[18:28] <asac> ccheney: in what function are you calling this?
[18:28] <asac> isnt that a fun with either self or klazz as parameter?
[18:28] <asac> func
[18:28] <ccheney> it looks like peek was required in hardy version maybe
[18:28] <asac> thats what i mean
[18:28] <asac> us peek on the current class
[18:29] <asac> if you have self you can get it by EPHY_GTK_ENTRY_CLASS(self)
[18:29] <asac> or something
[18:29] <ccheney> http://pastebin.ubuntu.com/392682
[18:29] <asac> i need to see the code ;)
[18:29] <ccheney> so i add that above the line referencing the parent_class for each call?
[18:29] <ccheney> ok will copy an example function in
[18:30] <asac> you just need it in .c
[18:30] <asac> ?
[18:30] <asac> you can create a static field then
[18:30] <asac> and set it in class_init
[18:30] <asac> i guess
[18:30] <asac> unset it in dispose
[18:30] <ccheney> http://pastebin.ubuntu.com/392686
[18:31] <ccheney> yea just in the c file as far as i can tell
[18:31] <asac> yeah you could do it there
[18:31] <asac> or in class_init
[18:31] <asac> please post the full file so i can do a quick check
[18:32] <ccheney> ok will do
[18:33] <ccheney> http://people.canonical.com/~ccheney/gtk-gtkentry.c
[18:33] <ccheney> should i add to the init something like http://pastebin.ubuntu.com/392688
[18:34] <ccheney> that was copied from hardy gtk
[18:34] <asac> ccheney: G_DEFINE_TYPE_WITH_CODE (EphyGtkEntry, gtk_entry, GTK_TYPE_WIDGET,
[18:34] <asac> thats G_DEFINE_TYPE_WITH_CODE (EphyGtkEntry, ephy_gtk_entry, GTK_TYPE_WIDGET,
[18:34] <asac> that shoujld help
[18:34] <ccheney> oh crap i don't know how i managed to do that, thanks :)
[18:34] <asac> hehe
[18:34] <asac> good that you catched it
[18:34] <asac> otherwise the _init wouldnt have been called etc.
[18:35] <asac> ccheney: check fi you failed to replace other lower case gtk_entry stuff
[18:35] <ccheney> ok will do
[18:35] <asac> not sure how you forgot it either
[18:35] <ccheney> i think i did a replace on gtk_entry_ to ephy_gtk_entry_
[18:35] <asac> unless you changed all gtk_entry manually ;)
[18:35] <asac> ah
[18:36] <asac> yeah that would explain it
[18:36] <asac> now you have to find all gtk_entry[^_] ;)
[18:36] <ccheney> yea that fixed it, thank you very much! :)
[18:36] <asac> np
[18:36] <ccheney> looks like that was the only non _ name
[18:37] <ccheney> that reduced my error list a bunch :)
[18:37] <asac> hehe
[18:49] <fta> !info openshot
[18:50] <fta> zzZZzz
[18:52] <fta> i wonder why we have pitivi but not openshot, it seems far more advanced
[18:53] <micahg> !info openshot lucid | fta
[18:53]  * micahg kicks ubuntulo1
[18:54] <micahg> oops
[18:54] <micahg> sorry ubuntulo1
[18:54] <fta> ok, nm
[18:55] <mahfouz> we need a video editor choice upon install
[18:55] <mahfouz> EU will step in soon
[18:56] <micahg> mahfouz: no EU can't do a thing it's Free :)
[18:56] <mahfouz> you don't know the EU :)
[18:57] <micahg> mahfouz: can't have both on the CD
[19:30]  * ccheney grabbing lunch, bbl
[19:57] <micahg> chrisccoulson: bug 536877
[19:58] <chrisccoulson> micahg - thanks, will look at that after dinner
[19:58] <micahg> chrisccoulson: k
[20:00] <micahg> asac: do you want the porting bugs tagged?
[21:05] <micahg> asac: also, can you spin TB3?
[21:11] <ccheney> down to the last failure in gtkentry.c now then on to see what all those added headers managed to need pulled in
[21:11] <ccheney> the last bit needs special mkenums code so need to make sure i do it right
[21:32] <ccheney> asac: after adding the code to generate the enums it seems to be switching the names around
[21:33] <ccheney> asac: pastebin.ubuntu.com/392794
[21:33] <ccheney> asac: but the build is looking for EPHY_GTK_TYPE_ENTRY_ICON_POSITION
[21:34] <ccheney> should i just redo the c file to point to the generated name?
[21:34]  * ccheney isn't sure why it generated differently
[21:34] <ccheney> i'm trying it that to way to see if it somehow works
[21:37]  * ccheney thinks he found the issue, forgot to strip some code out of the template file
[21:38] <ccheney> yea that was it :)
[21:39] <ccheney> it seems to work with reordering the name
[21:41] <ccheney> its compiling longer, thats a good sign :)
[21:41] <ccheney> cool it didn't fail until the linkage stage this time
[21:42] <ccheney> so now i just need to copy the additional code it needed in and see if it builds :)
[22:04] <BUGabundo> evening
[22:21] <micahg> maxb: I would guess that spidermonkey-bin has the same fate as mozjs in Ubuntu
[22:23] <maxb> IIUC the fate of mozjs is because of upstream's unwillingness to present a stable API?
[22:24] <maxb> That would not apply to a command-line program
[22:24] <micahg> asac: what's your take on this ^^^ also reference bug 536950
[22:26] <micahg> maxb: basically whatever asac says on this...
[22:27] <maxb> ok. ftr it came up because lazr-js / launchpad use smjs to lint javascript
[22:34]  * micahg is looking how it's made
[23:22] <micahg> hi asac
[23:23] <micahg> chrisccoulson: we don't need to worry about openjdk unless there are bugs with the firefox plugin now as doko just did another upload
[23:24] <chrisccoulson> cool, i'll not worry about that for now then :)
[23:25] <micahg> chrisccoulson: if I finish my $WORK, I'll try to have a few more debdiffs for you in teh morning :)
[23:26] <micahg> chrisccoulson: how much longer will you be on?
[23:26] <chrisccoulson> micahg - thanks. don't work for too long though, we've got all the really important bits done now
[23:26] <chrisccoulson> i'll be around for a bit longer, but probably not doing much work now
[23:26] <micahg> chrisccoulson: k, I want to chat, but I have to run out for a bit