=== PrivateVoid_ is now known as PrivateVoid
[09:16] <huats> morning everyone
[09:18] <seb128> lut huats
[09:18] <huats> lut seb128
[09:39] <seb128> who has an opinion on whether the "serie to track and usual updaters" updates list should be access restricted or not?
[09:39] <seb128> ie, bzr in ubuntu-desktop or desktop-bugs rather?
[09:48] <mvo> seb128: do you happen to remember the bugnumber for the "something opens when clicking on places" ? I just got it in another report
[09:49] <seb128> mvo: bug #260492
[09:49] <ubottu> Launchpad bug 260492 in nautilus "opening a directory using an application change associations incorrectly" [Medium,Fix released] https://launchpad.net/bugs/260492
[09:52] <mvo> seb128: in bug #291132 the person claims it happens with a recent upgrade as well (he says he upgraded from 8.04 to intrepid final)
[09:52] <ubottu> Launchpad bug 291132 in update-manager "upgrade 8.04 to 8.10" [Undecided,Fix released] https://launchpad.net/bugs/291132
[09:53] <seb128> mvo: hum?
[09:53] <seb128> mvo: we didn't do anything to migrate user configs on upgrade, that's why the update-manager task has been opened on the other bug
[09:53] <seb128> mvo: intrepid will not writte buggy configuration but users who did change it in hardy will notice that change after upgrading since gnome-panel respects the choice now which it didn't in hardy
[09:55] <mvo> seb128: oh, sorry. I thought it was a bug *during* the development cycle in intrepid
[09:56] <mvo> seb128: in this case I think we should do something similar to the fusa-migration stuff
[09:56] <seb128> mvo: no, we would not have bother for unstable users
[09:56] <seb128> I mean they know running unstable can lead to some glitches
[09:56] <mvo> my bad, I misread that
[09:56] <seb128> we will need to fix before the next lts in any case
[09:57] <seb128> I mean do something to fix those configs
[09:58] <seb128> mvo: that should be easier than the applet change, the configuration is one line in .local/share/applications/mimeapps.list
[09:58] <mvo> seb128: ok, do you plan to fix it in gnome-panel? or via a note ?
[09:59] <seb128> mvo: how would you fix that in gnome-panel? gnome-panel is only respecting the user config
[09:59] <mvo> seb128: if note, I can add it and prepare a upload now, I think this is anyoing (and common) enough so that we act quickly
[09:59] <seb128> mvo: you could be using GNOME and gtk-nautilus rather than nautilus
[09:59] <mvo> seb128: not sure, my gut-feeling is that if the config is "open totem for a directory" then there is probably something wrong
[09:59] <seb128> so gnome-panel should open directories in gtk-nautilus in this case
[09:59] <seb128> right
[10:00] <mvo> but yeah, I see your point
[10:00]  * mvo scratches head
[10:02] <seb128> mvo: basically we could to that
[10:03] <seb128> mvo: python -c 'import gio; print gio.app_info_get_default_for_type("inode/directory", True).get_executable()'
[10:03] <seb128> mvo: if that not == nautilus, display a note "your default association to open directories is not nautilus, that might be a bug, do you want to reset it to nautilus"
[10:04] <seb128> and the reset button would just make sure .local/share/applications/mimeapps.list has nautilus listed first for the directory
[10:04] <seb128> mvo: what do you think?
[10:04] <mvo> seb128: thats cool, lets do it - I think the right place would be in the panel itself but a note will be much quicker to do
[10:04] <seb128> That's not perfect but should be good enough
[10:04] <seb128> mvo: what in the gnome-panel?
[10:05] <seb128> mvo: gnome-panel respects associations for a reason, you might be using gtkfilemanager as your filemanager in which case you want the places menu to use that and not nautilus
[10:06] <seb128> so you can't say "gnome-panel always uses nautilus to open directories"
[10:06] <seb128> but maybe I don't get what you suggest
[10:06] <seb128> what would you change exactly?
[10:21] <mvo> seb128: I was thinking of a one time message "your association is not nautilus, if that is deliberate fine, if not click here to fix it" with better wording of course inside the panel. but I guess this leaves us with the disdavantage that we can not detect if it was a upgrade or a fresh install
[10:21] <mvo> seb128: with the note we can do that and only install the note on upgrades
[10:24] <mvo> seb128: let me know what you think, if we want a note, I can prepare a update, I would need help with the SRU verification instructions though
[10:24] <seb128> mvo: do we have a way to display this note only if nautilus is not the default association?
[10:25] <mvo> seb128: yes, there is a "DisplayIf" key that can run any shell command
[10:25] <mvo> seb128: any command really
[10:27] <seb128> mvo: I'm thinking about it, what you did for the applet migration was a gnome-panel change, that's different of the note, what are the advantage of the different solutions?
[10:27] <mvo> seb128: so we put the python code there plus a test if the check was already run (I think its enough if the check is run once after upgrade)
[10:27] <seb128> I've to admit the difference between an application note and an update-manager one is not clear to me right now
[10:27] <seb128> let's go the other way
[10:27] <mvo> seb128: update-manager can not do it  itself because it runs as root and may not have access to the users homedirs (e.g. in nfs environments with the rootsquash option)
[10:28] <seb128> we want something which is displayed once after upgrade from hardy for users where nautilus is not the default association
[10:28] <mvo> right, I think we can do it inside the panel itself or via a note?
[10:28] <seb128> you probably know better than me what is the best tool we have to do that
[10:28] <mvo> eh, no "?" here :)
[10:28] <seb128> gnome-panel, as a patch to the C upstream code?
[10:29] <mvo> yes
[10:29] <mvo> I think those are the alternatives we have
[10:29] <seb128> my gut feeling is that patching upstream code is not the right place for that
[10:29]  * mvo nods
[10:29] <seb128> what are the disadvantages of the note approch?
[10:30] <mvo> its a bit clunky, but otherwise there is none - I mean, a note displaying "there might be something wrong, fix it: [yes] [no]"
[10:31] <seb128> well, having it in gnome-panel would not display anything different
[10:31] <seb128> so it should be gnome-panel installing the note, similar to what you did for the applets migration?
[10:31] <mvo> hm, right
[10:31] <seb128> I think we should go this way
[10:32] <seb128> the test is basically the python snippet I wrote before
[10:32] <mvo> yes, I think so - we *could* just fix it automatically on upgrade and say that the (few) people who changed it deliberately can fix it themself, but I don't feel well about it
[10:32] <seb128> they didn't wrap the equivalent _set api yet though which sucks
[10:32] <seb128> no, I like better displaying a note to people who have a weird association
[10:33] <seb128> we could do a "appname is set to open directory, that could be a bug, do you want to change it back to nautilus?"
[10:34] <mvo> seb128: I will prepare something and post it for review (unless you want to take it which is fine with me of course)
[10:35] <seb128> mvo: I'm think in fact we could just automatically change it
[10:35] <james_w> what would be the fallout from just changing it back?
[10:35] <mvo> seb128: right
[10:35] <seb128> james_w: what I wrote before " gnome-panel respects associations for a reason, you might be using gtkfilemanager as your filemanager in which case you want the places menu to use that and not nautilus"
[10:35] <mvo> james_w: good question, nothing as far as the panel is concerned because hardy did not honor it anyway
[10:36] <seb128> mvo: right that was just what I was thinking too
[10:36] <mvo> so there is no change here
[10:36] <seb128> since hardy didn't respect it
[10:36] <mvo> does it have any other effect?
[10:36] <mvo> I mean, does anything beside the panel read that association?
[10:36] <seb128> well that's gio association
[10:36] <seb128> so anything which opens a directory using gio
[10:37] <seb128> but I would say it's a marginal usecase
[10:37] <seb128> I doubt anything out of gnome-panel is doing that in the standard install
[10:37] <seb128> and the world has not switched to gio otherwise
[10:37] <seb128> ok
[10:37] <seb128> let's do automatic fixing on upgrade ;-)
[10:37] <mvo> ok, so we need something in Xsession.d/ for that
[10:38] <seb128> urg
[10:38] <mvo> yeah, sucks
[10:38] <seb128> I don't like things staying around in Xsession.d
[10:38] <mvo> the alternative would be: "for d in /home/*; do ..."
[10:38] <mvo> in the postinst
[10:38] <mvo> which is *eeeeek*
[10:39] <seb128> I'm considering the gnome-panel code change now
[10:39] <mvo> (and will not work on nfs mounted homes)
[10:39] <mvo> right
[10:39] <mvo> that is best I think
[10:39] <mvo> check on startup, change if needed and set a gconf key that the check was performed and should never run again
[10:39] <seb128> the annoying part how to figure "first startup after hardy upgrade"
[10:40] <seb128> we will need to add a gconf key I guess
[10:40] <mvo> yeah
[10:40] <seb128> ok, so we are clear on what needs to be done
[10:40] <mvo> and for fresh installs we can just ship the gconf key with "already_run = True"
[10:40] <seb128> how?
[10:41] <mvo> hrm, right. no - so we need to run it once for fresh installs too, but that should be fine because the default there is nautilus
[10:41] <james_w> can you ship a default gconf key with "not_run = True" and then run the upgrade if that is found, setting "not_run = False" for the user?
[10:41] <seb128> we can hack a postinst snipet to set this key only on upgrade
[10:42] <mvo> seb128: yeah!
[10:42] <mvo> need_fixup = True :)
[10:42] <mvo> I like that
[10:42] <seb128> ;-)
[10:42] <seb128> ok, what we need then is
[10:43] <seb128> - have a new key defaulting to false
[10:43] <seb128> - a postinst snippet setting it to true for upgrades
[10:43] <seb128> - gnome-panel code which reads this key and call the code when the key is true
[10:43] <seb128> - the code change the default association to nautilus if that's not nautilus yet
[10:44] <seb128> - and after running the key is set to false
[10:44] <seb128> mvo: looks correct?
[10:44] <mvo> yes, looks perfect
[10:45] <seb128> do you want to do those changes or should I?
[10:45] <mvo> either way is fine for me
[10:46] <seb128> same here ;-)
[10:46] <seb128> I'll probably not start before lunch and I've lunch outside today but I can have a look this afternoon
[10:46] <seb128> feel free to start on it if you want, I'll look at this this afternoon otherwise
[10:46] <mvo> ok, cool
[10:47] <seb128> that should just be calling app_info_get_default_for_type and then app_info_set_as_default_for_type
[10:47] <mvo> let see what other issues I run accross and how busy the morning will be
[10:47] <mvo> hm, a opportunity to put gnome-panel into bzr ... ;)
[10:48] <crevette> hello chaps
[10:48] <mvo> hey crevette
[10:48] <seb128> lut crevette
[10:48] <seb128> mvo: you didn't do that yet? ;-)
[10:48] <seb128> bah bug #291482
[10:48] <ubottu> Launchpad bug 291482 in libgnome "package libgnome2-0 2.24.1-0ubuntu4 failed to install/upgrade: " [Undecided,New] https://launchpad.net/bugs/291482
[10:49] <seb128> did I already complained about those upgrade bugs ;-)
[10:49] <mvo> seb128: I did :) but nothing really major came up (yeah!)
[10:49] <seb128> joke aside looking at the recent bugs list I was surprised how many random upgrade bugs we are getting
[10:49] <mvo> seb128: make your scripts more robust ;)
[10:49] <seb128> lot of users must be running into issues
[10:50] <seb128> mvo: add || true after all the commands? ;-)
[10:51] <mvo> seb128: jokes aside, yes - this is a problem and something thats pretty anoying
[10:51] <mvo> seb128: I mean, upgrades are really too fragile and its just too many things that can go wrong (and do go wrong)
[10:52] <mvo> its hard to fix without major changes though, I think we did cover most of the easy and medium improvements
[10:52]  * mvo checks the error that seb mentions
[10:53] <seb128> mvo: we could easily delay all the cache updates, etc to be run after the upgrades no?
[10:54] <seb128> so installations would not break when update-icon-cache crash for a random reason
[10:54] <seb128> or similar issues
[10:58] <mvo> seb128: hrm, this particular one looks really nasty
[10:59] <seb128> mvo: what is the error exactly? I've been to lazy to read all the logs there ;-)
[10:59] <mvo> seb128: this one looks like a problem in the way apt calls dpkg :(
[11:00] <seb128> urg
[11:00] <mvo> yeah, really really nasty
[11:00] <seb128> you can reassign it where you want that doesn't seem to be desktopish
[11:00]  * seb128 hugs mvo
[11:00] <mvo> I will write some code that extracts his packages and tries to reproduce it, I would love to be able to and check a fix, this is the kind of error I don't want
[11:01] <mvo> there goes the gnome-panel work :)
[11:01] <mvo> seb128: I already reassigned it to apt
[11:01] <seb128> ok, I'll have a look to the gnome-panel changes
[11:01] <seb128> looks a nice friday afternoon project
[11:12] <mvo> seb128: ok, I updated the bugreport to include the plan
[11:19] <seb128> mvo: thanks
[12:00] <tuxice> mpt?
[12:00] <mpt> yep
[12:00] <tuxice> i have a fix for bug 160311
[12:00] <ubottu> Launchpad bug 160311 in metacity "Window Resize Difficult (Window Border Thickness)" [Wishlist,New] https://launchpad.net/bugs/160311
[12:01] <tuxice> i propose we add a slider to the theme selection tab in the appearence menu, or even a new tab altogether.
[12:03] <tuxice> what do you think?
[12:07] <tuxice> mpt?
[12:07] <mpt> one moment, reading the report
[12:08] <tuxice> k
[12:12] <mpt> this is a long bug report :-)
[12:13] <tuxice> ya
[12:27] <tuxice> mpt?
[12:28] <mpt> tuxice, I'm commenting on the report
[12:28] <mpt> I don't have anything massively useful to say though
[12:35] <tuxice> camoguy?
[12:35] <mpt> done
[12:36] <tuxice> Do you think adding a sliderbar, that would increase the border would be a worthy fix?
[12:36] <tuxice> mpt?
[12:37] <mpt> No, I think that would be dumping the problem on users without solving it
[12:37] <tuxice> i see.
[12:37] <mpt> Making them choose between efficient and ugly
[12:37] <tuxice> what would be a fix?
[12:37] <mpt> er, between efficient and ugly, vs. awkward and attractive
[12:38] <mpt> I've suggested possible solutions in the bug report
[12:38] <tuxice> ya
[12:38] <tuxice> ok
[12:38] <mpt> * try the invisible draggable area and see if it works
[12:38] <mpt> * get GTK to introduce a corner grippy that doesn't require a status bar
[12:38] <mpt> * report bugs on apps that could have a corner grippy but don't
[12:39] <tuxice> +1
[12:41] <tuxice> g2g
[13:33] <alexvanlier> hello
[14:28] <isaw> Hi... can anyone help with a fragged 8.1 upgrade?
[14:58] <huats> seb128: have you heard of some intrepid freezes ?
[14:58] <huats> i mean of system  freeze :)
[14:59] <mvo> wb seb128
[14:59] <seb128> re
[14:59] <seb128> huats: intrepid is stable now so it's frozen, you need sru to do updates
[14:59] <huats> no non
[14:59] <huats> :)
[14:59] <huats> i mean of system  freeze :)
[15:00] <huats> i just had 4 on my running system :)
[15:00] <seb128> urg
[15:00] <seb128> no vt switch?
[15:00] <seb128> what videocard and driver?
[15:00] <mvo> huats: when does it freeze?
[15:01] <huats> mvo: random :)
[15:01] <seb128> huats: can you ssh to the box when it's frozen?
[15:01] <mvo> huats: what videocard and driver?
[15:01] <huats> mvo: sometime with evolution (writing an email) sometime with flash in firefox
[15:01] <huats> ...
[15:01] <mvo> seb128: I put a proposed patch into the bugreport we talked about earlier (review welcome, its not a nice one :(
[15:01] <mvo>  what videocard and driver?
[15:02] <mvo> with compiz or without?
[15:02] <huats> searching that :)
[15:02] <mvo> lspci -nn
[15:02] <huats> (without compiz)
[15:02] <mvo> if you paste the output of that, we shoudl be fine
[15:02] <huats>  nVidia Corporation GeForce 8400M G
[15:02] <mvo> ok
[15:02] <huats> seb128: I haven't try the ssh, I cannot switch to the console
[15:02] <mvo> /var/log/Xorg.0.log will have the used driver (either nvidia or nv)
[15:03] <huats> nvidia
[15:03] <mvo> hrm, that is bad(tm)
[15:03] <seb128> huats: try to ssh
[15:03] <huats> (I know :( )
[15:03] <seb128> usually I blame compiz for those
[15:03] <huats> seb128: I try (next time which will be soon I am sure)
[15:03] <huats> and I'll let you know :)
[15:03] <seb128> try using nv instead of nvidia too
[15:04] <seb128> mvo: ok thanks, will have a look
[15:04] <huats> thanks mvo and seb128
[15:04] <mvo> seb128: no rush
[15:04] <mvo> seb128: while waiting for the upgrade test thing I had a bit of free time
[15:05] <seb128> ;-)
[15:12] <seb128> mvo: looking to your patch now
[15:12] <seb128> +	      g_warning("inode/directory points to '%s' - fixing", g_app_info_get_executable(app), "nautilus");
[15:13] <seb128> mvo: wrong number of arguments there?
[15:15] <seb128> mvo: you also g_object_unref(app); in the case where app == NULL
[15:17] <mvo> thanks for the review
[15:18] <seb128> mvo: otherwise for the loop that's either that or building a new GAppInfo so I think iterating over the option is reasonable
[15:18] <seb128> not sure if there is a function which takes a .desktop and return a GAppInfo
[15:24] <mvo> seb128: I tried that using the nautilus.desktop file, but that crashed for me (no idea why) - app != NULL
[15:24] <mvo> I mean it was != NULL
[15:24] <seb128> what function did you try?
[15:27] <mvo> give me a sec
[15:27] <mvo> g_desktop_app_info_new_from_file I think
[15:28] <seb128> mvo: also I'm not sure about that
[15:28] <seb128> +		    new_app = l->data;
[15:28] <seb128> +		 g_object_unref(new_app);
[15:28] <seb128> +	      g_list_free(l);
[15:29] <seb128> mvo: you don't increment the ref by doing new_app =l ->data do you?
[15:29] <seb128> mvo: isn't g_list_free unrefing l anyway?
[15:29] <dobey> no
[15:29] <dobey> g_list_free doesn't know how to deal with the data in it
[15:30] <dobey> you have to loop through the list and unref/free/whatever each item, and then free the list
[15:34] <mvo> thanks dobey
[15:39] <huats> seb128: no luck with the ssh after the freeze (and no ping of the computer either)
[15:39] <seb128> huats: seems a system crash and not an xorg one then
[15:39] <huats> yep
[15:39] <seb128> mvo: g_desktop_app_info_new_from_file should be working
[15:39] <seb128> weird
[15:41] <mvo> seb128: no idea, maybe I did something wrong
[15:41] <seb128> mvo: I'll have a look in a bit
[15:41] <seb128> out of the previous comment the patch looks good to me
[15:42] <mvo> seb128: thanks, I need to run out in a bit, so feel free to take over from here
[15:43] <seb128> mvo: will do, have fun see you later
[15:46] <mvo> seb128: thanks!
[16:25] <seb128> grrrr at xulrunner
[16:25] <seb128> you could think they would fix bugs sometimes but it's still crashing on closing and doing that since before hardy that starts being annoying
[16:26] <seb128> when it's not hanging and preventing you to open a new instance
[16:27] <dobey> welcome to Web 2.0
[16:28] <dobey> where nothing works, and there are more browser engines that all behave completely differently
=== jtisme is now known as jt1
=== jt1 is now known as jt2
=== jt2 is now known as jt66
=== jt66 is now known as jtisme
=== jtisme is now known as jt66
=== jtisme is now known as jt66
=== jtisme is now known as jt66
=== jt66 is now known as jtisme
=== jtisme is now known as jt66
=== jtisme is now known as jt66
[19:50]  * jt66 is away: I'm busy
[20:41] <mvo> hm, will g_list_free(g_list_last()) DTRT and free all of the list (and not just from the element it started on)?
[20:42] <dobey> that looks like it's asking for problems
[20:42] <mvo> heh :)
[20:42] <mvo> this is why I'm asking, I check the glib source
[20:42] <dobey> glib is doing that?
[20:43] <mvo> well, I don't know. I was just wondering if I need to keep a head pointer around
[20:44] <dobey> what are you trying to do exactly
[20:44] <mvo> I have a GList and iterate over it, when I'm done I want to free it
[20:45] <dobey> for (l = list; l && l->data; l = l->next) { item = l->data; list = list_remove (list, item); free (item); } list_free (list);
[20:45] <walters> mvo: no
[20:46] <mvo> thanks dobey and walters
[23:23] <simpman> Installing ubuntu desktop 8.10 having problems it's freezing during the loading splash screen while trying to boot. checksumed the md5, as well as booting it from USB and Live CD and the problem remains. Any suggestions would be appreciated