[02:45] <Unit193> ochosi: So only thing we're waiting for is knome to ack and someone to upload, right?  Everyone is fine with their email/name/etc?
[02:46] <knome> ack from my side.
[02:54] <Unit193> You don't even know if I filled it with rats or something.
[02:55] <knome> we'll find out...
[02:59] <Unit193> Did anyone save the rejected ones?
[03:00] <knome> no, they were infinitely deleted from the planet earth
[03:00] <Unit193> Bummer.
[03:01] <knome> they are still in /Accepted
[03:01] <knome> and in a secret tarball somewhere
[03:01] <knome> and my, ochosi's and probably pleia2's harddrives
[03:14] <bluesabre> mine too
[03:14]  * bluesabre is sneaky
[06:07] <ochosi> Unit193: i've sent them all an email together, let's give them until after the weekend to respond. just in case someone doesnt want their email or realname there...
[06:14] <ochosi> Unit193: so far i only collected the infos, only one of them has ack'ed it expressis verbis
[06:15] <Unit193> Sure, it'd take a while to get it up anywho.
[06:16] <Noskcaj> menulibre is now updated, mugshot is upload ready
[06:16] <Noskcaj> and i'll do parole later tonight
[06:17] <ochosi> i presume 0.6?
[06:19] <Noskcaj> yeah
[06:24] <ochosi> cool
[06:39] <Noskcaj> mugshot's uploaded, but in NEW
[07:36] <elfy> lderan: thanks - seen the pastebin 
[08:54] <zequence> I'd like to add a couple of apps to be autostarted when the user logs in, by default. How does one add that for users, by default?
[09:01] <zequence> Ah, /etc/xdg/autostart/*.desktop
[09:31] <slickymaster> morning all
[10:29] <slickymaster> work meeting
[10:29] <slickymaster> bbl after lunch ->
[11:26] <Unit193> zequence: You may want to make sure it doesn't conflict with another package or settings package.  You can use /etc/xdg/ubuntustudio/autostart/ if the path already exists in another package.
[11:31] <zequence> Unit193: It's for the next version of the application ubuntustudio-controls, and the idea is that it should autostart on any DE
[11:32] <zequence> There's a way to make it only start on certain DEs though, specified in the desktop file
[11:32] <zequence> even if put in /etc/xdg/autostart
[11:33] <Unit193> Yep, and to exclude a few.
[11:33] <Unit193> OnlyShowIn, NotShownIn.
[14:08] <brainwash> bug 880533
[14:09] <brainwash> not yet fixed, delete a file and relog to reproduce it
[14:22] <knome> brainwash, where's your patch for the bug?
[14:56] <brainwash> knome: work in progress I guess
[15:25] <brainwash> does anyone here use whisker menu?
[15:27] <brainwash> if it's the left most item in the panel and you try to drag a panel window button, does the whisker menu panel item turn black?
[15:30] <brainwash> nevermind, it's a known issue
[15:31]  * pmjdebruijn uses 1.3.1 backported to saucy
[15:34] <brainwash> https://github.com/gottcode/xfce4-whiskermenu-plugin/issues/37
[15:34] <brainwash> BUT it might affect more/all external panel plugins
[15:35] <brainwash> occasionally it happens to the places plugin too
[15:35] <pmjdebruijn> sounds like a panel bug?
[15:36] <brainwash> could be, marking whisker menu as internal plugin apparently resolves the glitch
[15:36] <pmjdebruijn> btw in the next intel video driver there are going to be some nice fixes, which are relevant for xfwm
[15:36] <pmjdebruijn> brainwash: huh?
[15:37] <brainwash> "Something else that also solved the bug for me was making the plugin internal instead of external."
[15:38] <brainwash> you mean SNA related fixes?
[15:38] <pmjdebruijn> define internal vs external?
[15:38] <pmjdebruijn> brainwash: indeed
[15:38] <pmjdebruijn> I helped troubleshoot like 5+ bugs in grand total
[15:38] <pmjdebruijn> 2 were xfwm artifacts with sna
[15:38] <pmjdebruijn> and 3 were TearFree related (which defaults to off)
[15:39] <brainwash> ppor dev, he is working on SNA on a daily base, but it still causes so many glitches
[15:39] <brainwash> tearfree related? did not notice anything odd
[15:40] <pmjdebruijn> do you have tearfree enabled i nthe intel driver?
[15:40] <pmjdebruijn> (not xfwm)
[15:40] <brainwash> currently not, but I did enable it occasionally
[15:40] <pmjdebruijn> will latest git master it should finally be reliable
[15:40] <pmjdebruijn> I hit a lot of issues using chromium
[15:40] <brainwash> but didn't notice anything strange
[15:41] <pmjdebruijn> chromium :)
[15:41] <brainwash> other than the expected performance loss
[15:41] <brainwash> oh ok
[15:41] <pmjdebruijn> there were lots of cornercases :)
[15:41] <brainwash> firefox here
[15:41] <pmjdebruijn> yeah didn't have any issues there either
[15:41] <pmjdebruijn> and I had some weird issue with scummvm :)
[15:41] <pmjdebruijn> like I said, I helped troubleshoot 5 (or 6?) issues by now :)
[15:41] <pmjdebruijn> ickle did the hard work of actually fixing stuff
[15:42] <brainwash> awesome :)
[15:42] <pmjdebruijn> just trying to get the intel driver in as best shape as possible for the next LTS
[15:43] <brainwash> hopefully we get all the fixes to land in trusty
[15:44] <brainwash> and regarding internal/external -> https://github.com/gottcode/xfce4-whiskermenu-plugin/issues/37#issuecomment-29758966
[15:45] <brainwash> I assume that the internal plugins are all those which ship with xfce4-panel
[15:45] <brainwash> app menu, window buttons,..
[15:46] <brainwash> I'll file a report against xfce4-panel after some more testing
[15:51]  * slickymaster damns his work internet connection
[15:55] <knome> slickymaster, yes (re: docs meeting)
[15:55] <knome> any reason not o?
[15:55] <knome> to
[15:55] <slickymaster> knome: ok, just lost connectivity and didn't notice 
[15:55] <slickymaster> if you've answer
[15:55] <slickymaster> it's ok with me
[15:55] <knome> ;)
[16:42] <brainwash> pmjdebruijn: https://bugzilla.xfce.org/show_bug.cgi?id=10656
[17:33] <slickymaster> knome: I have to go and pick up my kid at school. will be back in about 45 minutes
[17:33] <slickymaster> ->
[18:01] <ochosi> nice, fixed power-indicator already landed in trusty (with support for xfce4-powerman)
[18:59] <jjfrv8-work> if I disappear unexpectedly, it's because I've got like a triple remote connection going on here
[18:59] <pleia2> hah, sounds fun
[18:59] <jjfrv8-work> if it stays up :)
[18:59] <knome> #startmeeting Xubuntu community meeting
[18:59] <meetingology> Meeting started Thu Jan 30 18:59:47 2014 UTC.  The chair is knome. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[18:59] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[18:59] <knome> so who's here for the meeting
[18:59] <jjfrv8-work> o/
[19:00] <slickymaster> o/
[19:00] <pleia2> o/
[19:01] <elfy> yep
[19:01] <knome> ok, cool
[19:01] <knome> let me get my act together :d
[19:01] <knome> !team | meeting time
[19:02] <knome> #topic Open action items from previous meeting
[19:02] <knome> #action ali1234 follows up on gtk3 indicator status 
[19:02] <meetingology> ACTION: ali1234 follows up on gtk3 indicator status
[19:02] <knome> #action elfy to poke Noskcaj if time-admin and users-admin do not exist in the next daily 
[19:02] <meetingology> ACTION: elfy to poke Noskcaj if time-admin and users-admin do not exist in the next daily
[19:02] <knome> did that happen?
[19:02] <ali1234> again already?
[19:02] <ali1234> where does the time go?
[19:02] <knome> ali1234, shoo :P
[19:02] <elfy> poked and nothing happened
[19:02] <knome> keeping it carried on to make sure things happen
[19:03] <Noskcaj> o/
[19:03] <knome> #action knome to be in touch with people re Tech Lead position 
[19:03] <meetingology> ACTION: knome to be in touch with people re Tech Lead position
[19:03] <knome> still TBD
[19:03] <knome> #action knome to send an email to the mailing list re: bluetooth 
[19:03] <meetingology> ACTION: knome to send an email to the mailing list re: bluetooth
[19:04] <knome> TBD
[19:04] <knome> #action ochosi to follow up on xfce 4.12 release with nick and report back 
[19:04] <meetingology> ACTION: ochosi to follow up on xfce 4.12 release with nick and report back
[19:04] <knome> #action ~QA to write tests for new packages, sync to tracker and call for testing 
[19:04] <meetingology> ACTION: ~QA to write tests for new packages, sync to tracker and call for testing
[19:04] <knome> elfy, want to carry that on?
[19:04] <elfy> well it's ongoing 
[19:05] <knome> i ask you a simple yes/no question and you start with "well..." ;)
[19:05] <elfy> well ... 
[19:05] <elfy> yes
[19:05] <knome> do you need a weekly reminder?
[19:05] <elfy> no
[19:05] <knome> ok
[19:05] <knome> haha, so dropping it then :P
[19:05] <knome> #undo
[19:05] <meetingology> Removing item from minutes: <MeetBot.items.Action object at 0x1769290>
[19:05] <elfy> ok :p
[19:05] <knome> #action team members that are able to test/use bluetooth stuff, consider which software they would like to use, if it matters 
[19:05] <meetingology> ACTION: team members that are able to test/use bluetooth stuff, consider which software they would like to use, if it matters
[19:05] <knome> #nick team
[19:05] <knome> that's it.
[19:05] <knome> #topic Team updates
[19:06] <knome> please use #info and #action (for new action items) as appropriate
[19:06] <knome> lderan, autopilot
[19:06] <knome> Unit193, -core email
[19:06] <knome> #info knome updated the meetings page with the new structure
[19:06] <slickymaster> #info slickymaster finished Mugshot's online documentation -> http://smdavis.us/doku/doku.php?id=mugshot-docs
[19:07] <elfy> #info Image testing for the last 7 days -> 64 bit image tests 3, no 32 bit tests reported
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 64 bit 13.10 to 14.04 5 reported for update manager upgrading, no tests from image
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 64 bit lts to lts 5 reported for update manager upgrading, 3 reported for image update
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 32 bit 13.10 to 14.04 2 reported for update manager upgrading, no tests from image
[19:07] <elfy> #info Upgrade testing since call earlier in the week - 32 bit lts to lts 2 reported for update manager upgrading, none reported for image update
[19:07] <elfy> #info Settings Manager test call out soon - includes light-locker
[19:07] <knome> #info knome looked into the docs SRU and the new, fixed package (thanks bluesabre) should land in precise any day.
[19:07] <elfy> #info Manual testcase continues prior to calls 
[19:07] <knome> ali1234, news about gtk3 indicators?
[19:08] <knome> #info knome, ochosi and pleia2 held a meeting and selected the winners for the community wallpapers
[19:08] <ali1234> some changes were pushed to the indicators but still no fix to the core library problems afaik
[19:08] <knome> #info knome did housecleaning on the blueprints
[19:08] <knome> ali1234, ok, cheers
[19:08] <Noskcaj> #info mugshot in debian NEW
[19:08] <Noskcaj> #info menulibre updated
[19:09] <Noskcaj> #info parole 0.6 in ubuntu repos
[19:09] <knome> Noskcaj, i'd appreciate "#info Noskcaj did ..." (easier for the team reports)
[19:09] <Noskcaj> ok.
[19:09] <ali1234> it's looking a lot like we'll have to wait until feature freeze and then demand it's either fixed or rolled back
[19:09] <slickymaster> #info slickymaster started to work on migrating Mugshot documentation into docbook format
[19:09] <Noskcaj> #info Noskcaj updated gthumb to 3.3
[19:09] <knome> ali1234, but new "features" are in already, just broken?
[19:10] <micahg-work> ali1234, does the current gtk3 indicator stack need to be uploaded to the archive still or is that waiting on fixes?
[19:10] <ali1234> micahg-work: there is nothing new on our side. the problems all exist in the unity stack
[19:10] <Unit193> knome: Yes?
[19:10] <ali1234> knome: the new features are in some packages and not others
[19:10] <knome> Unit193, please #info that you actually did something!
[19:10] <ali1234> that mismatch is half the problem
[19:11] <knome> ali1234, okay. then we should get the new features in before FF if at all possible (there's still time)
[19:11] <knome> ali1234, but other than that, FF shouldn't be the hard deadline for the fixes, and i'm optimistic of landing those fixes
[19:11] <ali1234> i don't know the status of stuff like xfce4-panel actually
[19:11] <micahg-work> I uploaded 2 SRUs, but I don't remember which ones
[19:12] <ali1234> we can't land any fixes in libindicator3 for example, that is what is currently broken
[19:12] <ali1234> and it is broken in unity too, still
[19:12] <Unit193> #info Unit193 sent a message to the list about the xubuntu-core meta.
[19:12] <micahg-work> ali1234, is there a summary of the issues somewhere (or list of bugs)
[19:12] <knome> #info lderan made a list of apps that can be ran simple "does it open" tests with autopilot: http://paste.ubuntu.com/6840722/
[19:13] <ali1234> micahg-work: see https://bugs.launchpad.net/indicator-network/+bug/1185565 and https://code.launchpad.net/~a-j-buxton/libindicator/remove-timeout/+merge/198070
[19:13] <knome> ali1234, micahg-work: if you don't mind, i'll add an action item for you to follow up on it and actually fix the stupid issues
[19:13] <knome> #action ali1234 and micahg to follow up on gtk3 indicator stack issues
[19:13] <meetingology> ACTION: ali1234 and micahg to follow up on gtk3 indicator stack issues
[19:13] <knome> #nick micahg
[19:13] <ali1234> i already sent a MR, there's nothing more i can do until tedg gets around to fixing it
[19:14] <micahg-work> ali1234, poke tedg and ask if he has time to review or can hand off to someone else
[19:14] <ali1234> i'm poking him once a week already
[19:14] <knome> micahg-work, any possibility you could oversee how that goes? would be good to have more people on top of the issue
[19:15] <ali1234> i've spoken to him several times about this already and it's always "yeah, i'm working on it"
[19:15] <ali1234> he knows and understands the problems we face
[19:16] <micahg-work> well, that's great, but I don't see why an MR should go 8 weeks without a review 
[19:16]  * micahg-work <-- pot
[19:16] <ali1234> because it's part of a much bigger change, basically
[19:17] <micahg-work> yes, but there are ways to move these things forward, maybe it should be merged into a branch instead
[19:17] <ali1234> there are a bunch of other issues around this too, like under xubuntu it wont actually use upstart to launch indicators, because it's hardcoded to only do that in unity
[19:17] <knome> looking at the bug, not everybody agrees with what is going on
[19:17] <ali1234> knome: right
[19:17] <ali1234> that's a problem too
[19:18] <knome> i guess we're fine to do weekly reminders for a few more weeks
[19:18] <knome> if things do not progress, look at it again then
[19:18] <jjfrv8-work> sorry about that. I'm back.
[19:18] <knome> i guess another thing you could try, ali1234, is add more reviewers for the MP.
[19:18] <knome> jjfrv8-work, np :)
[19:19] <micahg-work> rewriting the indicator stack for the LTS seems so wrong...
[19:19] <ali1234> right, this is why i mentioned FF and either fix NOW or rollback
[19:19] <micahg-work> yeah
[19:20] <knome> as long as gtk3 indicators work for us, i don't mind how this falls
[19:20] <ali1234> we can always add the workaround to the environment
[19:20] <knome> ali1234, micahg-work: please obey the action item and follow up on it as much as needed :)
[19:20] <knome> and i'm of course also available, if you need something i can do to help.
[19:21] <brainwash> maybe we could already switch to gtk3 indicators and use the workaround (exporting an env var)
[19:22] <micahg-work> wait, we're still on GTK2 indicators?
[19:22] <knome> since FF is still somewhat far, i don't think it makes sense to push a workaround and then start using the new "real" fix
[19:22] <ali1234> agreed
[19:22] <ali1234> but it's always there if we need it
[19:22] <brainwash> the workaround can be reverted easily
[19:22] <knome> rather wait until the FF, and if the situation *then* looks stupid, do the workaround
[19:22] <brainwash> ok
[19:22] <knome> brainwash, it's still more work to get the workaround up than not.
[19:22] <ali1234> micahg-work: i'm not sure what is actually in the archive, because i work mainly upstream
[19:23] <micahg-work> ok
[19:23] <knome> we have to believe things are going to be fixed eventually
[19:23] <Noskcaj> micahg-work, i've got the stuff in a PPA, but i'd rather wait for a real release to upload stuff
[19:23] <brainwash> yes, Noskcaj's PPA + workaround works fine
[19:23] <Noskcaj> archive is all possible 4.11 stuff + garcon git snapshot
[19:24] <micahg-work> while I generally prefer that, we need baketime for the LTS, now if it'll just be broken in the archive, there's no point in uploading
[19:24] <ali1234> it's not as badly broken as gtk2 indicators...
[19:24] <knome> well exactly, my opinion is: hold until nearer to FF
[19:25] <knome> and see if things are fixed and then decide what to do, once, rather than uploading any workarounds now and having to poke around it later
[19:26] <Noskcaj> Is that for both panel and indicator?
[19:27] <brainwash> there is no panel 4.11 release yet
[19:28] <knome> looks like we're done with this. people involved, please keep in touch with each other.
[19:28] <knome> #topic Announcements
[19:28] <knome> i have one!
[19:28] <knome> at the end of the T cycle, jjfrv8-work will step from the doc lead position.
[19:29] <knome> while the T cycle lasts, he will keep on leading, with the assistance of slickymaster 
[19:30] <knome> and if everything goes well, jjfrv8-work should be able to hand over the leader hat to slickymaster at the start of the U cycle
[19:30] <knome> of course, with the approval of the team
[19:30]  * Unit193 approves.
[19:30]  * elfy approves
[19:30]  * pleia2 approves
[19:31] <knome> we are going to have a meeting on docs issues sometime soon, where those two can update each other on the situation etc.
[19:31]  * Noskcaj approves  the approvals
[19:31] <micahg-work> sure
[19:31] <knome> (well the approval should happen later, when U cycle is starting :P)
[19:31] <knome> so, anybody interested in docs... hear hear!
[19:31] <knome> jjfrv8-work, slickymaster: you around to schedule?
[19:31] <slickymaster> yeaps
[19:31] <jjfrv8-work> yes
[19:32] <knome> whatever time works for you two is the best
[19:32] <knome> next week before/after the community meeting?
[19:33] <jjfrv8-work> next week I should be pretty flexible
[19:33] <slickymaster> next week is my ubuntu membership meeting
[19:33] <slickymaster> it depends on how much it will eventually take
[19:33] <knome> friday though, isn't that it
[19:34] <slickymaster> on the UM meeting ins on the 6th
[19:34] <slickymaster> is^^
[19:34] <knome> aha
[19:34] <knome> then i've mismarked that on my calendar ;)
[19:34] <knome> what about wednesday 19utc then?
[19:35] <jjfrv8-work> ok with me
[19:35] <slickymaster> fine with me, also
[19:35] <knome> ok, that's it
[19:35] <knome> #info Documentation checkup meeting on Wednesday, Feb 5 at 19UTC
[19:36] <knome> aaand thanks for both jjfrv8-work and slickymaster for all the work they have done this far and will do in the future!
[19:36] <knome> any other announcements?
[19:36]  * pleia2 adds to calendar
[19:36] <knome> pleia2, ta
[19:36] <knome> pleia2, you can add thu 19utc as the community meeting while you're at it
[19:37] <knome> ok, moving on
[19:37] <knome> #topic Agenda
[19:37] <knome> #subtopic Enabling more people to push to Xubuntu branches (separate branches team, or would -team do?)
[19:37] <knome> micahg-work, ping
[19:37] <micahg-work> yes?
[19:37] <knome> see the subtopic
[19:37] <knome> basically, we'd like to allow more people to be able to push to xubuntu branches
[19:37] <micahg-work> depends on the branches
[19:38] <knome> -default-settings
[19:38] <knome> mostly, i think
[19:38] <micahg-work> we can separate the branches from the uploaders team
[19:38] <knome> mhm
[19:39] <knome> do you think it would be ok to add them under ~xubuntu-team, or would you prefer a new team?
[19:39] <Noskcaj> I'd suggest we allow -team to modify branches
[19:39] <micahg-work> but I'd prefer to limit the people who can push to people who understand the package and have proven through MRs that they know what they're doing
[19:39] <Unit193> Would be best to use merges and have a couple review and approve.
[19:39] <micahg-work> yes
[19:39] <knome> ok, so something like ~xubuntu-branches
[19:39]  * Unit193 likes to have at least bluesabre take a look.
[19:40] <micahg-work> so, I'd basically move the xubuntu-dev team out of the DMB control and we would create a new team for uploaders when someone needs that
[19:40] <micahg-work> xubuntu-dev is fine
[19:40] <knome> ok,
[19:40] <knome> when you say "when someone needs that", what are you exactly referring to?
[19:40] <knome> when somebody gains packageset uploader access?
[19:40] <micahg-work> yes
[19:41] <Noskcaj> That takes for ever
[19:41] <knome> right, i would hope that happens sometime soon
[19:41] <knome> and rather create a new team for -branches
[19:41] <Noskcaj> micahg-work, Is there anything you can do to speed up my application?
[19:41] <Noskcaj> It will be a month tomorrow
[19:41] <Noskcaj> probably a new record
[19:41] <knome> but i guess i'm fine with doing what you proposed, then create ~xubuntu-dev-upload if/when we need it
[19:41] <micahg-work> Noskcaj, it's being discussed
[19:42] <Noskcaj> ok
[19:42] <micahg-work> knome, the uploader team would be managed by the DMB, so, nothing to worry about there
[19:42] <knome> micahg-work, sure
[19:43] <knome> micahg-work, can i get back to you on this in a week or so, to land the change
[19:43] <micahg-work> land what change?
[19:43] <knome> the LP teams changes, and separating -dev from upload stuff
[19:43] <knome> or would you rather just do it right away, or does it need some ack from the DMB?
[19:43] <micahg-work> oh, I just need to discuss quickly with the DMB
[19:43] <knome> ok, sure
[19:44] <knome> #action micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
[19:44] <meetingology> ACTION: micahg to talk with the DMB and separate -dev from upload rights so we can allow more people to push to xubuntu branches
[19:44] <knome> #info if we need packageset uploader rights for certain people later, we shall create a new team for that purpose
[19:45] <micahg-work> nope
[19:45] <micahg-work> DMB would create that
[19:45] <knome> #undo
[19:45] <meetingology> Removing item from minutes: <MeetBot.items.Info object at 0x1632310>
[19:45] <knome> #info if we need packageset uploader rights for certain people later, we shall ask DMB to create a new team for that purpose
[19:46] <knome> nitpicking says me!
[19:46] <knome> #subtopic Status of Bluetooth in Xubuntu; what kind of testing we want to run, which software we want to use? 
[19:46] <knome> micahg-work, do you have any opinion to that discussion?
[19:46] <micahg-work> ah, so, I think blueman upstream has be revived
[19:47] <Noskcaj> fyi: i updated blueman last week
[19:47] <knome> do we have a preference? do they all work with indicators, or do we need to consider that kind of issues?
[19:48] <micahg-work> is there something better out there, IIRC, blueman was the only one that worked well that didn't pull in half the GNOME stack
[19:49] <knome> then that sounds like a good one to use
[19:49] <knome> if there's no problems with using that...
[19:49] <micahg-work> if there's another alternative, I'm all ears, but with the recent resurgence of development on blueman, I think it's a good horse to be hitched to
[19:49] <Noskcaj> I think blueman has a memory leak though
[19:50] <cyphermox> there are no big alternatives really
[19:50] <cyphermox> memleaks are fixable ;)
[19:50]  * micahg-work waves to cyphermox 
[19:50]  * cyphermox waves back
[19:51] <Noskcaj> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700863
[19:51] <Noskcaj> There's two other memory leaks i know of in xubuntu, so if someone could help me with them after the meeting
[19:52] <micahg-work> 1 year with no response from reporter , that bug isn't likely to be addressed
[19:52] <Noskcaj> no
[19:52] <knome> can anybody from the team even confirm that bug?
[19:53] <Noskcaj> It's just blueman uses 40mb of ram here and i've never used bluetooth
[19:53] <micahg-work> that doesn't sound like a memory leak as much as not loading on demand
[19:53] <cyphermox> Noskcaj: guess it would be worth running it through massif
[19:54] <micahg-work> if you said 400MB, that would sound like a memory leak
[19:54] <Noskcaj> I'll leave it on during the day to see if i can reproduce it
[19:54] <cyphermox> micahg-work: it really ought to be running all the time, to be able to get you anything
[19:54] <cyphermox> unless you don't have a bluetooth device of course
[19:54] <micahg-work> cyphermox, right, I have that on one machine, bluetooth is off and it's running
[19:54] <cyphermox> ah
[19:56] <knome> so i guess the gist is that we should use blueman.
[19:56] <knome> great, go file bugs!
[19:56] <knome> (:
[19:57] <knome> #subtopic Discuss documentation translations
[19:57] <knome> we should mostly do this on the docs meeting, but...
[19:57] <elfy> ummm - so what about testing blueman - forget it ?
[19:57] <knome> right... test it!  :)
[19:57] <micahg-work> hrm?
[19:58] <knome> micahg-work, hrm to what?
[19:58] <micahg-work> can launchpad not translate the docs?
[19:58] <micahg-work> hrm to test..
[19:58] <knome> it can
[19:58] <knome> we're doing that.
[19:58] <knome> we have the .po files in the branch
[19:58] <elfy> #action Someone with bluetooth to write a testcase
[19:58] <meetingology> ACTION: Someone with bluetooth to write a testcase
[19:59] <knome> but we need to tweak the packaging to build the translations and display them in a sane way
[19:59] <knome> Unit193 has been helping with that
[19:59] <slickymaster> there are already finish and portuguese versions of the docs
[19:59] <slickymaster> finnish ^^
[19:59] <knome> we also might need/want to set some kind of cut-off percentages, if that's not happening now
[19:59] <knome> micahg-work, if you happen to know about that side as well, poke Unit193 and me..
[20:00] <micahg-work> not too much, I could help on the packaging side
[20:00] <Unit193> knome: It was for me, I have that set up but not sure if any sane person would like it. :P
[20:00] <elfy> I've gtg - thanks - cya 
[20:00] <knome> micahg-work, that's probably helpful as well
[20:00] <knome> but ok, let's follow up on that
[20:00] <knome> #topic Schedule next meeting
[20:01] <knome> #info Next meeting Thursday, Feb 6, 19UTC
[20:01] <knome> #endmeeting
[20:01] <meetingology> Meeting ended Thu Jan 30 20:01:21 2014 UTC.  
[20:01] <meetingology> Minutes (wiki):        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-01-30-18.59.moin.txt
[20:01] <meetingology> Minutes (html):        http://ubottu.com/meetingology/logs/xubuntu-devel/2014/xubuntu-devel.2014-01-30-18.59.html
[20:01] <pleia2> on the calendar :)
[20:01] <knome> Noskcaj, so what about time- and users-admin?
[20:01] <Unit193> Hah, beat me.
[20:01] <Noskcaj> knome, I have no idea
[20:02] <Noskcaj> elfy has issues with it, i just did ask pitti asked, since i don't know the package very well
[20:02] <knome> Noskcaj, you can't leave a mess behind.
[20:02] <Noskcaj> i know. I think i asked elfy to ask pitti about it
[20:03] <knome> Noskcaj, why can't you ask pitti as you were the one who made the changes?
[20:03] <knome> i can't see why elfy would need to pick it up
[20:03] <Noskcaj> good point. My reasoning was i don't understand the issue
[20:03] <Unit193> micahg-work: I changed the packaging locally to be 'dh7' or dh sequencing, and a couple others.
[20:04] <Unit193> Noskcaj: Issue is, nothing is installed except 'pixmaps', try installing the package.
[20:04] <Unit193> Look at the .install file
[20:04] <Noskcaj> That's how debian has it, strangely
[20:04] <knome> maybe the debian package is broken
[20:04] <Unit193> knome: No, it's not split up.
[20:05] <knome> okay, then maybe the ubuntu port is broken
[20:05] <knome> which leads us to... Noskcaj, please fix it. Unit193 just told you what's wrong
[20:05] <Noskcaj> ok
[20:05] <knome> thanks
[20:06] <Noskcaj> on a different topic, do we want xkb-plugin 0.7 ?
[20:06] <Unit193> https://launchpad.net/ubuntu/+source/gnome-system-tools built packages vs http://packages.qa.debian.org/g/gnome-system-tools.html binaries.
[20:06] <knome> would also think cleaning your mess would help you gaining access rights
[20:06] <knome> re: xkb-plugin; i don't know; is there a very specific reason to have it?
[20:06] <Unit193> xkb-plugin?  Is that seeded?
[20:07] <Unit193> So it is.
[20:08] <knome> i'm off.
[20:08] <Unit193> knome: You know what's proper in a Makefile? :P
[20:08] <knome> see you later :)
[20:08] <Unit193> Bah.
[20:08] <Unit193> Chau.
[20:08] <knome> Unit193, no
[20:08] <Noskcaj> debian dropped back off 0.7, it might be worth seeing if we want it. http://metadata.ftp-master.debian.org/changelogs/main/x/xfce4-xkb-plugin/unstable_changelog
[20:08] <knome> you can tell me and i'll read it when i get back ;)
[20:09] <slickymaster> dinner time for. bbl ->
[20:09] <knome> Noskcaj, that doesn't tell much
[20:09] <knome> but yeah, i'm really off
[20:09] <knome>  ->
[20:20] <Noskcaj> the new xkb plugin is for settings 4.11, and the current one might break settings
[20:21] <Noskcaj> It will also allow us to patch bug 733563
[20:24] <Unit193> slickymaster: Russian is also pretty complete, but not fully.
[20:39] <Noskcaj> Unit193, you're right, all the files are missing from the binary. I'm guessing it's the extra packages we make
[21:05] <Noskcaj> https://code.launchpad.net/~noskcaj/ubuntu/trusty/gnome-system-tools/regression-fix/+merge/204099
[21:27] <ochosi> hmpf, wasn't able to make the meeting...
[21:30] <Unit193> That's alright, we just assigned everything to you.
[21:33] <ochosi> cool
[21:37] <slickymaster> yeah Unit193, Russian is 84% done
[21:38] <slickymaster> and GridCube has been keeping himself busy, the Spanish translation is half way through it
[21:38] <ochosi> so gtk3-panel and indicators are on hold, eh? :/#
[22:07] <Unit193> slickymaster: Not quite >80% yet though, so not autogenerated.
[22:08] <slickymaster> ok
[22:59] <knome> ochosi, until they work, or until we are so close to FF that we will (have to) land them with a workaround
[23:01] <knome> Noskcaj, fixing that bug is nowhere near our top priority
[23:01] <ochosi> actually the only indicator that doesn't work for me is appindicator at the moment
[23:01] <ochosi> sound and power work just fine
[23:01]  * Unit193 downloaded that one from saucy repos, works fine. :P
[23:02] <ochosi> yeah, but only because there is no upstart job yet
[23:02] <ochosi> (which is why it's borked in the first place i guess)
[23:03] <knome> ochosi, the ubuntu folks do not agree on whether they should have upstart jobs or "actually fix" .. something
[23:03] <Unit193> I like how they land something that's half transitioned, thus broken. :D
[23:03] <knome> yep
[23:04] <knome> but isn't that how it always goes?
[23:04] <ochosi> yeah, but at least the panel we will need if we want gtk3 indicators
[23:04] <knome> "ok boys, this cycle, no breaking stuff"
[23:04] <knome> "oops we landed that too early"
[23:04] <ochosi> that wouldn't be affected by changes to the indicator stack, it would mostly affect xfce4-indicator-plugin
[23:04] <knome> ochosi, well you read my reasoning why we want to hold
[23:04] <knome> ochosi, or why i want to hold
[23:06] <knome> ochosi, the branches stuff is moving forward.
[23:07] <ochosi> yeah, looking forward to that
[23:08] <ochosi> we should definitely try to prepare branches for the case that indicators get fixed with upstart jobs (or even: for the case that we use them)
[23:08] <ochosi> especially a default-settings branch and a seed-branch
[23:11] <Unit193> Yes, but just swap out the indicator-*-gtk2 for indicator-foo.  That's application and sound.
[23:11] <ochosi> well, and add in -power
[23:11] <ochosi> (and set powerman to always hide the trayicon)
[23:11] <Unit193> Doesn't xfpm do whatever that does?
[23:12] <Unit193> Just because we can't doesn't mean we should.  Something about seeding "all" doesn't make sense either, since that'd be at least: indicator-application indicator-appmenu indicator-appmenu-tools indicator-bluetooth indicator-china-weather indicator-cpufreq indicator-datetime indicator-sync indicator-sound indicator-session indicator-printers indicator-power indicator-network indicator-multiload indicator-messages indicator-location ...
[23:13] <Unit193> ... indicator-keyboard
[23:20] <ochosi> yeah, seeding sound, application, power and if needed bluetooth seems good enough
[23:21] <Unit193> Bleh. :P
[23:21] <knome> printers?
[23:21] <ochosi> i think they use app-indicators atm
[23:27] <knome> bluesabre, just don't take too much on your plate :)
[23:27] <Unit193> ^ +1
[23:27] <knome> bluesabre, but i just wanted to let you know people are asking about that
[23:27] <Unit193> I'm still interested as well, I wouldn't purge that.
[23:28] <knome> same.
[23:28] <brainwash> ochosi: and messages?
[23:28] <ochosi> yeah, guess also messages
[23:29] <brainwash> what about printers?
[23:29] <ochosi> but i don't have a strong opinion on messages as i've never used it
[23:29] <ochosi> afaik printers use indicator-application atm
[23:29] <Unit193> Already have something for printers.
[23:29] <knome> my take on it is that some people like it, some people hate it
[23:30] <ochosi> like/hate what?
[23:30] <ochosi> messaging?
[23:30] <ochosi> err, -messages?
[23:30] <knome> yep
[23:31] <ochosi> well i don't have a strong opinion because i've never tried how well it works with out default messaging apps
[23:31] <knome> yep
[23:31] <ochosi> (thunderbird, pidgin..)
[23:31] <knome> well,
[23:31] <knome> it could be a make-or-break thing for *single* users, but not the distro
[23:35] <bluesabre> from my experience, it works great for pidgin and thunderbird
[23:35] <Unit193> Quassel is iffy.
[23:35] <bluesabre> (finally caught up)
[23:36] <Unit193> Click any notification bubbles and up pops quassel...
[23:36] <bluesabre> but... thats not the indicator
[23:36] <bluesabre> :
[23:37] <Unit193> Right.
[23:37] <Unit193> (Quassel works with the indicator though, sort of.)
[23:38] <bluesabre> anybody else think action buttons at the top of a window are stupid? http://worldofgnome.org/a-redesigned-file-picker-4-gnome-mockups/
[23:39] <Unit193> Very.
[23:40] <Unit193> When the Windows Metro UI is starting to look sane....
[23:40] <bluesabre> :)
[23:40] <bluesabre> btw, adding these packages could be a value-add: libappindicator1    libappindicator3-1
[23:41] <knome> value added tax?
[23:41] <bluesabre> they're not pulled by the indicator stack, or indicator-application, yet they are required for skype and dropbox indicators (with no documentation)
[23:42] <bluesabre> and probably others as well
[23:42] <Unit193> Package: nautilus-dropbox -> Recommends: libappindicator1
[23:43] <bluesabre> it might be the 3-1 that is required then
[23:43] <bluesabre> there is an askubuntu about it somewhere
[23:43] <bluesabre> anyway, :_
[23:43] <bluesabre> )
[23:43] <Unit193> indicator-application: Depends: libappindicator3-1  same with network-manager-gnome.
[23:44]  * bluesabre will do more research to figure out what the lib is later
[23:45] <Unit193> libappindicator3-1 is even pulled in onto xubuntu-core, which doesn't even have the indicators. :D
[23:45]  * bluesabre returns to programming
[23:45] <Unit193> bluesabre: Yes, and when you figure out why there is a libappindicator1, libappindicator3-1, libindicate5, libindicator3-7, and libindicator7 tell us?? :P
[23:46] <Unit193> Sure, have fun!
[23:46] <bluesabre> because ubuntu!
[23:47] <ali1234> the ones with -3 are the gtk versions
[23:47] <ali1234> gtk3 versions
[23:47] <Unit193> libappindicator3-1 and libindicator3-7 are hard deps from something because -core pulls those two (and those are the only *indicat* packages.)
[23:47] <Unit193> Ah, hrm.
[23:47] <ali1234> appindicator is how all apps make their own indicators
[23:48] <ali1234> you either use appindicator, or you integrate with an existing indicator (sound, message...)
[23:48] <ochosi> yeah, which makes it suck even more that that one is currently not working in trusty :/
[23:48] <ali1234> appindicator = indicator-application
[23:48] <ochosi> yeah
[23:48] <ali1234> libindicator5 = i have no idea what that is
[23:49] <Unit193> libappindicator1 gtk2, libappindicator3-1 gtk3 and they are for the indicator-application, OK.
[23:49] <ochosi> frankly, i've been wondering since saucy whether we should just try to avoid indicators in our default panel layout
[23:49] <Unit193> 5 is what threw me off, this all makes more sense now except for that.
[23:49] <knome> ochosi, sucks for laptop users
[23:49] <ochosi> there was once talk of an mpris2 plugin for the xfce-panel
[23:49] <ochosi> knome: why?
[23:50] <knome> battery indicator?
[23:50] <Unit193> ali1234: Thanks.
[23:50] <knome> or is there still components for the notification area?
[23:50] <ochosi> knome: we never had an indicator for that
[23:50] <ochosi> that was always a trayicon
[23:50] <knome> what about sound?
[23:50] <Unit193> !info volumeicon
[23:50] <ochosi> that is an indicator, actually the only real one we have
[23:50] <Unit193> !info volumeicon-alsa
[23:50] <brainwash> xfce4-mixer plugin
[23:50] <Unit193> Boom.
[23:50] <knome> alsa, meh
[23:50] <ochosi> Unit193: we need something for pulse though
[23:51] <ali1234> basically without indicators you are stuck using the horrible crappy and broken tray icons, or writing xfce panel plugins
[23:51] <knome> ochosi, ^ that might be your winning answer
[23:51] <Unit193> ochosi: Well, that source package now supports pulse.
[23:51] <knome> i don't think migrating to indicators *itself* is too bad...
[23:51] <ali1234> if you think indicators are bad, tray icons are 100x worse
[23:51] <bluesabre> yes
[23:51] <ochosi> yeah, i agree that trayicons suck
[23:51] <brainwash> why do they suck?
[23:52] <knome> aaand we have a winner ;)
[23:52] <knome> congrats ali1234 
[23:52] <ali1234> no multimonitor support, not process separation...
[23:52] <bluesabre> thing is, everything will be significantly easier once there is an official gtk3 xfce4-panel
[23:52] <knome> bluesabre, now you're kidding ;)
[23:52] <bluesabre> no more hacky workarounds
[23:52] <bluesabre> when we get that 
[23:52] <bluesabre> in 2017
[23:52] <ochosi> well in fact the current git-panel handles it okay
[23:52] <knome> besides, didn't you go back to programming?
[23:52] <bluesabre> after gtk5 is out
[23:52] <knome> ochosi, isn't that what we're going to land in T?
[23:52] <ali1234> there wont be a gtk5
[23:52] <bluesabre> there's interesting discussion here
[23:53] <ali1234> there will be nothing left to remove by gtk4
[23:53] <knome> procrastinating, i see
[23:53] <bluesabre> haha
[23:53] <ochosi> anyhow, i think i'll try to do releases for our themes now, adding in support for gtk3 indicators, in case they ever land...
[23:53] <ochosi> ali1234: hehe, good point
[23:53] <knome> ochosi, they will, one way or another
[23:53] <bluesabre> ali1234: what about all the stuff they are adding in gtk3? they can get rid of that :)
[23:53] <knome> ochosi, they aren't on infinite hold, just "for now"
[23:53] <knome> ochosi, don't worry!
[23:54] <knome> i hate to see ochosi sad
[23:54] <ochosi> knome: yeah, trying hard to start loving the bomb...
[23:55] <knome> i hate even more when ochosi is ironic, but kind of right
[23:55] <dr_strangelove> maybe that helps
[23:55] <dr_strangelove> meh, doesn't seem to help...
[23:56] <ochosi> ali1234: quick question, as that's kinda relevant for our default panel setup, are you aiming at 14.04 with panel-switch?
[23:56] <ali1234> no, not really
[23:56] <ochosi> okey
[23:56] <knome> ali1234, maybe you should ;)
[23:56] <knome> push, push, push!
[23:56] <ali1234> i noticed that debian has a tool for this already
[23:57] <ali1234> when you first log in it asks you what layout you want
[23:57] <knome> does it bring half of gnome?
[23:57] <ali1234> you only get two choices though
[23:57] <ali1234> i dunno, it's installed y default
[23:57] <ochosi> that sounds nice actually
[23:57] <ochosi> i mean only being asked once is kinda "hmmm"
[23:57] <ochosi> but still
[23:58] <knome> doesn't allow experimenting
[23:58] <knome> so it's really "meh"