[00:07] ccheney: so the class and main struct seem compatible [00:08] so we can do this: [00:08] * ccheney looks to see where the problem laid [00:08] ccheney: no i see [00:08] oh ok [00:08] one second ;) [00:08] the icon stuff needs Private struct [00:08] which you cannot break/change [00:08] whati think we should do is because Class and main struct are compatible [00:09] we just copy the full gtkentry.c and gtkentry.h and name it gtkentryBackported [00:09] define a new type gtkentrybackported etc. [00:09] and use that in epiphany [00:09] that type would just inherit from gtkentry [00:09] iirc it uses some other newer types along with it might need to do that for those two i guess? [00:10] i'm not sure what you mean wrt inherit with C :) [00:10] i'm still pretty new with using glib/gtk so its probably something that they do with macros i suppose? [00:11] ccheney: right. the G_DEFINE_YPE Macro specifies a supertype [00:11] also you derive the structs like this: [00:11] struct _GtkEntryBackport { [00:11] GtkEntry parent; [00:11] }; [00:11] and GtkEntryBackportClass { [00:11] GtkEntryClass parent_klass; [00:11] } [00:11] ; [00:11] ah ok [00:11] then you basically put the G_DEFINE_TYPE macro there that says that GTK_TYPE_ENTRY is supertype [00:12] and in _init and _class_init you dont do anything [00:12] i'm going to copy this into the epiphany wiki page so i don't forget anything while working on it tomorrow [00:12] err [00:12] if that is ok? [00:12] in _class_init you basically copy what you currently have there [00:12] rather i just copy it locally [00:12] no wiki is fine [00:12] ok [00:13] so _class_init you keep as it is in the copy you created from the new gtkentry [00:13] ok [00:14] ccheney: look at the class_init [00:14] function [00:14] thats where they bind the functions to the static impls [00:14] yea i remember seeing that when working on it before [00:15] i'll try to get it at least partially done tonight after i get something to eat, if i am lucky maybe done by meeting tomorrow :) [00:16] ccheney: maybe we can even just first try to copy that entry over [00:16] as it is ... rename all the funcs and types [00:16] and see if that is enough ... if all uses of that are redirected in epiphany [00:17] for the other symbols: [00:17] gtk_show_uri -> shouldnt be a problem [00:17] gtk_status_icon_set_tooltip_text -> we can survive without that? [00:17] gtk_activatable_get_type -> guess we need this type backported [00:17] ok [00:18] gdk_app_launch_context_* -> feels like thats confined and can be backported or even added to gtk [00:18] if its imliar to the thread thing [00:18] from glib [00:18] yea probably so [00:18] let me check something [00:18] ok for gtk_entry we have icon and progress [00:18] from what i remember the context stuff seemed pretty easy [00:19] lib/widgets/ephy-location-entry.c lib/widgets/ephy-search-entry.c: [00:19] those are the places for icon [00:19] yea [00:19] iirc there is one other place but i forgot the filename [00:20] maybe was src/ephy-location-action.c [00:21] yea it refers to GtkEntry at least, not sure if it used the new functions though [00:22] oh no i think it wasn't that but src/ephy-window.c [00:22] i see where i commented out the +// #include "../lib/gtk-gtkentry.h" [00:22] hmm. problem is you did abunch of stuff [00:22] which i had done when trying to do the initial func backport [00:22] so i dont even see the original ;) [00:22] let me revert everything in that tree [00:22] oh :-\ [00:23] ok [00:27] ccheney: so yeah. simple approach would be to copy GtkEntry as EphyGtkEntry ... rename all gtk_entry to ephy_gtk_entry and all GtkEntry to EphyGtkEntry and GTK_ENTRY to EPHY_GTK_ENTRY etc. [00:27] in the copied source files [00:27] and then fix the few places where they say: gtk_entry_new() -> ephy_gtk_entry_new() [00:27] and of course all the other gtk_entry.* func [00:27] s [00:28] ok [00:29] feels like a plan [00:29] i dont think it passes gtk entries to different libs etc. [00:29] so should be fine [00:29] ok will try to implement it tonight and let you know how it goes tomorrow :) [00:30] yeah. just copy over ... and sed ;) [00:30] well. first see if it builds ;) [00:30] who knows what that thing pulls in [00:30] heh yea [00:31] iirc it pulls a few other bits in but not too much [00:31] the gtkentry.c file? [00:31] i can probably get away by doing something similar with the other bits if they have problems [00:31] yea [00:32] would be fun if gtk code is more portable than ephy ;) [00:32] i think there is a glib icon thing as well it messes with but i can remember for certain [00:32] er can't [00:35] I totally forgot what was that FF about:config entry to turn off process separation [00:35] * ccheney bbl, will check backlog when i get back :) [00:35] can anyone recall me ? [00:38] BUGabundo: i remember you. yes. [00:39] duh [00:39] BUGabundo: searhc for dom.ipc [00:39] or something [00:39] or ipc [00:39] help me out :D [00:39] plugins [00:39] thanks [00:39] its already false :( [00:39] so why is this crashing!! [00:39] grrr [00:39] [NoScript] document is null while processing JS redirects [00:39] ** (firefox-3.7:8620): WARNING **: Serious fd usage error 14 [00:39] ** (firefox-3.7:8620): WARNING **: Serious fd usage error 12 [00:40] noscript ;)? [00:40] maybe [00:40] ff 3.7 [00:47] bug 318849 322141 522254 [00:47] Launchpad bug 318849 in gnash "Deprecated klash kde3 binaries removed and not replaced with gnash-kde4" [Undecided,In progress] https://launchpad.net/bugs/318849 [00:47] bug 322141 522254 [00:47] Launchpad bug 322141 in gnash "konqueror-plugin-gnash contains no binaries" [Undecided,In progress] https://launchpad.net/bugs/322141 [00:47] bug 522254 [00:47] Launchpad bug 522254 in gnash "[MASTER] FFe: please sync with upstream version of Gnash .8.7" [Undecided,Confirmed] https://launchpad.net/bugs/522254 [00:54] asac: FF in lucid failed to start. rm -rf ~/.mozilla will let it start once. [00:55] bdrung_: global extensions cause this (some) [00:55] if you can figure out whats it, i would be grateful [00:55] e.g. waht extension [00:56] asac: "firefox -g" does not work: "/usr/lib/firefox-3.6/firefox": not in executable format: file format not recognised [00:56] i also suspect it has to do with the plenty of levels of links we have or with the new /usr/lib/mozilla location [00:56] hmm [00:56] thats a bug [00:56] run /usr/lib/firefox-*/run-mozilla.sh /usr/bin/gdm /usr/lib/firefox-*/firefox-bin [00:56] err gdb ;) [00:58] asac: i have these packages installed: xul-ext-adblock-plus, xul-ext-notify, xul-ext-pwdhash, xul-ext-mozgest [00:58] yes. one of those is it [00:58] try -safe-mode [00:58] and then enable one by one [00:59] i would suspect mozgest [00:59] it has something to do with xpt [00:59] so if an extension defines its own interfaces [00:59] asac: running with gdb, it gives me: "Program exited with code 01." [00:59] if an extension without a .xpt file causes this, it would invalidate my theory [00:59] bdrung_: yeah [01:00] it just ends ;) [01:00] needs some serious debugging ;) [01:01] asac: i used -safe-mode and enabled them step-by-step. but it still restarts without problems. [01:02] bdrung_: try twice ;) [01:02] you need to restart twice for this to kick in [01:02] first time enable will work [01:02] there must be a difference between restarting FF and closing+reopen it [01:02] no [01:02] its just about updating extension cache [01:02] in the run where that is updated it works. in the next it doesnt [01:03] at least the bug i saw showed that behaviour [01:05] asac: i checked it twice and your guess was correct: it is mozgest [01:07] asac: mozgest contains /usr/share/xul-ext-mozgest/components/mglMouseService.xpt [01:10] so yeah... we should check whether its the new locatoin [01:10] maybe by copying the bits to FIREFOX/extensions [01:10] moving rather [01:10] if its not the new location ... upstream bug i guess [01:10] unless i find to debug it [01:10] which probably has to happen to fix this for lucid :( [01:13] asac - so, do you have some thoughts about issues like bug 531583? (it seems to be similar to the issue you're talking about) [01:13] Launchpad bug 531583 in firefox "greasemonkey causes ff 3.6 to not load, without errors" [High,Confirmed] https://launchpad.net/bugs/531583 [01:13] bryce asked me if i could take a look at that [01:14] chrisccoulson: thats the issue [01:14] no ideas besides from what i said above [01:14] needs debugging ... if reproducible with upstream builds we might get help from there [01:14] what i found is that firefox seems to have an issue specifically with the sym-links (but you might have already figured that out) [01:15] chrisccoulson: thats what i asked bdrung to test [01:15] e.g. unpack directly in FIREFOX/extensions [01:15] rather than having the links in /usr/lib/mozilla/... [01:15] so its the symlinks? [01:15] yeah, if i unpack directly, then it works fine [01:15] if i symlink, then it breaks [01:15] chrisccoulson: bug still not writable? [01:15] and that applies in my home folder too [01:15] hmm [01:16] let me check something [01:16] but, other than that, i'm a little bit stuck ;) [01:16] asac: xpt files are made from what? [01:17] what does they contain? [01:17] bdrung_: do you have a broken profile? [01:17] can you paste compreg.dat? [01:17] (from a profile that doesnt start) [01:17] bdrung_: its xpcom interface description [01:17] produced from an .idl [01:17] or more than one etc. [01:18] bdrung_: also please verify what chrisccoulson said ... e.g. that not using symlinks works [01:18] but get me a compreg.dat first ;)) [01:19] asac: i have the solution: the xpt file is non-free and needs to be removed from the source. ;) [01:20] thats indeed a bug [01:20] usually it should be produced during build [01:20] but that wont help here i think [01:20] asac: removing this file works, because we removed the .so files (no source for them) [01:21] in this case yes. [01:21] get me a compreg.dat please of broken ;) [01:21] i'll downgrade the package and create the file for you. [01:21] cool [01:23] also the absent of a .so doesnt necessarily mean the .xpt is useless. might also be a .js implementing the interface that then can be called through xpcom (from js or C++) [01:24] pastebinit is buggy [01:25] asac: http://pastebin.com/2F9uLM6S [01:26] bdrung_: and xpti.dat [01:26] asac: http://pastebin.com/KXSXcCWs [01:27] {d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d} [01:27] thats mozgest? [01:27] bdrung_: ? [01:28] adblock it seems [01:28] that's adblock-plus [01:29] so my guess is that it does a stupid abspath somewhere [01:30] (or not) then doesnt see the file in the the xpti.dat and gives up [01:31] asac: btw, what's the status of getting the font rendering fixed? [01:53] in xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp [01:53] drop [01:53] + // nsIFile::Equals basically compares path strings so normalize [01:53] 4.8 + // before the comparison. [01:53] 4.9 + parent->Normalize(); [01:53] 4.10 + current->Normalize(); [01:53] those lines [01:53] and see if that helps [01:53] for the xpt thing [01:54] otherwise we might want to try to Normalize in FindDirectory in xptiWorkingSet.cpp [01:55] font rendenering ::: needs debugging [01:55] upstream seems not to care. didnt get a confirm whether its a problem on redhat too with upstream builds [01:55] if fedora has the same, we can escalate [01:55] otherwise we need to do it on our own [01:56] bdrung_: chrisccoulson: ^^ [01:56] (thats a blind guess) [01:56] (the de-normalizing) [01:58] Hello, there's something I've always wondered about the linux version of firefox: [01:58] why doe the open with alternate program dialog make you find the actual binary instead of just having a custom command [01:59] asac: i will try this, but compiling may take a while [02:01] masterme120: gtk doesnt offer a app chooser [02:01] so either firefox has to reinvent its own [02:02] the one from nautilus looks promissing but would need to get promoted to gtk in some what [02:02] way [02:02] oh [02:03] even if firefox would be willing to use gnome stuff ... nautilus chooser is not exposed in any API [02:03] so someone would need to rip that out [02:04] asac: igitt; a tarball in tarball. can you give me a debdiff for testing? [02:04] i will test it then tomorrow [02:04] * bdrung_ will go to bed now. [02:06] extract tarball ... create diff, dump in debian/patches and series [02:06] build [02:07] i am too tired for that [02:07] i am not less tired. <5h till wake up ;) [02:07] off [02:07] 'night === micahg1 is now known as micahg === dpm-afk is now known as dpm [08:54] \0 [10:12] hi [10:38] heys [10:38] is xulrunner-dev 1.9.2 still expected in lucid? [10:39] stefanlsd, sure, at some point within the next 18 months... [10:40] so not at release i take it [10:49] stefanlsd, good question. i've been told "imminently" for over a month now afaik [10:51] directhex: xul 1.9.2? [10:51] or fonts? [11:01] asac, xulrunner-dev 1.9.2. [11:03] hmm [11:03] i think i saw the new button order for the first time now [11:03] thats really odd ;) [11:03] * asac tries to get used to it [11:04] chrisccoulson: can you check with micahg on the xul 1.9.2 stuff and help getting that in the archive? [11:04] asac - no worries. last time i asked, he had a build issue with fennec [11:05] do you know if he got that sorted? [11:05] i had hoped for a few more ports first, but we shouldnt stress the good will of release team too much ;) [11:05] (most of my day yesterday was taken up by openjdk) [11:05] chrisccoulson: i think he sorted the prism problem ... which might also have been the fennec problem [11:05] chrisccoulson: openjdk now working? [11:06] not sure if he committed the stuff yet though [11:06] asac - it would be good to get all the stuff which is seeded done before the beta freeze [11:06] yes [11:06] thats why i think we should upload _now_ ;) [11:07] so i think the build system fix is still missing [11:07] asac - do you know what time micahg is around? [11:07] he is more around than not ;) [11:07] openjdk is not working yet btw, but that's not a xulrunner issue [11:07] it's due to a change in llvm [11:08] hmm. so openjdk doesnt ubild at all atm? [11:08] even in archive? didnt you say doko uploaded something? [11:08] asac - yeah, doko uploaded openjdk, and then a new version of llvm [11:08] but the current openjdk version built against the old llvm [11:08] it doesn't build with the new one [11:09] sigh [11:09] i assume he knows/deals with it? [11:09] i spent quite a few hours yesterday trying to track that down, i could probably do with some help from doko [11:09] i wouldnt bother. he will fix it [11:09] he seemed to be quite confused about the error message when i mentioned it to him yesterday [11:09] go for the other fruits ;) [11:10] yeah, will do :) [11:10] just ensure he is on it ;) [11:10] ... file a RC bug if there is none yet [11:10] did you get any where with the firefox failing to start issue since last night? [11:10] chrisccoulson: i suggested a patch [11:10] asked you or bdrung to test ;) [11:10] i already uploaded monodevelop-moonlight, so that's uninstallable right now [11:10] 02:53 < asac> in xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp [11:10] ah, i probably should check the scrollback [11:11] 02:53 < asac> drop [11:11] 02:53 < asac> + // nsIFile::Equals basically compares path strings so normalize [11:11] 02:53 < asac> 4.8 + // before the comparison. [11:11] 02:53 < asac> 4.9 + parent->Normalize(); [11:11] 02:53 < asac> 4.10 + current->Normalize(); [11:11] 02:53 < asac> those lines [11:11] 02:53 < asac> and see if that helps [11:11] 02:53 < asac> for the xpt thing [11:11] was easy enough for me to repaste [11:11] 02:54 < asac> otherwise we might want to try to Normalize in FindDirectory in xptiWorkingSet.cpp [11:11] directhex: good [11:11] chrisccoulson: no its fine ;) [11:11] so two approaches i can imagine [11:11] awesome, i will try that shortly [11:11] dropping Normalize there or adding Normalize in WorkingSet FindDirectofry (or maybe some other places) [11:12] makes somewhat sense, because that was landed in Jul 2009 ... probably after the 1.9.1 cut off [11:12] but let me double check ;) [11:12] so a good way to check source and cross reference is: http://mxr.mozilla.org/ [11:12] chrisccoulson: ^^ [11:12] there you can also find blame if you in a source file etc. [11:12] good thing there's months before release, otherwise the window for testing & bug-fixing all the 1.9.2 rdeps might be considered really short. [11:12] asac - thanks [11:13] directhex: right. plan is to kick stuff that doesnt make the cut out of the archive [11:13] kind of evolutionary cleanup [11:13] in the future we need to be able to do such porting swiftly [11:13] as we need to upgrade to .3 .4 etc. every 6 month or so [11:13] as a security/stability update [11:14] chrisccoulson: good ;) [11:14] http://mxr.mozilla.org/mozilla1.9.1/source/xpcom/reflect/xptinfo/src/xptiInterfaceInfoManager.cpp [11:14] that suggests that that code wasnt on the 1.9.1 branch ;) [11:14] so probably is a good lead ;) [11:16] asac - i've also been assigned a work item for looking at extensions to clean from the archive [11:16] right [11:16] important task [11:16] i'm not sure if you've got any special requirements for any that you would like to remain [11:17] chrisccoulson: check popcon as a first [11:17] chrisccoulson: also extensions with native components should stay [11:17] i compiled a list of source packages providing extensions at https://wiki.ubuntu.com/DesktopTeam/Specs/Lucid/FirefoxNewSupportModel/extension-list yesterday [11:17] as those are not available for all archs in addons.mozilla.org (amo) [11:17] yeah, i didn't think of checking popcon actually, that's quite a good idea [11:18] so out of head i would guess: all in main ;) [11:18] adblock-plus [11:18] all-in-one-sidebar [11:18] bindwood [11:18] bugmail-extension [11:18] firebug [11:18] firefox-launchpad-plugin [11:18] flashblock [11:18] flashgot [11:18] gears [11:18] greasemonkey [11:18] mozgest [11:19] notify-extension [11:19] mozilla-noscript [11:19] i thought gears was EOL [11:19] if it still works its good stuff [11:19] its EOL in chromium ... where they dropped it without replacement ;) [11:20] cool, i will try and spend some time going through this list today anyway [11:20] yeah [11:20] cross check that with popularity [11:20] chrisccoulson: btw, there have been quite a few coming [11:20] from debian in lucid named xul-ext-* [11:20] those seem to be not in your list ... not sure why [11:20] (maybe they us that prefix for binaries only) [11:24] chrisccoulson: can you make this scriptable? [11:25] asac - yeah, those names are binary only (the list only has source packages providing extensions) [11:26] bdrung - i don't see why i couldn't make it scriptable :-) [11:26] if there are any that i've missed off the list, please feel free to add them [11:27] chrisccoulson: it would be nice, if the list can be updated via a script - otherwise it will get outdated very soon. [11:27] yeah, that's a good point [11:31] the new policy permits that [11:31] because we have special headers [11:31] and even xul-ext* prefix [11:31] for now we have to maintain it through pain [11:31] and maybe we should write a pool/ grep [11:32] checking for install.rdf or something === asac_ is now known as asac [13:16] asac: grabbing all packages build depending on mozilla-devscripts will catch most of them [13:17] right, but not all [13:17] yes [13:17] asac: pool grep would be a good idea. [13:36] asac - so, if we want to start the xulrunner 1.9.2 transition today, would you mind doing the 1.9.1 upload to not ship xulrunner-dev any more? [13:36] i think i can do the initial 1.9.2 upload [13:39] chrisccoulson: yes. we should do that [13:40] chrisccoulson: we have to set replaces anyway, so we can remove the file in a later upload [13:40] err ;) [13:40] scratch that [13:40] we just have to remember to upload ;) [13:40] next upload would fail to upload [13:41] but yes, we should drop it from bzr right away [13:43] asac - it's already dropped in bzr (http://bazaar.launchpad.net/~mozillateam/xulrunner/xulrunner-1.9.1.head/revision/528) [13:52] good ;) [13:52] so just an upload. but that can wait till next update round [13:52] if thats before the releaes ;) [14:55] asac: my kvm instance went out of space. 10 GB was not enough. [14:55] lol [14:55] moz needs 10 gig? [14:55] for ffox you need 4 or more ,) [14:55] havent checked current space recently [14:55] directhex: my kvm has 10 gig. [14:57] did I hear somebody say that thunder gets its own repo? [14:57] directhex: i had 2.5 gig free before compiling [14:57] asac: that's even more that eclipse needs. [14:57] bdrung_, tried OOo? [14:57] directhex: nope. i compiled eclipse often enough === yofel_ is now known as yofel [16:30] asac - xulrunner-1.9.2 is in NEW now [16:31] ? [16:31] what did I miss? [16:31] hey micahg [16:32] we're going to start the transition in the archive quite soon [16:32] chrisccoulson: it doesn't have my latest changes [16:32] ah, where are those? [16:33] * micahg wonders why no one asked... [16:33]