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