[00:53] * hggdh is away: walking the dogs === hggdh is now known as hggdh|away [08:36] seb128: bryce acked my patches for bug #207781, and I've rebased the g-s-d one on your latest upload. [08:36] 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 [08:37] wgrant: hi, ok thanks, will sponsor those a bit later, I'm just waking up and catching up on mails from the night now [08:37] seb128: Pfft, devs can't sleep! OK. [08:37] Thanks. [08:37] ;-) [08:37] you're welcome, thank you for your work on the issue [09:11] morning everyone [10:26] lool: hey [10:27] lool: how did you fix your libtool errors on pygobject yesterday? [10:32] - Update patch 90_autofoo and update instructions to run libtoolize [10:32] --force --copy. [10:32] seb128: ^ [10:32] The first time I did this, I forgot to replace the contents in the patch in 90_autofoo [10:32] When I actually did it, it worked [10:32] lool: I copied the line in the patch but that gives me the same errors you had [10:32] However Keybuk pushed for not using --force [10:32] seb128: Which module is it? [10:33] lool: pygobject, there is a 2.15.3 available [10:33] lool: it was already available yesterday but I forgot to tell you [10:33] so they didn't change anything yet for the libs, etc, I just need to refresh the autofoo patch [10:34] "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 [10:34] seb128: Hmm well I hope it works; if not I have other things I could try [10:35] and I get [10:35] ../libtool: line 833: X--tag=CC: command not found [10:35] etc [10:35] Hmmm hmm [10:35] hate autotools ;-) [10:36] 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 [10:36] Sadly, I'm not educated enough to understand --install exactly [10:36] ok, I asked because I was wondering if you tweaking the commands again and didn't update the instructions [10:36] thanks [10:36] And I've been not using it for years, as does gnome-common, so wanted to stick to the classical calls [10:39] seb128: One thing which differs is that config.guess now ends up in the diff for some reason [10:40] seb128: Hmm it worked for me [10:41] seb128: Did you apply the other patches notably the one setting the macro dir? [10:41] (2.15.3 is building here) [10:41] lool: I did quilt push -f 90_autofoo [10:41] copied your line [10:41] quilt refresh [10:41] quilt pop -a [10:41] debuild [10:42] hum, weird [10:42] Ah in all cases you shouldn't do that [10:42] seb128: That's the typical quilt issue that it wont pick up new files in your patch [10:42] seb128: Do autotoools diff manually, or use differ [10:43] well, I assumed that your patch was modifying the same files so they were already added [10:43] That's risky really [10:43] I don't know whether it's the problem, but it could be [10:44] seb128: I also updated instructions to drop config.guess from the diff; but that's certainly unrelated [10:44] 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 [10:45] seb128: That's what I was about to ask [10:45] thanks ;-) [10:46] grrr W: pygobject source: patch-system-but-direct-changes-in-diff config.guess [10:46] anyway [10:47] seb128: (I uploaded but didn't test) [10:48] lool: (that's the intrepid way, isn't it ;-) [10:48] thanks [10:48] I'll test when it's published [10:48] Heh I usually test my uploads! [10:49] yeah, me too, I usually restart my session to test updates (not for random apps, but libs, gnome-panel, gnome-session, etc) [10:50] NCommander: hey, around? [10:51] seb128: Uhoh [10:51] zsh: segmentation fault (core dumped) alacarte [10:51] zsh: segmentation fault (core dumped) gnome-app-install [10:52] urg [10:52] Crashes in init_gtk() [10:52] that's always like that, updates that you try are fine but when you don't try one it's buggy [10:52] Exactly what I wanted to say [10:52] I'm wondering if pygtk should be updated to 2.13 in the same run [10:52] Yes, that's what I think as well [10:53] you can as well do an another quick upload to Breaks: python-gtk (<< 2.13) [10:53] that will stop updates [10:56] seb128, hi, did you do have a chance to look at cairo since yesterday ? [10:57] fta2: no, will do that today, I've been swamped with catching up after holidays and new GNOME [10:57] ok, np [10:57] fta2: it's one of the next things on my list after the gvfs update I'm building [10:59] great [11:02] brb, trying the new gvfs [11:14] seb128: don't suppose you hand a screenshot of the new dialog handy? [11:15] Keybuk: screenshots on http://bugzilla.gnome.org/show_bug.cgi?id=507101 [11:15] Gnome bug 507101 in general "New UI for logout/shutdown dialogs" [Minor,New] [11:15] and vuntz didn't manage to get the patch in yesterday tarball, I'll probably distro patch it [11:16] please do [11:18] hey [11:24] 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) [11:25] libgl1-mesa-dri looks like what I want [11:31] seb128: Unfortunately, it seems to crash even with new pygtk [11:31] make[3]: *** [check-local] Segmentation fault (core dumped) [11:31] not cool [11:38] test [11:38] DOING gedit 2.99.99 [11:38] STOPPED DOING gedit 2.99.99 (version does not exist) [11:40] DONE test of new bug bot? [11:40] lool: no, new way to claim updates [11:41] lool: using chan logs parsing [11:47] hurrah for Google Chrome [11:47] another webkit-based firefox killer [11:57] fta2: still around? my font look different using the new libcairo [11:58] I'm not sure I like the change but maybe the new libcairo is correct [11:58] anyway I'm going to upload, that need testing and fixing if required rather than being hold back [11:58] what changed? [11:58] Keybuk: in the rendering or in cairo? [11:59] rendering [11:59] not sure, font changes are not easy to describe, I'll try to take a screenshot [12:00] I would say the lines are "sharper" now [12:03] sounds like an LCD filter change? [12:03] could be yes [12:03] seb128: Mind if i have a look at upgrading to pidgin 2.5.1? [12:03] the update is 1.6 patched to 1.7 upstream [12:04] stefanlsd: hi, it requires a freeze exception, and do you know how to update the symbol files, etc? [12:06] seb128: understand bout the freeze exception. Dont know about symbol files but would like to learn... [12:07] 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. [12:07] 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 [12:08] stefanlsd: right [12:08] 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! [12:09] you're welcome [12:13] Keybuk: http://people.ubuntu.com/~seb128/cairo.png [12:13] the top one is cairo 1.6 patched the bottom one is 1.7 [12:15] I found the contrast better before [12:24] 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 [12:24] err [12:24] that looks like the lcd filter patch has been dropped [12:25] Keybuk, no, it has been merged [12:25] fta2: if you look at the N on the lower of the two, it only has a single black vertical line [12:25] whereas with the patch above, there are two light fringe lines around it [12:26] in fact, in the entire bottom line, you only get fringing in curves [12:26] which was the cairo behaviour pre-patch [12:26] ie. in 1.6 native upstream without our lcd filter patch [12:26] i'm surprised noone complained upstream (which is basically redhat) [12:27] so if the patch has been merged, it's been bodged [12:27] or not activated [12:28] (well, when I say "our" I really mean David Turner's patch) [12:28] there's no control for it, it's just there and interact with fontconfig [12:28] fta2: I'll pick through the code and see what got lost [12:28] Keybuk: thanks [12:34] 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 [12:34] vuntz: hey [12:35] vuntz: btw what do you do you to get compiz used only on cards where it's working on opensuse? [12:35] vuntz: the redhat guys dropped the gnome-wm changes in 2.23.91, I think I'll revert that for ubuntu [12:36] seb128: there's a compiz-manager script that does all the magic [12:36] what magic? [12:36] detection [12:36] right, but does it start something else if compiz can't be used? [12:36] yes [12:36] Oh thanks guys from bring up this topic: gnome-wm is complete crash [12:36] *crack [12:37] and doesn't it confuse gnome-session if there is no compiz registering? [12:37] seb128: the answer is probably yes, but what do you mean? :-) [12:37] 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 [12:37] lool: that was a distro patch, I'd say ;-) [12:37] vuntz: It is in the distro patch, but I'm pretty sure it's upstream as well [12:37] did anyone see Amaranth recently? [12:38] 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? [12:38] lool: ah, maybe in 2.23 [12:38] vuntz: no [12:39] seb128: absolutely no idea [12:39] seb128: mccann stopped shipping gnome-wm in the latest tarball [12:39] vuntz: right, and I've no wm starting when using .91 [12:39] score [12:39] it's still just a mess [12:39] vuntz: Indeed, the code was cleaned up it seems [12:39] hello [12:40] I think we should move away of our awful gnome-wm in Debian/Ubuntu [12:40] lool: in 2.22, this was not upstream and purely ubuntu (and maybe fedora) issue [12:40] vuntz: first the gconf key which was used in 2.23.90 is not used, so it's ignoring my compiz setting [12:40] seb128: so, the good news is that I'll be able to fix this. The bad news is "not this week" [12:41] vuntz: then it doesn't find any wm .desktop because it doesn't look in the right directory [12:41] lool: the gnome-wm used in ubuntu is the upstream one [12:42] Then what I'm saying is obsolete now; I can't complain anymore [12:43] did anyone see Amaranth recently? [12:44] vuntz: no === asac_ is now known as asac [13:57] seb128: Do you think you could check whether you get the crash of pygtk apps on i386? [13:57] lool: sure, give me some minutes to download and build 2.15.3 [13:57] seb128: http://people.ubuntu.com/~lool/packages/pygtk/2.13.0-0ubuntu1/intrepid/ is the new pygtk [13:58] seb128: I've not pushed it though; it requires the new pygobject which crashes and hence the testsuite fails [13:58] lool: should I update pygobject and pygtk or only pygobject? [13:58] seb128: Only pygobject should cause the crash [13:58] seb128: i'm handing you the pygtk tree just in case to avoid work duplication [13:58] ok thanks [13:59] rsync error: some files could not be transferred (code 23) at main.c(1058) [sender=3.0.3] [13:59] Intersting [14:00] lool: doesn't crash [14:00] I installed the current intrepid version using using dpkg and forcing the breaks [14:01] alacarte gnome-app-install update-manager work correctly [14:08] seb128: Ok, thanks for testing [14:08] re [14:08] lool: sorry, restart to try some changes [14:08] lool: everything works fine on i386, I'm lucky that you did the update ;-) [14:09] I would not have figured about the issue before we started receiving bugs otherwise [14:19] seb128: Am I likely to see my g-c-c and g-s-d patches in before the Alpha? [14:20] wgrant: yes [14:20] seb128: Thanks. [14:20] * wgrant -> bed [14:20] 'night wgrant === hggdh_ is now known as hggdh__ === hggdh__ is now known as hggdh [15:45] gicmo: do you have an ipod? [15:46] yes [15:46] gicmo: could you try something for me, start rhythmbox, plug the ipod and try to eject it in rhythmbox [15:48] hmm Ronja has it with her, need to wait for a bit until she arrives [15:48] ok [15:49] gicmo: https://bugs.launchpad.net/bugs/263903 has a valgrind log of the issue but lacks debug symbols [15:49] Launchpad bug 263903 in rhythmbox "[intrepid] rhythmbox crashed with SIGSEGV in free()" [Medium,New] [15:49] invalid read and free in the gvfs volume monitor code apparently [15:50] that new volume monitoring code is trouble [15:50] yeah, I should try to ping davidz about it [15:51] I guess he's busy doing devicekit and doesn't look much a gvfs nowadays [15:52] gicmo: I guess the crash is http://bugzilla.gnome.org/show_bug.cgi?id=546971 [15:52] Gnome bug 546971 in hal volume monitor "rhythmbox crashed when ejecting an ipod device" [Critical,Unconfirmed] [15:53] hmm maybe some locking issue [16:03] gicmo: do you know why valgrind has those: [16:04] --14017-- Discarding syms at 0x74ED000-0x7506000 in /usr/lib/gio/modules/libgioremote-volume-monitor.so due to munmap() [16:04] I'm wondering if that's the reason why the valgrind logs for the trash crashes lack debug symbols for example [16:04] hmm [16:07] 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? [16:07] Gnome bug 546971 in hal volume monitor "rhythmbox crashed when ejecting an ipod device" [Critical,Unconfirmed] [16:07] * gicmo ooks [16:08] (rhythmbox:14017): GLib-GObject-CRITICAL **: g_object_unref: assertion [16:08] `G_IS_OBJECT (object)' failed [16:08] eewwks [16:10] hum, imho rhythmbox is not clean either there [16:11] gicmo: ok, need log on the same bug which seems better [16:11] need log? [16:12] new log [16:12] that one seems to be a rhythmbox bug [16:12] 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? [16:13] ooh, interesting [16:13] Mac OS X calls this "Login Window...", which tells me they couldn't think of a good label for it either [16:14] 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 ;) [16:14] tedg, how is this usefully different from "Lock Screen"? [16:15] seb128: the code where valgrin points us to looks okish here [16:15] 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. [16:15] gicmo: yes [16:16] mpt: I guess lock screen also allows you to leave notes. Critical feature. [16:16] bah [16:17] seb128: #0 0xb6dfecc8 in strcmp () from /lib/tls/i686/cmov/libc.so.6 [16:17] No symbol table info available. [16:17] #1 0xb5834e11 in g_proxy_volume_update (volume=0x92d5d00, iter=0xbf9cb6fc) at [16:17] gproxyvolume.c:227 [16:17] gicmo: what about this one? [16:17] seb128: s the crash is if (volume->id != NULL && strcmp (volume->id, id) != 0) [16:17] gicmo: http://paste.ubuntu.com/42723/ [16:17] tedg, ah, I have a suggestion [16:17] gicmo: volume is being used after being freed apparently [16:17] seb128: means either id, or volume->id is bogus [16:18] seb128: yep, that was my guess as well [16:18] gicmo: should volume being unref-ed? maybe a ref counting on the gvfs side? [16:18] seb128: so this is prolly a race between the one thing that frees shit and the other one that reuses it, right? [16:18] ref counting issue [16:18] 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. [16:18] seb128: or that, indeed [16:18] gicmo: or that [16:18] I hate ref counting issues [16:18] never know how to debug those [16:19] seb128: with the nice GObject env varibles [16:19] gicmo: tell me about it ;-) [16:20] 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. [16:21] 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 [16:21] mpt: Let me send you a screenshot. [16:22] GOBJECT_DEBUG [16:22] seb128: set it to objects [16:24] seb128: can you reproduce that crash reliably? [16:25] gicmo: every time, I pinged davidz, see #gnome-hackers, he will look into it [16:25] seb128: sure, sure [16:25] seb128: we are on our own, I guess ;-) [16:28] seb128: if you can reproduce the crash fine, how about adding a [16:28] g_print ("%s, %s", volume->id, id); [16:28] to find out which id is NULL [16:30] seb128: args, there is lots of async stuff going on [16:30] seb128: I think, I even touched that code [16:30] its easy to mess that ref counting up [16:33] gicmo: where are printed the monitors logs? on the gvfsd stdout? [16:33] seb128: guess so [16:34] seb128: or wait, maybe gvfs-hal-volume-monitor [16:34] (gdb) p *volume [16:34] $2 = {parent = {g_type_instance = {g_class = 0x9022998}, ref_count = 0, qdata = 0x12}, [16:34] volume_monitor = 0x9021b30, id = 0x1

