#ubuntu-desktop 2008-09-01 <kwwii> pitti: hey man, did both of my packages get into the last alpha? (the ones I gave you before leaving for vacation) <pitti> hey kwwii <pitti> kwwii: which versions? (just use "rmadison foo" to check the version of foo in all Ubuntu releases) <kwwii> ahh, thanks, now I see it <lool> seb128: Hey, welcome back <seb128> hello lool, thanks <lool> seb128: We discussed some desktop bits on Friday <lool> seb128: (I was the fallback contact for desktop stuff last week as everybody was on vac) <seb128> who is we and which ones exactly? ;-) <lool> During release meeting <lool> You might want to read the first part of the log, skipping mobile stuff <lool> Concerning desktop, gvfsd-trasher crasher and gtk+ screen flicker were discussed <lool> mdz brought up an old gpm bug <seb128> I've noticed those bugs in the summary <lool> I mentionned cheese shall be updated <lool> seb128: I bought a webcam last week <seb128> the gvfsd-trash crasher is not really an issue out of the number of duplicates and I've no clue how to get good informations or fix it <seb128> the gtk+ screen flicker, mclasen consider it as an xorg bug <lool> seb128: Yeah, me neither, the valgrind log isn't very helpful <lool> seb128: That said, the valgrind log might be better with more ddebs or something <seb128> no <lool> seb128: The problem with the screen flicker is that it is a lack of API on the xorg side <seb128> I did get valgrind logs for the trash crasher using a debug build, etc <seb128> there is an incorrect jump listed but the top stacktrace has no symbol <lool> seb128: So what happened is that gtk+ moved to a new API only to realize that it was too expensive/disruptive <seb128> I don't think it's in my power to fix the xorg api ;-) <seb128> or gtk <seb128> I would rather prefer let upstream sort that <lool> seb128: Exactly my point, I agree with the analysis that going forward we ought to fix the API <lool> seb128: But this will be in xrandr 1.3, then all drivers will have to be updated to support it, then gtk+ will be able to use it <lool> And the new API wasn't yet accepted <lool> So we're talking of a 3 months minimum cycle here <lool> (AIUI) <seb128> I'm confident that upstream will do something for FC10 which is due around the intrepid schedule too <seb128> gtk upstream <seb128> so I would just let them sort that <lool> Ok; I personally think gtk+ should defer using randr's problematic API until it has what they need <lool> Hey pitti, welcome back! <lool> pitti: You also might want to poke at the release team meeting's log from friday! :) <lool> pitti: One of the thing which came up was the consolekit config patch to not allow everybody to shutdown or reboot the machine; this prevents shutdown/reboot from the desktop though <pitti> lool: hey, thanks <lool> pitti: I guess we should revert to the gdm socket method <pitti> lool: right, either we enable the functionality in CK like upstream, or use gdm <lool> pitti: Yup; I thought this was your choice to make as you were on top of misc hal/dbus/ck issues and have some security clue <lool> pitti: I am disturbed too with this shutdown/reboot dbus interface <pitti> lool: I have bug 250506 open in a tab to address it ASAP <ubottu> Launchpad bug 250506 in consolekit "shutdown and restart buttons do nothing" [High,Confirmed] https://launchpad.net/bugs/250506 <lool> That's indeed the one we discussed I think <huats> morning everyone <seb128> lut huats <huats> plop seb128 <huats> I hope you had nice (and deserved) holidays :) <seb128> yes, excellent, thanks ;-) <huats> :) <wgrant> seb128: Since you seem to be lord of all things g-s-d and g-c-c, what do you think of my proposed fixes for bug #207781? <ubottu> Launchpad bug 207781 in gnome-settings-daemon "gnome-control-center and gnome-settings-daemon hardcode "Synaptics Touchpad", which breaks without xorg.conf" [Low,Confirmed] https://launchpad.net/bugs/207781 <seb128> wgrant: I've no clue about touchpad so I would prefer let somebody else comment <seb128> wgrant: and apparently there is no patch attached to this bug? <wgrant> seb128: That's true, I apparently forgot to attach debdiffs. <wgrant> seb128: Who is more qualified? <seb128> you could ask bryce maybe or #ubuntu-x <wgrant> OK, will do. Thanks. <seb128> would be nicer to have an xorg api to query that rather than relying on the naming <wgrant> My patch relies on the name of a property, but that property is what is used to set things, so it's safe. <wgrant> I can't see a better way. * NCommander is away: This creature sleeps beyond the reaches of time itself <seb128> hey pedro_ <pedro_> hey seb128! welcome back ;-) <seb128> thanks ;-) <seb128> pedro_: pitti has started fixing the retracers, that's not perfect yet but the intrepid one should be running again now <pedro_> woohoo go pitti ;-) <pedro_> seb128: thanks for let me know dude <vuntz> seb128: hey <seb128> hello vuntz <vuntz> seb128: just wanted to know what were the ubuntu plans for the logout dialog? <seb128> vuntz: I was sort of waiting on you because you told me you were going to land the opensuse dialog upstream but I guess that's not going to happen this cycle now? <vuntz> seb128: I hope that http://bugzilla.gnome.org/show_bug.cgi?id=507101 will get committed today, but I'm not sure it's fine for you <ubottu> Gnome bug 507101 in general "New UI for logout/shutdown dialogs" [Minor,New] <vuntz> seb128: heh. So, it's going to happen really soon now. Just need an icon and a second release team approval <seb128> vuntz: ah excellent <andre__> vuntz: ping those lazy r-t lurkers, ping them to death! <vuntz> andre__: waiting for the icon to be ready (I'm making artists work right now ;-)) <vuntz> seb128: you can see the screenshots at the end of the bug <vuntz> seb128: if you want one dialog with everything, it's possible, but you'll likely need to patch gnome-session (I suggest adding an Ubuntu-specific dbus method for the new dialog) <seb128> vuntz: right, I like the dialog but I've the feeling we will be asked to get a variant listing all the options for ubuntu <seb128> right <seb128> lool: how busy are you nowadays? would you have some time to look at desktop packaging issues? <lool> seb128: I'm overcommitted, but depends what you're going to ask <seb128> lool: the pygobject update is tricky because they added a library and that doesn't play nicely with the multi python versions, doko started doing the packaging changes required before his holidays but there is a bug and it doesn't build <seb128> lool: I've planned to look at it but I think I'll be swamped with updates and catching up this week so I was trying to see if you were maybe interested by having a look at the update <lool> seb128: What source version didn't build? <seb128> 2.15.2 <lool> Where I can get this? <lool> ("buildd" says 2.15.1-0ubuntu2 and that it built fine) <seb128> lool: http://people.ubuntu.com/~seb128/pygobject/ is the work in progress that doko did <seb128> lool: right, I didn't upload the new one since it's buggy <seb128> lool: you have the version before the changes (which fails to build because there is a conflict on the new lib because python versions) and the doko changes which ftbfs too but for an another reason (not sure which one now, I looked at it before my holidays quickly) <lool> seb128: Do you know what doko intendend to do? <lool> He added autoconf and automake bdeps and changed the way the source is built <lool> Ah I need to rebase on my version it seems <seb128> lool: I think he wanted to version the library name, he said that's similar to what python-svn does <lool> seb128: Do you know why the library is public instead of being e.g. a python module? <lool> - Add a new installed library libpyglib-2.0, which contains the extension <lool> API for third-part modules instead of relying on macros which accesses <lool> struct fields. <lool> I'm not quite sure who's going to use it <lool> There's no .pc file at least <lool> Hmm there's also public API <seb128> lool: no, better to ask to jdahlin on the gnome IRC <seb128> you already did ;-) <kwwii> seb128: the ubuntulooks package was removed from the seed for intrepid, right? <seb128> no clue, but that's public information so you can look as quickly as I can do <kwwii> erm, where? <lool> kwwii: lp:~ubuntu-core-dev/ubuntu-seeds/intrepid or some such <lool> /platform.intrepid and /ubuntu.intrepid rather <mpt> loic, I've been pointed in your direction for implementing improvements to the codec installation interface. Do you have a few minutes to discuss the current implementation? <mpt> lool, ^^ <lool> mpt: Hmm <lool> mpt: Sure <lool> mpt: I might not be the best person depending on what you ask, but I'm happy to discuss this topic <mpt> lool, the window that lists the available codecs looks like a subset of the Add/Remove Programs window, right? How difficult is it to change bits in that window? <lool> mpt: It's gnome-app-install <lool> mpt: Indeed, it's built using synaptic IIRC <mpt> which? :-) <mpt> Specifically, the Help button needs removing (currently it does more harm than good in the codec context), and the "Quick Introduction" is a non-sequitur <lool> mpt: What's the problem with the Help button? <lool> mpt: When I press it, I land in the "Install and Remove Applications" manual in yelp <mpt> The help it displays is completely irrelevant <mpt> exactly <mpt> It's nothing whatsoever to do with installing codecs <mpt> and whenever that happens it makes people less likely to use help anywhere else <lool> mpt: Ok, so currently this uses a generic tool, gnome-app-install; you can launch it manually and imagine that it's useful in different scenarii; I fear that if you want to provide help specialied for code installation, you will have to provide some sort of wrapper or derived app which links to that <mpt> It would be nice to have help for it, but we're past FeatureFreeze, so just removing it is probably best for now <mpt> lool, yes, I realize that, that's why I'm asking how difficult it is to change bits in this window <lool> What you want to do is change bits in this window when it's called for codec installs, correct? <mpt> exactly <mpt> I assume the "Canonical Codec Store" link is context-dependent <lool> I agree that solving this "properly" might be too intrusive post FF, but I wouldn't want to remove the Help button unconditionally <lool> Indeed <mpt> Right, I don't want to remove the Help button unconditionally, just in the codec situation <lool> mpt: I guess you probably know some python; check /usr/lib/python2.5/site-packages/AppInstall/distros/Ubuntu.py <lool> (label, url) = distro.get_codec_information_link() <lool> if (label is not None) and (url is not None): <lool> button = gtk.LinkButton(url, label) <lool> mpt: in AppInstall/activation.py <mpt> I'm in 8.04 at the moment <lool> mpt: grab lp:~ubuntu-core-dev/gnome-app-install/main <mpt> ah, thanks <mpt> I was just wanting to know whether it was possible :-) <lool> mpt: Sure, it should be <mpt> ok <lool> mpt: BTW it's the first time I poke at this :) <lool> It seems the UI already supports various mode of operation by subclassing ActivationStyle <lool> class CodecSearchActivationStyle(SearchActivationStyle): <lool> mpt: So it's very trivial <lool> mpt: I think it would be cleaner to provide Help for installing codecs rather than dropping the button completely though <mpt> Sure, but I'm assuming we can't do that past feature freeze <mpt> If we can, I'll happily write some <mpt> This will all likely be revamped for Intrepid+1 <lool> mpt: I think it's a fairly trivial UI tweak, but I could be wrong <lool> mpt: You could discuss this with release team to make sure <mpt> Thanks for your info lool <carciofo> hallo alle zusammen <ember_> what can make pkg-config --cflags return something but --exists none? <ember_> seb128: in gtk2-engines i've added to .install the right .pc but it seems debian/ has the old .pc, should i remove the old .pc from debian or revert the .install? <Laney> If Banshee sometimes stops responding to GNOME global hotkeys that I've set up, whose bug is that? <Laney> And if the answer is "it depends", how can I find out? <seb128> ember_: why did you add the .pc to start? it was not installed because the debian maintainer decided it was not required <carciofo> does any1 know about video editing? #ubuntu-desktop 2008-09-02 * hggdh is away: walking the dogs <wgrant> seb128: bryce acked my patches for bug #207781, and I've rebased the g-s-d one on your latest upload. <ubottu> Launchpad bug 207781 in gnome-settings-daemon "gnome-control-center and gnome-settings-daemon hardcode "Synaptics Touchpad", which breaks without xorg.conf" [Low,Triaged] https://launchpad.net/bugs/207781 <seb128> wgrant: hi, ok thanks, will sponsor those a bit later, I'm just waking up and catching up on mails from the night now <wgrant> seb128: Pfft, devs can't sleep! OK. <wgrant> Thanks. <seb128> ;-) <seb128> you're welcome, thank you for your work on the issue <huats> morning everyone <seb128> lool: hey <seb128> lool: how did you fix your libtool errors on pygobject yesterday? <lool> - Update patch 90_autofoo and update instructions to run libtoolize <lool> --force --copy. <lool> seb128: ^ <lool> The first time I did this, I forgot to replace the contents in the patch in 90_autofoo <lool> When I actually did it, it worked <seb128> lool: I copied the line in the patch but that gives me the same errors you had <lool> However Keybuk pushed for not using --force <lool> seb128: Which module is it? <seb128> lool: pygobject, there is a 2.15.3 available <seb128> lool: it was already available yesterday but I forgot to tell you <seb128> so they didn't change anything yet for the libs, etc, I just need to refresh the autofoo patch <seb128> "libtoolize --force --copy && aclocal-1.10 -I m4 && automake-1.10 --add-missing --force --copy && autoconf && rm -rf autom4te.cache" is what is in the patch and what I tried <lool> seb128: Hmm well I hope it works; if not I have other things I could try <seb128> and I get <seb128> ../libtool: line 833: X--tag=CC: command not found <seb128> etc <lool> Hmmm hmm <seb128> hate autotools ;-) <lool> You could try with --install in libtoolize; that's what I had in mind yesterday, but it might require dropping --force from a couple of places <lool> Sadly, I'm not educated enough to understand --install exactly <seb128> ok, I asked because I was wondering if you tweaking the commands again and didn't update the instructions <seb128> thanks <lool> And I've been not using it for years, as does gnome-common, so wanted to stick to the classical calls <lool> seb128: One thing which differs is that config.guess now ends up in the diff for some reason <lool> seb128: Hmm it worked for me <lool> seb128: Did you apply the other patches notably the one setting the macro dir? <lool> (2.15.3 is building here) <seb128> lool: I did quilt push -f 90_autofoo <seb128> copied your line <seb128> quilt refresh <seb128> quilt pop -a <seb128> debuild <seb128> hum, weird <lool> Ah in all cases you shouldn't do that <lool> seb128: That's the typical quilt issue that it wont pick up new files in your patch <lool> seb128: Do autotoools diff manually, or use differ <seb128> well, I assumed that your patch was modifying the same files so they were already added <lool> That's risky really <lool> I don't know whether it's the problem, but it could be <lool> seb128: I also updated instructions to drop config.guess from the diff; but that's certainly unrelated <seb128> lool: alright, while you are at it and it's building for you, do you mind uploading the new version? I don't think other changes are required <lool> seb128: That's what I was about to ask <seb128> thanks ;-) <lool> grrr W: pygobject source: patch-system-but-direct-changes-in-diff config.guess <lool> anyway <lool> seb128: (I uploaded but didn't test) <seb128> lool: (that's the intrepid way, isn't it ;-) <seb128> thanks <seb128> I'll test when it's published <lool> Heh I usually test my uploads! <seb128> yeah, me too, I usually restart my session to test updates (not for random apps, but libs, gnome-panel, gnome-session, etc) <seb128> NCommander: hey, around? <lool> seb128: Uhoh <lool> zsh: segmentation fault (core dumped) alacarte <lool> zsh: segmentation fault (core dumped) gnome-app-install <seb128> urg <lool> Crashes in init_gtk() <seb128> that's always like that, updates that you try are fine but when you don't try one it's buggy <lool> Exactly what I wanted to say <seb128> I'm wondering if pygtk should be updated to 2.13 in the same run <lool> Yes, that's what I think as well <seb128> you can as well do an another quick upload to Breaks: python-gtk (<< 2.13) <seb128> that will stop updates <fta2> seb128, hi, did you do have a chance to look at cairo since yesterday ? <seb128> fta2: no, will do that today, I've been swamped with catching up after holidays and new GNOME <fta2> ok, np <seb128> fta2: it's one of the next things on my list after the gvfs update I'm building <fta2> great <seb128> brb, trying the new gvfs <Keybuk> seb128: don't suppose you hand a screenshot of the new dialog handy? <seb128> Keybuk: screenshots on http://bugzilla.gnome.org/show_bug.cgi?id=507101 <ubottu> Gnome bug 507101 in general "New UI for logout/shutdown dialogs" [Minor,New] <seb128> and vuntz didn't manage to get the patch in yesterday tarball, I'll probably distro patch it <Keybuk> please do <crevette> hey <lool> Hmm running Xvfb in a chroot gives me: (EE) AIGLX error: dlopen of /usr/lib/dri/swrast_dri.so failed (/usr/lib/dri/swrast_dri.so: cannot open shared object file: No such file or directory) <lool> libgl1-mesa-dri looks like what I want <lool> seb128: Unfortunately, it seems to crash even with new pygtk <lool> make[3]: *** [check-local] Segmentation fault (core dumped) <seb128> not cool <dholbach> test <dholbach> DOING gedit 2.99.99 <dholbach> STOPPED DOING gedit 2.99.99 (version does not exist) <lool> DONE test of new bug bot? <seb128> lool: no, new way to claim updates <seb128> lool: using chan logs parsing <Keybuk> hurrah for Google Chrome <Keybuk> another webkit-based firefox killer <seb128> fta2: still around? my font look different using the new libcairo <seb128> I'm not sure I like the change but maybe the new libcairo is correct <seb128> anyway I'm going to upload, that need testing and fixing if required rather than being hold back <Keybuk> what changed? <seb128> Keybuk: in the rendering or in cairo? <Keybuk> rendering <seb128> not sure, font changes are not easy to describe, I'll try to take a screenshot <seb128> I would say the lines are "sharper" now <Keybuk> sounds like an LCD filter change? <seb128> could be yes <stefanlsd> seb128: Mind if i have a look at upgrading to pidgin 2.5.1? <seb128> the update is 1.6 patched to 1.7 upstream <seb128> stefanlsd: hi, it requires a freeze exception, and do you know how to update the symbol files, etc? <stefanlsd> seb128: understand bout the freeze exception. Dont know about symbol files but would like to learn... <stefanlsd> seb128: I think exception should be ok - http://developer.pidgin.im/query?status=closed&milestone=2.5.1 list of bugs closed. Doesnt look like many new features. <seb128> stefanlsd: you can have a look if you want but I'm just back from holidays and I've a lot to do so it's not the best time to reply to question for me, maybe try the motu team rather <seb128> stefanlsd: right <stefanlsd> seb128: I think the big bug fixed is the connecting to MSN servers. Other LP bugs open about this one also. kk. Thanks. Will have a look and work with motu. thanks! <seb128> you're welcome <seb128> Keybuk: http://people.ubuntu.com/~seb128/cairo.png <seb128> the top one is cairo 1.6 patched the bottom one is 1.7 <seb128> I found the contrast better before <fta2> seb128, yes, i also experienced this. this looks sharper but it's not bad for me. just a bit different. i'm not sure if it's expected, a wider audience could help <Keybuk> err <Keybuk> that looks like the lcd filter patch has been dropped <fta2> Keybuk, no, it has been merged <Keybuk> fta2: if you look at the N on the lower of the two, it only has a single black vertical line <Keybuk> whereas with the patch above, there are two light fringe lines around it <Keybuk> in fact, in the entire bottom line, you only get fringing in curves <Keybuk> which was the cairo behaviour pre-patch <Keybuk> ie. in 1.6 native upstream without our lcd filter patch <fta2> i'm surprised noone complained upstream (which is basically redhat) <Keybuk> so if the patch has been merged, it's been bodged <Keybuk> or not activated <Keybuk> (well, when I say "our" I really mean David Turner's patch) <fta2> there's no control for it, it's just there and interact with fontconfig <Keybuk> fta2: I'll pick through the code and see what got lost <seb128> Keybuk: thanks <vuntz> seb128: yeah, I'm not sure I'll be able to convince people to commit the new logout dialog now :/ Calum doesn't seem happy about it <seb128> vuntz: hey <seb128> vuntz: btw what do you do you to get compiz used only on cards where it's working on opensuse? <seb128> vuntz: the redhat guys dropped the gnome-wm changes in 2.23.91, I think I'll revert that for ubuntu <vuntz> seb128: there's a compiz-manager script that does all the magic <seb128> what magic? <vuntz> detection <seb128> right, but does it start something else if compiz can't be used? <vuntz> yes <lool> Oh thanks guys from bring up this topic: gnome-wm is complete crash <lool> *crack <seb128> and doesn't it confuse gnome-session if there is no compiz registering? <vuntz> seb128: the answer is probably yes, but what do you mean? :-) <lool> it will set the gconf key of which WM to run, even if the user never changed anything; it doesn't really allow one to override the wm <vuntz> lool: that was a distro patch, I'd say ;-) <lool> vuntz: It is in the distro patch, but I'm pretty sure it's upstream as well <vuntz> did anyone see Amaranth recently? <seb128> vuntz: well, gnome-session starts compiz but the compiz wrapper decides compiz can't be used and start openbox for example, isn't gnome-session waiting on compiz registration in the session to continue? <vuntz> lool: ah, maybe in 2.23 <seb128> vuntz: no <vuntz> seb128: absolutely no idea <vuntz> seb128: mccann stopped shipping gnome-wm in the latest tarball <seb128> vuntz: right, and I've no wm starting when using .91 <seb128> score <vuntz> it's still just a mess <lool> vuntz: Indeed, the code was cleaned up it seems <crevette> hello <lool> I think we should move away of our awful gnome-wm in Debian/Ubuntu <vuntz> lool: in 2.22, this was not upstream and purely ubuntu (and maybe fedora) issue <seb128> vuntz: first the gconf key which was used in 2.23.90 is not used, so it's ignoring my compiz setting <vuntz> seb128: so, the good news is that I'll be able to fix this. The bad news is "not this week" <seb128> vuntz: then it doesn't find any wm .desktop because it doesn't look in the right directory <seb128> lool: the gnome-wm used in ubuntu is the upstream one <lool> Then what I'm saying is obsolete now; I can't complain anymore <vuntz> did anyone see Amaranth recently? <seb128> vuntz: no <lool> seb128: Do you think you could check whether you get the crash of pygtk apps on i386? <seb128> lool: sure, give me some minutes to download and build 2.15.3 <lool> seb128: http://people.ubuntu.com/~lool/packages/pygtk/2.13.0-0ubuntu1/intrepid/ is the new pygtk <lool> seb128: I've not pushed it though; it requires the new pygobject which crashes and hence the testsuite fails <seb128> lool: should I update pygobject and pygtk or only pygobject? <lool> seb128: Only pygobject should cause the crash <lool> seb128: i'm handing you the pygtk tree just in case to avoid work duplication <seb128> ok thanks <lool> rsync error: some files could not be transferred (code 23) at main.c(1058) [sender=3.0.3] <lool> Intersting <seb128> lool: doesn't crash <seb128> I installed the current intrepid version using using dpkg and forcing the breaks <seb128> alacarte gnome-app-install update-manager work correctly <lool> seb128: Ok, thanks for testing <seb128> re <seb128> lool: sorry, restart to try some changes <seb128> lool: everything works fine on i386, I'm lucky that you did the update ;-) <seb128> I would not have figured about the issue before we started receiving bugs otherwise <wgrant> seb128: Am I likely to see my g-c-c and g-s-d patches in before the Alpha? <seb128> wgrant: yes <wgrant> seb128: Thanks. * wgrant -> bed <seb128> 'night wgrant <seb128> gicmo: do you have an ipod? <gicmo> yes <seb128> gicmo: could you try something for me, start rhythmbox, plug the ipod and try to eject it in rhythmbox <gicmo> hmm Ronja has it with her, need to wait for a bit until she arrives <seb128> ok <seb128> gicmo: https://bugs.launchpad.net/bugs/263903 has a valgrind log of the issue but lacks debug symbols <ubottu> Launchpad bug 263903 in rhythmbox "[intrepid] rhythmbox crashed with SIGSEGV in free()" [Medium,New] <seb128> invalid read and free in the gvfs volume monitor code apparently <gicmo> that new volume monitoring code is trouble <seb128> yeah, I should try to ping davidz about it <seb128> I guess he's busy doing devicekit and doesn't look much a gvfs nowadays <seb128> gicmo: I guess the crash is http://bugzilla.gnome.org/show_bug.cgi?id=546971 <ubottu> Gnome bug 546971 in hal volume monitor "rhythmbox crashed when ejecting an ipod device" [Critical,Unconfirmed] <gicmo> hmm maybe some locking issue <seb128> gicmo: do you know why valgrind has those: <seb128> --14017-- Discarding syms at 0x74ED000-0x7506000 in /usr/lib/gio/modules/libgioremote-volume-monitor.so due to munmap() <seb128> I'm wondering if that's the reason why the valgrind logs for the trash crashes lack debug symbols for example <gicmo> hmm <seb128> gicmo: I've attached a valgrind log on http://bugzilla.gnome.org/show_bug.cgi?id=546971, could you have a look and tell me if you think it's useful? <ubottu> Gnome bug 546971 in hal volume monitor "rhythmbox crashed when ejecting an ipod device" [Critical,Unconfirmed] * gicmo ooks <gicmo> (rhythmbox:14017): GLib-GObject-CRITICAL **: g_object_unref: assertion <gicmo> `G_IS_OBJECT (object)' failed <gicmo> eewwks <seb128> hum, imho rhythmbox is not clean either there <seb128> gicmo: ok, need log on the same bug which seems better <gicmo> need log? <seb128> new log <seb128> that one seems to be a rhythmbox bug <tedg> mpt: So in the FUSA applet we have an "other" option, which is basically do a FUSA transition but not to a specific user, just to the login screen. I'm curious if there isn't a better analogy to what is happening there. Something like "Pause Session." I don't think "Other" really works. Thoughts? <mpt> ooh, interesting <mpt> Mac OS X calls this "Login Window...", which tells me they couldn't think of a good label for it either <tedg> mpt: They can't figure out how to put more than one button on their phone, I'm not sure they should be the gold standard ;) <mpt> tedg, how is this usefully different from "Lock Screen"? <gicmo> seb128: the code where valgrin points us to looks okish here <tedg> mpt: Really? Not much. Lock screen launches the screensaver and defaults to login in as the same user. While "Other" results in a clean slate login. Both effectively pause the sesion the same. <seb128> gicmo: yes <tedg> mpt: I guess lock screen also allows you to leave notes. Critical feature. <mpt> bah <gicmo> seb128: #0 0xb6dfecc8 in strcmp () from /lib/tls/i686/cmov/libc.so.6 <gicmo> No symbol table info available. <gicmo> #1 0xb5834e11 in g_proxy_volume_update (volume=0x92d5d00, iter=0xbf9cb6fc) at <gicmo> gproxyvolume.c:227 <seb128> gicmo: what about this one? <gicmo> seb128: s the crash is if (volume->id != NULL && strcmp (volume->id, id) != 0) <seb128> gicmo: http://paste.ubuntu.com/42723/ <mpt> tedg, ah, I have a suggestion <seb128> gicmo: volume is being used after being freed apparently <gicmo> seb128: means either id, or volume->id is bogus <gicmo> seb128: yep, that was my guess as well <seb128> gicmo: should volume being unref-ed? maybe a ref counting on the gvfs side? <gicmo> seb128: so this is prolly a race between the one thing that frees shit and the other one that reuses it, right? <seb128> ref counting issue <mpt> tedg, call it "Switch To...", and put it immediately above the list of user accounts. Then indent each account name underneath. That way, as well as being a functioning menu item, it serves as an incidental introductory explanation of the purpose of the user account items. <gicmo> seb128: or that, indeed <seb128> gicmo: or that <seb128> I hate ref counting issues <seb128> never know how to debug those <gicmo> seb128: with the nice GObject env varibles <seb128> gicmo: tell me about it ;-) <tedg> mpt: Hmm... interesting. I'm not quite sure how an intent should work in a menu. It seems bad to indent the icons, but then just indenting the text seems wrong also. <mpt> tedg, what does it look like at the moment? I tried it with yesterday's daily live CD, but it crashed whenever I tried to open it <tedg> mpt: Let me send you a screenshot. <gicmo> GOBJECT_DEBUG <gicmo> seb128: set it to objects <gicmo> seb128: can you reproduce that crash reliably? <seb128> gicmo: every time, I pinged davidz, see #gnome-hackers, he will look into it <gicmo> seb128: sure, sure <gicmo> seb128: we are on our own, I guess ;-) <gicmo> seb128: if you can reproduce the crash fine, how about adding a <gicmo> g_print ("%s, %s", volume->id, id); <gicmo> to find out which id is NULL <gicmo> seb128: args, there is lots of async stuff going on <gicmo> seb128: I think, I even touched that code <gicmo> its easy to mess that ref counting up <seb128> gicmo: where are printed the monitors logs? on the gvfsd stdout? <gicmo> seb128: guess so <gicmo> seb128: or wait, maybe gvfs-hal-volume-monitor <seb128> (gdb) p *volume <seb128> $2 = {parent = {g_type_instance = {g_class = 0x9022998}, ref_count = 0, qdata = 0x12}, <seb128> volume_monitor = 0x9021b30, id = 0x1 <Address 0x1 out of bounds>, name = 0x0, <seb128> uuid = 0x1 <Address 0x1 out of bounds>, activation_uri = 0x400 <Address 0x400 out of bounds>, <seb128> icon = 0xffffd400, drive_id = 0x1f800 <Address 0x1f800 out of bounds>, <seb128> mount_id = 0x2c00 <Address 0x2c00 out of bounds>, identifiers = 0x0, foreign_mount = 0xffffcc00, <seb128> can_mount = 130048, should_automount = 17408} <seb128> 227 if (volume->id != NULL && strcmp (volume->id, id) != 0) <seb128> so volume is already freed <seb128> or something is corrupting the id <seb128> (gdb) p id <seb128> $3 = 0x90fb734 "0x8e0a700" <gicmo> seb128: p id gives what? <gicmo> ahh you can read my mind! <gicmo> p *id ? <gicmo> but that looks totally valid <seb128> (gdb) p *id <seb128> $4 = 48 '0' <seb128> imho there is a ref counting issue and volume is already freed there <gicmo> seb128: how about adding a g_print () to the volume_finalize () function? <gicmo> or wait <gicmo> better <gicmo> set a breakpoint <gicmo> and then do a "bt" <seb128> gicmo: to <seb128> g_proxy_volume_finalize()? <gicmo> yeah <gicmo> seb128: lets find out who unrefs the last reference <seb128> gicmo: it's called once on rhythmbox startup and not between the click to eject and the crash, wth? <gicmo> ugh! <gicmo> on startup? <seb128> I did try to gdb the application though <seb128> gicmo: when plugging the ipod <seb128> Breakpoint 1, g_proxy_volume_finalize (object=0x9b95100) at gproxyvolume.c:81 <seb128> 81 volume = G_PROXY_VOLUME (object); <seb128> (gdb) bt <seb128> #0 g_proxy_volume_finalize (object=0x9b95100) at gproxyvolume.c:81 <seb128> #1 0xb70f0f33 in IA__g_object_unref (_object=0x9b95100) at /build/buildd/glib2.0-2.17.7/gobject/gobject.c:2411 <seb128> #2 0xb5799c29 in signal_emit_in_idle_do (data=0x9cd1f28) at gproxyvolumemonitor.c:392 <seb128> #3 0xb6f14881 in g_idle_dispatch (source=0xa705510, callback=0x9ce3610, user_data=0x9cd1f28) <gicmo> aha <mpt> tedg, ah, I see <mpt> tedg, "Restart" and "Shut Down" shouldn't be indented either <gicmo> seb128: ok, that function takes a ref and release a ref <gicmo> seb128: means that the application shouldn't be doing anything with the ref itself <mpt> tedg, so for the items that should have icons, can you include the icons as part of the item text, so that they don't move the left edge of the text for those items that don't have icons? <mpt> i.e. <mpt> Switch To... <mpt> [] foo <mpt> [] bar <mpt> --------- <mpt> Log Out <seb128> gicmo: ok, did "c", there is a second breakpoint <seb128> #0 g_proxy_volume_finalize (object=0xa756a60) at gproxyvolume.c:81 <mpt> Restart <seb128> #1 0xb70f0f33 in IA__g_object_unref (_object=0xa756a60) at /build/buildd/glib2.0-2.17.7/gobject/gobject.c:2411 <seb128> #2 0x0807fad9 in rb_removable_media_manager_add_mount (mgr=0x9ec60c8, mount=0xa757320) <seb128> at rb-removable-media-manager.c:582 <gicmo> seb128: I am already at that very code palce <seb128> gicmo: ;-) <seb128> and it's not called after that until the crash <gicmo> seb128: I dont see that damn g_object_unref <gicmo> I only see an unref ot a mount <seb128> gicmo: can't gdb put a watch on a variable? <seb128> to break when it changes or is freed? <gicmo> watch <gicmo> seb128: are you seeing my query? <seb128> gicmo: yes <tedg> mpt, well can, yes. That's non-standard for GNOME apps. <tedg> mpt, normally the text is in one column an the icons another. The text is shifted if there are any icons in the menu. <mpt> tedg, Gnome applications use icons for any menu item they can. This menu does not: this menu uses icons as an exception, representing statuses and people, rather than as a rule. <tedg> mpt: The only items that _don't_ have icons are the session ones. The status ones have icons and all the user-switching items have icons. <mpt> tedg, yes, the exceptions outnumber the rule-followers, but I don't think that matters <mpt> tedg, for example, the items without icons in <http://z.about.com/d/browsers/1/5/K/0/-/-/safarihistory2.jpg> don't change their indentation just because they're outnumbered by those with icons. <tedg> mpt: Hmm, let me play with some stuff. I'm not excited about this yet, but I think that it is going somewhere. I'll draw up something and send it to you. <mpt> ok <seb128> hey NCommander <NCommander> hey seb128 <seb128> NCommander: did you read my comment about pangomm yesterday? <NCommander> seb128, nope <seb128> there is an example which is under the GPL <seb128> but the tarball has no GPL license <seb128> did you contact upstream about that? <NCommander> seb128, no, I did note it in the copyright file though <seb128> lool didn't point it as an issue? <seb128> NCommander: it might be rejected in debian NEW due to that <seb128> I didn't sponsor to ubuntu yet <NCommander> If lool did, it was too long along for me to remember <NCommander> s/along/long/g <NCommander> er <NCommander> ... <NCommander> *fails* <seb128> well it's really a detail <seb128> but technically if there is a source under the GPL the license text should be in the tarball <seb128> or it's not distributable <lool> NCommander: I missed that example under GPL <lool> NCommander: Which file is it? <lool> seb128: Can I push pygobject with the fix? shall I check with slangasek? <NCommander> seb128, not if the full text of the license is in the the example itself <seb128> lool: no, just upload, there is already a bug complain about ubuntu-desktop not being installable right now and that breaks builds <lool> seb128: I have pygtk in the pipe as well <NCommander> lool, I don't remember off hand, someone noted it to me, and I remember adding it to the copyright file <seb128> lool: I still have a bunch of GNOME 2.23.91 tarballs I'll upload tomorrow <seb128> NCommander: the license text is a several pages text and is not in the example ;-) <lool> seb128: What happens when a FFE is granted exactly? <lool> seb128: I filed a FFE, but I don't know what I'm actually supposed to watch for <lool> (I subed ubuntu-release) <seb128> lool: you don't need a FFE <lool> (on Friday) <lool> seb128: it's for another package <seb128> ah for something else <NCommander> lool & seb128 damn it :-/. I wish I caught that beforehand <seb128> you will get somebody from the corresponding team giving an ack and changing the status, then you can upload <seb128> depends if that's main or universe <lool> seb128: The packages are elisa and its plugins <lool> in main <NCommander> Multiple people looked at it, which annoys me as well that we all missed it :-/ <seb128> just pitti slangasek or pitti on IRC to get your ack then ;-) <seb128> s/pitti/ping <lool> NCommander: grep "GNU General" -rl * only yields tools/extra_defs_gen/generate_defs_pango.cc and it's covered in the copyright file <NCommander> Yeah, I know, I caught that <lool> seb128: Ok; I'll poke him again then <seb128> lool: right, but there is no GPL license in the tarball <lool> seb128: I was asking because I wondered whether a tag would be set or somesuch <NCommander> But I didn't catch there wasn't a COPYING file in the tarball that had the GPL <lool> Oh <NCommander> Yeah >.<; <NCommander> d'oh <lool> That's an upstream issue; it wont be rejected in Debian for that I would guess <NCommander> If it clears the NEW queue, I'll just leave a bug on pangomm's bug tracker <seb128> those issues usually warant a NEW rejection in ubuntu <seb128> NCommander: you can open a bug in any case <NCommander> seb128, right, I plan to <NCommander> BTW, lool or seb128 you know anything about managing seeds? <NCommander> I'm pushing a change into the xubuntu seed, but I'm not sure I did it right <NCommander> (i.e., I made the change to the files right <seb128> that's documented on the wiki <lool> NCommander: You can't do anything else than file a bug in the upstream tracker anyway <NCommander> lool, I'll be suprised if it doesn't clear NEW, but I got to say the speed of the queue is suprising <NCommander> I don't remember my other packages taking this long to clear <seb128> the focus is probably on lenny and not on new uploads <NCommander> that's what I keep telling myself * NCommander is currently burning his way through T&S <lool> Doing glib 2.18.0 <seb128> lool: thanks, don't forget to get some sleep too you deserve it ;-) <seb128> lool: and don't bother opening a sync request I'll sync it tomorrow morning <lool> Ok <seb128> alright, enough work for me for today, I'm going to bed * lool waves 'night <seb128> good night <lool> I'm going too I think <seb128> 'night lool <lool> 'night to you too #ubuntu-desktop 2008-09-03 * hggdh is away: movie time <stefanlsd> seb128: I realise you said you may not have time at the moment to help with pidgin 2.5.1. I'm not getting any assistance from motu re. the libpurple0.symbols. I have created 2.5.1. Checked if the patches are still valid and it all seems good. I just wanted to verify the symbol stuff, but am unsure about this. Do you know of anything that I could read to help me out - i found https://wiki.ubuntu.com/PackagingGuide/Recipes/CheckingLibrarySymbols <stefanlsd> - but i'm not sure this is the correct thing. <seb128> no I don't know, I've never really used it myself before and I hacked a bit to do the previous pidgin update <seb128> I don't think the ubuntu wiki is updated for the new symbols list <seb128> that's a new debian feature and the wiki page was written before <stefanlsd> seb128: how do i determine if the symbols are correct or if there may be a problem with them? <seb128> during the build the dpkg-gensymbols call will display a symbols diff, if there is any change you need to update the list <seb128> the tricky part is how to update the list correctly <stefanlsd> seb128: kk. thanks. let me see if i get any errors. then i'll worry about how to fix them :) <seb128> alright <stefanlsd> seb128: yeah :| - http://pastebin.ubuntu.com/42980/ <seb128> stefanlsd: right <seb128> stefanlsd: I'm leanning torward "let debian do the update and merge on their new version" <seb128> they will likely package 1.5.1 in experimental <huats> seb128: hey <huats> seb128: I have put the new gcalctool on LP <seb128> hey huats, just read your gcalctool sponsoring request <huats> seb128: ok great <huats> :) <huats> thanks <mpt> seb128, hey there <seb128> hello mpt <mpt> seb128, I dinged Pidgin for having logging off by default. Upstream says they're uncomfortable with changing that, but might change their minds if we set logging on by default in our Pidgin package and no-one (or hardly anyone) complains. Is that something you'd be willing to do? <seb128> mpt: yes, I see no issue with that, we have time to get feedback and it's easy to change if that's an issue <wgrant> That default has always bugged me. <wgrant> It's always first thing I change if I remember. <mpt> seb128, ok, should I report a bug for it then? <seb128> mpt: yes please and give me the bug number <stefanlsd> seb128: i've been going through the symbol stuff (and i think im slowly understanding it!) dpkg-gensymbols wants to remove the libgnt.so.0 (do you know if this lib no longer being built as part of libpurple0?) <mpt> seb128, bug 180796 <ubottu> Launchpad bug 180796 in pidgin "Logging is off by default" [Undecided,New] https://launchpad.net/bugs/180796 <seb128> mpt: thanks <mpt> thank you seb128 :-) <seb128> stefanlsd: no, it was already doing that in the previous version, not sure why <stefanlsd> seb128: i am going to try add the new symbols and remove the libgnt symbols (i see libgnt is actually part of finch). Would this be the correct approach? <seb128> stefanlsd: I've no clue, honestly wait on debian to do this update <stefanlsd> seb128: heh. kk. i'm going to keep playing as its something i'd like to try learn and understand. <mpt> asac_, Firefox in Ubuntu defaults to storing history for 90 days. Is that a change from upstream? I thought the default was 9 days <asac_> mpt: we dont change anthing in that direction <mpt> hm, must be new in FF3 then <asac_> mpt: most likely it was bumped to 90 days because of the new places <asac_> yeah <andreasn> mpt: what would be the arguments against logging by default? privacy reasons or disk space? <mpt> andreasn, I don't know, but they seem to be against browsers storing history, e-mail programs storing messages, etc as well <mpt> http://pidgin.im/pipermail/devel/2008-August/006644.html <mpt> well, that's one person, I shouldn't extrapolate :-) <mpt> see also http://pidgin.im/pipermail/devel/2008-August/006643.html <lapo> hi <lapo> I read a strange story about the next default icon theme... <lapo> is oxygen+human really going to be the default icon theme on gnome for hardy+1? <thorwil> lapo: #ubuntu-artwork would be more appropiate. but no. where did you read that? <lapo> thorwil: this one sounds a tad scary to me: https://lists.ubuntu.com/archives/ubuntu-art/2008-September/007559.html <thorwil> lapo: you should read there. word for word. don't jump to conclusions. don't start silly rumors. pick the appropriate channel! <lapo> did I started a silly rumor? <seb128> tedg1: there is a new gnome-power-manager version available if you want to do the update <ember> asac make it two beers <thorwil> lapo: they start exactly like this <thorwil> lapo: i will leave no other word about this topic here <lapo> uhm, sorry about that, just asked <asac> ember: anything else ;)? <tedg1> seb128: Yes, it fixes mario's bug also. <tedg1> I'm going to try and get this icons working first though. <seb128> tedg1: do you confirm http://launchpadlibrarian.net/17251753/gnome-power-manager-hardy.debdiff is correct for an hardy update? <tgnb> hi there, i have a friend who has a strange ssh problem <tedg1> seb128: Yes, but, I'm offended that it removes the curly braces. They're a good coding practice. Richard said that he added the same patch to SVN for this release, I was going to grab that one so that it could be tied to an SVN version number as a cherry pick. <tgnb> i tried to help him but im actually stumped, thought maybe i could inquire in here <tgnb> he is on a ubuntu laptop, and connects to 5 servers via ssh <tgnb> recently he lost the ability to connect to one out of 5 servers .. but only from his office <seb128> tedg1: the patch is the svn one, http://svn.gnome.org/viewvc/gnome-power-manager/trunk/libhal-glib/libhal-gpower.c?r1=2910&r2=2909&pathrev=2910 <tgnb> when connecting it just sits there before prompting for username and password <tgnb> it doesn't seem to ever time out though .. he's waited a very long time <tedg1> seb128: Ah, cool. It should probably say that in the comment. For the record, I still don't like the lack of braces, but better to match SVN :) <seb128> tgnb: hi, that's not an user channel and ssh is not a desktop application so you are at the wrong place anyway <tgnb> ok sorry then :/ <seb128> tedg1: right, you can talk to upstream about the style change ;-) <seb128> tgnb: try #ubuntu <lapo> seb128: do you remember the iso image icon I sent you time ago? <asac> seb128: when will the next -keyring snapshot end up in the archive? <seb128> lapo: yes, it's used in the ubuntu gnome-icon-theme <asac> seb128: i think they committed a potential fix for my ssh agent issues <asac> so wonder if i should just wait a bit to verify ... or test the patch manually <seb128> asac: they didn't rolled a tarball this week but yet another GNOME is due next week, I've seen the bug, they fixed it in gnome-session though no? <asac> not sure ... was a bit of back and forth <asac> let me look <lapo> seb128: I think it would be important to have a .deb specific icon as well, if I send you the icons can you patch ubuntu g-i-t with them, I cannot add them upstream without being killed :-) <asac> seb128: one patch is against gnome-keyring-daemon-wrapper.c the other compat/gnome-keyring-daemon-wrapper.c <seb128> lapo: yes, can do that ;-) <lapo> seb128: thank, I'll send you the icon tomorrow or the day after <seb128> asac: that's gnome-session <seb128> asac: I packaged the new version but it has issues so I didn't upload <seb128> lapo: thank you! <asac> seb128: ok. thanks <seb128> asac: I can scp it somewhere if you want to give it a try <asac> seb128: what issues does it have? <seb128> asac: they changed again the way the wm is started which breaks compiz again <asac> ok ... if its just compiz its fine. i dont use it here ;) <seb128> asac: you might get no wm at all <asac> unless it busts other sessions as well :) <asac> hmm <asac> i think ill cherry pick ;) <seb128> alright <vuntz> seb128: you might want to grab patches from trunk and put back gnome-wm <seb128> vuntz: I'm going to wait for the next tarball and revert the gnome-wm changes <vuntz> seb128: next tarball? <seb128> vuntz: next week <seb128> 2.23.92 <vuntz> ah, ok <seb128> I'm not in a hurry to update <vuntz> asac: hopefully, the changes in 2.23.91 should fix your keyring issues. If not, please ping me <seb128> vuntz: has the gnome-wm thing be discussed somewhere? <vuntz> seb128: no... <seb128> vuntz: also it stopped looking at the directory where the metacity autostart is installed which means you get now wm at all <seb128> s/now/no <vuntz> seb128: we discussed all the issues afterwards, with fcrozat <seb128> and? <vuntz> seb128: this last one is fixed if you put back gnome-wm or if you use the latest metacity <vuntz> seb128: we didn't understand why gnome-wm isn't shipped anymore :-) <seb128> I'll put gnome-wm back I think <seb128> the redhat guys don't like it <vuntz> I know <vuntz> we need to discuss what's wrong with it and fix the issues <seb128> vuntz: btw how did the "what gdm version should be used for 2.24" discussion turned? <vuntz> seb128: andre is responsible for it. No idea where it went <seb128> ok <vuntz> andre__, I meant <seb128> vuntz: is opensuse using 2.23? <vuntz> yeah <seb128> no complain? <vuntz> not that much <seb128> I'm impressed ;-) <vuntz> but I've not been following this closely <seb128> hpj is looking at it right? <vuntz> yep <andre__> oh, i'm responsible for it? :-) <vuntz> andre__: sure yo uare <andre__> i thought it's vuntz :) <vuntz> andre__: stop lying! <andre__> no, really :) <andre__> don't outsource your tasks to me, honey! <vuntz> why would it be me? You handled everything! <seb128> alright, nobody is looking at this one <andre__> no, only a few things i had on my list last friday :) <asac> seb128: \o/ i can use the keyring again <asac> what a relieve ;) <seb128> :-) <vuntz> andre__: so, let's make it official. You're responsible of this decision :-P <asac> relief <asac> not sure <asac> ;) <seb128> asac: what I don't get is why you have the issue and nobody else <vuntz> seb128: I know the keyring was broken here too. Sure, it's not ubuntu ;-) <seb128> vuntz: well it's working for me, at least I get the ssh agent <seb128> anyway good to know it's working for asac too now ;-) <asac> i dunno. i am happy that vuntz had this as well ;) <asac> otherwise i probably would have ended up typgin my passphras 1billion times ;) <andre__> vuntz, i'm quite undecided now that i see that opensuse and foresight don't see big issues <vuntz> andre__: your call <seb128> andre__: how much testing does unstable opensuse get? ;-) <andre__> so i'll let the fun for you <vuntz> andre__: you're so dreaming ;-) <seb128> and I expect lot of the annoyance will be for normal users <seb128> ie no gdmsetup will really annoy users <seb128> no way to enable autologin <pedro_> themes ;-) <andre__> well, what if we're refusing to use it for another time? we will end up in some state where the gdm hackers won't care at all about r-t comments. on the other hand,
{'channel': 'ubuntu-desktop', 'month': 9}