[01:17] <rickspencer3> robert_ancell, so far as I can tell, gedit is still using ui_manager instead of a builder, can that be right?
[01:17] <rickspencer3> (I'm working on a plugin)
[01:18] <robert_ancell> rickspencer3, I don't know, but a lot of programs do seem to use UIManager
[01:18] <rickspencer3> I thought that was all getting thrown out for Gnome 3.0
[01:18] <rickspencer3> everything needs to switch to builder
[01:18]  * rickspencer3 googles
[01:20] <robert_ancell> it's still in git master.  Yes, I agree!
[01:20] <rickspencer3> hmmm, I guess just getting rid of libglade, but doesn't say anything about UIManager
[01:22] <rickspencer3> robert_ancell, is UIManager part of libglade?
[01:22]  * rickspencer3 bangs head on gnome docks
[01:22] <rickspencer3> docs, even
[01:22] <robert_ancell> no
[01:24] <rickspencer3> hmmm
[01:24] <rickspencer3> gtk.UIManager — construct menus and toolbars from an XML description (new in PyGTK 2.4)
[01:24] <rickspencer3> suggests they are related
[01:25] <robert_ancell> it seems to me to be a cut-down GtkBuilder, which must surely be considered obsolete
[01:27] <rickspencer3> well, so far as I can tell, it's what gedit is built with, at least in the plugin API
[01:27] <rickspencer3> I'm going to change my code to just build things DOM Style, so it will be easy to change if they change gedit
[01:27] <rickspencer3> hi mterry
[01:32] <mterry> rickspencer3, hi
[01:51] <rickspencer3> hey robert_ancell can I ask you a quick gtk questions ...
[01:51] <robert_ancell> rickspencer3, sure
[01:51] <rickspencer3> if I create widgets on the fly, and connect to signal handlers as I do so
[01:51] <rickspencer3> then I later remove the widgets
[01:51] <rickspencer3> does the connected signal handler mean I am leaking each new widget?
[01:52] <rickspencer3> in other words, so I need to track and disconnect the signal handlers?
[01:52] <robert_ancell> I don't believe a signal handler holds a reference to the object, so no.  As long as you destroy the objects, then you shouldn't get any more signals.
[01:52] <mclasen> you leak the signal handler itself, though
[01:53] <mclasen> g_signal_connect_object was supposed to take care of that, but its buggy and has never been fixed
[01:53] <rickspencer3> mclasen, could you explain?
[01:53] <robert_ancell> mclasen, really?  Is the signal table no part of the object?
[01:53] <mclasen> no
[01:53] <mclasen> its a global list
[01:53] <rickspencer3> so I am growing this table of widgets to signals?
[01:53] <rickspencer3> well, widgets to functions
[01:54] <rickspencer3> and even though the widget is deleted and can't activated, the table continues to grow if I don't use disconnect?
[01:54] <mclasen> you are growing the list of Handler structs
[01:55] <rickspencer3> even in PyGtk?
[01:55] <mclasen> you are expected to disconnect from signals that you connected to
[01:55] <mclasen> don't know if pygtk has any automatic cleanup for that
[01:56] <rickspencer3> ok, so I have to find a place to keep the signal handler id when I remove the widgets :(
[01:57] <robert_ancell> mclasen, thanks, I didn't know it was like that
[01:58] <rickspencer3> *sigh*
[01:58] <rickspencer3> so much bookkeeping
[01:59] <rickspencer3> thanks mclasen and robert_ancell
[07:59] <didrocks> good morning
[08:00] <RAOF> Good morning didrocks
[08:01] <didrocks> hey RAOF
[08:01] <RAOF> What's up in groove town?
[08:02] <didrocks> well, trying to play and fight gnome-session/gnome-panel without a lot of success until then :)
[08:02] <didrocks> also, snowing a little :)
[08:02] <didrocks> and for you?
[08:02] <RAOF> Subduing mesa.
[08:02] <RAOF> It's pretty thoroughly subdued now.
[08:03] <RAOF> I'll be looking for a sponsor for it, and an accompanying -radeon DDX upload soon.  Just as soon as my r700 system upgrades to natty so I can test it :)
[08:03] <didrocks> oh nice!
[08:04] <didrocks> keep us up to date once testing and done so that we can sponsor you :)
[08:04] <RAOF> That'll probably even drop the CD size down so it'll actually fit on a Cd :)
[08:05] <didrocks> it wasn't before?
[08:06] <RAOF> pitti seemed to be scrounging for space.  More than usual, too.
[08:07] <RAOF> Yeah, all the CDs look to be oversize at the moment.
[08:07] <RAOF> Oooh, ow.  By 30MB, too.
[08:10] <RAOF> Installed-Size: 15112 vs Installed-Size: 43004 will help a bit.
[08:12] <pitti> Good morning
[08:13] <RAOF> And a fine morning to you also pitti
[08:22] <didrocks> Guten Morgen pitti :)
[08:22] <didrocks> RAOF: and there is no unity!
[08:22] <didrocks> RAOF: tomorrow will be really ugly :)
[08:23] <RAOF> There's plenty of unity here, although that seems to be because I'm using the ini backend to compiz :)
[08:24] <didrocks> RAOF: well, you should switch to gconf, one the migration is done :)
[08:24] <didrocks> which will come soon
[08:24] <RAOF> I'm not sure why mine was set to ini.  I must have set it sometime in the dim and distant past.
[08:25] <RAOF> Does compiz now start when using the gconf backend? :)
[08:26] <didrocks> RAOF: depends, if you whip your old configuration, yes, otherwise no… but you will be a nice guinee pig (is it the right spelling?) for the migration script :)
[08:34] <pitti> jasoncwarner1: the process: https://wiki.ubuntu.com/MainInclusionProcess
[08:35] <pitti> jasoncwarner1: the requirements: https://wiki.ubuntu.com/UbuntuMainInclusionRequirements
[08:35] <jasoncwarner1> pitti: awesome, thanks
[08:37] <didrocks> hey jasoncwarner1
[08:38] <jasoncwarner1> didrocks: morning!
[08:41] <didrocks> pitti: can you NEW e-d-s please?
[08:42] <pitti> didrocks: sure
[08:42] <didrocks> thanks :)
[08:42] <pitti> seems that right after the sdl bug was fixed, this is now breaking CD builds :)
[08:43] <pitti> didrocks: hm, no powerpc binaries yet? anyway, accepted
[08:43] <didrocks> argh, sorry for that, I was thinking uploading evo now is better than later this week :)
[08:44] <pitti> didrocks: oh, don't worry
[08:44] <pitti> it was just a funny coincidence
[08:44] <pitti> (funny at this point in the release cycle :) )
[08:44] <didrocks> right :)
[08:44] <didrocks> and tomorrow… it will be unity on the CD!
[08:44] <didrocks> (hoping it won't break it)
[08:45] <pitti> \o/
[08:52] <rodrigo__> morning
[08:56] <didrocks> hey rodrigo_
[08:56] <jasoncwarner1> didrocks: so, before I sign off for the night...is today the day? Unity by default ? ;)
[08:56] <bilalakhtar> Package rhythmbox depends on NBS package valac-0.10 and libvala-0.10-dev . Is it ready for a migration to valac-0.12?
[08:56]  * bilalakhtar tries a test build with the new version
[08:57] <didrocks> jasoncwarner1: will rather be tomorrow :)
[08:57] <didrocks> jasoncwarner1: need to finish some profiles work and a lot of headaches :)
[08:58] <jasoncwarner1> 'aight :) I guess it is a Thanksgiving day thing for the American folks! ;) good time, I suppose! :P
[08:59] <didrocks> jasoncwarner1: "perfect" timing right :)
[08:59] <jasoncwarner1> :)
[09:00] <jasoncwarner1> well, that is it for me then. Talk to you guys tomorrow my time, afternoon your time !
[09:00] <didrocks> jasoncwarner1: have a nice evening/night!
[09:01] <seb128> hey didrocks jasoncwarner1
[09:01] <didrocks> good morning seb128
[09:42] <rodrigo_> need to restart, brb
[09:57] <seb128> rodrigo_, hey
[09:57] <rodrigo_> hi seb128
[09:58] <seb128> rodrigo_, how are you?
[09:59] <seb128> rodrigo_, what do you work on?
[09:59] <rodrigo_> fine, thanks, and you?
[09:59] <seb128> I'm fine thank you
[09:59] <rodrigo_> seb128, I'm trying to finish the invest applet thing before leaving it for more days
[09:59] <rodrigo_> talking with carlos, the guy who wrote did part of the libpanel-applet-3 thing
[09:59] <seb128> you are having some holidays?
[10:00] <rodrigo_> seb128, oh, yes soon there are a few national holidays
[10:00] <rodrigo_> and in Dec, going out for a week
[10:00] <rodrigo_> seb128, you?
[10:00] <seb128> there is no national holidays coming there
[10:00] <seb128> but I plan to take fridays until end of year
[10:00] <rodrigo_> btw, need to enter the national holidays in canonicaladmin
[10:00] <rodrigo_> seb128, ah, cool
[10:00] <seb128> then do an end of year break as well
[10:01] <rodrigo_> here there are 3 holidays coming, 3rd, 6th and 8th Dec :)
[10:01] <seb128> rodrigo_, well you say finishing the invest applet thing before letting it for some extra days, does it mean you are on vac tomorrow and friday...?
[10:01]  * rodrigo_ submits them
[10:01] <rodrigo_> seb128, oh no, just that it's been too long, and really want to fix it :)
[10:02] <seb128> great
[10:02] <seb128> I really want to get that landing as well
[10:02] <rodrigo_> yeah, I really think the typelib is wrong for libpanel-applet-3
[10:02] <seb128> so we can uninstall libbonoboui easily ;-)
[10:02] <rodrigo_> it complains about PanelApplet.Applet.factory_main not existing, but it's indeed in the gir generated
[10:02] <seb128> weird
[10:03] <rodrigo_> yes
[10:04] <seb128> rodrigo_, I will review gnome-keyring in the ppa btw
[10:04] <rodrigo_> ok
[10:04] <seb128> I might just fix things on the way, I don't want to dump to many things on your list
[10:04] <rodrigo_> will fix the g-c-c issues later
[10:05] <seb128> you should get gnome-applets done and fix the gnome-control-center issues from yesterday
[10:05] <rodrigo_> ok, just let me know what was wrong, so that I learn more
[10:05] <bilalakhtar> Rb in Ubuntu depends on NBS valac-0.10 and libvala-0.10-dev. Is it ready for a migration to valac-0.12 (now in Ubuntu) ?
[10:05] <seb128> ok, seems fine to me
[10:05]  * bilalakhtar is already test-building it
[10:05] <seb128> bilalakhtar, there is a 0.13.2 update in the work
[10:05] <seb128> bilalakhtar, it's in the vcs
[10:05] <seb128> it was blocked on a crash
[10:05] <bilalakhtar> seb128: it has been uploaded as well, I guess
[10:06] <seb128> no
[10:06] <seb128> upload was pending on getting a crash fixed
[10:06] <bilalakhtar> okay then
[10:06] <bilalakhtar> since in the vcs, that upload is shown as 'natty' rather than UNRELEASED
[10:07] <seb128> well I think the idea is that it was supposed to be uploaded
[10:07] <seb128> but it didn't because of the bug
[10:07] <seb128> I will sort that today
[10:19] <didrocks> rodrigo_: do you know who should I ping from u1 team (I want to know which desktop file to set in the unity launcher by default)?
[10:23] <seb128> didrocks, try aquarius?
[10:23] <didrocks> seb128: yeah, let's see when he's online :)
[10:24] <seb128> aquarius, ^
[10:25] <seb128> didrocks, otherwise seems the sort of task you can ping kenvandine about
[10:25] <seb128> he's the desktoper in charge of interactions with u1
[10:25] <didrocks> seb128: right, well, it's just while I'm thinking at it and to get the final list for the migration, but that can change after (just people already transitionned won't have the new icon)
[10:34] <seb128> rodrigo_, the gnome-keyring update is not right
[10:37] <rodrigo_> seb128, oh, what's wrong in it?
[10:37] <rodrigo_> didrocks, nessita or dobey
[10:37] <seb128> lot
[10:38] <rodrigo_> oh :(
[10:38] <didrocks> rodrigo_: ok, thanks :)
[10:38] <seb128> but basically it should build twice, once with gtk2 and once with gtk3 ideally
[10:38] <seb128> so libgcr0 and libgcr3 are built
[10:38] <rodrigo_> ah
[10:54] <huats> morning
[10:57] <pitti> seb128: oh, I just see that we still build /usr/share/gir-1.0/GLib-2.0.gir from gobject-introspection instead of from glib2.0
[10:57] <pitti> seb128: do you want me to look into that?
[10:57] <pitti> current glib2.0 fixed a couple of bugs in the annotations which now start to hurt us
[10:58] <seb128> pitti, do they plan to build it from glib now?
[10:58] <seb128> they were discussing it for a while
[10:58] <pitti> erm, why wouldn't they/we?
[10:59] <seb128> pitti, because gobject-introspection depends from glib
[11:00] <seb128> it would make glib depends on gobject-introspection
[11:00] <seb128> like circular requirement
[11:00] <pitti> ah, so that's a permanent plan then?
[11:00] <seb128> no sure that was the other reason
[11:00] <seb128> you should ask on their channel
[11:00] <pitti> okay, will do; thanks!
[11:00] <seb128> other -> only
[11:00] <seb128> you're welcome
[11:00] <pitti> I thought that gir-repository was just a kludge
[11:00] <seb128> it is
[11:00] <pitti> and it doesn't even build right now
[11:00] <seb128> but gir-repository != gobject-introspection
[11:01] <pitti> right, I know
[11:01] <seb128> pitti, gir-repsitory builds only a few gir not used
[11:01] <seb128> it's nothing to do with glib
[11:01] <seb128> or with bugs you might have
[11:01] <pitti> $ dpkg -S /usr/share/gir-1.0/GLib-2.0.gir
[11:01] <pitti> libgirepository1.0-dev: /usr/share/gir-1.0/GLib-2.0.gir
[11:01] <pitti> seb128: it is
[11:01] <pitti> that's why I noticed in the first place
[11:01] <seb128> that's coming from gobject-introspetion
[11:01] <pitti> we have a wrong annotation there
[11:01] <pitti> which causes a crash
[11:02] <seb128> not from gir-repository
[11:02] <pitti> but our glib package has that fixed already
[11:02] <pitti> oh, oops
[11:02] <seb128> you might want to update gobject-introspection to a git snapshot
[11:02] <pitti> ok, looking into that
[11:02] <seb128> that would make sense
[11:02] <seb128> but really gir-repository is a leftover
[11:02] <pitti> if that gir is built from libglib2.0-dev instead of being a static copy, then things would be fine
[11:03] <seb128> well I know they had discussions about that at GUADEC
[11:03] <seb128> and they was disagreement between upstream people
[11:03] <seb128> so they probably have solid reasons to do it the way they are doing it now
[11:03] <seb128> you should ask them
[11:03] <pitti> right, thanks
[11:03] <seb128> meanwhile I think walters blogged saying to use the git gobject-introspection
[11:03] <seb128> so maybe using a snapshot would solve your issues
[11:04] <seb128> just make sure they didn't break the abi again if you do that ;-)
[11:06] <didrocks> speaking about circular depends, it seems we have some bugs from doko: bug #677387 bug #677382 bug #677374 bug #677388
[11:06] <pitti> seb128: the ABI in the sense of "typelib version 4 expected, but 3 found blabla"?
[11:06] <ubot2> Launchpad bug 677387 in libgnome (Ubuntu) "libgnome b-d on libcanberra, which cannot be availabe at this time (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/677387
[11:06] <ubot2> Launchpad bug 677382 in gir-repository (Ubuntu Natty) (and 1 other project) "gir-repository fails to build from source in natty (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/677382
[11:06] <ubot2> Launchpad bug 677374 in glade-3 (Ubuntu Natty) (and 1 other project) "glade-3 link failures with --no-add-needed (affects: 1) (heat: 6)" [High,Confirmed] https://launchpad.net/bugs/677374
[11:06] <ubot2> Launchpad bug 677388 in gstreamer0.10 (Ubuntu) (and 1 other project) "gstreamer b-d on the *complete* gnome desktop via gir-repository-dev (affects: 1) (heat: 6)" [High,Fix committed] https://launchpad.net/bugs/677388
[11:06] <seb128> pitti, yes
[11:06] <seb128> didrocks, the third one is pending sync, I will do that today
[11:07] <seb128> didrocks, the second one will be fixed in the glade-3 update which is being worked
[11:07] <seb128> didrocks, the second is a known issue nobody cares about, we should probably just drop the source, we keep it because some things synced from debian still wrongly list it
[11:08] <seb128> ups, got my index wrong
[11:08] <pitti> drop the gir-repository package, you mean?
[11:08] <seb128> but basically most have been assigned or commented on already
[11:08] <seb128> yes
[11:08] <didrocks> ok, it's not me then :)
[11:08] <didrocks> ok, nice
[11:08] <didrocks> slomo fixed the gstreamer one IIRC
[11:08] <seb128> pitti, we keep it because a few things still build-depends on gir-repository-dev
[11:08] <seb128> didrocks,  didrocks, the third one is pending sync, I will do that today
[11:09] <seb128> got my index wrong as said
[11:09] <seb128> that was about the gstreamer one, see my comment on the bug
[11:09] <didrocks> ok, it wasn't glade :)
[11:09] <pitti> yep, seems that g-i git head fixes quite a lot of those
[11:09] <seb128> pitti, great ;-)
[11:09] <didrocks> just a ping, I kept that in my todo to ping people about it as I was pinged and not working on that
[11:09] <seb128> well depends use gir-repository-dev because they didn't add the gir builds to gtk etc
[11:10] <seb128> didrocks, ok, I handled them when I noticed the emails, but feel free to ignore doko pings
[11:10] <didrocks> seb128: understood :)
[11:10] <seb128> he shouldn't ping people directly but assign to our team rather
[11:11] <seb128> I wonder why the heck gstranslator has a distro diff to build-depends on liblaunchpad-integration-dev
[11:11] <seb128> it's the only diff and the code doesn't use the lib anywhere
[11:12] <seb128> people keep merging that diff since jaunty
[11:14] <aquarius> didrocks, you want to ping nessita about that
[11:15] <aquarius> didrocks, oh, rodrigo_ already said that, heh :)
[11:15] <didrocks> aquarius: yeah, thanks nonetheless! :)
[11:15] <pitti> seb128: so, g-i git head fixes my test program crash, and apport works just fine
[11:16] <seb128> pitti, upload ;-)
[11:16] <pitti> you bet!
[11:17] <rodrigo_> hey aquarius
[11:17] <aquarius> rodrigo_, hey
[11:20] <rodrigo_> seb128, https://code.launchpad.net/~rodrigo-moya/ubuntu/natty/gnome-control-center/several-fixes-2-91-2/+merge/41713
[11:20] <seb128> rodrigo_, thanks, reviewing when the diff will be there
[11:21] <rodrigo_> seb128, yeah, no hurry, just finished it so that I can concentrate in the invest applet thing
[12:06] <seb128> chrisccoulson, your icetead-web update failed to build!
[12:07] <seb128> no pkg-config found
[12:07] <chrisccoulson> hmmmmm
[12:07] <chrisccoulson> i wonder how that ever worked?
[12:07] <seb128> dunno
[12:07] <seb128> is pkg-config supposed to be in build essential?
[12:11] <chrisccoulson> i'm not sure. it's strange that that's only just stopped working though :/
[12:13] <chrisccoulson> hmmm, couchdb is a PITA :)
[13:22] <didrocks> hum, gsettings is weird sometimes
[13:37] <nessita> hello everyone! quick question: did I miss a package since today I'm getting debian/rules:4: /usr/share/cdbs/1/rules/debhelper.mk: No such file or directory
[13:37] <nessita>  ?
[13:38] <seb128> hey nessita
[13:38] <nessita> seb128: hey there!
[13:39] <seb128> how are you?
[13:39] <nessita> seb128: is my system crazy today? :-)
[13:39] <nessita> pretty good, and you?
[13:39] <seb128> I'm fine thanks
[13:39] <seb128> nessita, you did a typo it seems
[13:39] <seb128> ups sorry, I did a typo
[13:40] <seb128> nessita, do you have cdbs installed?
[13:40] <seb128> dpkg -l | grep cdbs
[13:41] <nessita> it shows nothing
[13:41] <seb128> sudo apt-get install cdbs
[13:41] <nessita> which is odd since I've been using this quite a few times
[13:41] <seb128> nessita, grep cdbs /var/log/dpkg.log
[13:41] <seb128> nessita, grep cdbs /var/log/dpkg.log
[13:41] <seb128> ups
[13:42] <nessita> seb128: http://pastebin.ubuntu.com/535885/
[13:43] <seb128> nessita, you removed it the day before yesterday it seems
[13:43] <seb128> reinstall it
[13:43] <seb128> "2010-11-22 15:51:48 remove cdbs"
[13:43] <nessita> seb128: *I* removed it?!?!?
[13:43] <seb128> it seems so
[13:44]  * nessita didn't (not intentionally at least)
[13:44] <seb128> or you installed something which conflicts with it
[13:44] <seb128> you can read the dpkg.log around the time that was removed
[13:44] <didrocks> hey nessita
[13:44] <didrocks> cyphermox: hey
[13:44] <seb128> just to see what else was installed or removed
[13:44] <didrocks> cyphermox: did you see the evo-exchange FTFBS?
[13:44] <didrocks> FTBFS*
[13:45] <cyphermox> hadn't seen it yet, but we should be able to fix that easily
[13:45] <didrocks> cyphermox: no hurry on that, can be next week
[13:45] <didrocks> just to warn you about it :)
[13:45] <cyphermox> yep yep.
[13:46] <cyphermox> I got another ftbfs on arm for wpasupplicant too, which might wait until next week :/
[13:46] <cyphermox> I jumped right into nm-applet this morning
[13:48] <cyphermox> didrocks, the ftbfs was due to evo not being ready: evolution-dev : Depends: evolution (= 2.30.3-1ubuntu7.1) but it is not going to be installed
[13:48] <didrocks> yeah, no worry, -exchange is in universe and isn't subject to freeze
[13:48] <didrocks> cyphermox: hum, even the latest?
[13:48] <didrocks> weird, it was published by the time
[13:49] <cyphermox> I don't know. looks to me like it's the reason for it to have failed
[13:49] <didrocks> cyphermox: ok, will do a retry
[13:50] <cyphermox> didrocks, just checked, i386 evo hadn't finished stripping translations by the time evo-exch failed
[13:50] <didrocks> cyphermox: ok, it means that the build-dep wasn't bumped on evo-exch, weird
[13:50] <didrocks> thanks
[13:50] <cyphermox> but it was... afaict
[13:52] <cyphermox> anyway, I do believe a rebuild with no changes will fix this
[13:53] <didrocks> yeah, will do that, thanks
[14:22] <seb128> rodrigo_, there?
[14:32] <nessita> didrocks: I updated lp:~nataliabidart/ubuntuone-control-panel/natty-release with the version requirement for ubuntuone-clinent (>= 1.5.0) which is the new u1-client release in natty. Is there any chance you (re) sponsor that natty package?
[14:33] <nessita> didrocks: by "that natty package" I meant u1 control panel package :-)
[14:33] <didrocks> nessita: oh sure, can do that :)
[14:33] <didrocks> nessita: so, the prefered u1 setting client replacing u1preferences is what command nonw?
[14:33] <didrocks> now*
[14:34] <nessita> ubuntuone-control-panel-gtk
[14:34] <didrocks> nessita: thanks! I have no access to your branch like the other day
[14:35] <nessita> what? I fixed this with a l.o.s.a
[14:35]  * nessita rechecks
[14:35] <didrocks> Not allowed here
[14:35] <didrocks> Sorry, you don't have permission to access this page.
[14:35] <didrocks> You are logged in as Didier Roche.
[14:35] <didrocks> not for me :)
[14:36] <nessita> oh
[14:39] <nessita> didrocks: I repushed to lp:~nataliabidart/+junk/ubuntuone-control-panel-natty-release until I get another l.o.s.a slot
[14:40] <didrocks> nessita: ok, thanks, will get to it today
[14:40] <nessita> didrocks: thanks!
[14:40] <didrocks> yw :)
[14:55] <bcurtiswx> kenvandine, did empathy 2.32.2 get uploaded to -proposed ?
[14:55] <kenvandine> not yet
[14:55] <kenvandine> soon
[14:55] <kenvandine> :)
[14:55] <kenvandine> i haven't forgotten
[14:55] <mvo> kiwinote: hello! I'm working on the fastlist stuff currently, if you want, check out lp:~mvo/software-center/experimental-fastlist , I will merge your changes next, I think we are relatively close now, thanks for all your great work
[14:56] <bcurtiswx> kenvandine, can you add a maverick part to bug #678330 ? i can't afaik
[14:56] <ubot2> Launchpad bug 678330 in empathy (Ubuntu) "Empathy 2.32.2 Stable Release Update Request (affects: 1) (heat: 8)" [Wishlist,Triaged] https://launchpad.net/bugs/678330
[14:56] <rodrigo_> seb128, yes
[14:56] <seb128> bcurtiswx, you might want to wait for the current sru to reach updates to do a new one
[14:57] <bcurtiswx> mvo, is it possible that aptitude ignores recommends on a dist-upgrade when new recommends are introduced between cycles ?
[14:57] <kenvandine> bcurtiswx, that will make it easier to test
[14:57] <bcurtiswx> seb128, sure.  :)
[14:58] <kenvandine> bcurtiswx, nominated for maverick
[14:58] <bcurtiswx> i forgot about 2.32.1 waiting for -updates
[14:58] <kenvandine> bcurtiswx, can you ping me when that happens?
[14:58] <seb128> rodrigo_, I've noticed you turned off quite some of the g-c-c distro patches
[14:58] <bcurtiswx> kenvandine, sure.
[14:58] <seb128> rodrigo_, do you plan to update those?
[14:58] <kenvandine> thx
[14:59] <rodrigo_> seb128, yes, they need a big rebase
[14:59] <mvo> bcurtiswx: apt has --no-install-recommends, I'm not sure about apttitude, it should follow this too
[14:59] <rodrigo_> seb128, I just disabled them to make the packages available asap for ckpringle to test the new shell
[14:59] <rodrigo_> seb128, but yes, will rebase them soon
[14:59] <seb128> rodrigo_, ok, I guess you might want to work on those before starting on other updates
[15:00] <rodrigo_> seb128, well, I wanted to wait for the g-c-c code to stabilize a bit, but yeah, will do it after the g-applets update
[15:00] <seb128> rodrigo_, no hurry, I will just open bugs for tracking
[15:01] <seb128> we might want to discuss what to do for things which don't apply to the new code as well
[15:01] <bcurtiswx> mvo, i am referencing to bug #620733 in which i'm trying to see if a distribution upgrade caused libdconf0 to not be installed.. as it was introduced as recommends to empathy between those two cycles (Lucid-->Maverick)
[15:01] <ubot2> Launchpad bug 620733 in glib2.0 (Ubuntu) (and 1 other project) "Empathy does not remember settings (affects: 12) (dups: 3) (heat: 104)" [Undecided,New] https://launchpad.net/bugs/620733
[15:01] <rodrigo_> seb128, yes, I removed a few of those
[15:03] <bratsche> Hi didrocks, can I ask you a quick packaging related question?
[15:03] <bcurtiswx> im invalidating the glib part now, it's not that
[15:04] <bratsche> didrocks: I'm making packaging for my libgrip, and when I make distcheck it creates libgrip-0.1.0.tar.gz but when I try to bzr-buildpackage it is looking for libgrip_0.0.1.orig.tar.gz
[15:04] <didrocks> bratsche: right, you have to rename it
[15:05] <didrocks> hum, 0.0.1?
[15:05] <bratsche> Err.. 0.1.0
[15:05] <didrocks> ok :)
[15:05] <didrocks> so, yeah, you just have to rename it
[15:05] <didrocks> welcome to packaging land :)
[15:05] <seb128> rodrigo_, ok, I've pushed a new revision to gnome-control-center
[15:05] <rodrigo_> ok
[15:06] <seb128> rodrigo_, you might want read it just to see what I cleaned
[15:06] <bratsche> didrocks: So I rename it in the packaging somewhere?
[15:06] <seb128> rodrigo_, your lib .symbols was empty btw
[15:06] <rodrigo_> oh
[15:06] <didrocks> bratsche: oh no, just put the tar.gz file in the parent directory of your branch
[15:06] <rodrigo_> hmm, I guess I generated it and didn't copy it back to the branch
[15:06] <didrocks> bratsche: and rename it to libgrip_0.1.0.orig.tar.gz
[15:06] <seb128> rodrigo_, I'm uploading that to the ppa
[15:07] <bratsche> didrocks: Oh okay, thanks
[15:07] <didrocks> yw :)
[15:08] <chrisccoulson> great, couchdb ported but crashes on start now :)
[15:08] <rodrigo_> seb128, oh, cool, thanks for the fixes :)
[15:09] <seb128> rodrigo_, you're welcome
[15:09] <rodrigo_> seb128, how do you find the libs are not used anymore, apart from looking at the code?
[15:09] <seb128> rodrigo_, I usually diff the configure.ac between versions
[15:09] <rodrigo_> ah, ok
[15:09] <seb128> and I did a review as well there
[15:10] <seb128> and searched in the configure.ac if things that seems old were still used
[15:10] <seb128> didn't find things like pango or the libxss etc there
[15:10] <rodrigo_> seb128, as for the removed conflicts/replaces, it won't work for people having previous packages from the PPA, right?
[15:10] <seb128> rodrigo_, well people who run a natty ppa should have upgraded by now
[15:10] <seb128> they will probably not stay weeks on the buggy version
[15:11] <rodrigo_> yeah, and manual fixing is possible, so yeah, ok
[15:11] <seb128> I wanted to make sure we don't carry it over when it lands to Ubuntu
[15:11] <bcurtiswx> i still have my apt-get dist-upgrade wanting to remove evolution :-\
[15:11] <seb128> but I could have kept it a bit longer
[15:11] <bcurtiswx> with the ubuntu-desktop PPA
[15:11] <seb128> bcurtiswx, it's not likely the ppa
[15:12] <bcurtiswx> i know, the ppa packages are being kept back with just an upgrae
[15:12] <rodrigo_> seb128, no, no problem,. just tried manual fixing and it works, so we can just point people to do thatr
[15:13] <rodrigo_> if they have any problem
[15:13] <seb128> right
[15:13] <seb128> it's just a race between unpacking
[15:13] <seb128> running apt-get -f install usually fix it
[15:13] <seb128> those using a natty ppa should be able to do ;-)
[15:13] <bcurtiswx> aptitude why-not says evolution depends on -data-server and libcamel1.2-19 but libcamel1.2-19 breaks evolution
[15:13] <rodrigo_> yeah :)
[15:13] <seb128> but it just concerns users who get the old version and didn't update yet
[15:14] <seb128> bcurtiswx, seems the new evolution didn't build yet on the architecture you are using
[15:14] <kiwinote> hey mvo! I'll have a better look once our branches are merged together, but it seems to look nice. The few things I am aware of in my branch: querying installed pkgs is quite slow, custom pkglists don't work, I changed the ordering for search results - this gives much better results for app-install data pkgs, but we probably need to write an axi plugin to add some weightings to the terms for axi pkgs
[15:14] <bcurtiswx> amd64 seems so :)
[15:14] <seb128> urg
[15:14] <seb128> no ctrl-w!
[15:15] <kiwinote> mvo: also nzmm had a branch with faster scrolling - I haven't looked into the code itself yet, but it seems like something we will want (possibly minus the batched display of icons)
[15:17] <mvo> kiwinote: thanks for this info, I'm currently resolving the conflicts, hope to have it ready in a couple of minutes to merge back
[15:17] <mvo> kiwinote: then I check the one from nzmm
[15:17] <mvo> kiwinote: brings in another startup speed improvement as well it seems
[15:17] <rodrigo_> didrocks, oh, is the new evo in the natty repos then?
[15:18] <kiwinote> mvo: thanks! (also for the merging of the startup-speed branches yesterday along with nice shiny daily builds :) )
[15:19] <mvo> kiwinote: the startupspeed brnach is a killer (just like the fastapp one), I meant to hug you for it when I did the merge, but you were not online
[15:19]  * mvo hugs kiwinote
[15:19] <mvo> now! :p
[15:19]  * kiwinote hugs mvo ;)
[15:20] <kiwinote> mvo: we query for the featured and what's new sections on startup - so that'll probably explain the extra improvements
[15:20] <mvo> I like the new nr_apps, nr_pkgs as its more accurate, I need to measure how slow it is (your comment mentions that). but a thread souds like a good idea
[15:20] <kiwinote> mvo: yeah, I think displaying the action bar in a thread will solve any issues there
[15:21] <kiwinote> mvo: it's mostly just that we need three queries to get the right numbers and the results, so pushing two of them into a thread should work
[15:21]  * mvo nods
[15:21]  * bcurtiswx kick freenode
[15:22] <mvo> bcurtiswx: this can happen if a recommend sis not instlalable at the moment the upgade is tried
[15:23] <mvo> bcurtiswx: at this point apt/aptitude will decide to skip it and later it does not know if it was skipped because the user wanted it like this or because (back then) it was not installable
[15:23] <bcurtiswx> mvo, hmm.  so is it a bug still?
[15:23] <didrocks> rodrigo_: yes!
[15:24] <bcurtiswx> didrocks, excepti believe it FTBFS
[15:24] <bcurtiswx> for amd64
[15:24] <rodrigo_> didrocks, ok, I'll release evo-couchdb, which includes the fixes to compile with 2.31/32, and package it
[15:28] <mvo> kiwinote: ok, should be ready for re-merging, there is a bit of flux and I hope I did not make a merge mistake. some stuff I simplified, works for me, there is a open question about only_packages_without_applications, but it looks like you solved this already nicely with the XD term that you use
[15:29] <mvo> kiwinote: I'm quite excited, --debug-filter=performance shows 0.2s on my system when clicking on "system" now :-D
[15:29] <mvo> and it starts faster than it can open the cache
[15:31] <seb128> rodrigo_, do it usually takes a while for you to get the ppa uploads accepted?
[15:31] <rodrigo_> seb128, hmm, not much, no
[15:31] <rodrigo_> a few minutes
[15:32] <seb128> ok, I'm wondering what happened to my g-c-c upload
[15:33] <dobey> pedro_: ping
[15:34] <pedro_> hi dobey
[15:35] <dobey> pedro_: hey. it looks like us ubuntu one hackers can't see any of the bugs on the ubuntuone packages in ubuntu, that are private.
[15:35] <dobey> pedro_: might you know why?
[15:35] <rodrigo_> heh, pedro_ again messing around with bugs :)
[15:36] <pedro_> dobey, because they are probably not part of the ubuntu bug control team
[15:36] <pedro_> dobey, only members of that team are able to see private bugs in the ubuntu product
[15:36] <dobey> pedro_: but we are. ~ubuntone-hackers is a member of ~ubuntu-bugcontrol
[15:37] <dobey> hrmm
[15:37] <pedro_> dobey, any example bug?
[15:38] <dobey> pedro_: https://bugs.launchpad.net/ubuntu/+source/ubuntuone-client/+bug/680968
[15:38] <ubot2> dobey: Error: Bug #680968 is private.
[15:38] <pedro_> dobey, is that a crash report?
[15:38] <Chipaca> yes, it is
[15:39] <dobey> pedro_: i have no idea, i can't see it :)
[15:39] <Chipaca> yes, it's a crash report
[15:39] <Chipaca> of the ubuntu one nautilus plugin
[15:39] <dobey> but chipaca says it is
[15:39] <pedro_> dobey, IIRC we cannot access those bugs until apport do something with those
[15:39] <Chipaca> pedro_: that wouldn't be an issue, but then we don't get an email about it either
[15:40] <pedro_> Chipaca, lp bug :-)
[15:40] <rodrigo_> kklimonda, hey, just released couchdb-glib 0.7.0, fyi
[15:40] <Chipaca> looks like it
[15:44] <pedro_> Chipaca, dobey btw bug 425127 has more info on why you don't get notification from those
[15:44] <ubot2> Launchpad bug 425127 in malone "private bugs in packages people with access to private bugs are subscribed to don't generate emails (affects: 1) (heat: 1)" [Low,Triaged] https://launchpad.net/bugs/425127
[15:44] <kiwinote> mvo: looking atm - just forgetting to update all the right db's in the right order ;)
[15:46] <seb128> rodrigo_, kklimonda: if you touch couchdb-glib please drop the build-depends on gir-repository-dev
[15:46] <rodrigo_> seb128, hmm, didn't I already removed it?
[15:46] <rodrigo_> seb128, but yeah, looking now, I'll package it now
[15:47] <rodrigo_> seb128, right, still there
[15:47] <seb128> rodrigo_, ;-)
[15:47] <mvo> kiwinote: heh, indeed, the local xapian one should be rebuild automatically now, it has a "version number" now
[15:47] <seb128> same if someone is going to touch libubuntuone one day
[15:47] <mvo> kiwinote: but of course the systemwide does not
[15:47] <seb128> rodrigo_, that used to be you as well do you know if there is any new release planned?
[15:47] <seb128> I might just rebuild the current version without it
[15:48] <rodrigo_> seb128, no, I still maintain couchdb-glib and evo-couchdb, but not libu1
[15:48] <rodrigo_> dobey, ^^
[15:48] <dobey> what now
[15:48] <rodrigo_> I can package it as soon as there is a new release
[15:48] <rodrigo_> or Chipaca ^^
[15:48] <seb128> dobey, do you know if libubuntuone will get a new version in the next weeks?
[15:48] <dobey> sure why not
[15:49] <seb128> dobey, I want to clean the build-depends on gir-repository-dev and was wondering if I should wait for the next normal upload or just do an upload for that
[15:49] <seb128> since that's deprecated and we want to drop it
[15:49] <rodrigo_> seb128, I can do the upload just for that
[15:49] <seb128> it should just depends on the specific gir binaries it needs
[15:49] <dobey> is there a replacement, or it just gets dropped?
[15:49] <seb128> dobey, the gir are built from gtk, etc now
[15:50] <dobey> in gtk3?
[15:50] <seb128> gir-repository-dev was a pack of those from the time they were not built by the components
[15:50] <Laney> I just uploaded new versions of banshee and b-c-e that should be good to seed/promote
[15:50] <dobey> or in gtk2 also?
[15:50] <seb128> gtk2 also
[15:50] <seb128> it was already the case in maverick
[15:50] <seb128> really gir-repository-dev probably contains nothing you use
[15:51] <seb128> apt-cache show gir-repository-dev
[15:51] <seb128> see the list of girs there
[15:51] <kiwinote> mvo: seems to be looking nice
[15:51] <dobey> ok
[15:51] <dobey> seb128: is there a bug for it?
[15:52] <seb128> you probably want to use gir:Depends as well and can dh_girepository
[15:52] <kiwinote> mvo: by the looks of it the purchase apps updater needs a display_name updater added (probably also a pkgname.replace('-','_') from last nights stuff I did)
[15:52] <mvo> kiwinote: some more cleanup in r1279
[15:52] <seb128> dobey, no but I can open one
[15:53] <mvo> kiwinote: replace()> good point
[15:53] <dobey> ok
[15:53] <kiwinote> mvo: as for only_packages_without_applications, I haven't quite worked out what it does
[15:53] <rodrigo_> seb128, an easy one -> https://code.launchpad.net/~rodrigo-moya/ubuntu/natty/couchdb-glib/0_7_0_release/+merge/41752
[15:53] <rodrigo_> seb128, I can do the upload for that one, since I have ppu permissions
[15:54] <mvo> kiwinote: its meant for removing packages that also have a application, the name is kind of hard to parse
[15:54] <mvo> kiwinote: but I think you solved that more elegantly with the XD query
[15:54] <kiwinote> mvo: ah ok - in that case it can indeed go
[15:55]  * kiwinote likes the amount of deletions in r1279 :)
[15:55] <mvo> yeah
[15:55] <mvo> this stuff was a pain to write in the first place, now its a joy to get rid of it again ;)
[15:55] <kiwinote> I can imagine
[15:56] <rodrigo_> seb128, btw, I just realized I always ping you for reviews, so will ping others as well :)
[15:57]  * rodrigo_ looks at didrocks and pitti
[15:57] <didrocks> rodrigo_: can do it, but tomorrow, needs finish compiz session
[15:57] <didrocks> and not sure how long it will take
[15:58] <rodrigo_> didrocks, yeah, don't worry, will ping you for other reviews from now on, not this one :)
[15:58] <didrocks> ok :)
[15:58] <rodrigo_> but not before tomorrow, of course :)
[16:01] <seb128> rodrigo_, just copy urls on the channel and let people pick those
[16:01] <rodrigo_> ok
[16:04] <seb128> rodrigo_, the couchdb-glib update is fine, you can upload but need somebody to merge in the vcs right?
[16:04] <rodrigo_> seb128, yes, need just the merge
[16:04] <seb128> ok will do that
[16:04] <bratsche> didrocks around still?
[16:05] <rodrigo_> ok, uploading then
[16:05] <didrocks> bratsche: I'm there, yeah
[16:06] <seb128> dobey, rodrigo_: bug #681013
[16:06] <ubot2> Launchpad bug 681013 in libubuntuone (Ubuntu) "should not build-depends on gir-repository-dev (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/681013
[16:06] <dobey> seb128: thanks
[16:06] <bratsche> didrocks: Hey, is there any chance you might have a few minutes to look at my packaging and see what is wrong with it? :)
[16:06] <rodrigo_> dobey, ok, I'll do an upload for that
[16:06] <dobey> rodrigo_: if you insist
[16:06] <rodrigo_> :)
[16:07] <didrocks> bratsche: really not know, but later yes :)
[16:07] <bratsche> didrocks: Awesome, thanks!
[16:07] <seb128> rodrigo_, you need to call dh_girepository in the rules
[16:07] <rodrigo_> oh, ok
[16:07] <seb128> gir:Depends doesn't work without that
[16:08] <rodrigo_> seb128, oh, in couchdb-glib also then?
[16:08] <seb128> rodrigo_, well, anywhere you use gir:Depends
[16:08] <dobey> seb128: for packages i need to get updates in for, that i don't already have upload privs for, should i just dput them and ask someone to sponsor?
[16:09] <seb128> dobey, either that or give a vcs url from where people can build the source
[16:09] <seb128> rodrigo_, binary-predeb/gir...:
[16:09] <rodrigo_> seb128, ok
[16:09] <seb128> rodrigo_, it's the target used in cdbs sources to call dhgirepository
[16:10] <seb128> where gir... is the gir binary name
[16:10] <rodrigo_> seb128, have you already merged the couchdb-glib branch?
[16:10] <seb128> rodrigo_, not yet
[16:10] <rodrigo_> seb128, ok, I'll add it there then, so don't merge yet
[16:11] <dobey> seb128: ok, thanks again
[16:11] <seb128> rodrigo_, ok
[16:11] <rodrigo_> I'll need another upload though, have already uploaded it
[16:11] <seb128> dobey, you're welcome
[16:14] <rodrigo_> debian/rules:8: *** target file `binary-predeb/gir1.0-couchdb-glib-1.0' has both : and :: entries.  Stop.
[16:14] <rodrigo_> what does that mean?
[16:15] <seb128> what did you use?
[16:16] <seb128> rodrigo_, you probably need "binary-predeb/gir1.0-couchdb-glib-1.0::"
[16:16] <seb128> rodrigo_, double :
[16:17] <rodrigo_> yay, seems so
[16:25] <seb128> rodrigo_, was there any reason you didn't upload gnome-bt to the ppa yet?
[16:25] <rodrigo_> seb128, I was waiting for your review
[16:26] <rodrigo_> I thought I can't upload to the PPA?
[16:26] <seb128> rodrigo_, ok, doing that now since I merged your depends fix
[16:26] <seb128> rodrigo_, oh ok, you only did it yesterday
[16:26] <seb128> rodrigo_, I though it was done before we suspended the ppa for you
[16:26] <rodrigo_> seb128, yes, the previous changes in the branch didn't get uploaded
[16:39] <kklimonda> seb128: have you had time to take a look at atkmm yet?
[16:40] <kklimonda> rodrigo_: \o/ (wrt the new couchdb-glib release)
[16:40] <kklimonda> chrisccoulson: what are you doing with couchdb? :)
[16:41] <chrisccoulson> kklimonda, trying to make it work with the latest version of spidermonkey
[16:42] <seb128> kklimonda, where is it? it's not on http://reports.qa.ubuntu.com/reports/sponsoring/index.html
[16:42] <seb128> kklimonda, sorry if things don't get on the sponsoring queue it's hard to keep track :-(
[16:42] <kklimonda> seb128: I've thought you were doing it through the debian?
[16:42] <seb128> well having a bug with the url and the sponsors subscribed would be useful
[16:42] <seb128> would it only be for comments
[16:43] <kklimonda> seb128: last time I've subscribed ubuntu-sponsors to the bug 672817 they were unsubscribed :/
[16:43] <ubot2> Launchpad bug 672817 in ubuntu "[needs-packaging] atkmm1.6 (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/672817
[16:43] <seb128> oh right you told me the other day
[16:43] <seb128> I will do that today
[16:43] <seb128> sorry for the delay
[16:43] <kklimonda> no problem, it's not like I don't have anything else to do :)
[16:51] <rodrigo_> hmm, dh_girepository -pgir.... gives me: Could not find gir file for Couchdb-1.0.typelib
[16:51] <rodrigo_> and using -I doesn't seem to fix it
[16:51] <seb128> rodrigo_, yeah, I'm having the issue with gnome-bt now, investigating why
[16:51] <rodrigo_> ah, ok
[16:51] <seb128> you ship the .gir in a binary right?
[16:51] <rodrigo_> no
[16:51] <seb128> that's why I guess
[16:52] <rodrigo_> I see gir-gtk doesn't neither
[16:52] <seb128> it does
[16:52] <seb128> the .gir are in libname-dev binaries
[16:53] <rodrigo_> ah
[16:56] <rodrigo_> right, that works
[16:56] <seb128> great
[16:58] <seb128> rodrigo_, the typelib are arch specific right?
[16:58] <rodrigo_> seb128, I think so
[16:58] <rodrigo_> seb128, ok, fixes pushed to https://code.launchpad.net/~rodrigo-moya/ubuntu/natty/couchdb-glib/0_7_0_release/+merge/41752
[16:58] <seb128> rodrigo_, ok, you defined the gnome-bt gir as arch all
[16:59] <seb128> that's why it was failing to build there
[16:59] <rodrigo_> hmm
[16:59] <rodrigo_> ah, ok
[16:59] <seb128> I've set it to arch any now and it works
[16:59] <rodrigo_> right, I guess a copy paste problem
[16:59] <seb128> rodrigo_, ok, merging the couchdb diff now
[17:00] <rodrigo_> seb128, so, can I upload it again then?
[17:01] <seb128> yes
[17:01] <seb128> rodrigo_, btw your binaries naming is buggy
[17:01] <rodrigo_> ok
[17:01] <rodrigo_> oh, in couchdb-glib?
[17:01] <seb128> yes
[17:01] <rodrigo_> I'll fix them then before uploading
[17:01] <seb128> the policy says it should be gir<version>-<typelibname>-<version>
[17:01] <rodrigo_> which one is wrong?
[17:02] <seb128> well you added -glib to the binaries
[17:02] <seb128> but the typelib doesn't have a -glib
[17:02] <seb128> gir1.0-couchdb-glib-1.0
[17:02] <rodrigo_> oh
[17:02] <seb128> should be gir1.0-couchdb-1.0
[17:02] <seb128> same for the other one
[17:02] <rodrigo_> ok, changing it
[17:02] <rodrigo_> don't merge the branch yet then :)
[17:02] <seb128> ok
[17:02] <seb128> do you have anything using those?
[17:03] <seb128> (seems not)
[17:03] <rodrigo_> no, afaik
[17:03] <seb128> in any case you want to Conflicts,Replaces,Provides the old name
[17:03] <seb128> Binary: gir1.0-couchdb-1.0
[17:03] <seb128> Conflicts: gir1.0-couchdb-glib-1.0
[17:03] <seb128> Replaces: gir1.0-couchdb-glib-1.0
[17:03] <seb128> etc
[17:03] <rodrigo_> yes
[17:08] <seb128> rodrigo_, ./usr/lib/gnome-bluetooth/libgnome-bluetooth-applet.so
[17:08] <seb128> do you know what this is is for exactly?
[17:09] <seb128> rodrigo_, it should probably not be in the libgnome-bluetooth8 deb
[17:09] <seb128> not sure if it should be in gnome-bt or in a new binary
[17:09] <rodrigo_> let me check, it's a lib for the applet, I think
[17:10] <sense> Evolution in Natty has some GTKHtml problems.
[17:13] <bratsche> didrocks: I think I have the packaging issue sorted out now.
[17:13] <didrocks> bratsche: oh nice! not sure I would have the time TBH :)
[17:14] <rodrigo_> afaics, it's just used by the panel applet, so I guess it's for some gnome-shell stuff, since it has a typelib
[17:14] <rodrigo_> seb128, ^^
[17:14] <rodrigo_> seb128, I'll ask bastien
[17:15] <seb128> rodrigo_, thanks
[17:15] <seb128> rodrigo_, I'm inclined to put it in the gnome-bt binary for now
[17:15] <seb128> we can create a new binary later if required
[17:15] <rodrigo_> seb128, in the meanwhile fixed the naming: https://code.launchpad.net/~rodrigo-moya/ubuntu/natty/couchdb-glib/0_7_0_release/+merge/41752
[17:15] <bratsche> didrocks: It turns out I was just missing some other files in my packaging branch and it was solved by running autoreconf -vfi and bzr adding those files.
[17:15] <rodrigo_> seb128, yes, probably, I just added it to lib... package because of the typelib
[17:16] <didrocks> bratsche: oh ok, nice you got it!
[17:16] <bratsche> Yeah
[17:25] <seb128> rodrigo_, you can upload couchfb-glib, I'm merging it
[17:25] <rodrigo_> seb128, ok, thanks
[17:36] <kenvandine> that crazy tar problem with dbusmenu and pbuilder... it has something to do with the tar getting created with make distcheck
[17:37] <kenvandine> someday i am going to really spend the time to figure out wtf is up with that
[17:37] <rodrigo_> oh, still no evolution update
[17:37] <kenvandine> if i extract the tarball, and create a new one it is like half the size
[17:39] <kenvandine> seb128, just gotta confirm pbuilder can build dbusmenu then i'll be ready to get you to look it over and tell me what i did wrong :)
[17:40] <seb128> kenvandine, ok ;-)
[17:40] <rodrigo_> kenvandine, btw, was going to update libu1, and got the ~ubuntu-desktop branch, but it's very outdated, so should it be removed?
[17:40] <kenvandine> getting multiple builds write is a pain
[17:41] <kenvandine> rodrigo_, yeah
[17:41] <seb128> indeed
[17:41] <kenvandine> s/write/right
[17:41] <rodrigo_> kenvandine, can you do it please?
[17:41] <kenvandine> sure
[17:41] <rodrigo_> thanks!
[17:41] <kenvandine> ordering is very weird...
[17:52] <seb128> rodrigo_, ok, gnome-bt cleaning commited
[17:52] <seb128> rodrigo_, we need to reactivate the indicator patch before upload though
[17:52] <seb128> hum, or not
[17:52] <seb128> rodrigo_, I guess we will need libappindicator on gtk3 for that
[17:53] <seb128> which kenvandine is working on
[17:53] <kenvandine> yeah
[17:53] <kenvandine> i hope today :)
[17:55] <kenvandine> ugh... evolution appears to have been removed
[17:55]  * kenvandine must have missed that in the dist-upgrade today
[17:58] <rodrigo_> seb128, yes, was waiting for that, is anyone working on it?
[17:58] <rodrigo_> ah, kenvandine
[18:00] <bcurtiswx> rodrigo_, where did the gnome-appearance-properties disappear to with Gnome 3 from desktop PPA ?
[18:00] <seb128> bcurtiswx, what part of it?
[18:00] <rodrigo_> bcurtiswx, yes, it's gone
[18:01] <seb128> you have a background utility now
[18:01] <bcurtiswx> i kinda missed the default gnome fallback.. :)
[18:01] <rodrigo_> yes, but for themes, etc, there will be gnome-plumbing
[18:01] <rodrigo_> a sort of tweakui tool
[18:01] <bcurtiswx> the background utility keeps crashing
[18:03] <rodrigo_> bcurtiswx, can you report a bug then, please?
[18:03] <rodrigo_> with a backtrace if possible
[18:03] <seb128> slomo, hello
[18:03] <seb128> slomo, could you get http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=603041 in the next upload you do?
[18:03] <ubot2> Debian bug 603041 in gstreamer0.10-plugins-base-apps "gst-visualize-m.m imports File::Basename which creates unnecessary perl dependency" [Minor,Open]
[18:03] <seb128> slomo, it's the only diff we have in ubuntu, so we could sync again
[18:04] <bcurtiswx> rodrigo_, whats the command line to the background GUI ?\
[18:04] <rodrigo_> bcurtiswx, there isn't, it's loaded as a plugin
[18:04] <rodrigo_> bcurtiswx, so, run gnome-control-center on gdb
[18:08] <slomo> seb128: sure, it's upstream too already
[18:08] <seb128> slomo, ok thanks
[18:26] <ari-tczew> baptistemm: around?
[18:36] <pitti> good night everyone
[18:37] <didrocks> good night pitti
[18:38] <baptistemm> ari-tczew: yeah, but not for long
[18:38] <ari-tczew> baptistemm: could you update your branch to merge bluez 4.70 from Debian unstable?
[18:43] <baptistemm> ari-tczew: Which branch? I didn't touch any packaging for months
[18:44] <ari-tczew> baptistemm: http://bazaar.launchpad.net/~bmillemathias/ubuntu/maverick/bluez/main/annotate/head%3A/debian/changelog
[18:44] <ari-tczew> now I'm trying to reproduce a debdiff debian -> ubuntu to get -1ubuntu1
[18:46] <baptistemm> debian has only 4.70? upsyream is 4.80
[18:50] <ari-tczew> baptistemm: yes, but till Debian doesn't have 4.79 (as PTS shows) / 4.80, we can figure out delta between Debian and Ubuntu, then request to Debian upgrade
[19:00] <didrocks> ok, will work a little bit offline, see you!
[19:02] <baptistemm> ari-tczew: To be hinnest I don't have free time for that, I could find some time this week-end, but this is not garanteed
[19:03] <ari-tczew> baptistemm: okok
[19:08] <kenvandine> seb128, whenever you have a chance, look at lp:~ubuntu-desktop/dbusmenu/ubuntu
[19:08] <kenvandine> not sure if it is ready
[19:08] <kenvandine> still waiting for it to build in a ppa
[19:08] <kenvandine> i forgot that dbusmenu never builds for me in pbuilder, but it does on the buildd
[19:09] <kenvandine> seb128, i had also forgotten i had needed to get gdk-pixbuf sponsored too... but i got that uploaded too
[19:09] <kenvandine> so you won't be able to build it until you get that
[19:10] <kenvandine> seb128, just look it over when you can and let me know if there is anything obvious i should fix
[19:37] <ari-tczew> seb128: don't you mind if I'll take merge libproxy?
[19:37] <seb128> kenvandine, urg, what did you do with libdbusmenu?
[19:37] <kenvandine> huh?
[19:37] <seb128> kenvandine, joking ;-) I will review it
[19:37] <kenvandine> haha!
[19:37] <seb128> just back from dinner
[19:38] <kenvandine> you got me
[19:38] <seb128> ;-)
[19:38] <seb128> ari-tczew, you can do it, I don't think anybody is working on it
[19:38] <ari-tczew> thanks seb128
[19:49] <Sarvatt> would anyone be willing to review/sponsor an x11-session-utils merge to fix the ftbs on natty by any chance? http://sarvatt.com/downloads/merges/x11-session-utils
[19:49] <seb128> Sarvatt, ok
[19:49] <kenvandine> seb128, ok dbusmenu did build in the ppa :)
[19:50] <Sarvatt> seb128: thank you thank you thank you :) build log and the patch that was added is in there
[19:52] <seb128> Sarvatt, done
[19:52] <seb128> kenvandine, great, one down, 2 to go? ;-)
[19:52] <Sarvatt> \o/ thanks again!
[19:52] <seb128> (libindicator, libappindicator)
[19:52] <seb128> Sarvatt, you're welcome!
[19:52] <kenvandine> yeah, working on it already
[19:52] <kenvandine> seb128, i still need to test the upgrade path on dbusmenu
[19:52] <kenvandine> waiting for debs to publish
[20:02] <seb128> kenvandine, we don't use the canonical vcs for libdbusmenu?
[20:03] <kenvandine> i think we do, i need to remove the Vcs line
[20:03] <kenvandine> that might have been added back from ted's branch again
[20:03] <seb128> no we don't
[20:03] <kenvandine> one of those things that bzr fights over
[20:04] <kenvandine> ok, that must be a different package
[20:04] <seb128> I've checkout libdbusmenu today to fix a build-depends
[20:04] <kenvandine> we should, since all the sources are imported
[20:04] <seb128> but it seems I don't get the same checkout with the ubuntu-desktop vcs now
[20:04] <seb128> can you see if james_w can fix that for us?
[20:04] <kenvandine> yeah
[20:04] <seb128> thanks
[20:04] <seb128> starting to review your update
[20:04] <kenvandine> we just need to get the branch linked right?
[20:05] <seb128> we want the ubuntu-desktop version to become the canonical one
[20:05] <kenvandine> right, linked to lp:ubuntu/dbusmenu
[20:05] <kenvandine> right?
[20:05] <seb128> libdbusmenu
[20:05] <seb128> it's the source name
[20:05] <seb128> don't ask why the source and project have different names
[20:05] <kenvandine> yeah
[20:05] <kenvandine> legacy...
[20:06] <seb128> ok so my fix was to drop to build-depends on
[20:06] <seb128>  gir-repository-decv
[20:06] <seb128> -c
[20:07] <kenvandine> ah, yeah that isn't needed anymore
[20:07]  * kenvandine removes it
[20:08] <seb128> kenvandine, gir1.0-dbusmenu-gtk3-0.2
[20:08] <seb128> you should depends on gir:Depends
[20:08] <seb128> and call dh_girepository in rules
[20:08] <seb128> rather than listing the depends manually
[20:08] <seb128> binary-preinst/gir1.0-dbusmenu-gtk3-0.2::
[20:09] <seb128>     dh_girepository -pgir1.0-dbusmenu-gtk3-0.2
[20:09] <seb128> kenvandine, would be nice to use .symbols for the libs
[20:11] <seb128> kenvandine, it seems you have the rules snippet in fact
[20:12] <kenvandine> ok
[20:13] <ari-tczew> does anybody know what is the reason of this ftbfs? src/io/ChannelListWriter.vala:88.36-88.41: error: Argument 1: Cannot convert from `string?' to `uint8[]'
[20:13] <kenvandine> we should work on convincing tedg on the .symbols
[20:13] <seb128> kenvandine, ?
[20:13] <seb128> it's an ubuntu thing, not an upstream one
[20:13] <seb128> he will just merge back what we do ;-)
[20:13] <kenvandine> yeah, but he maintains the package for their ppa
[20:13] <seb128> he will merge back I'm sure
[20:13] <kenvandine> somehow his changes keep coming back to haunt us
[20:14] <seb128> kenvandine, the rules seems weird to me
[20:14] <kenvandine> it took lots of trial and error to get that working at all
[20:16] <kenvandine> i want to figure out why bzr doesn't like to preserve the delta between our package and ted's
[20:16] <seb128> talk to james_w
[20:16] <kenvandine> ok
[20:16] <seb128> he probably knows better than us ;-)
[20:16] <kenvandine> :)
[20:16] <kenvandine> it is really frustrating...
[20:16] <seb128> kenvandine, I'm testbuilding since I don't understand the rules
[20:17] <seb128> the cdbs multi builds are weird
[20:17] <kenvandine> they are
[20:17] <seb128> well it's weird to have a gtk3 target without gtk2 one
[20:17] <seb128> but I guess the gtk2 one is the standard cdbs build
[20:17] <kenvandine> and you need to get the target depends just right so the sequence is right
[20:17] <kenvandine> yes
[20:18] <kenvandine> soname versions and all look sane?
[20:18] <kenvandine> package names?
[20:18] <seb128> yeah, that's makefiles for you ;-)
[20:18] <seb128> kenvandine, I will tell you after build since those depends of the files on disk
[20:18] <seb128> but from a first glance yes
[20:18] <kenvandine> libdbusmenu-gtk3-2 and libdbusmenu-gtk2 is weird
[20:18] <seb128> I need to apt-get update and upgrade my gdk-pixbuf though
[20:19] <kenvandine> but it is correct, as far the actually libs that get built go
[20:19] <seb128> right
[20:19] <kenvandine> but i can see where people might get confused if they ever try to figure out which lib is which :)
[20:19] <kenvandine> more confusing because gtk2 and gtk3 happens to be in the names
[20:19] <kenvandine> :)
[20:19] <kenvandine> i also didn't build docs for gtk3
[20:19] <seb128> I saw
[20:19] <kenvandine> since it would be redundant
[20:20] <seb128> I'm wondering why we build those at all
[20:20] <kenvandine> make sense?
[20:20] <kenvandine> devhelp :)
[20:20] <seb128> usually upstream ship the .html in the tarball
[20:20] <seb128> and the packaging doesn't build them
[20:20] <kenvandine> ah
[20:20] <seb128> since there is no reason a rebuild would be different from what upstream ships
[20:20] <kenvandine> DX isn't the typical upstream, i guess
[20:20] <seb128> it just cost build time
[20:20] <seb128> well my typical upstream is GNOME
[20:20] <seb128> which might be a standard one either ;-)
[20:21] <seb128> kenvandine, no ted today?
[20:21] <seb128> kenvandine, btw are you off starting tonight for the weekend?
[20:21] <seb128> I'm not sure when thanksgiving is etc
[20:21] <kenvandine> apparently not
[20:21] <kenvandine> DEB_DH_MAKESHLIBS_ARGS_libindicator0 += -V 'libindicator1 (>= 0.3.14)'
[20:22] <kenvandine> yes
[20:22] <seb128> I just know it's this week
[20:22] <kenvandine> tomorrow is thanksgiving, and i am taking vacation on friday
[20:22] <seb128> ok, makes sense
[20:22] <kenvandine> US is typical thurs and friday
[20:22] <kenvandine> but bank holiday is just thursday
[20:22] <seb128> we should probably land all those gtk3 next week or after alpha1 then
[20:22] <seb128> /usr/bin/vapigen --library=Dbusmenu-Glib-0.2 Dbusmenu-Glib-0.2.gir
[20:22] <seb128> error: The type name `gint' could not be found
[20:22] <seb128> error: The type name `gpointer' could not be found
[20:22] <seb128> kenvandine, it fails to build there
[20:23] <seb128> Generation failed: 57 error(s), 0 warning(s)
[20:23] <kenvandine> humm
[20:23] <kenvandine> do you have anything "weird" gir related?
[20:24] <seb128> in the build log? or installed?
[20:24] <kenvandine> installed
[20:24] <seb128> I'm on stock natty
[20:24] <kenvandine> built in the ppa
[20:24] <seb128> with maybe some upgrades missing
[20:24] <seb128>   gir1.0-freedesktop gir1.0-gdkpixbuf-2.0 gir1.0-glib-2.0 gir1.0-nautilus-2.0
[20:24] <kenvandine> make sure you have the latest gtk2 and gtk3
[20:24] <seb128> have pending updates
[20:24] <seb128> let me update them
[20:24] <kenvandine> and gobject-introspection
[20:24] <kenvandine> yeah
[20:25] <kenvandine> gir1.0-glib-2.0 is th culprit there
[20:25] <kenvandine> that was fixed
[20:25] <kenvandine> and you need gir1.0-gdkpixbuf-2.0
[20:25] <seb128> so your build-depends is not strict enough
[20:25] <kenvandine> i guess
[20:25] <kenvandine> i'll fix it for gobject-introspection
[20:26] <seb128> it was not those
[20:26] <kenvandine> humm
[20:26] <kenvandine> how about gobject-introspection?
[20:26] <seb128> gobject-introspection (0.9.12+git20101124-0ubuntu1) ...
[20:27] <seb128> it got updated with the gir1.0-glib-2.0
[20:27] <seb128> it's the snapshot pitti did today
[20:28] <kenvandine> shouldn't be that then
[20:28] <kenvandine> and libgirepository1.0-dev?
[20:29] <seb128> uptodate as well
[20:29] <seb128> did you update today?
[20:31] <seb128> kenvandine, I don't see anything in the pending updates that should have an impact on that
[20:31] <seb128> no gir, no gobject, no glib or gkt
[20:31] <kenvandine> weird
[20:31] <seb128> gtk
[20:31] <kenvandine> weird
[20:31] <kenvandine> it built in the ppa for natty though
[20:32] <kenvandine> https://edge.launchpad.net/~ken-vandine/+archive/ppa/+sourcepub/1374384/+listing-archive-extra
[20:40] <seb128> kenvandine, weird, I'm a bit puzzled
[20:40] <kenvandine> me too
[20:40] <kenvandine> although i also can't explain why dbusmenu won't build in pbuilder but it does on a buildd
[20:41] <kenvandine> been like that for ages now
[20:41] <seb128>             <type name="gint" c:type="gint"/>
[20:41] <seb128> do you have lines like that in the gir?
[20:41] <kenvandine> in Dbusmenu-Glib-0.2.gir?
[20:41] <seb128> yes
[20:41] <seb128> b$ vapigen --version
[20:41] <seb128> Vala API Generator 0.10.0
[20:42] <seb128> I guess that's the issue
[20:42] <kenvandine> ah!
[20:42] <kenvandine> yeah
[20:42]  * kenvandine bumps that
[20:42] <kenvandine> i'll specify valac-0.12
[20:43] <seb128> ok, works now
[20:43] <seb128> well I have both installed
[20:43] <seb128> the alternative was just set on 0.0
[20:43] <seb128> 0.10
[20:43] <kenvandine> ok
[20:43] <seb128> we should probably rank the new version higher
[20:43] <seb128> it works now ;-)
[20:44] <seb128> restarting a build
[20:46] <seb128> dpkg-source: error: gunzip gave error exit status 1
[20:46] <seb128> weird
[20:46] <seb128> that's at the lintian time
[20:48] <seb128> kenvandine, seems fine to me
[20:49] <seb128> kenvandine, do you want to get that in or should we get the stack transitioned at once rather?
[20:49] <kenvandine> i can get it in, let me test it first
[20:49] <kenvandine> see if i can find any breakage
[20:50] <seb128> kenvandine, with some luck the next ones will be easier ;-)
[20:50] <kenvandine> :)
[20:50] <kenvandine> well libindicator will be
[20:50] <kenvandine> only problem seems to be top_srcdir vs top_builddir related
[20:50] <kenvandine> almost done
[20:51] <Chipaca> any idea why gnome-open is ignoring what's set in 'preferred applications'?
[20:51] <Chipaca> (in natty)
[20:52] <dobey> Chipaca: you mean it's starting chrome instead of firefox?
[20:52] <dobey> Chipaca: the way that url handlers is done in gnome changed
[20:52] <Chipaca> it's starting firefox 4 instead of chromium
[20:52] <seb128> Chipaca, because the way handlers work is transitionning to a new system and that didn't get updated yet
[20:53] <Chipaca> anything i can poke at to make it work in the interregnum?
[20:56] <seb128> Chipaca,
[20:56] <seb128> you can change the defaults.list
[20:56] <seb128> in /usr/share/applications
[20:56] <seb128> or in .local
[20:57] <seb128> x-scheme-handler/http=firefox.desktop
[20:57] <seb128> set what you use instead
[20:57] <seb128> you will need to run update-mime-database then
[21:01] <Chipaca> how is this different from the existing mimetypes database we've had for ages, btw?
[21:02] <seb128> Chipaca, the url handlers where in gconf
[21:02] <seb128> now they use the same system than mimetypes
[21:03] <Chipaca> seb128: right... but before gnome and kde, way back when fvwm was cool, we had the mimetypes database all figured out :-/
[21:04] <Chipaca> it wasn't particularly nice to edit, but netscape 3/4 used that
[21:05] <Chipaca> and in debian (2.0) the level of integration it afforded was awesome
[21:05] <Chipaca> maybe i'm just being silly and nostalgic :)
[21:13] <Chipaca> seb128: changed firefox to chromium-browser in /etc/gnome/defaults.list, /usr/share/applications/defaults.list and /usr/share/gnome/applications/defaults.list, ran update-mime-database /usr/share/mime, and still getting firefox instead of chrome. What am I missing?
[21:17] <seb128> Chipaca, the 3 files you list are the same on ubuntu
[21:17] <seb128> dunno, it worked for dobey
[21:18] <Chipaca> maybe I need to restart my session?
[21:19] <seb128> you should not
[21:19] <dobey> Chipaca: you are actually getting firefox to start?
[21:20] <dobey> Chipaca: copy the chromium desktop file to ~/.local/share/applications and then update-desktop-database ~/.local/share/applications
[21:20] <Chipaca> dobey: I am getting firefox 4, and I want chromium
[21:21] <dobey> Chipaca: i had the exact opposite experience. but now that i've used firefox 4, i don't want it, or chrome, or epiphany. :(
[21:22]  * dobey wonders if mosaic will still run on narwhal
[21:23] <Chipaca> dobey: nope, needs libc5 x11 libs
[21:23] <dobey> seb128: since you're still here; do you know what rule i would use in debian/rules to be able to generate a .substvars for ALL the packages in debian/control?
[21:28]  * dobey downloads navigator 3.04 GOLD.
[21:57] <jasoncwarner> RAOF: TheMuso: robert_ancell: reminder meeting time in a few minutes. https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-23
[21:58] <seb128> oh right, it's today for you guys
[21:59] <seb128> I read the irc logs twice this morning searching for the eastern edition logs
[21:59] <seb128> I wondered if you just didn't have a meeting this week
[21:59] <seb128> it's confusing to have a day difference ;-)
[21:59] <Nafallo> seb128: you should fix that! :-)
[22:00] <seb128> Nafallo, not my business ;-)
[22:00] <Nafallo> seb128: you're the one annoyed about it :-P
[22:00] <seb128> I would not say annoyed, I just wanted to see if they did follow on conversations we had in the western edition
[22:00] <seb128> so a bit surprised
[22:00] <seb128> but now it makes sense
[22:01] <seb128> I was not in an hurry, I will read what they say today ;-)
[22:01] <seb128> I might even do comments still I'm still online today :p
[22:01] <seb128> but first small break
[22:01] <seb128> brb
[22:09]  * TheMuso reads through the meeting notes.
[22:12] <JanC> dobey: http://bit.ly/hxb8qH --> Mosaic 1.0 works fine under Wine at least...  ;)
[22:12] <dobey> JanC: as fine as looking at like all 3 web pages that still work on it, anyway
[22:13] <dobey> netscape 3.04 gold works under wine too
[22:13] <dobey> but the javascripts are murder upon it
[22:13] <JanC> dobey: it also doesn't support HTTP 1.1 I think, so no virtual domains...  ;)
[22:13] <dobey> well netscape 3 does
[22:14] <dobey> but it doesn't have any useful CA certs either
[22:14] <dobey> so it won't even let me try to open launchpad.net
[22:14] <dobey> it also doesn't do utf-8 very well
[22:19] <RAOF> Ok. People seemed to have resolved the "better activity reports" discussion, but I can't quite see *what* was resolved :)
[22:24] <robert_ancell> RAOF, I think the resolution was to keep discussing it :)
[22:25] <RAOF> :)
[22:26] <robert_ancell> seb128, One of the points I was also trying to make is to break the per-person reports and make a single team report.  That makes it harder to collate separate blog entries into one cohesive element. You can still have attribution with a tag like in the work items.
[22:27] <seb128> robert_ancell, hi!
[22:27] <robert_ancell> seb128, hello
[22:28] <robert_ancell> jasoncwarner, meeting action - move meeting to Wednesday?
[22:28] <jasoncwarner> yes
[22:28] <jasoncwarner> thank you!
[22:28] <robert_ancell> (move eastern edition)
[22:28] <seb128> how is a single report make from individual people items different from the same items sorted by people?
[22:28] <jasoncwarner> was just going to ask that
[22:29] <robert_ancell> seb128, I think that makes it harder to read.  As we get more and more people the reports get more fragmented and it means a contribution from a community member doesn't really "fit in".
[22:29]  * jasoncwarner  wish me luck...going to work with google calendar
[22:29] <seb128> hum
[22:30] <robert_ancell> seb128, a single list ordered from highest priority to lowest means you immediately know what's important and you can choose how far to read down it
[22:30] <seb128> robert_ancell, so you think that 90 items listed are easier to read that 9 blocks which each have 10 items?
[22:30] <robert_ancell> seb128, yes, because in one minute you know the most important ones (say the first 10), and you can skip the lower 30 if you don't need to know so much detail
[22:30] <seb128> well if you list my summary after meeting I suggested we focus on writting something easy to read
[22:31] <seb128> then we should have someone picking the highlights and do a shorter summary
[22:31] <seb128> well what you say imply that people rank their items dynamically
[22:31] <robert_ancell> right, you suggested writing separate posts and collating them,  pitti said that was quite some overhead
[22:32] <seb128> I think we should first improve what you write
[22:32] <seb128> then we can see what we can do from it
[22:32] <robert_ancell> I'm suggesting we have one list (e.g. in etherpad/wiki) where people insert their items where they think the priority is.  Then someone (e.g. jasoncwarner) tidies up that list and potentially drops the least important ones (or puts them into an appendix)
[22:32] <seb128> but I think if the content is nice it should be easy for someone to pick and do a blog post
[22:32] <robert_ancell> agreed
[22:34] <seb128> robert_ancell, it seems people were resistant to have a dynamic list
[22:34] <robert_ancell> seb128, what do you think about proposing we try what I suggested there for next meeting and then assess it?
[22:34] <seb128> or at least pitti seemed to think that a weekly summary is enough
[22:35] <robert_ancell> seb128, so, it is a weekly summary, and you could add all your items the day before the meeting (as we do currently).  But it would be possible to update it duing the week
[22:36] <seb128> not sure, I'm happy to try a format if you suggest one
[22:36] <seb128> I hate the wiki enough that's I'm pretty sure I will not edit it as dynamically I would edit something else
[22:36] <seb128> like commiting a change to the wiki often spin for a minute there
[22:36] <robert_ancell> as I read it pitti seemed rightly worried about making a process that required one person producing a summary (e.g. meeting notes)
[22:37] <seb128> I would do one lines commits like I do on a whiteboard
[22:37] <seb128> wouldn't
[22:37] <robert_ancell> seb128, right, and the exact technology we choose is not important, so if the wiki has performance issues we should use etherpad (as long as it's not limiting as TheMuso said)
[22:38] <TheMuso> As was pointed out, I can get a plain text export.
[22:38] <seb128> we should go back to what you want to solve
[22:38] <seb128> I'm not sure if there was one or several things you wanted out of that
[22:39] <seb128> do you want only a way to have better weekly summaries?
[22:39] <seb128> something we can interest people about?
[22:39] <robert_ancell> ok, I'll propose the experiment, and hopefully the result will look more useful.  I'll manually add some of the thing that should be automatable.
[22:39] <seb128> or do you want to solve also a cross timezones and contribution enterance level issue
[22:40] <seb128> like the fact that we discuss lot of what we do in european,us IRC hours
[22:40] <robert_ancell> that was my main point.  I was also talking about the eastern edition meeting, but that discussion was more meant for the people who attend that meeting
[22:40] <seb128> which cuts people not on IRC or not on IRC at the right time from jumping in
[22:40] <seb128> because I feel like people agree on better notes to solve the first issue
[22:40] <robert_ancell> I personally think that's unavoidable, and the current system is getting the best we can
[22:40] <seb128> but we didn't really address the second one
[22:41] <seb128> one way to respond to the second one is to use the list for discussions when we can
[22:42] <seb128> IRC is nice but having all the discussions there tend to get people distracted and not able to focus and cut other people not on IRC at this time out as well
[22:42] <robert_ancell> ok, reading the email I sent - I'm not proposing any particular changes to the format.  I did try and document the purpose of the meetings, as it might not be obvious to outside people how the meetings work.  I think others were interested in changing the meeting format, and I'll leave it to them to propose ideas.
[22:43] <robert_ancell> (meeting format, and other methods we can use)
[22:43] <seb128> I didn't see anybody suggesting to change the format
[22:43] <seb128> out of you last week suggesting that wikipedia page with the 15 minutes a day format
[22:43] <robert_ancell> yes, that was a suggestion for the eastern edition only.
[22:44] <seb128> ok
[22:44] <seb128> so I don't think we get a lot out of this
[22:44] <seb128> we did agree to improve the format of what we have for writters though
[22:44] <robert_ancell> and the feedback seemed to be "not necessary" on that one.
[22:45] <seb128> we didn't agree on whether we should make it directly nice to read or if someone should do a better summary from some highlights once a week
[22:45] <seb128> writters->readers
[22:46] <seb128> robert_ancell, do you want to suggest the format you think is right and have the team try for a week?
[22:46] <seb128> so we can see what works or not for people
[22:46] <robert_ancell> yes, I think that will be easiest
[22:46] <seb128> ok, let's do that
[22:46] <seb128> so you think we should try to advertise that out of the wiki
[22:47] <seb128> I've the feeling not many people will come read a wiki
[22:47] <seb128> compared to having a blog once a week
[22:47] <robert_ancell> advertise = publish?
[22:47] <seb128> yes
[22:47] <seb128> blog posts or similar
[22:47] <seb128> email on the list
[22:47] <robert_ancell> so yes, the official summary should be on the wiki, but it should be concise enough to copy and paste it into an email/blogpost
[22:47] <seb128> I don't want to add that as a task
[22:48] <seb128> we have enough sponsoring, review, etc duties already
[22:48] <seb128> and enough difficulties to get people to work on those
[22:48] <robert_ancell> I would suggest we post it on the wiki and email it every week, and people may choose to blog it if they wish
[22:48] <seb128> if the wiki summary is nice and easy to read it might encourage some community member to pick and publish it
[22:48] <robert_ancell> exactly
[22:49] <seb128> ok
[22:49] <seb128> so that's one thing
[22:49] <robert_ancell> what I'm proposing shouldn't take any more effort than the current system, and if it does we should not do it
[22:49] <seb128> do you think we need to figure something for inter team and contributors detailled status?
[22:49] <seb128> like what you did today and are blocked on and which could use extra eyes
[22:50] <robert_ancell> I'm not sure what you mean by "inter team and contributors detailled status"
[22:51] <seb128> well like a place when we have a note that your totem update is blocked on a crash
[22:51] <seb128> or the rb one on a python issue
[22:51] <robert_ancell> you should just add that to the same list
[22:51] <seb128> or kenvandine's libdbusmenu gtk3 update is hitting vala issues
[22:52] <robert_ancell> I'll put some examples into the email as to what to add and where
[22:52] <robert_ancell> jasoncwarner, are you ok with this?
[22:52] <seb128> or let's try for a week
[22:53] <seb128> I've the feeling it's not going to work great
[22:53] <seb128> but let's see
[22:53] <robert_ancell> that's ok, it's worth a go
[22:53] <seb128> yeah, no discussion
[22:53] <seb128> I think we can do better to be interesting to read without doubt
[22:54] <robert_ancell> I figure I'll do the summarising this week with jasoncwarner and we can assess how much work it is, and if it should be one person or cycle around
[22:54] <seb128> the not so easy part is to have people being doing dynamic editing
[22:54] <robert_ancell> "no discussion"?
[22:54] <seb128> rather than dumping once a week
[22:54] <seb128> "no discussion", "without doubt"
[22:55] <seb128> or "yeah, it's worth a go for sure"
[22:55] <seb128> ;-)
[22:55] <robert_ancell> ah, must be a French translations?
[22:55] <seb128> yes
[22:55] <seb128> we say "nothing to discuss, it's clear it makes sense"
[22:55] <seb128> -> "no discussion needed"
[22:55] <robert_ancell> I don't see the issue with the dynamic editing, but hopefully we'll see by next week
[22:55] <seb128> for me it's the wiki :p
[22:56] <robert_ancell> well that's just technology, we can change that any time
[22:56] <seb128> it would be an etherpad or gtg or tomboy that would be easier
[22:56] <seb128> but maybe that's just me hating wikis
[22:56] <seb128> let's see how it goes
[22:56] <seb128> and what people find annoying
[22:57] <seb128> we can change the support later on if we have better
[22:57] <seb128> or if we feel the wiki is an issue
[22:57] <robert_ancell> jasoncwarner, yay, the meeting change worked!
[22:57] <seb128> ;-)
[22:58] <jasoncwarner> robert_ancell: it's worth a go ;) I was more interested in finding a way to communicate across timezones that people were stuck or needed some help or to announce something. I personally thought status.net would be perfect for that (for as much as I hate twitter and that style of communication, it is effective for somethings)
[22:58] <robert_ancell> oh, I meant the google calendar entry.
[22:58] <seb128> including dst time? ;-)
[22:58] <jasoncwarner> robert_ancell: well, I did a delete/add!
[22:58] <jasoncwarner> I couldn't change the meeting to be the right time/day and still repeat
[22:58] <jasoncwarner> ugh
[22:59] <robert_ancell> jasoncwarner, ok, I'll leave that one to you!
[22:59] <seb128> jasoncwarner, well it seems robert_ancell think those points could just go on the standard activity report
[22:59] <seb128> we can see if that's the case in practice
[23:00] <robert_ancell> yes.  I don't see the need for the knowing them within minutes rather than days but I'm open to trying that if people think it's useful
[23:00] <jasoncwarner> i'm cool with whatever works best for you guys in this, because in effect, this is your information that needs to be shared. :) we should experiment away
[23:00] <seb128> well it's rather than weekly highlights might not fit with detailed technical blockers
[23:01] <jasoncwarner> seb128: yeah, probably two different problems trying to be solved
[23:01] <seb128> one goal is to move away from a dump of technical details to things interesting to read
[23:01] <seb128> I've the feeling not a lot of people are interested that $source doesn't build with --as-needed
[23:03] <seb128> but you could want to note somewhere that you have no clue about gcc and would welcome help on it
[23:03] <seb128> well maybe sorting items on the wiki solves that
[23:06] <robert_ancell> would I be out of line suggesting we try it without traditional stuff like present/absent/apologies - this information is in the irc logs
[23:07] <seb128> you mean? moving that section out of the wiki?
[23:08] <seb128> I don't see any value having it there is the meeting leader knows about people on holidays, etc
[23:08] <seb128> but I guess it's a question for jasoncwarner ;-)
[23:09] <jasoncwarner> robert_ancell: feel free to suggest any format ;)
[23:09] <jasoncwarner> no worries...we can talk about it after.
[23:10] <rickspencer3> I think that's also so that community people reading it later know what who was there, and who wasn't, etc...
[23:12] <seb128> well that informations is in the IRC log
[23:12] <robert_ancell> ok, I'm going to get radical and keep it ultra simple and we can discuss if it's too far at the next meeting
[23:13] <rickspencer3> seb128, sort of
[23:13] <rickspencer3> i don't really care much, just a reminder that we have an important value to be transparent
[23:13] <seb128> rickspencer3, well if it's important we should start the meeting by stating who is there
[23:14] <seb128> and who is not
[23:14] <rickspencer3> of course, part of transperancy is to focus on important information in a digestable format
[23:14] <rickspencer3> seb128, that doesn't say who couldn't be there, but was expected
[23:14] <seb128> we can have those informations at the bottom of the summary rather than at the start at least
[23:14] <rickspencer3> again, I don't much care, just a reminder about that there are audiences and purposes
[23:14] <seb128> they are probably less important that the content
[23:15] <rickspencer3> seb128, right, or you could determine that it's a distraction and detracts from your communication and drop it
[23:16] <seb128> robert_ancell, btw while I've you online, is there anything you need help on or think that needs work?
[23:17] <seb128> robert_ancell, it seems to me that GNOME3 will not be in a natty state in the next weeks
[23:18] <seb128> I was thinking that we had a nice start with it but now is maybe time to switch to unity work
[23:18] <seb128> unity is usable enough now to start using it and working on it
[23:19] <seb128> I don't see GNOME3 being in a natty state in the next weeks
[23:19] <seb128> or before end of year
[23:20] <robert_ancell> seb128, yes, I also think it's not worth the risk trying to get any of GNOME3 into natty.  And now we have unity we need to focus on that.
[23:20] <robert_ancell> We should continue to update the PPA as we can and see how we go
[23:20] <seb128> right
[23:20] <seb128> I've tried the new g-c-c today
[23:20] <seb128> (I didn't run it before)
[23:20] <robert_ancell> very wip right?
[23:20] <seb128> it has lot of issues and I don't see any real value out of it
[23:21] <seb128> it just drops lot of things users might be using
[23:21] <seb128> like themes
[23:21] <robert_ancell> there really aren't many packages we can update without dragging in too many other things. And since everyone has spent the time updating to GNOME3 there aren't any new features worth getting
[23:21] <seb128> in fact the new design seems really a win for devices
[23:21] <seb128> it feels like the ui would git on a screen without clutter
[23:21] <seb128> but it's not a win on a desktop config
[23:22] <seb128> git->fit
[23:22] <robert_ancell> N+1 will be the time to update to GNOME3 I think
[23:22] <seb128> right
[23:22] <seb128> ok, seems we agree on that
[23:22] <seb128> do we still want gtk3 on the CD?
[23:22] <robert_ancell> we will have some GTK3 apps though right?
[23:22] <robert_ancell> hah, thinking the same thing :)
[23:23] <robert_ancell> isn't dx moving to gtk3 for some stuff?
[23:23] <seb128> well right now I don't see a strong reason for it
[23:23] <robert_ancell> the only reason is "we have to migrate some time, so moving some apps will mean less work later"
[23:23] <seb128> but at the same time we might want it part of the standard install
[23:23] <micahg> is it safe for me to upgrade gnome-shell then to 2.9X?
[23:23] <robert_ancell> I think if we can, we should.
[23:23] <seb128> we got apport using it
[23:23] <seb128> so it's in now
[23:24] <robert_ancell> micahg, I've been working on the clutter update, should hopefully be done today
[23:24] <seb128> I think we can probably push some things
[23:24] <seb128> gnome-games
[23:24] <seb128> or this calculator of yours :p
[23:24] <robert_ancell> gnome-games is blocked on clutter
[23:24] <robert_ancell> gcalctool, sure
[23:24] <seb128> well I mean during the cycle
[23:24] <seb128> I had an hard time to find things which don't bring g-s-d or g-c-c in
[23:24] <robert_ancell> eog seems to work fine, but I'm always worried that something might change and we get cornered
[23:25] <micahg> robert_ancell: ok, great, I haven't tried yet, I just want to make sure to not cause issues for you guys
[23:25] <seb128> micahg, you can try but you will like hit issues or depends missing
[23:25] <seb128> micahg, it will be want lot of GNOME3
[23:25] <robert_ancell> seb128, and the issue is we can't deliver two g-s-d etc right?
[23:25] <seb128> robert_ancell, well eog for example as a "set as background"
[23:25] <micahg> seb128: right, but assuming I can get to build, then uploading would be ok since it's not in the seed?
[23:26] <seb128> robert_ancell, which will use gsettings
[23:26] <seb128> robert_ancell, so nautilus or g-s-d will not pick it
[23:26] <robert_ancell> seb128, yeah
[23:26] <seb128> I didn't find lot of softwares not integrated with some system keys
[23:26] <robert_ancell> micahg, gnome-shell is in a PPA at the moment right?
[23:26] <seb128> there is a daily build ppa
[23:26] <micahg> robert_ancell: idk, is it?
[23:26] <seb128> micahg, well feel free to do what you want on g-s
[23:27] <seb128> we don't have anybody working on it officially
[23:27] <robert_ancell> I'm thinking the best place to push gnome-shell is the gnome3-builds PPA, because then it can have all the dependencies
[23:27] <seb128> ricotzs does daily builds in a ppa for a while
[23:27] <micahg> seb128: ok, thanks, the only reason I need to upgrade it is for the xul20 transition
[23:27] <seb128> you need to update gjs rather?
[23:28] <seb128> but yeah, I think updating can only make upstream and users happier
[23:28] <seb128> so if you get the new one working go for it
[23:28] <micahg> seb128: right, but I would guess a new gjs would mean a new gnome-shell as well
[23:28] <seb128> if you run into any lack of depends let me know
[23:28] <seb128> we might just want to drop the universe one and use the ppa as robert_ancell was saying
[23:29] <micahg> seb128: ok, do you have any idea for Debian's plans WRT GNOME3?
[23:29] <seb128> debian is frozen for their next stable
[23:29] <seb128> so it's not an easy timing
[23:29] <seb128> don't count on anything this cycle
[23:29] <micahg> ah, right, it could be another 4 months before release
[23:30] <seb128> they start building a GTK3 stack in experimental
[23:30] <seb128> but I don't think they will go on with GNOME3 as we do in the ppa
[23:30] <seb128> not until their stable is out
[23:30] <micahg> seb128: ok, I'll check out ricotz
[23:30] <micahg> s package
[23:33] <robert_ancell> seb128, jasoncwarner, proposed meeting page: https://wiki.ubuntu.com/DesktopTeam/Meeting/2010-11-30
[23:36] <seb128> robert_ancell, seems fine to me
[23:36] <seb128> do you think we should keep some sections in the summary?
[23:37] <seb128> like the current dx, unity, etc
[23:37] <seb128> s-c
[23:37] <seb128> xorg
[23:38] <seb128> I know I like have a clear status for those
[23:38] <seb128> I'm not sure how it would work having the same items randomly list between other topics
[23:38] <seb128> not sure if we should have some categories and "others"
[23:38] <seb128> or just a dump from all notes
[23:39] <jasoncwarner> as the new guy, I did like having some breakdown by category...FWIW...it was useful for me.
[23:40] <jasoncwarner> but not sure if that is b/c I'm the new guy or b/c that information naturally breaks down that way
[23:40] <rickspencer3> fwiw, I put those theres because folks kept getting out of sync on those areas
[23:40] <robert_ancell> yes, I'm not sure about the categories.  I've decided to drop them for the experiment and see how it goes.
[23:40] <seb128> ok, let's try
[23:40] <seb128> but I quite like the kubuntu, s-c, unity, etc status
[23:40] <TheMuso> So do I.
[23:57] <Sarvatt> is natty hardcoded to use firefox to open http:// links or something? any magic way to change it?
[23:58] <RAOF> I fiddled with the gnome-www-browser alternative group, but I've gone back to firefox with the FF4 beta, so I can't tell you if it still works.
[23:58] <rickspencer3> Sarvatt, maybe I'm not getting what you're saying ...
[23:59] <rickspencer3> but you should be able to go System->Preferences->Preferred Applications and set your choice of default browser there
[23:59] <Sarvatt> gnome-www-browser points to chromium
[23:59] <Sarvatt> rickspencer3: chromium is my browser there but links open in firefox