[09:35] kenvandine: I've made a merge request for the libindicator fix to this bug; https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/564034 but the appindicators patch for ibus needs to be applied in the packaging stage, is that something you do? I was under the impression it is [09:35] Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/564034) [09:37] klattimer, hey [09:38] klattimer, it's middle of his night [09:38] hey seb128 [09:38] oh [09:38] klattimer, ibus changes should be applied to the package yes [09:38] wouldn't it be nice to have timezone indicators in pidgin [09:38] ted, bratsche, kenvandine are all us based [09:38] ie it's 3:38 for them now [09:39] yeah, I thought kenvandine was europe that's probably because he was online in the morning when I started :) [09:39] maybe he was conferencing or sprint or something [09:43] right, the week you started we had a distro sprint in europe [09:44] anyway you can ask questions to davidbarth or me during european morning [09:44] the ibus change needs to be reviewed by the canonical-desktop-team [09:45] kenvandine will probably do it when he's around [09:45] but feel free to assign the review to the team meanwhile [09:51] hi [10:05] seb128: I think the review is already assigned [10:05] klattimer, ok, excellent [10:05] https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/564034 [10:05] Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/564034) [10:05] does that look right to you? [10:05] I don't want to say fix committed because it's an updated package patch [10:06] klattimer, yes, assigning to the canonical-desktop-team is fine, we review our bugs regularly [10:08] cool [10:16] klattimer: the patch seems to conflict and replace a lot of files atm [10:17] klattimer: apart from that, how are things with the keyboard indicator? in particular do i need to reclarify with design what they have to provide you with for icons? [10:29] davidbarth: how can it replace a bunch of files? [10:29] maybe I've got something messed up but it should be an absolute replacement to the existing patch [10:30] davidbarth: I'm pretty sure mpt has specced it up enough for the keyboard indicator [10:30] i need to get my teeth deep into the code and see if I can implement what we've spoken of [10:31] http://launchpadlibrarian.net/52423973/05_appindicator.patch <- you are talking about this patch right? [10:35] davidbarth: I see what you mean with the patch [10:35] grr [10:35] something has gone very wrong here [10:35] chaotic, hi [10:48] davidbarth: I'm having some *issues* with bzr [10:50] klattimer: yeah, maybe it's not proposed against the right branch / revision [10:50] davidbarth: that's a good point! [10:51] what are you guys trying to do with icons there? [10:52] davidbarth: I've re-submitted the merge request with the correct changes [10:52] yay! [10:53] seb128: I've emailed Ivanka asking to get an artist to work on the replacements, given details of which files need updating etc... [10:53] the branch I've just proposed a merge for fixes the issue *for now* but we want to use themed symbolic icons, so that'll require a further change [10:53] however I don't want to make that change until we know we're getting icons for this release [10:54] so atm, we'll use absolute paths for the icons, after we've got some icons we can add themed icons [10:54] might not make it into maverick but we'll see [10:56] klattimer: for design requests, make sure to CC me because i'm also managing the list of requests with Iain (ivanka is on holiday this week) [10:56] I'm not sure to follow [10:56] why do you need icons for the keyboard indicator? [10:56] ah, OK i'll forward on the email [10:56] shouldn't that be labels? [10:56] seb128: no, cannot after the (long) discussion we've had on the topic [10:57] seb128: it needs to special decoration and that's better managed with proper svg icosn [10:57] davidbarth, it's a label now [10:57] why can't it be a label with indicators? [10:57] davidbarth: keyboard indicator is just labels with a background colour [10:57] icons for ibus [10:58] davidbarth: that isn't what was discussed to my recollection [10:58] ok [10:58] it does make sense for ibus ;-) [10:58] the point is that the status icon that currently exists is a label, which is squashed if it's too big [10:58] we do need to figure out how to get the label to look the way we want which is what I'm working on now [12:06] davidbarth: the current gnome-settings-daemon development branch is broken [12:06] I've tried a couple different ones but I can't built it [12:07] gst-a11y-keyboard-plugin.c undefined reference to gnome_settings_plugin_get_type [12:17] seb128: do you know anything about the above problem [12:17] seems you were the last to commit [12:24] klattimer, which one did you check out? how do you build it? === DrPepperKid is now known as MacSlow|lunch [12:25] lp:ubuntu/gnome-settings-daemon [12:25] built with dpkg-buildpacakge [12:27] seb128: I don't suppose it's possible i'm missing a dep [12:27] at least not with that error [12:28] klattimer, let me try there [12:28] k cheers [12:34] klattimer, hum, I get a similar error there as well but ld segfaults before [12:34] :/ [12:34] not good [12:34] :( [12:38] not really indeed [12:41] seb128: any ideas what can be done [12:41] is this upstrea [12:41] m [12:41] or something introduced by one of the patches [12:41] hmm [12:42] I should investigate this I suppose [12:42] klattimer, seems a compiler issue rather than an upstream one [12:42] klattimer, you can comment the LDFLAGS in the rules [12:43] klattimer, it doesn't crash without the optimizations there [12:43] klattimer, would be nice if you would still open a binutils bug about the ld crash if you get it though [12:45] klattimer, right, confirmed it builds fine without the LDFLAGS [12:46] the flag is not required, we can disable it until binutils get fixed if required [12:58] seb128: I assume you mean comment the whole LDFLAGS line from debian/rules [12:58] yes [12:58] however when I do that I get an error on build that the 99_ltmain_as-needed.patch does not remove cleanly [12:59] different issue [12:59] *head*desk* [12:59] :( [12:59] we usually us lp:~ubuntu-desktop/gnome-settings-daemon/ubuntu [12:59] and bzr-buildpackage [12:59] that's only the debian dir in the vcs [12:59] and it uses the tarball for build [13:00] that avoids such issues with patches after build [13:00] k [13:00] I'll do that instead [13:01] if you need to edit a patch you can bzr bd-do [13:01] that will send you in an uncompressed source [13:01] when you exit 0 it applies changes to the vcs [13:02] ie usually way is bzr bd-do [13:02] edit-patch patch [13:02] do changes [13:02] exit twice [13:03] but if you work on code changes you should rather get an uncompressed source with patch applied and work there [13:03] no point to do packages builds when hacking until you get something ready to test [13:03] ie hack away in a checkout, get a working patch and then try to go back to the packaging vcs [13:04] seb128: checking out and building the way you've said causes the same a11y bug to re-appear [13:04] right, comment the LDFLAGS [13:04] that's a binutils bug [13:04] it doesn't like the -z,defs [13:05] you should not get the other issues which was due to retrying a build in a non clean source [13:06] seb128: I actually checked out the source a second time and commented the LDFLAGS before I even tried rebuilding as I suspected that was the case [13:06] but the problem persisted [13:06] it's looking OK now though [13:07] ok, not sure what happened before then [13:07] but if that's working now... ;-) [13:49] seb128: do you know anything about the current g-s-d indicators patch [13:49] I can't seem to build it with the patch enabled [13:50] even though I've made sure it's configuring with support, and building with support [13:50] it still appears in the notification-area [13:52] klattimer, how did you try it? [13:52] seb128: well, I checked the configure ac, which is set to default to auto [13:52] kamstrup, did you try the xrandr or a11y one? [13:52] I can't find any specific calls to configure in the debian folder so I'm assuming all is well and that will configure with default [13:52] run gnome-display-properties [13:53] and I built with bzr-buildpackage [13:53] click the show monitor in panel checkboxc [13:53] you get an appindicator for it [13:53] ah [13:53] so the app indicator for monitors is there [13:53] but no app indicator for the keyboard layout [13:53] no [13:53] right... OK, well I thought both were included [13:54] there's another patch I'll make sure I can apply it over the top and see what's what [13:54] klattimer: sorry, back here after some sprint break [13:54] np [13:55] davidbarth: the correct branch for libindicator is now waiting a merge request [13:55] klattimer: i thought that the end of the discussion was thta having the "inverse video" flag was not a good extension of the API, and so that using pre-generated icons was the way to go [13:55] klattimer: ah, ok cool [13:56] davidbarth: so you don't want the background rectangle as was suggested by mpt [13:56] in which case we'll only be using a label [13:56] no-icons [13:56] klattimer: have the link handy? so that i can forward that to ted/bratsche; thanks [13:56] klattimer, no, cf the bug I pointed on launchpad [13:57] k [13:57] davidbarth: https://bugs.edge.launchpad.net/bugs/564034 [13:57] Error: Could not parse data returned by Launchpad: list.index(x): x not in list (https://launchpad.net/bugs/564034) [13:57] for ibus [13:57] klattimer, we dropped the keyboard indicator change previous cycle because appindicator didn't have label support and users want the current layout to be indicated [13:57] seb128: ? [13:57] yes, way better for the patch ;) [13:57] to my knowledge libindicator now supports labels right? [13:58] it does in trunk I think [13:58] ted was working on it last week [13:59] klattimer, I was just explaining why we don't use the patch for the keyboard loayout [13:59] i thought that was in the last release [13:59] the versions we had use an icon [13:59] hey guys [13:59] hey kenvandine [13:59] hey kenvandine [13:59] kenvandine, we didn't get any indicator-application tarball for weeks no? [14:00] kenvandine, I didn't see any maverick update in any case [14:00] oh, i guess not [14:00] with ted being out [14:00] he said last week that he was a bit short and would rather roll one this week [14:00] i guess i was just expecting that last week :) [14:00] right, forgot :) [14:04] klattimer: it does support labels, but i thought we said that adding that API was not the right thing to do [14:04] davidbarth: you're confused with ibus [14:04] we want icons only for ibus, and labels only for keyboard indicator [14:04] hmm, maybe ;) [14:04] the current keyboard indicator uses labels only [14:04] albeit squashed with a cairo surface [14:05] klattimer: but only labels, or labels with a surrounding frame? [14:05] we can either attempt the squash (which will be hard) or instead we just allow it to be the natural width of 4 characters [14:05] davidbarth: from what you'd just said, the surrounding frame has been dropped [14:05] at least that was my impression [14:06] so to clarify [14:07] ibus would have svg icons, based on what currently exists, right [14:07] and g-s-d would get what? just labels, or labels with a frame? [14:07] the frame i thought we had dropped the idea, to get back to plain svg icons containing those short labels with their enclosing frame [14:08] and we said, it's not a problem if the font used for the g-s-d icon is potentially different from the system font, in that it represents the /keyboard/ font, as opposed to the font used to display things on the screen [14:11] currently ibus will use png icons until such a time as we've got themed icons, I'll cook a patch to hack support for theming ibus when we're ready for it [14:11] the problem is if we don't have the icons, and there may be some trouble with the artists as they're a bit strange in some cases [14:11] then we have to ship something better than 10.04 [14:12] so we'll keep the branch I've submitted as is for now and we'll update it for theme support later [14:12] g-s-d would have just a label with no frame [14:12] but as I say there are no icons for g-s-d at all [14:12] even in the status area [14:12] so we just use a label [14:16] klattimer: ok, so plain label, no frame, and the spacing between indicators will do the rest [14:17] yeah [14:17] exactly [14:18] klattimer: once there, we could ask tedg to generate svgs at build stage, based on some template frame; but that's a 2nd level, nice-to-have evolution [14:18] klattimer: cool [14:19] klattimer: do you still have place on your plate to consider the g-p-m indicator too btw? [14:19] davidbarth: not before the 12th [14:20] I really want to get the feature bugs done before then [14:20] after that I've got to try and finish sense's patch for deluge/signal difficulties [14:20] klattimer: ok, no worries, we'll talk later about this one then [14:20] cool [14:20] davidbarth: I've responded to your review comment [14:35] bratsche: ping? could you comment on https://code.launchpad.net/~karl-qdh/ubuntu/maverick/libindicator/absfilename-ibus-bug564034/+merge/32077 [14:35] Sure. [15:36] iainfarrell: ping === MacSlow|lunch is now known as MacSlow [20:43] Is RGBA still planned for Maverick, or has it been delayed? [20:43] Will it be turned on when the new theme lands? [20:58] Hey, anybody know if RGBA is still planned for Maverick? [21:21] Is RGBA still planned for Maverick? [21:30] Is RGBA still headed for Maverick?