[08:42] <LucidFox> didrocks, thanks for sponsoring!
[09:44] <jcastro> vish: around?
[09:45] <jcastro> https://bugs.edge.launchpad.net/ubuntu/+bugs?field.tag=indicator-application
[09:45] <jcastro> klattimer: that's the list of tagged bugs
[09:45] <jcastro> klattimer: I'm going to be assigning you the ones from among this team
[09:45] <jcastro> these tags I mean
[09:46] <klattimer> k
[09:51] <vish> jcastro: hey
[09:57] <jcastro> vish: klattimer will be working with us to finish off some app indicator work
[09:57] <jcastro> vish: got any pet bugs?
[09:57] <vish> awesome! , let me check..
[09:57] <jcastro> klattimer: agateau recommends that we skip hplip, there's apparently lots of stuff that needs to get done up there to do it
[09:57] <klattimer> "up there"
[09:57] <klattimer> coding from heaven?
[09:57] <jcastro> in upstream qt
[09:58]  * jcastro gives you vino and gnome-bt instead
[09:59] <klattimer> was just looking at the hplip patch
[09:59] <klattimer> generally speaking it looks good, my guess was that there was an upstream bug causing the segfault
[10:00] <klattimer> so it's not easily fixable within the context of app indicators
[10:01] <vish> jcastro: klattimer: Bug 548981 ? this actually needs to be fixed in indicator-session
[10:01] <vish> bad bot!
[10:02] <klattimer> lol
[10:02] <jcastro> that one could be cool, but after the big ones
[10:02]  * vish digs deeper
[10:02] <klattimer> vish: i was talking about bug 497877
[10:03] <klattimer> erm nooo
[10:03] <klattimer> hmm, the bug bot isn't happy today
[10:03] <klattimer> https://bugs.edge.launchpad.net/ubuntu/+source/hplip/+bug/497877
[10:03] <vish> bot gone crazy!
[10:04] <klattimer> anyway I'll move on to vino
[10:04] <vish> klattimer: yeah , i'm looking.. most of the bugs are tagged indicator-application  , I'll see if any are left out..
[10:05] <jcastro> klattimer: seb128 will be assigning you bugs as well, so don't freak out, heh
[10:05] <klattimer> ;)
[10:06] <jcastro> vish: the main scope of the work is fixing existing indicators and "big bang for the buck" ones
[10:06] <vish> sweet!
[10:06] <jcastro> vish: so for each app we're going to have to make a judgement call of how many people could be using the app
[10:07] <jcastro> vish: after that we are keen on getting him time to clean up notify-osd stuff as well
[10:07] <jcastro> vish: and then we can have cake!
[10:08] <klattimer> mmmm cake
[10:08] <vish> jcastro: oh , notify-osd as well , this one got assigned last cycle , but seems to have gotten lost > Bug #333269
[10:09] <jcastro> vish: mpt and seb will be putting together lists of bugs for notify-osd, however when they have those I'd like you to go over it as well
[10:11]  * vish searches for more "big bang for the buck" ones
[10:16] <vish> jcastro: seen > Bug 601209 ?
[10:16] <vish> and there is another that has to be fixed as well , supporting icon + text in the indicators..
[10:23] <jcastro> klattimer: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators/ContractorWorkflow
[10:23] <jcastro> that's kind of old and out of date, but has some useful bits
[10:24] <klattimer> k
[10:24] <klattimer> cheers
[10:25] <jcastro> vish: yeah, you know what would be awesome would be a list of bugs (sorted by priority) of things that app developers are needing to port their apps
[10:31] <jcastro> vish: but we'll cross that bridge when we get there, heh
[10:31] <jcastro> klattimer: did the bugmail start hitting you?
[10:33] <klattimer> I've got two so far
[10:36] <vish> hmm , how many users would like a Thunderbird support for messaging menu...
[10:37] <klattimer> vish: quite a few I'd imagine
[10:39] <vish> oh! , there is already a patch for that : Bug #367175
[10:40] <klattimer> jcastro: I'm assuming it's best to test on maverick?
[10:43] <jcastro> klattimer: yeah, I don't know how comfortable you are running alpha releases
[10:44] <jcastro> virtualization!
[10:45] <klattimer> jcastro: got virtualbox on my mac
[10:45] <klattimer> it'll be fine ;)
[10:45] <vish> jcastro: another one is tomboy indicator is in need of "pins"...
[10:45] <klattimer> oh the bugs in the maverick pages are fun
[10:46] <vish> we dont support that yet in app-indicators..
[10:46] <klattimer> alpha1 is the google top hit, and the download links go nowhere
[10:46] <klattimer> alpha2 the download link in the menu doesn't jump to the section
[10:46] <klattimer> lovely ;)
[10:53] <klattimer> maverick installing ;)
[11:12] <didrocks> LucidFox: yw ;)
[11:12] <didrocks> LucidFox: thanks for the patch!
[11:12] <LucidFox> Hmm, now it turns out that Debian released 1.6.4-1 two days ago, we'd need to merge
[12:49] <klattimer> jcastro: I'm looking for which source code to apply the vino patch to
[12:50] <klattimer> was wondering if any of the existing launchpad branches are valid, or whether I should be taking from upstream?
[12:50] <sense> klattimer: We do try to forward patches upstream as much as possible, so upstream would probably the best place to look for the source code if upstream is prepared to include it.
[12:52] <klattimer> sense this is for app indicators, so unlikely upstream will use it
[12:52] <klattimer> but I'm just looking for the baseline code to apply a patch to
[12:52] <klattimer> confused as to what I need to do about debian/* in the package if it's coming from upstream
[12:53] <sense> klattimer: We have been sending most patches upstream, so I hope that Vino will accept it as well. I assume you're using autoconf flags to disable AppInd by default?
[12:53] <klattimer> sense: it's not my patch but it looks that way
[12:54] <sense> good
[13:10] <jcastro> klattimer: I would work on whatever will ship in maverick, so git head. :D
[13:10] <jcastro> sense: glad you're here, klattimer is our man for some time to work on app indicator issues
[13:10] <jcastro> sense: do you happen to have a link to that submenu bug he'll likely run into?
[13:10] <jcastro> sense: ted will likely fix that one soon
[13:10] <sense> jcastro: No, but I think I did ran unto it when working on Deluge.
[13:11] <jcastro> ah
[13:11] <sense> I've got a plugin for that ready, but its submenus don't work.
[13:11] <jcastro> aha!
[13:11] <jcastro> let me find dbarth and get a timeline for completion on it
[13:12] <sense> bug 585153 is a submenu bug, but it is not what I saw.
[13:13] <jcastro> klattimer: you'll likely hit that at some point
[13:13] <jcastro> sense: dbarth says to please file a new bug and assign it directly to agateau
[13:13] <jcastro> (on your issue)
[13:13] <sense> ok
[13:14] <sense> jcastro: Could be related to Glade as Deluge is still using that.
[13:16] <klattimer> jcastro: I'm using git-head
[13:17] <klattimer> but wondering where the debian folder can be sourced from for package building?
[13:17] <sense> If it's up-to-date that would be lp:ubuntu/vino or lp:ubuntu/maverick/vino
[13:17] <sense> bzr branch lp:stuff
[13:17] <sense> Otherwise there's always apt-get source
[13:18] <klattimer> k
[13:20] <sense> klattimer: I think most branches are up-to-date nowadays, but you might want to check it really provides you with the latest version available, just to be sure.
[13:21] <klattimer> sense: just checked 2.28 in bzr maverick vs 2.31 in git-head
[13:21] <klattimer> the question is, which version is shipping with maverick 2.30?
[13:21] <sense> 2.28.2 is the one being shipped in maverick.
[13:21] <klattimer> right so I'll just forget about git then
[13:22] <sense> I think we will eventually ship the new release from upstream, which is now still 2.31, but meanwhile you could provide a patch for 2.28.2 while waiting for the patch to be accepted upstream.
[13:22] <klattimer> k
[13:22] <sense> Once it gets accepted upstream and the new version gets uploaded to maverick you can drop the patch and enable the appindicator flag.
[13:22] <sense> (or just add libappindicator-dev to Build-Depens if the default value of the flag is auto)
[13:35] <klattimer> urgh... patch failed to apply
[13:35] <klattimer> :/
[13:36] <sense> jcastro: bug 608219
[14:05] <jcastro> klattimer: travis' patch applied to lucid, so whatever was in 2.28
[14:06] <klattimer> jcastro: I've stumbled on some dpkg weirdness i think
[14:06] <jcastro> I mean 2.30
[14:06] <klattimer> adding the patch to the patch sequence breaks building
[14:06] <klattimer> patching before buildpackage it works
[14:06] <jcastro> klattimer: pastebin me
[14:06] <klattimer> ... weirdness
[14:06] <klattimer> jcastro: can't do atm
[14:06] <klattimer> working between two machines and a third virtual
[14:06] <jcastro> k
[14:07] <jcastro> for packaging related issues kenvandine can help. He's in #ubuntu-desktop
[14:07] <klattimer> but anyway I'm building and will be able to test the patch I hope soonish
[14:07] <klattimer> k, good to know
[14:09] <bratsche> Hey.
[14:09] <sense> hi bratsche
[14:10] <kenvandine> klattimer, hey
[14:11] <kenvandine> klattimer, if you have packaging questions, feel free to ping me
[14:11] <sense> kenvandine: I thought that during the UDS someone was appointed to fix the C# inheritance problems of AppIndicator. Is someone already working on that?
[14:11] <kenvandine> sense, not that i know of
[14:12] <sense> kenvandine: I thought ROAF proposed to seal the class and someone said he should do so.
[14:13] <sense> RAOF
[14:14] <RAOF> sense: Yo!
[14:14] <sense> RAOF: ^^
[14:14] <sense> and yo, of course
[14:14] <RAOF> I have no memory of that conversation.
[14:14] <klattimer> grr, now hitting buts with an undefined identifier
[14:14] <klattimer> :(
[14:15] <sense> ok
[14:15] <RAOF> And no one assigned me a work item for it, so it hasn't been done my me.
[14:15] <sense> That's logical. :)
[14:15] <RAOF> I even forget what the problem was!
[14:15] <sense> RAOF: Cannot inherit from the C# AppInd class because the Category and Status things are stored in a weird hybrid way, between enums and strings.
[14:16] <sense> RAOF: the constructor causes trouble
[14:16] <sense> It expects the category value to accept a certain type, but it wants another and then crashes.
[14:16] <RAOF> Ok.  So the solution I proposed was to make it not possible to subclass AppInd?
[14:16] <kenvandine> sense, oh... you can't do that in python either
[14:16] <RAOF> That makes sense :)
[14:17] <sense> RAOF: I think that was you.
[14:17] <RAOF> It could well have been.
[14:17] <sense> You have a black beard, right?
[14:17] <RAOF> That should be a simple matter of prepending “sealed”
[14:17] <RAOF> sense: Hah!  You're thinking of dbo!
[14:17] <sense> RAOF: No, it isn't.
[14:17] <sense> ah!
[14:17] <sense> :P
[14:18] <sense> RAOF: It's using GAPI2 to generate things, so we have to work in the .metadata file.
[14:18] <RAOF> Ah.
[14:18] <RAOF> Right.
[14:18] <RAOF> Well, you could use a .custom file.
[14:18] <sense> That would mean we'd have to maintain the whole constructor manually.
[14:18] <RAOF> Yeah, true.
[14:18] <sense> Isn't there a way to seal a class from GAPI?
[14:19] <RAOF> Dunno.
[14:19] <RAOF> Actually, no!  You wouldn't have to manitain the whole constructor.
[14:19] <sense> Really?
[14:19] <RAOF> What you'd do is have basically “sealed partial class AppInd”, and have nothing in there.
[14:19] <sense> That would be nice.
[14:19] <sense> and not hide the generated thing
[14:19] <sense> I see
[14:20] <RAOF> I'm not sure if GAPI would need to add the “partial” modifier on the class.
[14:21] <RAOF> There's an easy way to find out, though!
[14:21] <sense> That can be tested! :)
[14:21] <sense> We could make it work fully by inventing some custom string-like enum and not using ints anymore anywhere in the whole libappindicator library, or stick to the enums, but write a custom layer between the DBus API and the library.
[14:21] <sense> All a lot of work to do.
[14:21] <sense> So sealing seems to best solution to me.
[14:22] <sense> RAOF: Shall I give your proposed method a try?
[14:23] <RAOF> Yeah.
[14:32] <klattimer> kenvandine: any clues on fixing a glib-mkenums problem
[14:32] <klattimer> the patch I have changes two enum vals, but these aren't detected by glib-mkenums
[14:52]  * kenvandine reads back
[14:52] <kenvandine> klattimer, is this for vino?
[14:53] <klattimer> yeah
[14:53] <kenvandine> is the file your patching actually generated at build time?
[14:53] <klattimer> seems theres a missing file from vino_enum_headers post patching
[14:53] <kenvandine> or before?
[14:54] <klattimer> before build time
[14:54] <kenvandine> vino-enums.h
[14:54] <kenvandine> ?
[14:56] <kenvandine> that looks like it is generated at build time
[14:58] <klattimer> kenvandine: yeah it is
[14:58] <klattimer> but I'm talking about a patch applied before buildtime
[14:58] <klattimer> I think I've fixed it
[14:58] <klattimer> gimme a few minutes to build
[15:00] <klattimer> urgh, nope that didn't fix it
[15:15] <klattimer> kenvandine: appears I'm hitting some kind of configure problem with GNOME_COMPILE_WARNINGS(yes) and it's refusing to rebuild the makefiles
[15:15] <klattimer> thus causing a bunch of other problems
[15:15] <klattimer> This seems to be something to do with gnome-common, which wasn't installed but is now
[15:15] <klattimer> could I be missing another package?
[15:15] <klattimer> this is a clean vm for building, so I imagine i'm missing some things
[15:19] <kenvandine> klattimer just installing the build-deps should be enough
[15:20] <klattimer> hmm
[15:20] <klattimer> seems not
[15:20] <klattimer> I've added gnome-core-dev and gnome-dev
[15:20] <kenvandine> want to share your patch and let me take a swing?
[15:20] <klattimer> lets see if that helps
[15:20] <klattimer> kenvandine: be my guest https://bugs.edge.launchpad.net/ubuntu/+source/vino/+bug/497883
[15:22] <klattimer> gah, same thing
[15:22] <klattimer> syntax error near unexpected token 'yes'
[15:22] <klattimer> GNOME_COMPILE_WARNINGS(yes)
[15:22] <klattimer> :(
[15:25] <klattimer> hang on
[15:25] <klattimer> this might be what you mention in your comment
[15:25] <klattimer> have_app_indicator should be enable app_indicator
[15:27] <klattimer> grr, missed that comment :(
[15:28] <kenvandine> klattimer, you need to autoreconf too
[15:28] <kenvandine> are you building from the package or just a checkout?
[15:28] <kenvandine> in debian/rules add
[15:29] <kenvandine> include /usr/share/cdbs/1/rules/autoreconf.mk
[15:29] <kenvandine> or just run ./autogen.sh
[15:29] <kenvandine> and you should add the configure arg as well
[15:32] <klattimer> building from a bzr checkout from ubuntu/maverick/vino
[15:32] <kenvandine> ok, autoreconf will do it
[15:34] <klattimer> thanks
[15:34] <klattimer> seems to be working now
[15:34] <kenvandine> np
[15:35] <kenvandine> klattimer, let me know if you need anything
[15:35] <klattimer> will do
[15:35] <klattimer> seems I'll be able to get on with it from here on
[15:35] <klattimer> seem to be some configure bugs which will need fixing though