, name = 0x0, [16:34] uuid = 0x1

, activation_uri = 0x400

, [16:34] icon = 0xffffd400, drive_id = 0x1f800

, [16:34] mount_id = 0x2c00

, identifiers = 0x0, foreign_mount = 0xffffcc00, [16:34] can_mount = 130048, should_automount = 17408} [16:34] 227 if (volume->id != NULL && strcmp (volume->id, id) != 0) [16:34] so volume is already freed [16:34] or something is corrupting the id [16:35] (gdb) p id [16:35] $3 = 0x90fb734 "0x8e0a700" [16:35] seb128: p id gives what? [16:35] ahh you can read my mind! [16:35] p *id ? [16:35] but that looks totally valid [16:35] (gdb) p *id [16:35] $4 = 48 '0' [16:36] imho there is a ref counting issue and volume is already freed there [16:36] seb128: how about adding a g_print () to the volume_finalize () function? [16:36] or wait [16:36] better [16:37] set a breakpoint [16:37] and then do a "bt" [16:38] gicmo: to [16:38] g_proxy_volume_finalize()? [16:39] yeah [16:39] seb128: lets find out who unrefs the last reference [16:42] gicmo: it's called once on rhythmbox startup and not between the click to eject and the crash, wth? [16:42] ugh! [16:42] on startup? [16:42] I did try to gdb the application though [16:43] gicmo: when plugging the ipod [16:43] Breakpoint 1, g_proxy_volume_finalize (object=0x9b95100) at gproxyvolume.c:81 [16:43] 81 volume = G_PROXY_VOLUME (object); [16:43] (gdb) bt [16:43] #0 g_proxy_volume_finalize (object=0x9b95100) at gproxyvolume.c:81 [16:43] #1 0xb70f0f33 in IA__g_object_unref (_object=0x9b95100) at /build/buildd/glib2.0-2.17.7/gobject/gobject.c:2411 [16:43] #2 0xb5799c29 in signal_emit_in_idle_do (data=0x9cd1f28) at gproxyvolumemonitor.c:392 [16:43] #3 0xb6f14881 in g_idle_dispatch (source=0xa705510, callback=0x9ce3610, user_data=0x9cd1f28) [16:43] aha [16:44] tedg, ah, I see [16:45] tedg, "Restart" and "Shut Down" shouldn't be indented either [16:45] seb128: ok, that function takes a ref and release a ref [16:45] seb128: means that the application shouldn't be doing anything with the ref itself [16:46] 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? [16:47] i.e. [16:47] Switch To... [16:47] [] foo [16:47] [] bar [16:47] --------- [16:48] Log Out [16:48] gicmo: ok, did "c", there is a second breakpoint [16:48] #0 g_proxy_volume_finalize (object=0xa756a60) at gproxyvolume.c:81 [16:48] Restart [16:48] #1 0xb70f0f33 in IA__g_object_unref (_object=0xa756a60) at /build/buildd/glib2.0-2.17.7/gobject/gobject.c:2411 [16:48] #2 0x0807fad9 in rb_removable_media_manager_add_mount (mgr=0x9ec60c8, mount=0xa757320) [16:48] at rb-removable-media-manager.c:582 [16:48] seb128: I am already at that very code palce [16:48] gicmo: ;-) [16:49] and it's not called after that until the crash [16:54] seb128: I dont see that damn g_object_unref [16:54] I only see an unref ot a mount [16:54] gicmo: can't gdb put a watch on a variable? [16:54] to break when it changes or is freed? [16:55] watch [17:02] seb128: are you seeing my query? [17:03] gicmo: yes [17:25] mpt, well can, yes. That's non-standard for GNOME apps. [17:25] mpt, normally the text is in one column an the icons another. The text is shifted if there are any icons in the menu. [17:28] 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. [17:28] 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. [17:29] tedg, yes, the exceptions outnumber the rule-followers, but I don't think that matters [17:30] tedg, for example, the items without icons in don't change their indentation just because they're outnumbered by those with icons. [17:32] 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. [17:32] ok === emgent`NL is now known as emgent`nl === mcasadevall_ is now known as NCommander === hggdh_ is now known as hggdh [23:08] hey NCommander [23:09] hey seb128 [23:09] NCommander: did you read my comment about pangomm yesterday? === hggdh_ is now known as hggdh [23:09] seb128, nope [23:09] there is an example which is under the GPL [23:09] but the tarball has no GPL license [23:09] did you contact upstream about that? [23:10] seb128, no, I did note it in the copyright file though [23:11] lool didn't point it as an issue? [23:11] NCommander: it might be rejected in debian NEW due to that [23:11] I didn't sponsor to ubuntu yet [23:11] If lool did, it was too long along for me to remember [23:11] s/along/long/g [23:11] er [23:11] ... [23:11] *fails* [23:15] well it's really a detail [23:15] but technically if there is a source under the GPL the license text should be in the tarball [23:15] or it's not distributable [23:27] NCommander: I missed that example under GPL [23:27] NCommander: Which file is it? [23:28] seb128: Can I push pygobject with the fix? shall I check with slangasek? [23:28] seb128, not if the full text of the license is in the the example itself [23:28] lool: no, just upload, there is already a bug complain about ubuntu-desktop not being installable right now and that breaks builds [23:28] seb128: I have pygtk in the pipe as well [23:29] lool, I don't remember off hand, someone noted it to me, and I remember adding it to the copyright file [23:29] lool: I still have a bunch of GNOME 2.23.91 tarballs I'll upload tomorrow [23:29] NCommander: the license text is a several pages text and is not in the example ;-) [23:30] seb128: What happens when a FFE is granted exactly? [23:30] seb128: I filed a FFE, but I don't know what I'm actually supposed to watch for [23:30] (I subed ubuntu-release) [23:30] lool: you don't need a FFE [23:30] (on Friday) [23:31] seb128: it's for another package [23:31] ah for something else [23:31] lool & seb128 damn it :-/. I wish I caught that beforehand [23:31] you will get somebody from the corresponding team giving an ack and changing the status, then you can upload [23:31] depends if that's main or universe [23:31] seb128: The packages are elisa and its plugins [23:31] in main [23:32] Multiple people looked at it, which annoys me as well that we all missed it :-/ [23:32] just pitti slangasek or pitti on IRC to get your ack then ;-) [23:32] s/pitti/ping [23:34] NCommander: grep "GNU General" -rl * only yields tools/extra_defs_gen/generate_defs_pango.cc and it's covered in the copyright file [23:34] Yeah, I know, I caught that [23:34] seb128: Ok; I'll poke him again then [23:35] lool: right, but there is no GPL license in the tarball [23:35]