[00:00] TheMuso, BTW, the combo box bug have been fixed by mgorse - FYI [02:28] RAOF, wow, alt-tab is super crashy now... See bug 740648 [02:29] robert_ancell: Yeah. I'm back in the classic session now. [02:29] RAOF, are you using ATI or other? [02:29] There seem to be at least three separate crashers in alt-tab now, none of which are in the driver code. [02:30] ATI and intel. [02:30] why is alt-tab so flaky? It doesn't seem like that complicated a feature [02:30] But the crashers are in a glib closure that's not touching the driver stack. Apart from the one which was in free() (!). [02:32] I presume that someone's hooked some handlers up to alt-tab that aren't particularly tested. [02:33] Notably this seems to only occur when unity's loaded. === Amaranth_ is now known as Amaranth === chaotic_ is now known as chaotic === Amaranth_ is now known as Amaranth [07:04] Good morning [07:11] good morning pitti! [07:21] hey chrisccoulson [07:21] hi pitti, how are you? [07:22] good morning [07:22] hi didrocks [07:22] hey chrisccoulson [07:31] bonjour didrocks [07:31] Guten Morgen pitti [07:37] hello [07:49] back in ~ 1 h [07:52] ping() [08:24] hey didrocks, around at all? [08:24] jasoncwarner: sure [08:24] didrocks: morning :) [08:25] hey...pitti and I were talking about what happens with ATI if the card/driver the person has won't run and what the default experience would be...figured we could talk through it if you didn't mind... [08:26] jasoncwarner: shouldn't be the same than nvidia? (in theory) [08:26] jasoncwarner: like the testing tool is failing [08:27] so, my question was this...what happens if someone has an a card/driver combo that doesn't work...what will happen on boot for that person? [08:27] so, we fallback to the classic mode [08:27] oh [08:27] this is more a Xorg thing, right? [08:27] I know that currently, on nvidia, it's ackward [08:27] black screen [08:27] well, I would think that if they can't run unity, yes, we would fallback to classic mode...but I was wondering about order of oeprations as well as initial experience for them [08:27] like, you need the -96 driver for your card [08:28] like...do we try to boot unity...compiz crashes a couple of times and then we fall back' [08:28] and you forced to the current [08:28] ? [08:28] xorg doesn't start [08:28] jasoncwarner: no, that was planned, but unfortunately nobody had the time to tackle it [08:28] I harrass the dx team for a month to at least, with have unity_support_test --compiz [08:28] which exist [08:29] but just trigger the same test than unity itself [08:29] (alone) [08:29] so perhaps it is worth talking through a scenario, just so I can get my head wrapped around it. [08:29] 1. from talkign to people, I hear there is a nux test that will tell us if they can run compiz/unity...is that right? [08:30] right, now, it just tell if you can run unity [08:30] so it's either unity / metacity [08:30] ok [08:30] it's either unity - compiz / metacity - gnome-panel [08:30] to be exact :) [08:31] jasoncwarner: TBH, first test, I think we should ensure the testing tool is working fine [08:31] which isn't the case [08:31] so lets say someone has an ATI card and fglrx. It happens that this combo doesn't run unity. What happens at boot? [08:31] and nobody has time to finish it [08:31] so, the testing tool should report "can't run unity" [08:31] (or crash even…) [08:32] in that case gnome-session go on "let's fallback" [08:32] and the guy should have metacity and gnome-panel started [08:32] the thing to access that and ensure we have the exact same level [08:32] do they get a blank screen? a flicker? or does it appear to _try_ to load something and then fall back to GDM with a message saying "select classic desktop"? [08:33] is that the unity test tools really test every requirement [08:33] or does it do it automaticallY? [08:33] jasoncwarner: no, it's automatic [08:33] ok, let's me sum up [08:33] there are multiple case that I implemented :) [08:33] :) [08:33] so stock installation: [08:33] let's say the the testing tool is perfect, it can detect unity/compiz/metacity [08:34] you log in [08:34] the testing tool tries unity [08:34] "it can't" (crash/timeout or return 1) [08:34] gnome-session fallback in compiz and gnome-panel [08:35] fallback to a different UI, gnoeme-session knows that and prompt a message (will copy the message later) [08:35] tghen the testing tool tries compiz (<---- this is what is missing currently) [08:35] "let's say it can't" [08:35] so, we fallback to metacity + gnome-panel [08:36] (no message here as the ui is exactly the same) [08:36] let me show you the message [08:36] so we really have three diff combos? Unity + compiz. Compiz + gnome-panel and metacity + gnome-panel? [08:37] "It seems that you do not have the hardware required to run Unity. Please choose the Ubuntu Classic Desktop at the login screen and you will be using the traditional environment. [08:37] " [08:37] even more :) [08:37] pitti - well, i sort-of have swt-gtk working locally with webkit [08:37] because if you install unity-2D [08:37] but i had to hack the binary ;) [08:37] (which isn't on the cd by default) [08:37] it will try unity + compiz [08:37] if it can't [08:37] it will fallback to unity2D + metacity [08:37] i still haven't figured out why i'm seeing this problem [08:37] (which is always supported) [08:37] jasoncwarner: no warning message in this case as we have the same ui [08:38] ok...so (recapping myself :) ) [08:38] hi jasoncwarner [08:38] how are you? [08:38] hey chrisccoulson...pretty good thanks! :0 [08:38] pitti - if i replace the cltq instruction in http://paste.ubuntu.com/584176/ with 2 nop's, then swt-gtk magically works [08:39] didrocks: if they can't run unity, try compiz + gnome. If can't run compiz, enable metacity + gnome. [08:39] which i think proves my point. now to figure out why gcc puts it there [08:39] if Unity2d is installed, it becomes [08:39] try Unity3d. If not, try Unit2d and then we are done b/c that will always work [08:39] ? [08:40] jasoncwarner: right, the only missing piece today is "testing compiz without unity" [08:40] not on gnome-session in the test tool [08:40] and that is missing b/c we just haven't had time to finish/test it? [08:41] so if that doesn't work/get tested, can we just default to "if not unity3d, if not unity2d, use metacity + gnome"? [08:41] jasoncwarner: only dx opengl guys knows what's opengl req. for unity and compiz [08:42] jasoncwarner: also, that requires that we are sure that all opengl req. are tested so that we don't get then a crash believing that the card support unity which isn't the case [08:42] ok...so we'll need to check with dbarth to see about getting that looked at.. [08:42] jasoncwarner: so testing there :) === tkamppeter_ is now known as tkamppeter [08:42] jasoncwarner: yes please :-) [08:42] about how long would the rpocess take, start to finish [08:43] if someone had to fall all the way back? [08:43] jasoncwarner: the test tool has a bug that it can take 4s on some machine in the live session (I had to put the timeout for 5s) [08:43] jasoncwarner: on my installed machine, it takes 0.7s [08:44] so, in the worst case, it's 2x0.7s [08:44] in the live, it's more of course [08:44] about 8-10s...ok... [08:44] on a live of course :) [08:44] yeah :) [08:45] I tested on a netbook, can be quite embarrassing, 2x2s approx [08:45] ok...I think I have a handle on it now... [08:45] btw...that message you gave me earlier...where does the user see that? when they finally get into a desktop session? [08:45] or at gdm? [08:46] jasoncwarner: right now, only in the desktop session [08:46] jasoncwarner: that's a way we can explore later for OO I guess to get those sessions/fallback integated in the DM [08:47] I like it better that they get to a desktop rather than make them select something in gdm first time in...no worries there...thanks! [08:48] didrocks, jasoncwarner: which additional gl reqs do you want us to test? [08:49] dbarth: just that the --compiz option is wired up [08:49] jasoncwarner: just not really possible today with gdm unfortunately [08:50] dbarth: and ensuring that the tests in the unity initilization are the same than in the testing tool (not the case today) [08:53] didrocks, jasoncwarner: I think our concern was what happens if the testing tool says "thumbs up" (e. g. the driver claims to have the capabilities), but compiz keeps crashing due to a bug [08:54] chrisccoulson: *bowing to your assembly sk1llz* [08:54] pitti: well, not really differently than today if compiz is crashing because it's not supported [08:54] pitti: yeah, good case... didrocks, what happens there? [08:55] jasoncwarner: ^^ [08:55] chrisccoulson: that's "convert long to quad"?, i. e. destroys the upper 32 bits? [08:55] meaning you will see (still needs testing, respawn is under work and don't work with latest version as announced) compiz respawning/crashing [08:55] but that's already the case today [08:55] pitti - yeah, i'm losing the upper 32 bits of the pointer, which is making it crash later on [08:55] chrisccoulson: do you know how that got in there, i. e. from which C operation? sounds like a typecast of some way? [08:56] didrocks: right; I think it's a corner case really, it just came up in discussion [08:56] pitti - i'm not too sure yet, as the function is pretty much identical to all the others in that object file (and it's the only one which ends up with that cltq instruction) [08:56] pitti: TBH, I really want to address that in the long term. It just seems the ETOOMUCH for this cycle :) [08:57] didrocks: no worries [08:58] didrocks: the --compiz is still not there? [08:58] pitti - bug 740815 :) [08:58] Launchpad bug 740815 in xulrunner-2.0 "[FFe] Updates to enable us to drop xulrunner from main" [Undecided,New] https://launchpad.net/bugs/740815 [08:58] it's actually quite a bit of work :( [08:59] i might need a bit of help with some of that [08:59] dbarth: it's there, but it's fake. it has the same test req. than unity [09:00] didrocks: ahhhhh [09:00] dbarth: well, basically, it's not that bad with the test that way [09:01] dbarth: it's just that the user has either compiz + unity or metacity + gnome-panel [09:01] chrisccoulson: quite a long list :) [09:01] pitti - yeah, it's longer than i thought ;) [09:01] chrisccoulson: that's for xulrunner-2.0, not for -1.9.2, right? [09:01] pitti - that's for both [09:03] chrisccoulson: would it be a significant win to only get it half-done for natty? I. e. less porting work when we switch to ffox 5? [09:04] pitti - the only issue is if we ship with it in main, we are sort-of committed to supporting it (and that would mean porting everything really, so we don't break universe) [09:04] hmmm, is it only gwibber which keeps gnome-python-extras in main? [09:05] it certainly looks like it [09:05] what is gwibber using from it? [09:05] seb128 - python-gtkspell [09:05] chrisccoulson: thanks for the analysis -- it is quite some work indeed, but it seems feasible; and it's nicely parallelizable [09:05] chrisccoulson: g-p-e is pretty much obsolete by itself [09:05] chrisccoulson: in oneiric, when we switch to gtk 3, we need to get rid of it anyway [09:06] seb128 - the issue with having gnome-python-extras in main is that it keeps xulrunner in main (with python-gtkmozembed), and the only things using it are in universe [09:06] which is the same situation i have with swt-gtk [09:06] pitti - oh, that's cool that it is going away then :) [09:06] if you want to get ride of it in main for natty duplicate the source [09:06] confirmed, no other build/binary depends in main [09:06] stop building -mozembed from g-p-e [09:07] then add a g-p-e-universe which builds only that [09:07] it's a small cost [09:07] so for gwibber we'd need to build a .gir for libgtkspell, and then use that instead of the python binding [09:07] yeah, i guess we could do that [09:07] pitti, you can mix pygtk and gi? [09:07] pitti, gwibber is not using gi [09:08] seb128: depends [09:08] you can't mix gi.repository.Gtk with pygtk [09:08] well in any case that seems a next cycle sort of thing [09:08] you can certainly mix e. g. gi.repository.GUdev with pygtk [09:08] it would require building the .gir and porting gwibber [09:08] gtkspell links with libgtk, so it might be an issue [09:08] we better duplicate the source for natty [09:09] morning [09:09] hey rodrigo_ [09:09] seb128: i. e. build a python-gtkspell source? [09:09] and drop g-p-e to universe? [09:09] pitti, what I just wrote 15 lines before [09:10] ah, sorry [09:10] if you want to get ride of it in main for natty duplicate the source [09:10] stop building -mozembed from g-p-e [09:10] then add a g-p-e-universe which builds only that [09:10] or that way around [09:10] I've no strong preference which way it's done, as long as things needed in main are still built from the main source [09:11] note: [09:11] try: [09:11] well I would go for that rather than starting porting things to gi for this cycle [09:11] import gtkspell [09:11] except: [09:11] gtkspell = None [09:11] so in the simplest case we could just drop the spell check :) [09:11] (... dependency) [09:12] we could, be still it seems we have no reason [09:12] hmm [09:12] there is no issue with python-gtkspell [09:12] self.spell = util.gtkspell.Spell(self, None) [09:12] that's the only call to gtkspell ever in gwibber [09:12] and self.spell is not used anywhere !? [09:12] dpkg -L gwibber|xargs grep spell [09:13] https://bugs.launchpad.net/ubuntu/+source/gwibber/+bug/451374 [09:13] Launchpad bug 451374 in gwibber "gwibber is not spellchecking" [Low,Fix released] [09:13] same for grepping the entire source [09:13] suggests that spell checking is working though [09:14] ah, it probably attaches itself to the gtk.TextView, nevermind [09:15] seb128: anyway, its API is tiny [09:15] pitti - do you think you'd be able to fix that then? :) [09:16] chrisccoulson: building a .gir should be easy [09:16] excellent, thanks :) [09:16] chrisccoulson: but it requires porting gwibber to gtk gi as well [09:16] oh, that's a bit of a pain i guess ;) [09:16] so it's not for natty, I'm afraid, we have to go with the source split [09:16] ok, that shouldn't be too much of an issue [09:17] chrisccoulson: it's not a separate API, it basically provides an extension of Gtk.TextView [09:17] is Sweetshark not around today? [09:18] the split is tiny cost [09:18] it's not like g-p-e had weekly uploads and those would need to stay in sync [09:18] *nod* [09:18] seb128: I doubt that it will get a lot more releases in the first place [09:18] upstream has certainly ceased to work on it [09:18] right, I would really got the split in natty [09:18] we will go gi next cycle [09:19] seems that ported gwibber to gi now is calling for extra work and issues [09:19] that "porting" [09:19] gwibber is quite large, porting would be quite an issue [09:19] and it's a lot harder to port to PyGI gtk2 than to gtk3 [09:19] gtk3 pretty much just works now, but gtk2 is still a bit of a pain [09:20] just one week ago I committed http://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=6e178a69fc73b45f66fc511f7a274b8fefc2e2e7 which fixes more stuff (not even in natty yet), but we'll keep running into those [09:21] chrisccoulson: so, I'm happy to help out with some bits [09:22] just not today; I really need to take "off" today to catch up with bureaucracy, I need to do the brainstorm review for tech board and the performance review stuff [09:23] chrisccoulson: for gtk-vnc and friends, do you think it's cleaner to build against ffox-dev or copy headers? the latter sounds very .. unelegant [09:24] * pitti fixes a broken crash bug and restarts the amd64 retracer [09:36] pitti - we can build againt firefox-dev, but other npapi plugins (eg, totem) already include their own headers [09:36] npapi is cross-browser, so depending on firefox or xulrunner is quite a heavy dependency just to build a browser plugin [09:36] (a plugin which will work in any browser, too) [09:36] chrisccoulson: what happens if e. g. ffox 5 changes the API/ABI? with firefox-dev it would fail to build, with header copies it would crash; the former seems better? [09:37] or is npapi basically stable? [09:37] pitti - npapi is pretty stable (i don't think it's changed for a long time) [09:37] that would break things like flash [09:37] chrisccoulson: ok; my gut feeling is still that ffox-dev is better, if for nothing else than to avoid code copies? [09:37] yeah, we can do [09:38] as long as people are aware that we don't need to rebuild these plugins when we do a major firefox update === ogra is now known as Guest42038 === Guest42038 is now known as ogra_ [09:42] chrisccoulson: ah, you forgot to subscribe -release, so my first few comments went into the void [09:43] pitti - oops :/ [09:43] (no worries) [09:43] sorry about that ;) [09:45] chrisccoulson: I'll leave the evaluation of the libreoffice tasks to Sweetshark [09:45] chrisccoulson: libmozjs is also a stable sub-API of xulrunner? i. e. it's by and large just a splitout? [09:45] pitti, cool, thanks [09:46] pitti - libmozjs isn't terribly stable, which is the motivation for decoupling it from the firefox release schedule (and upstream are even going to provide release tarballs for that too) [09:46] the official release tarballs just won't get the same frequency of updates as firefox [09:47] ie, we'll be able to support it for a LTS without needing to upgrade it [09:47] chrisccoulson: for icedtea, that sounds like it wouldn't need the firefox bits at all, and just globally disable the xpcom stuff (which happens now anyway?) [09:47] pitti - mozilla bug 628723 for the libmozjs stuff [09:47] Mozilla bug 628723 in JavaScript Engine "Create JS 1.8.5 source release" [Normal,Assigned] http://bugzilla.mozilla.org/show_bug.cgi?id=628723 [09:48] pitti - yeah, icedtea still needs the npapi headers though (but it looks like that's all it needs) [09:48] pitti: Hi Martin, [09:48] pitti: Struggling with bug 740754 and C syntax. A helping hand from you - or somebody else you suggest - would be much appreciated. [09:48] Launchpad bug 740754 in gdm "Language selection for newly created user confusing" [Undecided,New] https://launchpad.net/bugs/740754 [09:49] GunnarHj: can you please subscribe me? I'm afraid I won't get to it today, but I'm happy to review the bug tomorrow [09:49] (or just ping other people, lots of folks here should be proficient with C) [09:57] pitti: Ok, just subscribed you. Maybe I ask somebody else later, as well. [10:06] pitti - oh, turning on -Wall in swt-gtk helps a bit ;) [10:07] webkitgtk.c: In function ‘Java_org_eclipse_swt_internal_webkit_WebKitGTK__1webkit_1get_1default_1session’:webkitgtk.c:775:2: warning: implicit declaration of function ‘webkit_get_default_session’ [10:07] i should have done that at the start ;) [10:07] chrisccoulson: oh, might that be the reason for the invalid conversions? [10:07] pitti - yeah, i guess so [10:07] chrisccoulson: as C implicitly assumes an int f(int) signature? [10:08] yeah, i think that's going to be the problem :) [10:08] phew [10:08] :) [10:08] chrisccoulson: wow, that seems serious enough to always warn about, not just with -Wall.. [10:08] i almost thought i wasn't going to be able to figure that out ;) [10:08] * pitti ^5s chrisccoulson [10:08] * chrisccoulson ^5s pitti too [10:24] pitti - http://paste.ubuntu.com/584212/ [10:24] fixed \o/ [10:25] awesome! [10:25] chrisccoulson: this is the kind of error which really should just abort compilation entirely :( [10:25] I see little point of assuming an ABI for an unknown function [10:25] yeah, i'm surprised that it doesn't already [10:25] the fun of C [10:25] heh [10:34] the buildds fail the build on implicit declaration warnings [10:34] well they grep the build log for those and fail the build if there is some [10:34] seb128 - the issue here is that there wouldn't have been any in the log [10:34] (as it's built without -Wall) [10:35] right, I was just pointing it ;-) [10:35] well, it's not built with any warnings enabled [10:35] that's probably a bug ;) [11:06] chrisccoulson, if it compiles, ship it! That is my mantra :) [11:13] heh :) [11:36] seb128: Hi Sebastien, do you possibly have time to help with a C syntax problem in GDM? [11:37] GunnarHj, yes? [11:37] mterry, hey [11:37] seb128, hi! [11:37] mterry, how busy are you today? ;-) [11:37] seb128: The attachment to bug 740754 explains the problem, I think. [11:37] Launchpad bug 740754 in gdm "Language selection for newly created user confusing" [Undecided,New] https://launchpad.net/bugs/740754 [11:39] seb128, I can become busier. I was just about to dump eclipse (it's got too much to work on for natty, I believe -- will leave brain dump in bug) [11:39] mterry, ok, so https://launchpad.net/ubuntu/+source/indicator-datetime/+bugs [11:40] mterry, mtp just opened quite some bugs, especially the location dynamic list is not working great [11:40] mterry, like it doesn't use translations, doesn't match things correctly [11:40] bug #740870 [11:40] Launchpad bug 740870 in indicator-datetime ""Location" auto-complete menu doesn't understand "london"" [Undecided,New] https://launchpad.net/bugs/740870 [11:40] bug #740874 [11:40] Launchpad bug 740874 in indicator-datetime ""Location" auto-complete menu doesn't know about San Francisco, USA" [Undecided,New] https://launchpad.net/bugs/740874 [11:40] bug #740884 [11:40] Launchpad bug 740884 in indicator-datetime ""Location" auto-complete menu often offers duplicate suggestions" [Undecided,New] https://launchpad.net/bugs/740884 [11:40] mterry, etc [11:40] seb128, yup, those look like my bugs :)( [11:40] mterry, karl seems to be busy enough with what is assigned to him [11:41] hello [11:41] mterry, could you maybe try to tackle some of those today? [11:41] mterry, just pick anything in the list you feel like doing [11:41] mterry, the idea is to improve a bit the indicator ;-) [11:41] seb128, yup :) I'm on it [11:41] mterry, thanks [11:41] dbarth, ^ [11:44] today upgraded from 7.10 to 8.4 - it was a great experience [11:44] seb128, what is this 'sniffles' tag? :) [11:44] mterry, it's a design thing I think [11:44] you can try asking mpt [11:45] but seems like what design guys spot when they do a review [11:46] seb128, mterry: cool, thanks; karl is also doing the triaging of the bug list at the same time; he's taking the string changes as a priority [11:50] is Hardy Heron still supported ? i checked this on wikipedia. On kubuntu page it said it is not spported but on the ubuntu page it is mentioned that it is still supported. I want to install the restricted extra - meaning i want to have the adobe flash. Should i upgrade all the way to 9.10 or i can keep on running Hardy Heron ? [11:58] kmanzoor, it is still supported on Desktop until April [11:58] kmanzoor, server for longer [11:59] i am using desktop [11:59] hmm, just upgraded and I get 'C++ compiler cannot create executables' error on configure [11:59] kmanzoor, but if you were to upgrade, I wouldn't recommend 9.10, you can jump right to 10.04, the new LTS [11:59] any idea if g++ is broken or something? [12:00] kmanzoor, but this isn't the best channel anyway. for support questions like that, try #ubuntu [12:00] 'Unrecognized option -qversion' [12:01] ok i joined #ubuntu === smspillaz|zzz is now known as smspillaz [12:05] pitti, just got your mail about the nautilus folder view thing, so just to say that yes, I'm willing to do it :-) [12:05] pitti, I'll read it in more detail in a bit [12:09] seb128: pitti: i've updated the FFE request at https://bugs.launchpad.net/ubuntu/+source/gtk+2.0/+bug/730740 [12:09] Launchpad bug 730740 in gtk+2.0 "Provide support for dynamically loading the new overlay scrollbar feature" [Wishlist,Confirmed] [12:12] pitti - ok, i think i've got all swt-gtk packages ready [12:12] Daviey, are you able to test euca, or is it broken to the point of not being testable? [12:13] chrisccoulson, I think it might be possible actually... The breakage we have now is starting an instance, but i don't think swt-gtk is related to that! [12:13] It's the web ui... so yes... should be able to test that [12:13] cool, thanks [12:14] chrisccoulson, will keep you posted, thanks. [12:17] re [12:17] rodrigo_, no clue about the gcc error [12:18] good morning! [12:19] hey cyphermox [12:19] how are you? [12:19] seb128, doing alright [12:20] cyphermox, did you get any upstream comment about your gnome-media work? I noticed the merge request but I'm not sure to understand enough about it to have an opinion [12:20] seb128, no I didn't yet. I should go poke somebody on gimpnet I guess [12:21] did you file it on gnome-media or gnome-control-center? [12:21] did that code move to g-c-c this cycle? [12:21] I think so yes [12:22] did you file it on g-c-c? [12:22] seb128, the best way to understand what is going on is to start mumble without an external mic, then plug one in and try to switch the input device from gnome-volume-control, not mumble [12:22] it's likely that nobody is reading gnome-media bugs, they do read g-c-c ones though [12:22] no, you're right, I filed it against gnome-media, 2.32 or whatever [12:22] try moving it to g-c-c [12:22] seb128, yeah [12:23] I'm getting a 500 now though ;) [12:23] or ping hadess on IRC [12:23] right, seems bgo is down since yesterday evening [12:23] ah [12:23] seb128: Will be away for an hour or so. Pls submit possible questions to the bug in the meantime. [12:23] ok, I noticed the mumble issue [12:23] GunnarHj, sorry I had it open in a tab but I had to run for lunch [12:23] GunnarHj, I will [12:24] seb128: No problem, see you later. [12:24] GunnarHj, the issue is obvious in your example [12:25] GunnarHj, *language is a pointer pointing to nothing [12:25] GunnarHj, you need to allocate some memory and point to it [12:27] seb128: Well, nothing about C is obvious to me. ;-) How could it work in the separate script then? [12:28] GunnarHj, the small example segfaults there [12:28] you might be lucky and get the pointer hitting a memory address you can use [12:29] but that's only luck === MacSlow is now known as MacSlow|lunch [12:36] chrisccoulson, bug #739497 is not a g-c-c issue right? [12:36] Launchpad bug 739497 in gnome-control-center "firefox 4.0 is not default by default" [Low,Invalid] https://launchpad.net/bugs/739497 [12:37] seb128, I pinged hadess, I'll see when I get a response [12:37] ok [12:37] GunnarHj, hey again, did you see my comments before timeouting? [12:37] rodrigo_: ah, great, thanks! [12:37] seb128: No, I didn't. [12:37] seb128 - the issue is that firefox is expecting to be default in gio and gconf, and we aren't setting /desktop/gnome/url-handlers/http to firefox by default anymore [12:37] although [12:38]