[01:55] <schmichael> can someone point me to good docs on how to integrate with the main appindicator icon?
[01:55] <schmichael> preferably in python
[01:55] <schmichael> this seems too high level: https://wiki.ubuntu.com/MessagingMenu/
[01:55] <schmichael> this isn't exactly comprehensive: https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators#Python
[01:56] <schmichael> and this is for C and doesn't really tell what I should do: http://people.canonical.com/~ted/libappindicator/current/AppIndicator.html
[01:56] <schmichael> 6pm Pacific timezone is probably the wrong time to ask
[02:05] <RAOF> schmichael: This isn't really the correct channel.  You probably want #ubuntu-app-devel or #ayatana.  That said, there are multiple things you could mean here: do you want to integrate with the messaging menu?  With the Me menu?  With the sound menu?  Or just use the replacement notifiation-area-like appindicator?
[02:07] <schmichael> holy shit that's a lot of menus
[02:07] <schmichael> um
[02:07] <schmichael> I think the messaging menu
[02:08] <schmichael> where Mail, Compose, and Broadcast live
[02:08] <schmichael> I've never even heard of ayatana
[02:08] <schmichael> Sorry for posting in the wrong channel, I think one of the pages I cited says to drop by here
[02:10] <RAOF> That's ok.
[02:14] <RAOF> Right; so you're looking for information about the messaging menu.  I think python-indicate is the package you'll be needing, and gwibber-service is an example of a python app using it.
[02:14] <schmichael> I think I'll just use libnotify and figure out what I want to do about an icon later
[02:14] <schmichael> ah
[02:14] <schmichael> hm
[02:15] <schmichael> looking
[02:15] <RAOF> Your app is something that presents messages, right?
[02:15] <schmichael> yes
[02:16] <RAOF> Yeah, python-indicate will be what you're after then.
[02:16] <schmichael> hm, can't find that in pypi
[02:16] <schmichael> ah but there's a deb
[02:17] <RAOF> “apt-get source gwibber-service” might help you work out how to use it if you can't find better documentation.
[02:17] <schmichael> how is python-indicate different from python-appindicator?
[02:17] <schmichael> I've been toying with the latter and it seems to create a new icon entirely
[02:18] <RAOF> App indicators are the replacement for the notification area.  They're for generic apps which want some form of notification-area like control system - see for example Banshee, gtg, the power manager & bluetooth thingies.
[02:19] <schmichael> gotcha
[02:19] <schmichael> python-indicate seems to offer the same api though
[02:19] <schmichael> er, similar
[02:19] <RAOF> The API should be substantially the same, they're both based on dmusmenu.
[02:19] <RAOF> Ahem. dbusmenu.
[02:19] <schmichael> any idea where docs might live?
[02:20] <schmichael> I'll look at gwibber
[02:20] <RAOF> Yeah.
[02:20] <RAOF> I wouldn't be surprised if the pydocs weren't bad; we often have good docstrings in my experience.
[02:22] <schmichael> Thanks for the help. I'm a web/server python developer trying to take a stab at a desktop client
[02:22] <schmichael> Very difficult to figure out where to start
[02:22] <schmichael> Also, I'm at a pub. Which may be the wrong place to be hacking
[02:24] <RAOF> Nonsense!
[02:25] <schmichael> :)
[02:26] <schmichael> Pint #2 in progress
[02:26] <schmichael> First one might have been 8% ABV, a poor choice
[02:26] <schmichael> This one is 5.4% though, so I should be able to recover
[02:35] <schmichael> RAOF: so gwibber appears to try to load a desktop file from the directory it's launched from...
[02:35] <schmichael> ...do you know if this is important?
[02:36] <schmichael> And if so, why from the dir it's launched from, shouldn't desktop files be in HOME directories?
[02:36] <schmichael> or at least not by executables
[02:37] <RAOF> As I understand it you need to stick a .desktop file somewhere that the Messaging menu checks in order to register yourself.  After all, you can _start_ apps from the messaging menu.
[02:40] <schmichael> I have so much to learn
[02:40] <schmichael> I barely know what a .desktop file is...
[02:40] <schmichael> ...just that it describes desktop applications
[02:40] <schmichael> and associated resources (icons, translated names, etc)
[02:40] <schmichael> Web development is so much easier
[02:41] <schmichael> You have GET variables, request data (POST/PUT variables), and each request/response cycle is completely independent
[07:10] <pitti> Good morning
[07:15] <robert_ancell> james_w, do you have an updated empathy indicator patch?
[07:31] <didrocks> good morning
[07:40] <pitti> hey robert_ancell, bonjour didrocks
[07:40] <didrocks> guten morgen pitti
[07:41] <robert_ancell> pitti, hello
[08:36] <seb128> hey there
[08:37] <pitti> it's a Seb!
[08:37] <baptistemm> hello
[08:38] <didrocks> salut seb128
[08:38] <didrocks> hello baptistemm
[08:38] <baptistemm> salut didrocks
[08:38] <seb128> hey pitti
[08:38] <seb128> lut baptistemm didrocks
[08:40] <robert_ancell> seb128, hey, I have empathy updated ready for maverick.  This will be the first package to have a definite dependency on GSettings.  Any final words?
[08:42] <baptistemm> salut seb128 didrocks pitti and robert_ancell
[08:42] <robert_ancell> baptistemm, hey
[08:42] <pitti> hello baptistemm
[08:42] <pitti> robert_ancell: wohoo!
[08:42] <seb128> robert_ancell, hey, I've been trying to figure from empathy guys if they will depends on gtk3 for a week now
[08:43] <didrocks> robert_ancell: they have a shared gconf key, we should maybe look at that
[08:43] <seb128> robert_ancell, I'm fine with gsettings, not with gtk3
[08:43] <seb128> robert_ancell, I guess we can go for it but we will need to distro patch to build with gtk2 if required
[08:43] <robert_ancell> seb128, so what do you think?  Shall we leave it in bzr/a ppa wait and see what they do, or roll back if there is a problem
[08:43] <seb128> robert_ancell, what is your take on updates? did you pick that one for a reason or do you plan to start doing GNOME 2.31 updates?
[08:44] <seb128> robert_ancell, btw I was wrong about new poppler it doesn't require new cairo
[08:44] <robert_ancell> seb128, picked that one because you mentioned it, debian already has it in experimental, there's lots of stability updates and the geolocation is a nice new feature
[08:44] <seb128> robert_ancell, got the new cairo in the ubuntu-desktop ppa as well
[08:44] <baptistemm> anyone to review lp:~bluetooth/ubuntu/maverick/bluez/main and lp:~bluetooth/ubuntu/maverick/obexd/main?
[08:44] <seb128> robert_ancell, did you enable geolocation?
[08:44] <robert_ancell> seb128, sweet, is that in bzr too?
[08:45] <robert_ancell> seb128, yes, I figure we'll disable at a later date if it causes problems
[08:45] <seb128> robert_ancell, no, Sarvatt did the update I just sponsored to get some testing there
[08:45] <seb128> robert_ancell, the issue is that it will need mir for the libchamplain etc
[08:45] <seb128> robert_ancell, it can't build until then
[08:45] <seb128> robert_ancell, otherwise back to the topic I think empathy is fine to update, limited risk, easy to downgrade and nice changes
[08:46] <seb128> robert_ancell, do you want me to upload it with the geoclue stack for now?
[08:46] <robert_ancell> seb128, why can't it build?  what happens in maverick if you depend on a universe package?
[08:46] <seb128> robert_ancell, it depwaits
[08:46] <robert_ancell> Ah ok
[08:46] <seb128> robert_ancell, the main builders don't know about universe
[08:46] <seb128> so they will not find the binaries
[08:47] <robert_ancell> seb128, but they can have universe build-eeps right?
[08:47] <robert_ancell> deps
[08:47] <seb128> no
[08:47] <seb128> they don't know about universe
[08:47] <seb128> ie universe is not in their sources.list
[08:47] <robert_ancell> ok
[08:48] <seb128> I will sponsor that
[08:48] <robert_ancell> ok, it's in bzr
[08:48] <seb128> sorry I didn't follow up on other things you mentioned
[08:48] <robert_ancell> np
[08:48] <seb128> where are the compiz updates?
[08:48] <robert_ancell> in bzr (~compiz_)
[08:48] <seb128> I'm also not sure if you let the gnome-menus merge etc for me to finish or still planned to do it
[08:48] <seb128> I got busy with other changes
[08:48] <seb128> but I can catch up today
[08:49] <robert_ancell> yeah, I've just left that one for now, it had changes I didn't understand
[08:49] <seb128> just apply those ;-)
[08:49] <seb128> which ones? want to discuss those now?
[08:49] <robert_ancell> nah, I don't let it through unless I can put a changelog entry and a patch header :)
[08:49] <robert_ancell> ok
[08:50] <seb128> robert_ancell, btw you still have one work item for alpha2 to write a mir for d-conf
[08:50] <seb128> robert_ancell, do we need to get d-conf installed for the new empathy yet?
[08:51] <robert_ancell> seb128, no, but the next release requires it
[08:51] <seb128> ok, so will do
[08:51] <seb128> I will do the libglib update today
[08:52] <seb128> robert_ancell, sorry lot of context switch and catchup, we have low overlap recently and I feel you will call it a week rsn ;-)
[08:52] <robert_ancell> you got 10 minutes :)
[08:52] <seb128> robert_ancell, what are the gnome-menus changes you didn't understand? the ones with "??" in the changelog?
[08:54] <seb128> robert_ancell, so 06_menus_rename.patch and 08_menus_prefix.patch is a debian change
[08:54] <seb128> they prefixed the names on their menus to not conflict with kde
[08:54] <seb128> it did create extra work and some issues though and is not required since the kde ones are already prefixed in ubuntu
[08:55] <seb128> so we don't use those debian changes
[08:55] <robert_ancell> seb128, yeah, looking over it now.  Nothing stands out.  I think it was just a combination of the prerm/postinst changes, the cache and just not being familiar with the pacakge
[08:55] <robert_ancell> compared to compiz it looks simple :)
[08:55] <seb128> the admin one is to hide things which require sudo if you are not in the admin group to use those
[08:56] <seb128> no point to lists entries you can't use
[08:56] <seb128> robert_ancell, great work on the merges btw
[08:56] <seb128> robert_ancell, you did some I wouldn't have started on seing the number of changes, it sometime seems lot of work for low benefit...
[08:57] <seb128> but I guess it's still nice to do those if we can once a cycle to see our changes and reduce delta where we can
[08:57] <robert_ancell> I think if we're going to merge we have to do them all otherwise they'll just get harder and harder to merge in the future
[08:58] <seb128> right
[08:58] <seb128> sometime it's easy the other way around
[08:58] <seb128> diff what debian changed since we merges and apply those changes to what we have
[08:58] <robert_ancell> sure
[08:59] <robert_ancell> seb128, hey, do you know about the latest webkit - 1.3?  Is that going to be released in time for Maverick?
[09:00] <robert_ancell> (and where are their releases?)
[09:00] <didrocks> (2nd warning try) there is a shared gconf key for the used font with empathy, not sure how that can be handled with gsettings
[09:01] <robert_ancell> didrocks, shared between what?
[09:01] <didrocks> robert_ancell: that was what Zdra told me, I can ask him what else uses it
[09:02] <seb128> didrocks, we will get this gconf, gsettings sync issue for some things anyway
[09:02] <seb128> we will need to sort it
[09:03] <didrocks> seb128: yeah, but didn't we tell at UDS "we won't update apps using shared keys?"
[09:03] <seb128> robert_ancell, I guess empathy uses the desktop font settings
[09:03] <robert_ancell> has anyone got any ideas about the gconf->dconf migration?  It requires you to restart your sessing for your keys to be migrated (if the package has a migration script).  If you upgrade and restart your app it will use blank keys until the session is restarted and the migration occurs.  I assume this then overwrites the keys you might have just set
[09:03] <robert_ancell> session
[09:03] <seb128> didrocks, we don't want to step in tricky situations like breaking mimetype handles or automounting or that sort of things
[09:03] <robert_ancell> man my spelling is awful at the moment
[09:04] <didrocks> seb128: ok, for a font settings, it seems not to be so much a big deal
[09:04] <seb128> didrocks, I think if empathy users have to change fonts in empathy that's a fair trading for the new version
[09:04] <didrocks> just wanting to point that :)
[09:04] <seb128> didrocks, thanks
[09:04] <didrocks> robert_ancell: maybe we can drop the magic file to say "restart required"
[09:04] <seb128> robert_ancell, well after distro versions change we highly encourage users to restart
[09:05] <robert_ancell> didrocks, yeah, that was the best I could come up with
[09:05] <robert_ancell> seb128, so can we accept "strange behaviour" if they don't?
[09:05] <didrocks> in any case, with lucid -> maverick upgrades, people will have a new kernel, so it's highely possible they will restart :)
[09:05] <seb128> robert_ancell, yes
[09:05] <robert_ancell> ok
[09:05] <seb128> robert_ancell, we will always have some anyway
[09:07] <robert_ancell> so if empathy is upgraded and uses gsettings (successfully), we should upload any GNOME apps we want as long as they don't use GTK3 and we have the time to support them?
[09:08] <seb128> right and we don't get tricky gconf, dconf shared key issues
[09:08] <seb128> we should review the dg,conf keys used
[09:08] <seb128> I'm a bit concerned for things like proxy to use
[09:09] <robert_ancell> yeah
[09:09] <robert_ancell> anything that is set by gnome-control-center is vulnerable
[09:09] <seb128> but seems GNOME will mostly depends on gtk3
[09:09] <huats> morning
[09:09] <robert_ancell> seb128, what parts of GTK3?
[09:09] <seb128> robert_ancell, gtkapplication
[09:09] <seb128> they will also change their configure to use the new pkgconfig files
[09:10] <seb128> ie gtk+-3.0
[09:10] <robert_ancell> meh, is anyone using that?  (is it required for gnome shell?)
[09:10] <seb128> robert_ancell, it's the libunique replacement for GNOME3
[09:10] <robert_ancell> seb128, it doesn't sound too complex then, a candidate to port to GTK2?
[09:10] <seb128> we might want try to convince upstream to backport gtkapplication to 2.22
[09:10] <seb128> that would make our job easier
[09:11] <seb128> robert_ancell, well I'm a bit careful about what might land in gtk3 and requirements that might be created on the road
[09:11] <seb128> robert_ancell, let's not upgrade everything we can think of but only what we think would be really valuable
[09:12] <seb128> if the new version is mainly a gsettings gtk3 port without nice changes there is no point to take the extra work and risk now
[09:12] <robert_ancell> seb128, I'm thinking it wont be anything too invasive that many apps will pick up, not without more warning than this
[09:12] <seb128> we can have a better overview around 2.31.9x
[09:12] <robert_ancell> yeah
[09:12] <didrocks> urgh, I forgot the "halsectomy" of banshee for UNE
[09:12] <seb128> then decide easily on what we will take
[09:12] <seb128> robert_ancell, but I'm fine doing a GNOME3 ppa if you want
[09:12] <didrocks> pitti: do you think you will have some time to play with removing hal from banshee or do you have a guide so that I can see what I can do?
[09:13] <seb128> robert_ancell, we should just maybe keep focussing a bit on maverick and the platform for now and don't track every 2.31 versions
[09:13] <seb128> robert_ancell, seems we can avoid some work and start getting those updates later in the cycle
[09:14] <pitti> didrocks: that sounds like nontrivial upstream work; you'd need to switch to using media-player-info and add the parser to it which was added to rhythmbox
[09:14] <pitti> to be able to parse music player capabilities, formats, etc.
[09:14] <pitti> it's not just an 1:1 API conversion from libhal to gudev
[09:15] <robert_ancell> seb128, I think we have most of the Maverick platform in place now.  There is some optional/universe stuff like GTK3 but the core platform is ther
[09:15] <didrocks> pitti: urgh, maybe I should talk with upstream about that, that's clearly a showstopper for banshee by default on UNE
[09:15] <pitti> !
[09:15] <seb128> robert_ancell, right, next real task will be to get gtk3 packaged and gtk3 versions of libraries
[09:15] <pitti> didrocks: why do we switch now?
[09:15] <seb128> real -> requiring work
[09:16] <seb128> didrocks, pitti: I though banshee switched to udev etc previous cycle?
[09:16] <pitti> didrocks: it's much slower and memory hungry and uses hal/hal-info; also, does it have u1 music store?
[09:16] <robert_ancell> oh, what do you guys think about putting the latest sane-backends in Lucid?
[09:16] <didrocks> pitti: we talked about that in the UNE session, and there is a better netbook interface that I've hacked on the last few days
[09:16] <seb128> robert_ancell, what does it change?
[09:16] <didrocks> pitti: yes, it has u1 music store plugin
[09:17] <robert_ancell> seb128, lots of bug fixes, I have it in Maverick now, and a Lucid PPA.  It would help a lot of users.  Don't know the best way to test it
[09:17] <robert_ancell> they took ages to make a release
[09:17] <seb128> robert_ancell, do a sru bug, hard to say without saying the diff
[09:17] <seb128> seeing
[09:18] <robert_ancell> that's the issue, the diff will be huge, and there's no way to test any significant proportion of the drivers
[09:18] <seb128> robert_ancell, but seems it something that should be doable, maybe let sit in the candidate update for a while
[09:18] <seb128> to make sure it gets testing
[09:18] <robert_ancell> perhaps the PPA will be good enough, and users will find out about it on the forums
[09:18] <pitti> seb128: I don't know, I'm not following banshee development
[09:18] <pitti> I'm currently dealing with u{dev,disks}-ifying xfce :)
[09:19] <seb128> pitti, ^ do you have an opinion about the sane sru?
[09:19] <pitti> unless it changed ABI, sounds ok; it's by and large adding support for new hw?
[09:19] <RAOF> didrocks: There's a gudev backend in development, Alex Launi has done the initial work.
[09:19] <robert_ancell> pitti, and fixing bugs in existing drivers.  There were some specific models that people were having problems with and used to work in Jaunty
[09:20] <pitti> robert_ancell: diff is still interesting to see what kind of changes it has
[09:20] <robert_ancell> ok, I'll SRU it up next week
[09:20] <didrocks> RAOF: do you think it will be finished before our feature freeze?
[09:20] <pitti> robert_ancell: I can test it on a Canoni LiDE 40, but that has worked for ages
[09:20] <pitti> "Canon"
[09:21] <robert_ancell> without a hardware lab we can't be sure it won't cause regressions.  and it's too much work I think to take individual patches
[09:22] <robert_ancell> beer o'clock!  See you guys later
[09:23] <RAOF> didrocks: Not unless someone steps up and finishes it.
[09:23] <didrocks> enjoy your week-end robert_ancell
[09:23] <didrocks> RAOF: ok, I'll see with jcastro if we can leverage some community help there
[09:24] <RAOF> Dinner making time!
[09:27] <didrocks> RAOF: enjoy :)
[09:58] <didrocks> seb128: if you have some time today, I sponsored kenvandine package for indicator-network yesterday evening. It should be waiting in NEW
[10:01] <seb128> didrocks, ?
[10:01] <seb128> didrocks, I newed it yesterday evening I think
[10:02] <seb128> didrocks, or did that didn't work?
[10:02] <didrocks> seb128: oh sweet, I didn't check TBH, I wasn't thinking you connected back
[10:02] <seb128> I did
[10:02] <didrocks> right, it's done, you are so quick :)
[10:02] <seb128> there is usually quite some sponsoring required on thursday
[10:02]  * didrocks hugs seb128
[10:02] <seb128> kenvandine desktop set upload right don't work for quite some dx sources
[10:02] <seb128> so I usually try to come back to sponsor things he can't upload
[10:03]  * seb128 hugs didrocks back
[10:03] <didrocks> oh ok, it's the "late Thursday tasks" so? :)
[10:03] <seb128> yeah
[10:22] <seb128> pitti, we stopped assigning bugs to desktop-bugs now btw
[10:23] <pitti> seb128: oh, good to know
[10:23] <seb128> pitti, just fyi since I noticed you reassigned one to it
[10:23] <pitti> yes, I'm afraid I have no time for that one, and it didn't seem that urgent
[10:25] <seb128> pitti, yeah, no discussion about the bug itself ;-)
[10:25] <pitti> seb128: is there a replacement for desktop-bugs, or we just stop caring?
[10:26] <seb128> "stop caring" for whatever that means to you ;-)
[10:26] <seb128> we still care about the bug but we have tools to build buglists nowadays without having to assign those to a team in launchpad
[10:26] <pitti> ah, right
[10:27] <seb128> we can do json queries for those now
[10:27] <seb128> ie do "bugs reported on all components this team is subscribed to"
[10:54] <kamstrup> Is it me or are the icons and tiles and the launcher (trunk) a bit blurry?
[10:59] <chrisccoulson> is it possible to do a dist-upgrade between releases with PPA sources? i tested a hardy -> lucid upgrade last night before realising that firefox hadn't been updated because the new version is still only staged in a PPA
[11:00] <chrisccoulson> i suppose that's a mvo question, but he's not around
[11:01] <seb128> chrisccoulson, what do you mean exactly?
[11:01] <seb128> it's always possible to run dist-upgrade, it will just grab newest versions and install those
[11:02] <seb128> or do you mean "does the dist-upgrade tweak ppa source lines as well as normal distro ones"
[11:02] <chrisccoulson> seb128 - i want to do an upgrade from hardy -> lucid, but keeping the u-m-s PPA as a source
[11:02] <seb128> dist-upgrader
[11:02] <seb128> using the graphical dist-upgrader you mean?
[11:02] <chrisccoulson> yeah
[11:02] <seb128> I'm not sure
[11:03] <chrisccoulson> i wanted to make sure the upgrade still works, but i forgot that it disables the PPA sources before the upgrade
[11:03] <seb128> I would add the hardy and lucid ppa lines to the source before running it
[11:03] <seb128> oh
[11:03] <seb128> I guess it's a mvo question then yes
[11:03] <seb128> he will be back on monday
[11:03] <chrisccoulson> thanks, i can wait until then. i've got lots of karmic bugs to fix already ;)
[11:06] <seb128> ok
[11:06] <seb128> didrocks, can you check bug #595867
[11:06] <ubot2> Launchpad bug 595867 in evolution (Ubuntu) "recipient address with german umlauts gets broken on new/reply .. mail (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/595867
[11:07] <seb128> didrocks, the descriptions says it's happening after the recent update
[11:08] <didrocks> seb128: do you think it's the mailing list encoding in e-d-s?
[11:08] <seb128> didrocks, I guess it would be the e-d-s change
[11:08] <seb128> well, I'm not sure
[11:08] <didrocks> hum, not sure I have the time right now, will try to reproduce and revert this change…
[11:09]  * didrocks will never ever have serious time to work on banshee anyway :/
[11:09] <seb128> I can't confirm though
[11:09] <seb128> I've tried to reply to emails from macslow and it works
[11:10] <seb128> didrocks, try maybe just asking questions about since when he's having the issue and how to trigger it easily for now
[11:10] <didrocks> oh really?
[11:10] <didrocks> seb128: sure I will thanks
[11:10] <MacSlow> seb128, cover-display in notificatiosn again?
[11:11] <seb128> MacSlow, no sorry, an evolution bug with names with umlauts, I was taking you as an example to test it
[11:11] <MacSlow> seb128, ah ok
[11:12] <seb128> MacSlow, sorry for the highlight ;-)
[11:12] <MacSlow> didrocks, ok... bring on the german umlauts then :)
[11:14] <didrocks> MacSlow: heh, you have an uptodate lucid too? can you try to hit reply on an email from an expeditor having an umlaut in the name, please?
[11:15] <MacSlow> didrocks, pulled lucid updates yesterday... recent enough?
[11:15] <seb128> yes
[11:15] <didrocks> MacSlow: should be :)
[11:18] <MacSlow> didrocks, ok did that... everything looks ok in the email-reply window
[11:18] <seb128> MacSlow, thanks
[11:18] <didrocks> MacSlow: sweet, thanks a lot :)
[11:18] <MacSlow> seb128, didrocks: np yw
[11:18] <seb128> didrocks, let's start by asking if the issue is in the composer or in the email sent and if that happens with any names with an umlaut
[11:20] <didrocks> seb128: done, thanks
[11:24] <seb128> didrocks, thank you
[13:34] <didrocks> bug #525807 is really embarrassing when you are giving an ubuntu presentation
[13:34] <ubot2> Launchpad bug 525807 in openoffice.org (Ubuntu) (and 2 other projects) "[upstream] [3.2.1] OOo Slide Show and Fullscreen modes - not full screen under compiz (affects: 86) (dups: 6) (heat: 462)" [Medium,Triaged] https://launchpad.net/bugs/525807
[13:35] <seb128> didrocks, did you get hit by this?
[13:35] <didrocks> yeah, during the ubuntu party :)
[13:35] <didrocks> and I'm still hit by this
[13:35] <didrocks> (I'll give an ubuntu presentation in Paris this evening)
[13:35] <didrocks> just tested again and yeah, still there :/
[13:38] <seb128> we should make sure it gets fixed for .1
[13:38] <seb128> ccheney should be back to work so I guess he can work on this one
[13:38] <didrocks> right, this one should be high IMHO to not get dropped for .1
[13:39]  * didrocks tries in metacity as it seems to happen only with compiz from the report
[13:39] <seb128> you should use your netbook and unity for presentations I guess ;-)
[13:40] <didrocks> seb128: heh, unity had some issues with OOo fullscreen too during the party :-)
[13:40] <didrocks> ok, works with metacity, I can workaround with that
[13:41] <didrocks> I put that in autohide but when you show what's new, it wasn't really convenient
[13:42] <seb128> lol
[13:46] <seb128> it's not germany's day
[13:55] <didrocks> why?
[13:56] <ccheney> the fix that went into 3.2.1 should make it into our .1
[13:56] <didrocks> ccheney: apparently, the last person told that the fix in 3.2.1 doesn't work
[13:56] <didrocks> hey btw :)
[13:56] <ccheney> didrocks: hi :)
[13:57] <ccheney> didrocks: hmm, will have to look at the report again, to fix it properly required a pretty invasive change upstream, from what i recall so they were trying to first just fix it for gnome (iirc)
[13:58] <ccheney> but it has been a while since i last read the status for the bug
[13:58] <didrocks> ccheney: ok, if you need testing, do not hesitate
[13:58] <ccheney> didrocks: ok
[13:58] <didrocks> thanks ccheney :)
[14:01] <seb128> ccheney, hey
[14:01] <seb128> ccheney, how are you?
[14:01] <ccheney> seb128, doing pretty well :)
[14:02]  * ccheney brb, have to run to restroom before his daily mumble meeting
[14:04] <didrocks> 14:46:22        seb128 | it's not germany's day
[14:04] <didrocks> seb128: what happened to those poor germans? :)
[14:04] <seb128> didrocks, yeah, serbia scored one, germany got one player out due to a fault and they didn't score the penalty they had
[14:05] <didrocks> ok, it was football, not something broken on ubuntu :)
[14:06] <seb128> didrocks, no ;-)
[14:06] <seb128> right, it's football
[14:07] <didrocks> :-)
[14:07] <seb128> ccheney, didrocks: the slideshow bug is correctly lucid tasked with milestone for lucid .1 now
[14:08] <didrocks> seb128: thanks a lot
[14:08] <seb128> np, thank you for pointing it
[14:12]  * ccheney back
[14:59] <rickspencer3> good morning everyone
[15:06] <seb128> rickspencer3, hello! how are you?
[15:11] <didrocks> good morning rickspencer3
[15:12] <rickspencer3> hi seb128 and didrocks
[15:12] <rickspencer3> I
[15:12] <didrocks> reboot, bbiab
[15:12] <rickspencer3> m good, otp with stormy talking about guadec
[15:54] <seb128> kenvandine, Riddell: could you update https://wiki.ubuntu.com/DesktopTeam/ReleaseStatus if you have anything to set there?
[15:54] <seb128> I will update the list of specs for the cycle in a bit
[15:55] <kenvandine> seb128, sure
[15:56] <seb128> kenvandine, thanks
[15:57] <kenvandine> seb128, the heat for the twitter change in gwibber is off, for now
[15:57] <kenvandine> seb128, they have postponed the change... but no new target date
[15:58] <kenvandine> seb128, they haven't even turned on the new service yet...
[15:58] <seb128> ok
[15:58] <seb128> kenvandine, let's move it to alpha3 then?
[15:58] <kenvandine> hopefully we'll hear when the new date is soon, hopefully it isn't too soon
[15:58] <kenvandine> ok
[16:02] <davidbarth> seb128, kenvandine: will update that now too; ping hard when it's my turn
[16:04] <seb128> davidbarth, ok
[16:39] <rodrigo_> is libappindicator0.1-cil broken in maverick? tomboy doesn't start for one user, while it works for another one
[16:39] <rodrigo_> and can't build a tomboy packae, it complaiuns:
[16:39] <rodrigo_> error CS0006: cannot find metadata file `/usr/lib/cli/appindicator-sharp-0.1/appindicator-sharp.dll'
[16:40] <seb128> rodrigo_, yes, tedg is working on it right now
[16:40] <rodrigo_> ah, ok
[16:40] <seb128> or I think he is
[16:41] <seb128> check with him
[16:46] <rodrigo_> tedg, ^^
[16:51] <tedg> rodrigo_, Sorry, right now learning to hate mono's al >:-(  Should hopefully be fixed in a bit.
[16:52] <rodrigo_> tedg, ok, let me know if you want me to test, I'm waiting on having it fixed for building a tomboy package
[17:32] <didrocks> ok, let's call it a week, going to Paris to give a conference on Ubuntu now :)
[17:34] <didrocks> enjoy your week-end everyone o/
[17:40] <seb128> didrocks, thanks, have fun today and a nice weekend ;-)
[17:45] <schmichael> Is there a simpler example than gwibber on using appindicator from python?
[17:45] <seb128> schmichael, jockey
[17:45] <schmichael> seb128: thanks
[17:45] <seb128> yw
[17:46] <seb128> schmichael, https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators
[17:46] <seb128> schmichael, there is a small code example there as well
[17:46] <schmichael> seb128: yeah, I've done that, but it's a little too simple to be very useful
[17:47] <schmichael> and it uses appindicator when evidently using indicate is preferred
[17:47] <schmichael> and I'd like to integrate with the existing messaging appindicator
[17:49] <schmichael> "NOTICE: 'jockey' packaging is maintained in the 'Bzr' version control system at:"
[17:49] <schmichael> that's pretty cool!
[17:54] <schmichael> seb128: I'm not understanding how jockey uses appindicator. It appears to me to just be a gtk app that uses notify
[17:54] <schmichael> Considering I'm building a messaging related app, I think gwibber is probably what I should be looking at :(
[17:56] <seb128> schmichael, well appindicator does basically what the example on the wiki or jockey are doing...
[17:56] <seb128> ie adding a menu to an icon
[17:57] <seb128> it's what you get for ie the bluetooth icon in lucid
[17:57] <seb128> seems you want to integrate with the messaging menu though rather than using appindicator
[17:57] <seb128> you can ask questions about that on #ayatana
[17:58] <schmichael> hm
[17:58] <schmichael> I have a messaging application which will pop-up notifications that need to fire an event (eg launch an app)
[17:59] <schmichael> Since Ubuntu removed the ability for notifications to do anything, I figured appindicator was the route to go...
[17:59] <schmichael> is that correct? should I take these questions to #ayatana?
[17:59] <schmichael> (and wth is ayatana? I've been an Ubuntu user for years and never heard of that...)
[18:04] <schmichael> "The Ayatana Project is the collective project that houses user interface, design and interaction projects started by Canonical." hm
[18:10] <seb128> schmichael, the indicator work is ayatana work
[18:10] <seb128> as is notify-osd
[18:11] <seb128> schmichael, well, there is a specification about user interactions on the wiki
[18:11] <seb128> schmichael, incoming messages should be queued in the message indicator
[18:12] <seb128> schmichael, things which require user to know about and act with should probably be opened in a dialog
[18:12] <schmichael> hm, interesting. reading the full MessagingMenu wiki now
[18:12] <seb128> ok
[22:04] <Rebus> Perhaps i dropped the question of starting XFCE-desktop in the wrong room (#xubuntu)?
[22:59] <nessita> hello all
[22:59] <nessita> didrocks: you around? I managed to break python-mkdebian ;-)
[23:10] <arand> Is this a place to discuss potential papercuts? I that case I would like to point at Bug #479489 as a good candidate, I've even prepared to report a new bug before i found that, and did a writeup (use case abd all..): http://pastebin.org/340224
[23:10] <ubot2> Launchpad bug 479489 in compiz (Ubuntu) "disable Super+MiddleClick by default (affects: 1) (heat: 15)" [Medium,Triaged] https://launchpad.net/bugs/479489