[11:32] <bdrung> is this the right channel to find graphics designer?
[11:34] <bdrung> can someone convert the svg icon of audacious into a monochrome one that integrates well with ubuntu's default themes (bug #563043)?
[11:34] <ubot4> Launchpad bug 563043 in audacious (Ubuntu) "audacious2.png alpha blending is wrong (affects: 1) (dups: 1)" [Medium,Fix released] https://launchpad.net/bugs/563043
[11:36] <mpt> bdrung, you could try #ubuntu-artwork
[11:36] <bdrung> k, will ask there
[15:57] <qense> jcastro: There are building issues and all kinds of nasty installation errors and crashes with Banshee.AppIndicator -- including the version in the Lucid repo -- because the much needed fix for libappindicator0-cil hasn't been released yet. Am I right hyperair?
[15:57] <qense> I was wondering if you could bug anyone about this issue.
[15:58] <hyperair> oh look seb128_ is here too
[15:58] <qense> maybe he can help us
[15:59] <qense> jcastro, seb128_: it's this bug: bug #564506 (Critical)
[15:59] <ubot4> Launchpad bug 564506 in indicator-application (Ubuntu) (and 1 other project) "libappindicator-cil-dev's .pc file points to the wrong place (affects: 12) (dups: 4) (heat: 96)" [Critical,Triaged] https://launchpad.net/bugs/564506
[15:59] <jcastro> qense, is it fixed upstream and just needs to get into the distro?
[15:59] <qense> jcastro: there is a merge request for the Ubuntu packaging, but it needs to be reviewed and uploaded.
[16:00] <qense> jcastro: The banshee-community-extensions part has been fixed, but it will continue to FTBS until the appind fix is uploaded.
[16:00] <jcastro> I see
[16:00] <jcastro> ok so we need to hug seb128_
[16:01] <Zdra> tedg, Hi, you are the one working on libappindicator integration in rhythmbox?
[16:01] <qense> Zdra: I thought that was Nafai
[16:02] <jcastro> Zdra, it was initially bratsche and then jpetersen finished it off
[16:02] <seb128_> no, bratsche wrote the rhythmbox change
[16:02] <qense> hyperair: the diff renames libappindicator0-cil to libappindicator0.0-cil, but libappindicator-cil-dev to libappindicator0.1-cil-dev? Why the different number?
[16:03] <jcastro> Zdra, it's sitting on bgo but the upstream maintainer wants to discuss it so we'll probably chat about it at UDS.
[16:04] <Zdra> bratsche: So when I don't have the indicator applet, the status icon goes to the notification area. But its behaviors isn't reverted to upstream's. For example I don't have tooltip, popup menu is on left-click instead of right-click, no way to play/pause with middle-click, not changing volume on scrolling, no way to show/hide the main window
[16:05] <Zdra> jcastro, tedg Nafai (who ever is doing that) ^
[16:05] <Zdra> I would like to fix that, but I don't know how I can know in the code if the indicator applet is present
[16:05] <qense> I was wrong about Nafai, sorry.
[16:05] <qense> Zdra: I think we're providing it as a patch
[16:06] <Zdra> yep, there is a patch in the rb package
[16:06] <qense> Zdra: I think they're using preprocessor #ifdef structures.
[16:07] <Zdra> but that should be run-time since I can add/remove the indicator applet at runtime
[16:07] <Zdra> that's what I would like to change, but I don't see how
[16:07] <tedg> Zdra: You can override the fallback functions.
[16:07] <tedg> Zdra: So we have a default way to create the GtkStatusIcon
[16:07] <tedg> Zdra: And you can build it anyway you want if you subclass and override.
[16:08] <qense> jcastro, seb128_: To add to the pain of the problems with Banshee.AppIndicator due to libappindicator0-cil's packaging: I can't work on the two bug reports since libappindicator0-cil doesn't seem to be working at all now.
[16:08] <seb128_> it's not used anywhere in lucid anyway
[16:09] <seb128_> I fail to see that as a real issue, we will get it working next cycle
[16:09] <qense> seb128_: You mean AppInd-sharp?
[16:10] <qense> There is a fix for it already. The bug is blocking the building of banshee-community-extensions.
[16:10] <qense> If the fix won't land we'd have to remove banshee-extension-appindicator from the archives because it's not workable.
[16:10] <seb128_> right, but we are frozen for rc now
[16:10] <jcastro> is this SRUable?
[16:10] <seb128_> well it's universe software, after rc doesn't seem time to rename binaries from a source in main to accomodate universe software which never worked
[16:10] <qense> Not due to a complicated programming bug, but due to a packaging mistake in a library that is used by exactly one package.
[16:11] <qense> plus: the packaging is a violation of the Debian CLI Policy.
[16:11] <seb128_> right, we have people every day arguing that $random_universe_software not working is end of the world
[16:11] <seb128_> we ship on time, it that change is late for lucid we will get it working next cycle
[16:11] <qense> and in its current state we actually should not only remove banshee-extension-appindicator from the archives, but also libappindicator0-cil and libappindicator-cil-dev because they are not working at all.
[16:12] <seb128_> they are not breaking anything either
[16:12] <seb128_> we limit changes to what we really need between rc and lucid
[16:12] <qense> I understand that, but those three packages aren't even on the CD, nor required or even suggested by any other package at all.
[16:12] <jcastro> can we fix it in a PPA, test it for a bit and then propose it as an SRU post-lucid?
[16:13] <seb128_> no but they require an upload for a chance which is on the CD
[16:13] <Zdra> tedg, is all the code in 82_rhythmbox-indicators.patch ?
[16:13] <seb128_> Zdra, yes
[16:13] <qense> seb128_: what change?
[16:13] <seb128_> chance -> source
[16:13] <seb128_> qense, indicator-application has binaries on the CD
[16:13] <seb128_> if we update it we need to respin CD
[16:13] <qense> ah, you mean the fact that you can't build the C# bindings apart.
[16:14] <seb128_> yes
[16:14] <seb128_> it needs an indicator-application upload
[16:14] <seb128_> which will mean new binaries for all the thing it builds
[16:14] <seb128_> including the C library
[16:14] <qense> I forgot to look at it from the source package perspective, you're completely right here.
[16:14] <qense> In that case, would it be possible to do the update post-release?
[16:16] <seb128_> qense, I will sponsor the pending change and let slangasek decide for after rc and with eventual respins
[16:16] <seb128_> qense, otherwise yes we will be able to SRU that
[16:16] <qense> seb128_: great, thank you
[16:17] <seb128_> np
[16:17] <Zdra> tedg, for what I understand, the function rb_tray_icon_new() is implemented in 2 places: in the indicator patch and in status-icon plugin
[16:18] <tedg> Zdra: I'm not as familiar with the RB patch, I'm sorry.  I'm more familiar with the library.
[16:18] <tedg> I'm not sure who did the RB patch
[16:18] <seb128> brastche and jpertersen working on it
[16:19] <Zdra> I see, it is in makefile it replace rb-tray-icon-gtk.c by rb-indicator.c
[16:20] <Zdra> tedg, so do you know how in runtime I can know if tray icon will be embeded inside the notification area or the indicator applet?
[16:22] <bratsche> I wrote the original RB patch, but I don't understand what the issue is.
[16:24] <Zdra> bratsche, I would like to modify the patch, so at runtime, if the indicator applet is not in the panel, it revert to upstream behavior
[16:24] <tedg> Zdra: You can either listen to the signal or wait for the function to be called.
[16:24] <tedg> Zdra: I think in general it's best to just implement fallback/unfallback and they'll be called if needed.
[17:25] <hyperair> seb128: slangasek already gave his approval
[17:26] <hyperair> seb128: directhex and i discussed it with him yesterday
[17:26] <hyperair> after which i pinged you in #ubuntu-release
[17:26] <seb128> I was probably away for lunch
[17:26] <seb128> I didn't read that backlog
[17:26] <hyperair> ah
[17:27] <hyperair> seb128: basically he acked it as long as there would be *no* further changes to indicator-application
[17:27] <seb128> ok
[17:27] <seb128> I will just sponsor what is waiting if you confirm what should be uploaded
[17:28] <hyperair> seb128: the changes that were in the merge request. that's it.
[17:28] <hyperair> seb128: tested by directhex to build, install, and work fine
[17:29] <seb128> ok
[17:29] <hyperair> seb128: if tedg doesn't have any more changes then i think it can be uploaded.
[17:29] <tedg> seb128: I think the only other possible change would be if Nafai can figure out the gnome BT one.
[17:30] <Nafai> yeah :)
[17:30] <tedg> seb128: The Mono updates work for me though.  I was able to rebuild my local Tomboy happy happy now.
[17:30] <seb128> ok
[17:30] <seb128> will sponsor that after the meeting in ubuntu-desktop
[17:31] <qense> tedg: I'll be restarting my work on the C# bindings in the Maverick cycle, it is too late now to push such a large change to the Mono bindings that isn't needed by anything at the moment, actually, and I don't really have time to work on it. I'll await the roadmap for AppInd.
[17:32] <tedg> qense: Cool, that'd be great!
[17:32] <tedg> qense: I don't think there'll be many changes in the Maverick cycle.  Hopefully just fixes.
[17:32] <qense> tedg: We already now what the exact problem is, but I need to make time to write a proper fix. And i haven't made time yet. ;)
[17:32] <qense> tedg: No exciting new stuff like categorising? :D
[17:33]  * tedg hates exciting and new as they all create bugs :)
[17:33] <vish> qense: thanks for looking at the merge > https://code.launchpad.net/~ubunt-u-markbenjamin/indicator-applet/reorient/+merge/23524  :)
[17:33] <qense> vish: yw
[17:34] <qense> tedg: I like exciting and new because I make myself forget all the bugs1
[17:34] <vish> qense: its now awaiting tedg to merge it to main?
[17:34] <qense> vish: I have no idea, but considering the RC freeze: only after the release
[17:34] <qense> seb128: We also have another merge request, this time for indicator-applet. It adds support for vertical panels. Definitely something for post-release updates?
[17:37] <tedg> Yeah, I can't imagine we can do that one at this point in the release cycle.
[17:37] <tedg> It seems reasonably for an SRU though to me.
[17:37] <vish> \o/
[17:38] <MarkieMark1> I should say too, qense thanks for that :)
[17:38] <qense> MarkieMark1: thank you for the fix
[17:39] <MarkieMark1> it's a pleasure :)
[17:39] <qense> and apologises for making you create a new branch because I can't figure out the difference between indicator-application and indicator-applet. :P
[17:40] <MarkieMark1> no worries, I learnt some of how debian packaging works
[17:40] <qense> good!
[17:42] <seb128> qense, yes
[17:42] <qense> ok
[17:43] <qense> lets not make your life harder now :)
[23:47] <mesula> Can someone help me get Pidgin working with the messenger applet please?