[00:03] <johanbr> apparently devicekit-power is supposed to provide the equivalent functionality now, see /lib/udev/rules.d/95-devkit-power-battery-recall-*
[00:03] <chrisccoulson> thanks johanbr
[00:03] <chrisccoulson> :)
[00:04]  * asac considers to not use his laptop on next flight 
[00:10] <chrisccoulson> asac - probably a wise decision ;)
[00:12] <chrisccoulson> g-s-d media-keys plugin seems to be a mess at the moment:(
[00:21] <fta> chrisccoulson, it's always for "Filesystem root", assume this is /
[00:22] <chrisccoulson> fta - yeah, that's right
[00:22] <chrisccoulson> that name comes straight from GLib. i wish it could pick a better name ;)
[00:28] <Riddell> gnome dudes: where are these icons from and what's their licence?  http://people.canonical.com/~jriddell/tmp/icons.png
[00:36] <chrisccoulson> hmmmm. if you do a g_hash_table_lookup on something, then remove the returned value from the table with g_hash_table_remove (and the GDestroyNotify function for that value is g_object_unref), things will go pretty wrong if you then try to access that object afterwards without first increasing the ref count won't they?
[07:29] <didrocks> morning everyone
[07:33] <kklimonda> Hey, I was wondering - are we ever going to make installing single packages from -backports less troublesome? I remember reading about new gui for package managment, was it even discussed?
[07:50] <crevette> ola ubuntuereos$
[07:51] <didrocks> morning crevette
[07:51] <crevette> hey didrocks
[08:43] <seb128> hello there
[08:45] <crevette> hi hi seb128
[08:45] <seb128> hey crevette mvo huats
[08:45] <mvo> hey seb128
[08:46] <chrisccoulson> hey seb128
[08:46] <seb128> hello chrisccoulson
[08:46] <huats> hello seb128 chrisccoulson crevette and mvo !
[08:46] <chrisccoulson> hello huats
[08:46] <crevette> hey hey huats, chrisccoulson and mvo
[08:46] <chrisccoulson> hello crevette and mvo also
[08:47] <chrisccoulson> anyone i've missed? ;)
[08:47] <mac_v> asac: hi... Bug #387626 , are you involved in nm?
[08:48] <didrocks> hey seb128, chrisccoulson, mvo
[08:48] <mvo> hey huats, crevette, didrocks and chrisccoulson :)
[08:48] <seb128> lol
[08:48] <crevette> :)
[08:49] <chrisccoulson> hey didrocks
[08:49] <didrocks> the chan was so quiet before seb128 arrived :)
[08:49] <huats> didrocks: we follow our leader :P
[08:49] <chrisccoulson> seb128 - i did some debugging with gsd last night. i've got a fix for the broken notification on mute now
[08:49] <seb128> didrocks, right, and now is time to collect homework
[08:49]  * mvo hugs seb'party-cannon'128
[08:49] <chrisccoulson> but i havent solved the crash yet
[08:50] <seb128> chrisccoulson, ok, good
[08:50] <seb128> didrocks,huats: what about you? ;-)
[08:50] <didrocks> seb128: hem... you already collected it and I'm fighting against launchpad translation tool :)
[08:51] <didrocks> the automatic export in bzr branch don't want to take my branch!
[08:51] <huats> seb128: I am about to work on deskbar-applet
[08:51] <seb128> didrocks, ah ;-) Collected what, clutter-1? ;-)
[08:51] <chrisccoulson> seb128 - i ran gsd in debug mode, and if you switch audio devices a few times, something goes horribly wrong (it starts spewing out loads of g_criticals) and it never recovers, but it doesn't always crash
[08:51] <seb128> huats, good!
[08:52] <seb128> chrisccoulson, you can maybe add a comment saying that on th GNOME bug
[08:53] <chrisccoulson> i will do. i wanted to try and get a trace of the first critical with G_DEBUG=fatal_criticals, but the problem is it prints an unrelated critical message at startup and causes it to abort long before it gets to the interesting bit
[08:53] <chrisccoulson> is there any way around that other than fixing the first error?
[08:54] <mvo> seb128: I just tried and it seems that for me gksu re-asks if I enter my password wrong
[08:54] <didrocks> seb128: no, yesterday's homework updates. You already sponsored them :-) Clutter will be more a week-end homework, I guess :)
[08:54] <seb128> mvo, in fact it doesn't there because it "*** glibc detected *** gksu: malloc(): memory corruption (fast): 0x08520467 ***"
[08:54] <didrocks> ok, and I'm taking empathy as an extra bonus :)
[08:54] <seb128> mvo, which might be the same issue that you fixed yesterday
[08:54] <seb128> didrocks, it's already done
[08:55] <mvo> seb128: ok
[08:55] <didrocks> oh? waiting for publishing?
[08:55] <seb128> didrocks, huats, robert_ancell: versions.html outdated by one day
[08:55] <seb128> the script is crashing on rookery for some reason
[08:55] <didrocks> hum, ok :/
[08:55] <seb128> and there is no gdb or valgrind there to debug
[08:55] <huats> ok seb128 thanks for letting us know
[08:56] <robert_ancell> hmm
[08:56] <seb128> I blame it on mvo, sources_record.Lookup() crashes
[08:56] <robert_ancell> seb128, can it be run manually?  It should dump a stacktrace
[08:56] <seb128> I can get the issue easily with a python line
[08:56] <seb128> robert_ancell, it doesn't
[08:57] <robert_ancell> seb128, can you update the script to pipe the output to a log file?
[08:57] <seb128> robert_ancell, well the issue is simple enough
[08:58] <seb128> (waiting to get the prompt on the box)
[08:58] <robert_ancell> ok
[08:59] <crevette> seb128, you want to keep the new libgnome settings for menu icons?
[08:59] <crevette> don't you fear user reactions ? :)
[08:59] <seb128> crevette, it's an upstream choices why not giving a try to what they decided?
[08:59] <seb128> crevette, no, I'm used to users complaining
[08:59] <crevette> :)
[08:59] <crevette> honnetly I used thi settings since 2 weeks, and I'm fine with it
[08:59] <seb128> robert_ancell, mvo:
[09:00] <seb128> $ python -c 'import apt, apt_pkg; apt_pkg.Config.Set("Dir::Etc::sourcelist","./index/debian/etc/apt/sources.list"); cache = apt.Cache(rootdir="./index/debian"); cache.update(); sources_record = apt_pkg.GetPkgSrcRecords(); sources_record.Restart(); print sources_record.Lookup("speex")'
[09:00] <seb128> /usr/lib/python2.4/site-packages/apt/__init__.py:17: FutureWarning: apt API not stable yet
[09:00] <seb128>   warnings.warn("apt API not stable yet", FutureWarning)
[09:00] <seb128> *** glibc detected *** double free or corruption (!prev): 0x0821ce78 ***
[09:00] <seb128> Aborted
[09:00] <seb128>  
[09:00] <seb128> that's the issue basically on rookery
[09:00] <seb128> code didn't change, Ng said rookery didn't change
[09:00] <seb128> and the same code works locally there
[09:00] <robert_ancell> could be the cache?
[09:00] <seb128> I tried deleting the dir
[09:01] <seb128> it does the same after rebuilding a new one
[09:01] <robert_ancell> something weird with speex?
[09:01] <seb128> no, same on any source
[09:01] <seb128> speex is just the first in the list
[09:01] <seb128> but I tried with a bunch of names same issue
[09:01] <robert_ancell> very odd
[09:02] <seb128> indeed
[09:02] <seb128> I might ask IS to install gdb or valgrind today
[09:27] <asac> mac_v: yes i am involved with NM :)
[09:28] <mac_v> asac: ah... could that be fixed? can nm notifications send the right signal strength?  BTW this only affects ubuntu , since we use notify-osd
[09:28] <seb128> asac, hi, did you do a wiki table or something about bluetooth devices?
[09:30] <asac> seb128: you mean a table where desktop team can say what devices they hav?
[09:30] <seb128> asac, what did we decide during the meeting?
[09:31] <seb128> asac, I though we would list devices we have so we know what else we need to test or I misunderstood?
[09:31] <asac> seb128: you are right.
[09:31] <seb128> asac, context I want to buy some device for testing not sure which one though
[09:31] <asac> wonder if that would be on wiki.ubuntu.com
[09:32] <seb128> ok, so the reply is that we don't have the table yet
[09:32] <seb128> I will just pick something, I've discount in a near shop to use before this evening
[09:33] <asac> seb128: i think there is so much bluetooth hardware that its unlikely that you will pick a dupe
[09:33] <seb128> right, thanks ;-)
[09:34] <mvo> seb128: python-apt> hm, myserious
[09:35] <seb128> mvo, they have a custom version supporting lzma or something
[09:35] <seb128> mvo, the box is still running dapper I think
[09:35] <mvo> woah
[09:35] <mvo> dapper :)
[09:35] <mvo> that brings back memories
[09:35] <seb128> ie weird mix but used to work until this week
[09:35] <seb128> and Ng says the install didn't change this week
[09:36] <seb128> so maybe the current debian index has something which makes this python-apt old version crash
[09:36] <asac> seb128: setup a "StaffBluetoothHardware" wiki.c.c patge
[09:36] <seb128> I'm wondering if I could do a local install of a newer version
[09:36] <seb128> asac, thanks!
[09:37] <asac> seb128: add your thing there .. i will ask folks to add their info
[09:37] <seb128> asac, will do ;-)
[09:39] <asac> mac_v: doesnt upstream also notify if connection was established?
[09:39] <mac_v> upstream doesn send the signal strength, just uses this icon > /usr/share/icons/gnome/scalable/status/nm-device-wireless , for everything
[09:39] <mac_v> asac: ^
[09:42]  * seb128 is away for some shopping be back later
[09:50] <cassidy> seb128: hi. Would be good to sync telepathy-sofiasip package from Sid. Should I open a bug about that or can you do it directly?
[09:51] <asac> mac_v: i dont get the problem.
[09:52] <asac> mac_v: whats the differenve that makes this not an upstream bug?
[09:52] <asac> mac_v: i mean: why are we supposed to send signal strength, but upstream isnt? just because we use something that has -full in its name?
[09:52] <mac_v> asac: upstream doesnt have notification icons for every signal strength
[09:53] <mac_v> asac: we have icons for all strengths why not use them , make the notification more useful?
[10:02] <asac> mac_v: so checkout wireless_get_icon src/applet-device-wifi.c
[10:02] <asac> mac_v: the notifications can try the same thing that is used there to decide which icon to use in tray
[10:02] <asac> thats in wireless_device_state_changed
[10:03] <mac_v> asac: could you comment this on the bug report , about how this can be done?
[10:03] <mac_v> pls
[10:03] <asac> mac_v: paste what i wrote
[10:03] <asac> i have no more to say about it ;)
[10:03] <mac_v> MacSlow: ^
[10:03] <asac> except that i dont thinkg its really useful
[10:04] <mac_v> asac: just that MacSlow  wanted to know from your side , so felt it was better if the concerned dev wrote it
[10:04] <asac> paste it to the bug. i dont see him commenting there though
[10:05] <MacSlow> mac_v, asac: haeh, what?
[10:05] <mac_v> the bug about the wireles icon in the bubble
[10:05] <mac_v> asac: we had discussed it on #ayatana ;p
[10:05] <asac> now i pasted it
[10:06] <asac> you could have done the same ;)
[10:06] <mac_v> :)
[10:06] <MacSlow> mac_v, asac: which icon to use for what notification (if it is a system-level thing, like the wireless strength) is something to discuss with the design-folks on #ayatana
[10:07] <mac_v> MacSlow: we discussed the other day with kwwii in #ayatana, remember
[10:07] <MacSlow> mac_v, asac: btw... the initial patch for NetworkManager/applet I did not write
[10:07] <MacSlow> mac_v, only vaguely if at all
[10:08]  * MacSlow is in bug-fixing mode atm
[10:08] <asac> i dont know about ayatana
[10:08] <asac> they should be in here
[10:08] <mac_v> asac: they have a separate room #ayatana ;p
[10:08] <MacSlow> asac, btw... trying to merge you mem-leak related patch and fix some of the other pending reasons for potential mem-leaks
[10:09] <asac> MacSlow: please just push it ;)
[10:09] <asac> MacSlow: there were no commits after it
[10:09] <asac> MacSlow: what what are you trying to fix?
[10:10] <MacSlow> asac, I know... but nothing is going into notify-osd without me looking thoroughly over it... not being strict about such things caused problems
[10:11] <asac> ok. but shouldnt take long ;)
[10:11] <MacSlow> asac, there are probably still some GObject-related issues in class Bubble causing g_object_unref(bubble) to not clean up as much as it should
[10:12] <MacSlow> asac, I want to add that to the commit/push with your patch as it fits the same topic/issue
[10:12] <asac> MacSlow: nah. please keep my commit separately
[10:12] <asac> MacSlow: dont try to be scarce about commits ;)
[10:13] <asac> MacSlow: wait another second i try to find another gigantic patch fixing many other memleaks
[10:13] <MacSlow> asac, I hope "gigantic" is a joke there
[10:14] <asac> no its the truth
[10:14] <asac> wait a nother second
[10:15] <asac> i made that in /tmp/ ... so the tree is gone. luckily i pastebinned it :)
[10:19] <asac> MacSlow: http://pastebin.com/f181a86ec ... thats on top of my patch
[10:19] <asac> MacSlow: there is a lot of fine cleanup code added.... but the big hit I hit in the end in stack.c
[10:20] <asac> MacSlow: so three main issues ádddressed there on top of what i already did:
[10:20] <asac> 1. lots of error conditions didnt cleanup everything
[10:21] <asac> 2. not all data surfaces not properly destroyed (i introduced destroy_cloned_surface )
[10:21] <asac> 3. bubbles get never popped
[10:21] <asac> -> never unreffed
[10:21] <asac> -> never freed
[10:21] <asac> -> big bustage
[10:21] <asac> i ran som bruteforce thing against notify-osd
[10:21] <asac> before it was 100M mem-leak in 2 minutes
[10:22] <asac> now its 200 k
[10:22] <MacSlow> looks like a win
[10:22] <MacSlow> asac, thanks for getting some overtime off my shoulders!
[10:22] <asac> MacSlow: yeah i am not sure why you never freed any bubble ... the code suggested that there were issues with crashes
[10:22] <asac> but i couldnt reproduce them ... and even if there were there is no reason not to free any bubble ;)
[10:23] <MacSlow> asac, there's some fundamental design issues in stack and the list-queue it maintains
[10:23] <asac> MacSlow: no problem. just get that reviewed and committed. if there are problems let me know.
[10:23] <MacSlow> asac, I can tell you a bit more about what led to this in Dublin... if you're interested
[10:23] <asac> MacSlow: what are those probles. i didnt see that directly. when things get removed they should get popped of the stack
[10:24] <MacSlow> asac, e.g. stach should not keep a list of bubbles... way too heavy objects... but instead abstract notifications objects... much lighter
[10:25] <MacSlow> asac, at any time only two bubble objects at maximum should be in memory
[10:26] <asac> MacSlow: thats true thats what i wondered about as well ;)
[10:26] <asac> but we should free them for now when they got processed
[10:26] <MacSlow> asac, that's when you get rushed and told "you can polish that later, move on"
[10:27] <asac> MacSlow: i know :)
[10:27] <mvo> I need a good name for the list on the left side of: https://wiki.ubuntu.com/AppCenter?action=AttachFile&do=get&target=1.0-available-home.jpg - do you have any suggestions? the one with "avaialble software", ...
[10:28] <mvo> "ActivityList", "SwitchBoard" - help :)
[10:29] <asac> MacSlow: i will commit that as a separate commit to the leak branch or make a separate branch on top of that ... let me know
[10:29] <chrisccoulson> pitti - now that gnome-session suspends the machine directly via dk-power, what tells gnome-screensaver to lock the screen now, so that it resumes in the locked state? (i think that g-p-m used to do that, but i can't test it because suspend doesn't work on my machine)
[10:29] <chrisccoulson> i only ask because i've seen some users saying their machines resume with the screen unlocked now
[10:30] <MacSlow> asac, well for the sake of clean-ness if you could make a second branch-proposal with your pastebin stuff on top of trunk (after I merged your first stuff)
[10:30] <MacSlow> asac, one moment
[10:30] <asac> MacSlow: ok thats better
[10:30] <asac> MacSlow: i can make two or three commits out of it
[10:30] <asac> e.g. error case fixes
[10:31] <Ng> mvo: a conceptual name, or a display name?
[10:31] <MacSlow> asac, even better thanks
[10:31] <mvo> Ng: a conceptual name
[10:31] <asac> copy_surface fixes, etc.
[10:31] <asac> MacSlow: let me know when you have merged the other in
[10:31] <mvo> Ng: not a UI name, I will nag the design guys for that
[10:31] <mvo> Ng: but something I can idenitfy it (and name the class after) - I feel so uncreative today :/
[10:31] <Ng> mvo: viewswitcher?
[10:32] <Ng> that seems to express what it does
[10:32] <mvo> Ng: yeah, thats nice
[10:32] <mvo> thanks!
[10:32] <Ng> mvo: when you talk to the UI folks about display names, can I suggest that "Available software" say "Get new software"? I think "Available" and "Installed" could be interpreted to mean the same thing ;)
[10:33]  * mvo was also considering class ViewView(gtk.TreeView)
[10:33] <Ng> hehe
[10:33] <mac_v> mvo: listswitcher ? ;p
[10:34] <mvo> Ng: thanks, that does make sense, I will mention it to mpt when he is back
[10:35] <Ng> :)
[10:37] <davmor2> seb128: I know this isn't priority but I found a work around for bug 384767 however once the bbc iplayer plugin is up and running there is a new error but I think that might be just audio teething issues on my test box but I'll create a new bug for it shortly.
[10:37]  * mvo is happy that his 10 minutes writer's block is over :)
[10:37] <Ng> hmm, is something a bit sideways in karmic gtk atm? context menu icons don't seem to be loading
[10:44] <MacSlow> asac, merged, tested and pushed
[10:44] <asac> MacSlow: great
[10:44] <MacSlow> asac, lp is still updating
[10:45] <pitti> Good morning
[10:45] <asac> hi pitti
[10:45] <pitti> *grumble* virus infection and fever :/
[10:45] <mvo> oh, poor pitti
[10:45] <asac> pitti: oh dear .... keep that away from me
[10:45] <asac> ;)
[10:45] <mvo> get well!
[10:45] <pitti> yeah, will try
[10:45] <asac> pitti: go back to bed so you  are getting well for dublin ;)
[10:45] <MacSlow> pitti, well... get well soon... and don't spread it in Dublin ;)
[10:45] <al-maisan> pitti: gute Besserung :)
[10:45] <pitti> the doctor said it usually lasts three days, so if I'm feeling good enough I can come to the sprint
[10:46] <pitti> but no hugs this time
[10:46] <pitti> thanks guys
[10:46]  * asac takes a mental note
[10:46] <pitti> no swine flu, though :)
[10:48] <pitti> lool: sure, for home users that might make sense; however, in order for that to make sense we also need to sort out the keyring password and such
[10:49] <crevette_> asac, I seen your reply on the gnome-bluetooth, the introspection build should be disabled I guess, it is true I read somewhere it was not building
[10:49] <crevette_> this is weird the build on ppa worked.
[10:50] <asac> crevette: it didnt buld here. either missing build-dep or something else not proper
[10:50] <crevette> asac, no, introspection is not working
[10:50] <crevette> s/working/building/
[10:50] <crevette> I can disable that, this is a know issue apparently
[10:55] <asac> crevette: yeah could be its automatically enabled if the package is on system (i didnt not use pbuilder etc.)
[10:55] <asac> crevette: so explicitly disabling might help
[10:56] <asac> crevette: why doesnt introdpection not work? any idea?
[10:57] <didrocks> pitti: take care :)
[11:07]  * pitti -> back to bed, cu next week
[11:09] <crevette> asac, it does't build upstream neither, this is not ubuntu specific.
[11:11] <asac> crevette: right. we should disable it explicitly then. whats the configure switch for that so i can check what i wanted to check in the first place?
[11:11] <seb128> cassidy, can do it
[11:12] <seb128> pitti, hey
[11:12] <seb128> pitti, should I start taking vitamines to not get your flu sunday? ;-)
[11:14] <crevette> asac, I can't see the flag in configure.ac, perhaps a ./configure --help may help
[11:14] <asac> i found enable introspection in acinclude.m4
[11:15] <asac> let me try --disable-introspection
[11:19] <asac> ok builds with that
[11:19] <asac> gnome-bluetooth conflicts with bluez-gnome
[11:19] <asac>   blueman provides bluez-gnome and is present and installed.
[11:19] <asac> dpkg: error processing gnome-bluetooth_2.27.8-0ubuntu1_i386.deb (--install):
[11:19] <asac>  conflicting packages - not installing gnome-bluetooth
[11:19] <asac> crevette: ^
[11:19] <crevette> that's why I don't like build in system, you pick unwanted dependencies :)
[11:19] <asac> i think we need to conflit/provudes it
[11:20] <asac> crevette: yes. but its a packaging bug if it does that ;)
[11:20] <crevette> hmm, I used to be there....
[11:20] <crevette> asac, my sentence was unrelated to the error you just pasted
[11:20] <asac> heh ok
[11:20] <asac> still its a packaging bug ;)
[11:21] <crevette> yep
[11:21] <asac> crevette: so i dont see the problem you describe
[11:21] <crevette> okay perhaps a ppa issue
[11:22] <asac> the build starts and works without CPU spikes ... also i dont get any error/warning
[11:22] <crevette> did you launched the properties or the wizard?
[11:22] <crevette> it happened there
[11:22] <asac> crevette: ok i will --disable-introspection and check if there is something with the conflicts/provides we can do and upload
[11:22] <asac> crevette: oh let me try that
[11:24] <asac> yeah that shows the same bug
[11:24] <MacSlow> asac, any estimates when you think you can work on that three-way split up of the pastebin patch for notify-osd?
[11:31] <asac> MacSlow: when do you need it?
[11:31] <MacSlow> asac, the earlier the better...
[11:31] <asac> heh
[11:31] <MacSlow> asac, today I only do bug-fixing, testing and merge work
[11:32] <asac> i will check after lunch
[11:36] <asac> hell. emacs diff-split-hunk is gone ... where was that in?
[11:36] <asac> i had that for ages
[11:37] <asac> emacs22-el ... maybe
[12:21] <asac> MacSlow: https://code.edge.launchpad.net/~asac/notify-osd/lp405364_more_memleaks/+merge/9502 -> "please push (not merge) to keep my detailed commit logs ;)."
[12:21] <asac> htx
[12:23] <MacSlow> asac, I only know how to merge using "merge"
[12:24] <MacSlow> asac, how does the other suggested process work?
[12:25] <asac> MacSlow: you can just pull it and if you did review push to the lp:notify-osd branch
[12:25] <asac> MacSlow: that only works if the branches have not diverged (e.g. no more commits on lp:notify-osd after i started the other  branch)
[12:25] <asac> but i think thats the case
[12:26] <asac> if you already committed something afterwards only merge will work ;)
[12:27] <MacSlow> asac, oh... thanks for rev. 358 I was expecting to do this maintainer-burden stuff myself
[12:27] <asac> MacSlow: let me know if there is something or if you have pushed it ... would like to upload a new notify-osd to karmic today based on latest upstream
[12:27] <MacSlow> asac, yeah... I'd like to do a tarball-release too today if possible
[12:27] <asac> MacSlow: hehe. i just found by accident that you actually did maintain such a file in bzr log ... so i added myself (other projects ask you to add yourself if you want to be in that list)
[12:27] <seb128> oh, asac tracking notify-osd now, one less thing to do for me there ;-)
[12:27] <asac> MacSlow: yeah then do some testing and let me know
[12:28] <asac> seb128: its an opportunistic thing because i did some work on it ... in future you can have it back ;)
[12:28] <seb128> asac, you touch it you keep it ;-)
[12:28] <asac> seb128: actually i think its a team thing anyway
[12:28] <seb128> it's sticky
[12:28] <asac> oh good
[12:28] <MacSlow> seb128, asac helped me a good bunch with some overdue bug-fixing (mem-leaks)
[12:28] <seb128> MacSlow, I noticed I'm subscribed to notify-osd component on launchpad
[12:28] <asac> seb128: i can do that ... everything is in bzr so its pretty great ;)
[12:29] <seb128> or rather the ubuntu notify-osd one
[12:29] <asac> and simple
[12:29] <seb128> asac, make sure to nag MacSlow to look at bugs too ;-)
[12:29] <asac> seb128: hmm. unlikely i can do that regularly ;)
[12:29] <seb128> alright, I will keep having a look then ;-)
[12:30] <seb128> was worth trying
[12:30] <seb128> ;-)
[12:30] <asac> i am still confident that adding QA resources to our team would be a great win
[12:30] <seb128> no doubt about that
[12:32] <MacSlow> asac, argl... rev 360 conflicts with fixes I did myself in another branch
[12:32] <MacSlow> *sigh*
[12:33] <MacSlow> asac, but it's not that bad as it's mostly the same kind of fix
[12:34] <asac> MacSlow: 360 is the big error handling ?
[12:34] <MacSlow> no
[12:34] <MacSlow> asac, just conflicts with some GObject disposal cleanups and fixes I did
[12:35] <asac> ah even more ;)
[12:35] <MacSlow> asac, god... I hate that inconsistent coding style... in stack.c (not your fault)
[12:36] <asac> MacSlow: yeah.
[12:38] <asac> MacSlow: are we working towards notify-osd 1.0?
[12:39]  * asac saw that there is a 0.9 branch
[12:39] <MacSlow> asac, no... it#s not feature complete
[12:39] <MacSlow> and there's still too much left to fix
[12:39] <MacSlow> to call it 1.0
[12:40] <MacSlow> only if all feature from the spec are implemented and it's cleaned of all major bugs it'll be considered 1.0
[12:40] <asac> ok
[12:40] <asac> MacSlow: so 1.0 not for karmic?
[12:40] <MacSlow> asac, and I don't see that happening soon
[12:40] <asac> hehe
[12:40] <asac> yeah
[12:40] <MacSlow> asac, impossible
[12:40] <MacSlow> asac, and I don't want to know what additiona work will be piled upon me in Dublin
[12:41] <MacSlow> asac, except for coding-style/formatting I'd say https://code.edge.launchpad.net/~asac/notify-osd/lp405364_more_memleaks looks good testing now
[12:42] <asac> MacSlow: what coding style things you dont like?
[12:42] <MacSlow> if (condition) {
[12:42] <MacSlow> ....
[12:42] <asac> given that its inconsitent we could do a coding style cleanup commit afterwards i would thiink
[12:42] <MacSlow> }
[12:42] <asac> MacSlow: oh yeah. thats where i had printf in i think
[12:42] <MacSlow> asac, well sure but
[12:43] <asac> anything else?
[12:43] <MacSlow> asac, I'm also missing the time to write a coding-style guideline for patch submission
[12:43] <MacSlow> asac, not that I can think of atm
[12:43] <asac> MacSlow: ok i can fix those if you want that
[12:43] <asac> its an odd coding style though ;)
[12:43] <MacSlow> asac, no... I'll do that afterwars
[12:44] <asac> ok thanks
[12:50] <MacSlow> asac, what did you do to monitor notify-osd's mem-usage to verify your patches?
[12:50] <asac> MacSlow: valgrind
[12:50] <asac> MacSlow: also i reduced timeout and ran a while sending notifications
[12:51] <asac> MacSlow: there are still a few leaks ... but i managed to get down from 200MB in a few minutes to like 200-300k
[12:51] <MacSlow> asac, how do you test with valgrind
[12:51] <MacSlow> asac, I mean in a "monitoring" fashion
[12:51] <seb128> run valgrind notify-osd, use a bit and ctrl-c
[12:52] <seb128> and see the summary
[12:52] <asac> MacSlow: build it with debugging symbols and -O0 .... then killall valgrind --leak-check=full; ./src/notify-odf
[12:52] <asac> then wait until you see in top that memcheck has settled
[12:52] <MacSlow> asac, seb128: ah... I thought it had a top-like mode too
[12:52] <asac> and start sending notification
[12:52] <asac> then after a few minutes, you cancel it and get a summary
[12:52] <asac> but those are a bit tricky to interpret
[12:52] <seb128> MacSlow, G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --leak-check=full valgrind notify-osd
[12:53] <seb128> MacSlow, G_SLICE=always-malloc G_DEBUG=gc-friendly  valgrind -v --tool=memcheck --leak-check=full notify-osd
[12:53] <seb128> rather
[12:53] <asac> right G_SLICE=always-malloc is also good
[12:53] <MacSlow> asac, I still have to learn the full ins and outs of valgrind
[12:53] <asac> MacSlow: yeah. so testing in a build tree, do like i said and set  G_SLICE=always-malloc G_DEBUG=gc-friendly
[12:53] <asac> that will give you beset results
[12:54] <asac> killall notify-osd; valgrind --leak-check=full ./src/notify-osd
[12:54] <asac> sorry there were typos further up ;)
[12:55] <asac> so: killall notify-osd; G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --leak-check=full ./src/notify-osd
[12:55] <asac> MacSlow: ^ ;)
[12:55] <asac> then hit ctrl-c after a while processing notification
[12:56] <asac> sometimes the output directly shows you where theproblem is ... but often it just tells you: you still have a leak ... and you still have to read code thoroughly; which is why i did all the error case cleaning
[13:03] <MacSlow> asac, so I can push your branch now to trunk via lp you said?
[13:03] <asac> MacSlow: yes. if it doesnt work bzr would complain
[13:03] <asac> so its safe
[13:04] <MacSlow> asac, how? I don't see any button on link for it... where is that "hidden"?
[13:05] <asac> MacSlow: oh . i dont know about lp interface. you can just do a bzr push lp:notify-osd if you have my branch locally
[13:05] <asac> MacSlow: it should also mark the merge request merge. at least it does if i push merges that way
[13:06] <asac> how do you merge without merging on your local disk?
[13:06] <asac> it doesnt do that if i approve merges at least
[13:07] <MacSlow> asac, if I do "bzr push lp:notify-osd" from your branch I've locally on my hd I get "No new revisions to push"
[13:08] <asac> MacSlow: heh. do you have a local checkout?
[13:08] <asac> or branch?
[13:08] <MacSlow> asac, I always work with branches
[13:08] <MacSlow> never used checkout
[13:08] <asac> MacSlow: if you have a local checkout and do bzr pull ... it automatically pushed it
[13:08] <MacSlow> because ehm...
[13:08] <MacSlow> I forgot
[13:08] <asac> did you bind?
[13:08] <MacSlow> someone from the dx-team suggested taht
[13:08] <asac> bzr info
[13:09] <asac> MacSlow: are you sure you are in my new branch? which revision is on top there?
[13:09] <MacSlow> asac, no it's unbound
[13:09] <asac> maybe you are accidentially in the already merged one?
[13:10] <asac> if i do it locally it works:
[13:10] <asac> notify-osd.memleak1$ bzr push ../notify-osd
[13:10] <asac> All changes applied successfully.
[13:11] <asac> Pushed up to revision 363.
[13:11] <crevette> asac, http://bugzilla.gnome.org/show_bug.cgi?id=589280
[13:11] <asac> thx
[13:12] <asac> DBusGlib-1.0.gir missing?
[13:12] <asac> seb128: how do we get the xlib-1.0.gir into the repository?
[13:12] <asac> which package is supposd to do that?
[13:13] <MacSlow> asac, I don't want to waste more time on relearning some process with bzr which I already know and which works
[13:13] <MacSlow> asac, I'll do it the way I'm used to
[13:13] <crevette> asac, don't need to bother with introspection now
[13:13] <MacSlow> asac, besides... doing so nothing of your comments or commits is lost
[13:13] <MacSlow> asac, I can see everything just find in olive-gtk or bzr log
[13:14] <asac> MacSlow: its ok ... but its really just bzr branch mybranch; cd mybranch; bzr push lp:notify-osd
[13:14] <asac> if that doesnt work its a bug
[13:14] <asac> go ahead as you suggested
[13:15] <seb128> asac, xlib-1.0.gir? since when has xlib introspection?
[13:15] <asac> seb128: not sure. gnome-bluetooth wants that
[13:15] <seb128> where?
[13:15] <asac> one sec
[13:15] <crevette> asac, as I said this is not a showstopper now
[13:15] <asac> https://bugs.edge.launchpad.net/ubuntu/+source/gnome-bluetooth/+bug/406592/comments/5
[13:15] <crevette> I wouldn't loose 2 minuts on that :)
[13:15] <asac> seb128: ^
[13:16] <seb128> hum
[13:16] <asac> crevette: well. introspection is nice ;) ... not a showstopper yes.
[13:16] <crevette> I don't even know what is it :)
[13:16] <seb128> asac, gobject-introspection-freedesktop
[13:16]  * crevette is ashamed :/
[13:16] <seb128> asac, it's xlib-2.0.gir not xlib-1.0.gir ;-)
[13:17] <asac> crevette: its something that makes it more or less trivial to code against dbus interfaces like in python
[13:17] <asac> at least thats the most use.
[13:17] <asac> i guess its probably something general for python gobject bindings
[13:17] <asac> seb128: nice
[13:18] <asac> seb128: but it seems that that isnt even referred to in the source code :)
[13:18] <asac> maybe what ever ships 2.0.gir did add it wrongly to the repo
[13:18] <asac> or something including 1.9.dir
[13:18] <asac> gir
[13:18] <seb128> asac, well gobject-introspection is a pack will all the .gir
[13:19] <seb128> asac, the goal is to have those built by each source though
[13:19] <asac> seb128: i dont have anything related to Xlib in /usr/lib/girepository-1.0/
[13:19] <seb128> ie ideally the xlib .gir would be built by xlib
[13:19] <asac> seb128: so its a standalone source package?
[13:19] <seb128> asac, it's in /usr/share/gir-1.0/xlib-2.0.gir
[13:20] <seb128> asac,  /usr/lib/girepository-1.0/ was the old location
[13:20] <seb128> ups
[13:20] <seb128> no, not the old one, the typelib one
[13:20] <asac> seb128: maybe you have something on your system that i dont have yet? e.g. gnome-öshell?
[13:21] <seb128> asac, /usr/lib/girepository-1.0/ has the .typelib for runtime
[13:21] <asac> at least xlib is not there for me
[13:21] <asac> seb128: which package ships that for you?
[13:21] <seb128> asac, sudo apt-get install gobject-introspection-freedesktop?
[13:22] <asac> seb128: why wasnt that installed? there were other gir things installed there
[13:22] <seb128> asac, gir is splitted in gir and gir-fdo
[13:22] <seb128> ie the gnome and freedesktop stacks are different binaries
[13:22] <asac> ah ok
[13:23] <seb128> you probably had the gnome only, which is required for gnome-shell
[13:24] <asac> yeah so now i end up in DBusGLib-1.0.gir
[13:24] <asac> missing
[13:24] <asac> like in the gnome bug
[13:25] <seb128> asac, it's name Dbus-1.0.gir
[13:25] <seb128> named
[13:25] <seb128> oh, or they are different things
[13:25] <asac> seb128: i think DbusGlib is the dbus glib thing
[13:26] <asac> seb128: the dbus lib in C is not using gobject ... so i guess its really Dbus-1.0.gir
[13:26] <asac> but thats a wrong name imo
[13:26] <asac> though its shipped by same source afaik
[13:27] <asac> seb128: so i guess we need to add that manually to -freedesktop
[13:27] <seb128> asac, let me look
[13:28] <seb128> asac, it's possible that somebody forgot to update a .install
[13:28] <seb128> asac, I'm test building right now
[13:29] <asac> i dont see a DBus thing in the introspection sources ... nor in dbus. but could be that gir's are produced during build
[13:32] <seb128> $ ls gir | grep DBus
[13:32] <seb128> DBus-1.0.gir
[13:32] <seb128> DBusGLib-1.0.gir
[13:33] <seb128> "MISSIONCONTROL_GIRSOURCES = DBusGLib-1.0.gir \
[13:33] <seb128>                             TelepathyGLib.gir \
[13:33] <seb128>                             LibTelepathy.gir
[13:33] <seb128> "
[13:33] <seb128> I guess it lacks a build depends on mission-control
[13:33] <seb128> dnl mission-control (disabled for now, it has odd structs and isn't useful yet)
[13:34] <seb128> in configure.ac
[13:34] <seb128> asac, ^ upstream doesn't build it right now
[13:34] <seb128> "dnl PKG_CHECK_MODULES(MISSIONCONTROL, libmissioncontrol,
[13:34] <seb128> dnl                  have_missioncontrol=true, have_missioncontrol=false)
[13:34] <seb128> have_missioncontrol=false"
[13:35] <seb128> not sure why they need missioncontrol to build dbusglib though
[13:35] <seb128> let's ask walters when he's around
[13:41] <asac> k
[13:48] <asac> seb128: what is mission control?
[13:49] <asac> e.g. why is a base thing like dbusglib in there?
[13:49] <seb128> asac, the sort of server in the telepathy stack
[13:49] <seb128> asac, " not sure why they need missioncontrol to build dbusglib though"
[13:49] <seb128> asac, dunno, that's what I want to ask when walters is around
[13:50] <asac> yeah sorry. this whole telepathy thing is pretty far from what i know about
[13:50] <asac> i think they came up with this whole introspection thing?
[13:51] <seb128> no, the introspection and telepathy guys are the same ones
[13:52] <seb128> introspection is mainly done by the litl and js binding guys I think
[13:52] <asac> interesting. do we have those js bindings already?
[13:53] <seb128> asac, yes, apt-cache show gjs
[13:53] <seb128> asac, that's what gnome-shell is using
[13:53] <asac> oh ;) ... that was what i just got removed when trying ot install the old gobject-introspection package
[13:55] <asac> oh gjs istn installable atm
[13:55] <asac>  gjs: Depends: libgirepository1 (>= 0.5.0)
[13:56] <asac> maybe needs a respin because of lib transition or something?
[13:57] <asac> ok seems like it
[13:57] <asac> will upload
[13:57] <asac> we had a transition in libgirreposiory to 1.0-0
[13:59] <seb128> re
[13:59] <seb128> asac, yes that's due to the gir recent changes
[13:59] <seb128> I will fix that now
[13:59] <asac> seb128: i changed build depends and wanted to upload
[13:59] <asac> hmm
[13:59] <seb128> ie didrocks resynced on debian
[13:59] <asac> ok
[13:59] <seb128> and the naming slightly changed
[13:59] <seb128> asac, go for it
[13:59] <asac> i have the bits ready if you dont mind
[13:59] <asac> thx
[13:59] <seb128> thank you
[14:08] <asac> urgh. forgot depends of -dev package. also fixed ;)
[14:21] <didrocks> asac, seb128: yes, that's why mutter as weel should be worked on this week-end. But as I wasn't in the repo yet, I didn't take the time to do it before renaming :)
[14:21] <seb128> didrocks, gjs is in universe
[14:22] <didrocks> hum, really? Strange that I didn't rdepends first :/
[14:22] <didrocks> sorry in this case
[14:24] <seb128> didrocks, that's ok don't worry gjs is of no real use until we get gnome-sheel
[14:24] <seb128> shell
[14:40] <seb128> mvo, not sure how much you read bug emails; bug #407240 is easy to close
[14:40] <mvo> seb128: right, thanks
[14:41] <seb128> mvo, could be easier for you to make debian rules update it automatically
[14:41] <seb128> mvo, you're welcome
[14:45] <dobey> seb128: is there any way to have the ubuntuone team automatically be able to view all the private bugs against our packages?
[14:45] <seb128> dobey, not that I know the way usually is to be in the bugsquad
[14:46] <seb128> talk to pedro about it, you can probably be added there
[14:46] <chrisccoulson> seb128 - i think i've solved that gnome-settings-daemon crash now :)
[14:47] <seb128> chrisccoulson, you rock as usual ;-)
[14:47] <chrisccoulson> certainly, there's no more memory errors in valgrind
[14:47] <chrisccoulson> i couldn't reproduce the crash that reliably so i could do with finding someone else who could reproduce it so they can test it;)
[14:48] <seb128> well fixing valgrind errors is a good start
[14:48] <seb128> I guess awe will be able to test when he's back online
[14:50] <dobey> seb128: but then i get all the ubuntu bugs in my mail if i do that, right?
[14:50] <seb128> dobey, no, the team has a mailing list members don't get emailed
[14:50] <seb128> it just access control by team membership basically
[14:50] <dobey> seb128: oh ok
[14:51] <pedro_> dobey, thought you were able to see those reports, let me have a look
[14:51] <dobey> pedro_: i don't get to see the private ones automatically, no
[14:52] <pedro_> dobey, added you to the team, could you check now?
[14:53] <seb128> dobey, pedro_: btw I've added an apport hook which should reassign crashers in libnautilus-ubuntuone directly to ubuntuone-client
[14:53] <seb128> and make the ubuntuone-client hook to be run
[14:53] <dobey> pedro_: i see more bugs now
[14:53] <pedro_> nice!
[14:53] <pedro_> dobey, then it's working :-)
[14:54] <dobey> seb128: nice
[14:54] <seb128> dobey, you don't get email notification for private bugs btw so you need to watch this list on launchpad
[14:54] <dobey> seb128: yeah
[14:54] <asac> didrocks: no problem. you say we will get mutter in archive soon?
[14:55] <seb128> asac, we should, I put didrocks on that task because it blocks gnome-shell ;-)
[14:55] <seb128> asac, it's in the ubuntu-desktop ppa for now
[14:55] <dobey> seb128: i wish i could not get mail for other things too :)
[14:56] <asac> will we do that in debian? i should open ITPs for network-manager-netbook and carrick (both need mutter) then
[14:56] <didrocks> asac, seb128 : I'll work on this this week-end
[14:57] <seb128> asac, you are welcome to do debian sponsoring if you want, I don't intend to work on it there
[14:57] <seb128> debian not accepting source uploads sucks and I don't have the bandwith to keep a debian unstable uptodate for builds
[14:57] <didrocks> asac: I can open an ITP later for mutter if you wish
[14:57] <didrocks> whish*
[14:59] <didrocks> wish* :)
[15:00] <asac> didrocks: your decision ;) ... if you want to maintain that on longer run, than that makes sense
[15:01] <asac> otherwise we should open a RFP and attach our work
[15:01] <asac> it always is a bit hard to see how work we do gets trashed because someone in debian does his own package from scratch
[15:03] <seb128> you could think that by now debian people know they can use ubuntu work and look there first when packaging something new ;-)
[15:04] <didrocks> asac: I volonteer to maintain it :)
[15:04] <didrocks> asac: I will ping you on Monday about that
[15:04] <asac> seb128: you would think. but thats not the case
[15:05] <asac> at least not always
[15:13] <seb128> mvo, what is the canonical source for SimpleGtkbuilderApp?
[15:13] <chrisccoulson> seb128 - i'm failry certain that the patch i've written will fix that gsd crash now. i'm just sending it upstream - do you want it in ubuntu before the next tarball release? you might want it if you're all testing bluetooth hardware next week;)
[15:13] <seb128> chrisccoulson, would be nice yes
[15:14] <chrisccoulson> thanks - i'll push that to bzr shortly
[16:03] <chrisccoulson> seb128 - i've pushed the gsd changes to bzr now
[16:03] <seb128> chrisccoulson, thanks
[16:04] <chrisccoulson> it also fixes the notification issue, and i've fixed another issue i just noticed where it sends notify-osd duplicate notifications
[16:05] <seb128> walters, hey
[16:06] <walters> hi seb128
[16:06] <seb128> walters, do you know why the DbusGlib gir depends on mission-control and is not built?
[16:06] <seb128> or DBusGLib rather
[16:07] <seb128> walters, gnome-bluetooth gir build-depends on it apparently
[16:07] <walters> the dependency is the other way around; and basically because i ran into problems scanning something in that stack, i forget
[16:07] <seb128> hum
[16:07] <walters> gnome-bluetooth depends on the dbus-glib gir?
[16:08] <seb128> ok, I need to look again at why we don't have a DBusGLib gir then
[16:08] <asac> http://bugzilla.gnome.org/show_bug.cgi?id=589280
[16:08] <seb128> walters, ^
[16:09] <seb128> bah bugzilla sucks, it's not responding again
[16:09] <asac> i hope its the right one. i couldnt open it either ;)
[16:11] <walters> hm, yeah not loading here either
[16:11] <walters> i should try to move the dbus-glib gir into dbus-glib itself
[16:12] <seb128> chrisccoulson, 61_fix_volume_notification.patch .. did you send that one upstream?
[16:12] <chrisccoulson> seb128 - i'm going to open it on bugzilla and do that now
[16:12] <seb128> chrisccoulson, ok thanks
[16:13] <chrisccoulson> you're welcome
[16:13] <SiDi> asac: MacSlow: hi guys. In notify-osd's source, defaults.c:defaults_init (l625+) isnt there a memory leak in case there is an error ?
[16:13] <SiDi> Gerror* error would then be set but never fred
[16:14] <asac> did MacSlow commit my stuff yet? /me checks
[16:14] <seb128> gra, I suck, I looked to wrong gobject-introspection source directory
[16:14] <SiDi> asac: i may not have the latest code. i've got some changes on my side so i dont wanna merge :]
[16:14] <MacSlow> asac, SiDi: asac's patches are in trunk now
[16:15] <asac> ok its committeed
[16:15] <asac> thx MacSlow
[16:15] <MacSlow> asac, SiDi: atm I'm doing further potential mem-leak fixes
[16:15] <SiDi> MacSlow: okey.
[16:16] <SiDi> defaults.c hasnt been touched so its probably still there. I suppose the error should be fred but i never used gconf so i dont know if it explicitely wants you to free it or if it uses static memory for it
[16:17] <asac> yes. error needs to be freed afaik
[16:17] <SiDi> okies, thanks
[16:18] <asac> its not returned or something, so yeah
[16:18] <seb128> asac, walters: bugzilla is back
[16:19] <asac> same for src/dialog.c pango_parse_markup error
[16:19] <asac> and bubble.c load_icon
[16:19] <seb128> walters, are you sure that's the other way around for mission-control? it seems that DBusGLib is not installed due to mission control not being built
[16:20] <walters> hm, that's possible
[16:20] <asac> and dnd.c: dnd_is_screensaver_active and dnd_is_screensaver_inhibited
[16:20] <seb128> walters,
[16:20] <asac> dbus.c has the proper error_free ... good
[16:20] <seb128> "MISSIONCONTROL_GIRSOURCES = DBusGLib-1.0.gir \
[16:20] <asac> thats it
[16:20] <seb128>                             TelepathyGLib.gir \
[16:20] <seb128>                             LibTelepathy.gir"
[16:21] <asac> MacSlow: ^^
[16:21] <asac> take those too
[16:21] <asac> (last few lines i wrote)
[16:21] <seb128> walters, that's gir/Makefile.am
[16:22] <seb128> chrisccoulson, I've fixed the patch tags to be the same than on https://wiki.ubuntu.com/UbuntuDevelopment/PatchTaggingGuidelines and sponsor the upload now
[16:23] <seb128> chrisccoulson, ie Ubuntu, Upstream, Description
[16:23] <chrisccoulson> seb128 - thanks
[16:23]  * rickspencer31 is getting on a plane in 20 minutes
[16:23] <seb128> hey rickspencer31
[16:23] <rickspencer31> HIYA
[16:24] <rickspencer31> oops, caps lock :/
[16:24] <seb128> rickspencer31, have a good atlantic crossing
[16:24] <rickspencer31> seb128: thanks
[16:25] <rickspencer31> I'll be in SF airport for bit this afternoon
[16:33] <mvo> seb128: there is no canonical source currently, but we should just create a project :)
[16:33] <seb128> mvo, ok
[16:34] <seb128> mvo, I'm wondering if that makes sense to display a warning for get_name on non buildable objects
[16:34] <seb128> ie gdebi
[16:34] <seb128> WARNING: can not get name for '<gtk.TextBuffer object at 0x98d9b44 (GtkTextBuffer at 0x9c41a00)>'
[16:34] <mvo> seb128: I have not yet made up my mind on this, I added it for now
[16:34] <seb128> I'm not sure why you consider it as being an issue worth a warning
[16:34] <mvo> seb128: but I don't quite undetstand how gtkbuilder does deal with those
[16:35] <mvo> i mean, it needs to have a way to contruct them too
[16:35] <seb128> yeah, I don't know either
[16:35] <mvo> I just added it to see what is affected, just silence it :)
[16:35] <mvo> it should probably be something like logging.debug()
[16:36] <seb128> right, no big deal I was just having a look to some gdebi bugs
[16:36] <seb128> and I noticed that warning
[16:36] <mvo> do you want me to import it into a branch?
[16:36] <mvo> aha, ok
[16:36] <mvo> seb128: anything interessting? gdebi should be ok-ish as far as triage goes
[16:36] <seb128> but apparently I suck at making valgrind run on python code
[16:36] <seb128> mvo, deprecation warning
[16:36]  * mvo nods
[16:36] <seb128> ie .installedVersion -> installed.version
[16:37] <mvo> yeah, a lot
[16:37] <seb128> but some less trivial too ;-)
[16:37] <walters> seb128: pymalloc does crazy stuff; there's a patch to have python detect valgrind and be less crazy in their issue tracker i think
[16:37] <seb128> walters, ah, thanks for the hint
[16:38] <seb128> mvo, in fact I was looking at a crash which has quite some duplicates but otherwise gdebi seems in good state
[16:38] <seb128> the " 	 gdebi-gtk crashed with SIGSEGV in gtk_button_set_label()" one
[16:38] <walters> seb128: i'm poking at doing the dbus-glib gir in dbus-glib itself, but if it's blocking you i'd just build gnome-bluetooth without introspection for now since I don't think anything uses it
[16:38] <mvo> seb128: oh, this one - I have no idea what might cause it :/
[16:38] <seb128> mvo, but I failed to make valgrind work as said and got sidetracked by warnings ;-)
[16:39] <mvo> seb128: have you seen the new "look-inside-the-deb" feature?
[16:39] <mvo> I quite like it
[16:39] <seb128> walters, right, that's what asac was about to do I think, we just tried to understand if the issue was a packaging one for dbusglib gir
[16:39] <seb128> mvo, yes, nice work ;-)
[16:42] <seb128> asac, can I tell firefox to display patches inline?
[16:49] <asac> seb128: i usually change the mime type of the attachment ;)
[16:49] <seb128> asac, bah ;-)
[16:49] <seb128> not to mention that firefox 3.5 display no choice by default to open a patch
[16:49] <seb128> and that the "select an application" dialog sucks
[16:50] <asac> seb128: what do you want in the dialog?
[16:50] <seb128> the same thing as in nautilus? ;-)
[16:50] <asac> seb128: you mean if you select "other ..." ?
[16:51] <seb128> yes
[16:51] <asac> we are waiting for nautilus or gtk shipping that feature in a lib
[16:51] <asac> to adapt firefox
[16:51] <asac> we would be happy to do that
[16:51] <seb128> the default is "open with <nothing>"
[16:51] <seb128> good point
[16:51] <asac> seb128: does it at least suggest gedit?
[16:51] <asac> in preferences -> applications
[16:52] <seb128> well now I picked /usr/bin/gedit in the fileselector so yes
[16:53] <seb128> but by default there was nothing
[16:53] <seb128> and it return an error about <null>
[16:53] <seb128> when clicking on the open button
[16:53] <asac> seb128: what mime type is it on launchpad?
[16:53] <asac> text/x-patch?
[16:54] <asac> also does gnomevfs-info URL suggest something sane?
[16:54] <seb128> asac, "text/x-diff"
[16:54] <seb128> $ gnomevfs-info http://launchpadlibrarian.net/29751919/gwbber.diff
[16:55] <seb128> MIME type         : text/x-diff
[16:55] <seb128> Default app       : gedit.desktop
[16:55] <asac> sounds like a bug then
[16:55] <asac> let me check if i can reproduce
[16:56] <seb128> asac, though that's not the one I had the issue on early when I had to pick gedit though
[16:56] <asac> hmm suggests gedit for me here
[16:56] <asac> http://launchpadlibrarian.net/29751919/gwibber.diff
[16:56] <asac> seb128: yeah. maybe the one with the problem has a different mime type?
[16:56] <asac> seb128: which one was it
[16:57] <seb128> asac, I didn't note it that was yesterday, any way to reset the associations I did?
[16:58] <asac> seb128: yes: find $HOME/.mozilla/firefox-3.5/ | grep mime
[16:59] <asac> mimeTypes.rdf ... and remove those
[16:59] <asac> stop ffox before
[16:59] <asac> at least i think thats the case ;)
[16:59] <asac> seb128: you can also go to preferences -> applications
[16:59] <asac> and set it to always ask again
[16:59] <asac> but not sure if that forgets the gedit association completely
[17:00] <seb128> asac, ok, so I deleted the types rdf thing and restarted firefox
[17:00] <seb128> asac, firefox-3.5 http://launchpadlibrarian.net/29751919/gwibber.diff
[17:00] <seb128> it has "open with <browse>"
[17:01] <seb128> if I click ok it says
[17:01] <seb128> "The application you chose ("(null)") could not be found.  Check the file name or choose another application."
[17:01] <seb128> ie no default choice there
[17:03] <asac> seb128: do you have firefox-3.5-gnome-support installed?
[17:03] <asac> or rather xulrunner-1.9.1-gnome-support ?
[17:04] <seb128> asac, no
[17:04] <seb128> should that be a recommends? ;-)
[17:06] <asac> seb128: yes. but but but ...
[17:07] <asac> i gave in to requests from kubuntu folks
[17:07] <asac> imo thats a general problem. we cannot recommend anything from gnome if the software is also used on kubuntu :(
[17:08] <asac> needs some innovation
[17:08] <asac> i guess something for mvo ^^
[17:10] <seb128> asac, the software is not used on kubuntu though, at least by default
[17:10] <seb128> asac, the users who install it can uninstall the recommends if they don't want it
[17:11] <seb128> or they could have a xulrunner-kde in alternative recommends
[17:11] <seb128> but yeah, having some flavor hint for install would be nice
[17:12] <asac> right but their argument is: because its used by default in ubuntu a recommends is not needed because -gnome-support gets pulled by ubuntu-desktop
[17:12] <seb128> well proof it doesn't work
[17:12] <seb128> especially on a non default firefox version ;-)
[17:12] <asac> ack
[17:13] <asac> anyway i have a hacky solution ;)
[17:13] <seb128> I think we should not break the recommends meaning to please some users
[17:13] <asac> just need to implement it and convince myself to maintain that. it involves shipping all plugins in the xulrunner main package and stripping the gnome related depends manually out of control or something
[17:13] <seb128> they can switch off recommends if they don't want those
[17:13] <asac> it works because the plugins are just not loaded if not all libs are fulfillede
[17:14] <asac> seb128: right. i would have never given in, if it wasnt that most kubuntu users use firefox ;)
[17:14] <asac> and install it afterwards
[17:14] <seb128> asac, I don't like the runtime thing
[17:14] <asac> seb128: thats how firefox upstream is shipped
[17:14] <seb128> I much prefer a -gnome which has the right depends
[17:15] <asac> they ship the gnome components
[17:15] <asac> if kubuntu folks run it, they just are auto disabled
[17:15] <asac> seb128: yes the -gnome would still exist
[17:15] <asac> just an empty package with just the dependencies
[17:16] <asac> but the libs we need are installed on all machines anyway, so it wouldnt be a problem if someone doesnt install -gnome anymore
[17:17] <seb128> asac, the issue with your way is that an apt-get install firefox-3.
[17:18] <seb128> on a stock install wouldn't install gnomevfs, etc
[17:18] <seb128> so opening patches wouldn't work out of the box
[17:18] <seb128> stock install being a minimal install, not an ubuntu-desktop one
[17:19] <seb128> if firefox needs xulrunner-1.9.1-gnome-support for a full user experience it should recommends it
[17:19] <seb128> or recommends gnomevfs, etc
[17:20] <asac> yeah. the gnomevfs part changed since gvfs is not default
[17:22] <asac> ok off ... for weekend. see you in dublin seb128
[17:22] <seb128> same here
[17:22] <seb128> asac, enjoy, see you on sunday
[17:23] <asac> i am landing at 2300 ... so maybe monday
[17:26] <seb128> asac, yeah probably then
[17:45] <maxb> mvo: Are you around? I've noticed that when you did the last notification-daemon upload you didn't commit it to the bzr branch - just an accident?
[17:54] <pitti> seb128: vitamines> heh, you might; but as I said, no cuddling this time (viruses don't really spread airborne)
[18:00] <chrisccoulson> you're not very well pitti? virtual hugs only then ;)
[18:01]  * chrisccoulson hugs pitti
[18:01] <mvo> maxb: let me check
[18:02] <didrocks> chrisccoulson: not hug, you are mad :)
[18:02] <didrocks> pitti: do you feel a little better, less tired now?
[18:03] <chrisccoulson> hey didrocks
[18:03] <chrisccoulson> how are you?
[18:03] <didrocks> fine, and you? :)
[18:04] <chrisccoulson> yeah, not too bad. i always like fridays because i finish work at lunchtime :)
[18:04] <didrocks> how lucky you are :)
[18:05] <chrisccoulson> i don't feel so luck from mondays to thursdays though ;)
[18:05] <chrisccoulson> i'm always glad to get to the weekend!
[18:05] <didrocks> ahah!
[18:05] <didrocks> chrisccoulson: do you have some holidays soon?
[18:05] <mvo> maxb: should be up-to-date again now
[18:06] <chrisccoulson> didrocks - i've got the week after next away from work, but i'm not actually going on vacation anywhere
[18:06] <didrocks> chrisccoulson: hum, you will be the channel keeper in august, I guess
[18:07] <maxb> mvo: Excellent! Can I trouble you to upgrade the branch to a nondeprecated format whilst you're there?
[18:07] <chrisccoulson> is everyone disappearing in august?
[18:08] <didrocks> chrisccoulson: it seems that from former discussion.
[18:08] <mvo> maxb: sure, doing that now
[18:08] <didrocks> Well, I have an ITP to fill in :)
[18:08] <chrisccoulson> dicrocks - so i'll have nobody to talk to? i might have to actually do some work :-/
[18:08] <chrisccoulson> lol
[18:09] <maxb> mvo: Also, the reason I was looking at it is because I'm afraid you dropped a bit that shouldn't have been dropped in that last merge - one of the patches patches autoconf/automake files, but you dropped the rerunning of autoconf/automake
[18:09] <didrocks> chrisccoulson: hehe :)
[18:09] <didrocks> chrisccoulson: or work more on Ubuntu :p
[18:09] <chrisccoulson> didrocks - yeah, i'll probably do that instead
[18:26] <chrisccoulson> anyone know if epiphany can display feeds from here: https://help.launchpad.net/Feeds ?
[19:14] <dobey> hrmm
[19:14] <dobey> i wonder if there's a bug about media player icons in karmic
[19:22] <chrisccoulson> dobey - what's the issue?
[19:23] <dobey> chrisccoulson: in karmic, my ipods are all getting the drive-removable icon on the desktop now
[19:23] <dobey> instead of the multimedia-player icon
[19:23] <chrisccoulson> hmmm, what's the output of gvfs-mount -li ?
[19:24] <chrisccoulson> is your ipod just mounting as removeable storage or as a MTP device?
[19:24] <chrisccoulson> if it's removeable storage, then that icon name comes from dk-disks i think
[19:24]  * dobey plugs in his shuffle
[19:25] <dobey>     themed icons:  [drive-removable-media-usb]  [drive-removable-media]  [drive-removable]  [drive]
[19:25] <chrisccoulson> what type of mount is it?
[19:26] <dobey> what specific piece of information am i looking for to determine that? there's a lot of info here
[19:28] <chrisccoulson> there should be a Type: field. But it will probably say "GProxyMount (GProxyVolumeMonitorGdu)"
[19:28] <chrisccoulson> it probably wouldn't say anything else actually
[19:32] <dobey> that's what it says, yes
[19:32] <dobey> which i guess isn't helpful
[19:37] <maxb> Is this the best channel to find people who know about OOo ?
[19:49] <dobey> chrisccoulson: capabilities in gnome-device-manager shows "portable_audio_player"
[19:49] <dobey> chrisccoulson: so i suspect a regression in the switch to DK
[19:49] <chrisccoulson> dobey - most likely, yes
[19:51] <mvo> maxb: hm, shouldn't this be handled via the DEB_AUTO_UPDATE_AUTOMAKE and friends in the debian/rules file?
[19:51] <maxb> mvo: Yes, but they got dropped in -1ubuntu1
[19:52] <mvo> maxb: oh, ok. seems like I overlooked that :/
[19:53] <maxb> There's the further complication that -1 introduced a patch touching ltmain.sh, which is in conflict with our use of DEB_AUTO_UPDATE_LIBTOOL
[19:53] <maxb> but if you don't update libtool, you must not run aclocal
[19:53] <maxb> I've been having 'fun' trying to convince cdbs to do automake and autoconf but not libtool or aclocal
[19:54] <fta> chrisccoulson, "has only 3.5 MB disk space", lol, I still have more than 4 GB left in /
[20:01] <chrisccoulson> fta - that's strange. i might write a little C program in a bit which copies what gsd does but prints some info about your disks, so you can run it and i'll hopefully understand a little why it isn't working
[20:02] <chrisccoulson> or i could do a build of gsd with some debug lines in it, but it might be easier to just write a little C program
[20:02] <chrisccoulson> i cant recreate the issue here :-/
[20:02] <chrisccoulson> is there anything perculiar or non-standard about your disk setup?
[20:16] <fta> ext2
[20:16] <fta> nothing fancy
[20:23] <Fluffles> In karmic, will gnome-sound-properties and the old gnome-volume control be brought back like they were in jaunty? Or will karmic keep the new gnome-volume-control?
[20:26] <chrisccoulson> Fluffles - karmic is keeping the new gnome-volume-control
[20:29] <chrisccoulson> ah
[20:29] <chrisccoulson> fta - so, you have 4GB left, but the disk space warning shows only 3.5MB right?
[20:29] <chrisccoulson> how big is the volume?
[20:30] <fta> Filesystem            Size  Used Avail Use% Mounted on
[20:30] <fta> /dev/sda1             288G  284G  4.1G  99% /
[20:30] <chrisccoulson> the gsd code does f_bavail/f_blocks for working out the percentage of free space. f_bavail is the number of free blocks available for non-root users
[20:31] <chrisccoulson> so that doesn't count the reserved 5% for root users
[20:31] <chrisccoulson> that's probably what you're seeing
[20:32] <fta> maybe it's a rounding issue
[20:32] <fta> $ df -B 1 /
[20:32] <fta> Filesystem           1B-blocks      Used Available Use% Mounted on
[20:32] <fta> /dev/sda1            308918038528 304411000832 4302237696  99% /
[20:32] <chrisccoulson> i think it's related to the 5% reserved blocks that you're not allowed to use
[20:32] <fta> 4302237696-2^32
[20:32] <fta> 7270400
[20:33] <fta> hmm
[20:33] <Fluffles> chrisccoulson, kk thank you. Is anything going to be provided by default to allow you to change the levels of different channels, and set which channels the volume up/down Fn keys will change instead then?
[20:33] <fta> chrisccoulson, i usually tweak that value, the default 10% doesn't make sense for big disks
[20:34] <chrisccoulson> fta - yeah, i agree. i've set it to zero for my /home partition - it just doesn't make sense there
[20:35] <chrisccoulson> but i think that explains your issue. i could use f_bfree rather than f_bavail, but then i think that would be wrong as it would count the space that you're not allowed to write to as available.
[20:36] <chrisccoulson> for working out the absolute space for displaying on the screen, it literally does f_frsize * f_bavail
[20:36] <chrisccoulson> these all come from statvfs()
[20:38] <fta> i know stat*fs pretty well
[20:38] <fta> i'm the author of libfilesys-diskspace-perl
[20:39] <chrisccoulson> ah, ok - i didn't know that
[20:39] <fta> http://search.cpan.org/~ftassin/Filesys-DiskSpace-0.05/lib/Filesys/DiskSpace.pm
[20:39] <fta> from another life ;)
[20:39] <chrisccoulson> cool. i've never done any perl in my life ;)
[20:40] <fta> i last touched this module 10 years ago, yet it's in karmic ;)
[20:41] <chrisccoulson> lol, does anyone maintain it now?
[20:41] <fta> debian
[20:42] <chrisccoulson> yikes, my home partition is 80% full. i'm going to have to start having a clear out i think
[20:42] <fta> lol, we also have my libdata-compare-perl
[20:42] <fta> and libpdf-create-perl
[20:43] <fta> seems i have some fans
[20:44] <fta> and my libsnmp-mib-compiler-perl too, lol
[21:06] <SiDi> Quick question for devs : how can i know the content of a g_string ? Can i compare it with a static string ? How can i check if its empty ?
[21:20] <chrisccoulson> SiDi - did you figure out your answer?
[21:21] <SiDi> chrisccoulson: i'm hoping for a proper way than "g_string_compare(mystring, g_string_new(NULL)) :/
[21:21] <chrisccoulson> a GString is just a struct containing 3 members - the actual string, it's length and the allocated length
[21:21] <SiDi> oh
[21:21] <SiDi> and am i meant to be able to directly reach the string?
[21:21] <kklimonda> yeah
[21:21] <chrisccoulson> yeah, you can just access the str member
[21:21] <SiDi> great
[21:22] <SiDi> so a NULL g_string would contain a NULL str and a 0 length ? :]
[21:22] <chrisccoulson> a NULL GString is just that - nothing ;)
[21:23] <chrisccoulson> but you can check the size of the string by accessing the "len" member. that obviously only works if you use the g_string_* functions to write the string
[21:24] <SiDi> chrisccoulson: ok. my concern is that i risk having a g_string initialized to NULL in my code
[21:26] <chrisccoulson> but you can check for that.
[21:26] <kklimonda> SiDi: you can always check first if it's null or init it with g_string_new (NULL); which will create an empty but correct gstring
[21:26] <SiDi> yeh, im gonna check if the string's str is NULL
[21:27] <SiDi> chrisccoulson: kklimonda thanks :]
[21:27] <chrisccoulson> SiDi - you're welcome
[21:28] <chrisccoulson> but i'm not sure of the value of a NULL pointer check on the str member, as you will already know what you initialized it too when creating the GString
[21:28] <chrisccoulson> so it seems a bit redundant;)
[21:29] <SiDi> i get it from an external function which can return NULL. But i could indeed check the gchar before
[21:30] <SiDi> which is what im going to do, after i get a coffee >_<
[21:30] <SiDi> Sorry for the noise
[21:31] <chrisccoulson> that's ok ;)