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