[09:33] <bluesabre> Can anybody confirm if this is still an issue for them: https://bugs.launchpad.net/light-locker-settings/+bug/1303652
[09:33] <bluesabre> /them/you
[09:51] <ochosi> elfy: hmm, those two testers on the lid-close bug seem to have misunderstood the bug. one thinks it's related to the screen DPMS setting and the other seems to think it's related to auto-login on boot time...
[09:53] <ochosi> so i'm kinda wondering whether to ignore that...
[11:30] <ochosi> hey sergio-br2 
[11:31] <knome> elfy, see my looong reply ;)
[11:36] <sergio-br2> hey ochosi
[11:36] <sergio-br2> congratulations 
[11:37] <sergio-br2> (late...)
[11:37] <ochosi> thanks sergio-br2 
[11:37] <ochosi> make sure you "git pull" before committing stuff in elementary-xfce ;)
[11:38] <ochosi> anyway, wanted to ask how things are going with the open issues for our next release
[11:38] <ochosi> i also noticed that i have to draw two more libreoffice sizes (there are currently 128px apps and 96px mimes in the old style)
[11:38] <sergio-br2> yeah, i messed up, sorry
[11:39] <ochosi> hehe, no problem, it happens
[11:42] <sergio-br2> lua mime is uploaded, with that 24 px icon. I don't know if it's worth doing 16 px for the news mimes
[11:42] <sergio-br2> (and i tried other color, not so good)
[11:44] <ochosi> news mimes?
[11:48] <sergio-br2> (php, perl... that i was thinking)
[11:48] <sergio-br2> mimetypes
[11:48] <sergio-br2> mime is other thing in english :D
[11:50] <ochosi> ah
[11:50] <ochosi> :)
[12:07] <sergio-br2> i would take this 96 and 128 px libreoffice icons (i think i said i could do them), but apparently there are many things to do
[12:08] <sergio-br2> when do you think to release new version ochosi? beta1 of utopic?
[12:09] <ochosi> well, i'd like to decouple the icon-theme a bit from xubuntu
[12:09] <ochosi> as we have other distros that use them too
[12:09] <ochosi> so i'd like to finish the stuff we need for the next release asap
[12:09] <ochosi> and whenever we need a new release for xubuntu, we do a 0.x.1 release
[12:09] <ochosi> so a maintenance release for xubuntu mostly
[12:10] <sergio-br2> thougt a name for the theme?
[12:10] <sergio-br2> elementary-plus?
[12:11] <ochosi> meh, nah
[12:11] <ochosi> but yeah, i haven't thought about it for a while
[12:17] <ochosi> sergio-br2: btw, i've started with the 96px mimes already for LO, so no need to do that
[12:18] <ochosi> and as you said, you already have other things to finish first
[12:20] <sergio-br2> ok
[12:38] <elfy> afternoon
[12:39] <ochosi> hey elfy 
[12:39] <elfy> saw your reply on the bug :)
[12:40] <ochosi> i think we oughta change the bug description
[12:40] <ochosi> otherwise we get more fake tests
[12:40] <elfy> oooh it's a bug - I'll add my kind of the same random issue to it  ... 
[12:40] <ochosi> or tests for other bugs
[12:40] <ochosi> suspending is generally a thing that can fail
[12:40] <ochosi> so we can get all kinds of issues mixed up there...
[12:41] <elfy> ochosi: yea - agreed 
[12:41] <knome> elfy, read my reply? :P
[12:42] <ochosi> elfy: anyway, i've put things in motion so that we can test the final patch soon
[12:42] <elfy> knome: I did - as there were stats and 99.999% of stats are made up I ignored it :p
[12:42] <knome> hah, well they aren't made up :P
[12:42] <ochosi> elfy: (this was only a quick hack to see whether this approach actually works)
[12:42] <elfy> ochosi: yep - I understand 
[12:42] <knome> elfy, the first two paragraphs, i hope, answers your question...
[12:42] <elfy> knome: yea it did :)
[12:43] <elfy> ochosi: Black screen after reboot from lid-close suspension ?
[12:43] <knome> elfy, also, i'd read the conclusions after the stats ;)
[12:43] <knome> but bbiab, lunch/dinner
[12:43] <elfy> knome: I didn't really ignore it lol 
[12:43] <ochosi> elfy: reboot is really too ambiguous. "Black screen after wakup from suspending by closing the laptop lid" maybe?
[12:44] <elfy> sounds good to me 
[12:44] <elfy> done 
[12:44] <ochosi> ty
[12:45] <ochosi> btw, knome mentioned a few things wrt -release today
[12:45] <ochosi> i'm still very new to this, so you might have to hold my hand a bit this cycle
[12:45] <elfy> it's shame that these things don't get discussed in here :|
[12:46] <elfy> ochosi: anyway - if I can help you - just ask :)
[12:46] <ochosi> nah, this was just a PM between him and me where he shoved all the team-ownership down my throat
[12:46] <ochosi> nothing of substance was discussed
[12:46] <elfy> ok :)
[12:47] <ochosi> i just asked what the release team has to do
[12:47] <elfy> just so long as it's not bunches of xubuntu-team stuff that should be in here being in some random shimmer channel ;)
[12:47] <ochosi> heh, i hear you. will try to be more focussed in this respect
[12:48] <ochosi> thing is, sometimes i'm not sure it's good if we pollute this channel with discussions on the greeter roadmap
[12:48] <ochosi> or stuff we're working on in parole
[12:48] <elfy> the trouble is - if bits of it are important - then it get's missed
[12:49] <elfy> we've already had one thing going on with non-communication this cycle
[12:49] <ochosi> this cycle == 14.10?
[12:49] <elfy> yea
[12:49] <ochosi> which thing then?
[12:50] <elfy> someone just chucking a request to the m/l for testing something - I knew absolutely nothing about it 
[12:50] <elfy> I might have been sending something at the same time
[12:52] <ochosi> right
[12:52] <ochosi> not sure whether that was discussed anywhere
[12:52] <ochosi> i presume you mean the call for testing menulibre?
[12:53] <elfy> yea
[12:53] <ochosi> i think bluesabre just wanted to help you by doing the work himself
[12:53] <ochosi> but i agree, if an email has "testing" in the subject line, you should be made aware of that first
[12:54] <elfy> that's great - in itself - but if I'd been ready to do something with the testers - it wouldn't have helped
[12:54] <elfy> anyway - this just brings home the need for better communication - one way or the other :)
[12:54] <ochosi> yeah
[12:55] <ochosi> i think we should discuss this at tomorrow's meeting though
[12:55] <elfy> if we don't do something like trello team wide - perhaps we can add those likely to want things tested to the board - then they can make notes on it about that they're up to - so there are no surprises
[12:55] <elfy> yep 
[12:56] <ochosi> i think the easy solution would be: if there is a call for testing, send it to you instead of the list
[12:56] <elfy> my issue is that I have to plan testing around immovable things like milestones - people chucking random stuff about doesn't help with that
[12:56] <ochosi> thing is that there aren't *so* many ppl here working on app-development
[12:56] <ochosi> or even bugfixing
[12:56] <elfy> yep I know - which makes the communication thing even more exasperating :)
[12:57] <elfy> it's not like we have to look at a list of 200 people to see who needs to know something lol
[12:57] <ochosi> yeah
[12:57] <ochosi> exactly
[12:57] <ochosi> would you be fine with this routine of just re-routing these emails through you?
[12:57] <ochosi> or would you prefer some other process
[12:57] <elfy> let's see what occurs in the meeting re m/l's and stuff
[12:58] <ochosi> yeah, i actually seem to have a problem with the @xfce address
[12:58] <ochosi> i haven't received stuff from the ML for a day oro so
[12:59] <elfy> I seem to be getting the digests - which is all I get 
[13:00] <elfy> so they are coming out
[13:00] <ochosi> yeah
[13:00] <ochosi> i also haven't received stuff from the xfce-ml
[13:00] <ochosi> so it surely is related to my forwarding
[13:01] <elfy> I'd guess so
[13:05] <knome> one option is to leave pre-alpha time for random teting
[13:05] <knome> *testing
[13:06] <elfy> knome: I specifically have set it so that we'll have loads of time apart from milestones at the end 
[13:06] <knome> yep
[13:06] <knome> i understand
[13:07] <knome> though, the other issue is
[13:07] <knome> the menulibre release was a clear bugfix release
[13:07] <elfy> that's not the issue
[13:07] <knome> which fixed many things recently reported
[13:07] <knome> it's better to get them confirmed fixed now
[13:07] <knome> than later
[13:07] <elfy> the issue is communication is abysmal
[13:09] <elfy> I would have said something to [team] in the m/l about how testing was planned - but it was completely ignored last time by the majority of us
[13:10] <knome> well, i can only speak for myself
[13:10] <knome> not replying doesn't necessarily mean ignoring
[13:11] <knome> even if nobody replied anything, it's good to have an informal mail on the list
[13:11] <elfy> well I didn't :)
[13:11] <knome> and it'll be more discoverable if we decide to moderate the list
[13:11] <elfy> well actually I did - just not to team 
[13:12] <elfy> moderation doesn't equal people communicating things ;)
[13:12] <knome> no
[13:12] <knome> nor does it mean people will actually look at the archives
[13:13] <elfy> anyway - I really don't want to get into this discussion now 
[13:16] <knome> elfy, is the QA schedule for 14.10 anywhere visible?
[13:17] <elfy> the draft is on the mailing list 
[13:17] <knome> hmpf.
[13:17] <knome> i must have missed it this time...
[13:17] <knome> or then just forgot :P
[13:18] <knome> hmm, right
[13:18] <knome> actually, what i think we need to discuss is
[13:18] <knome> testing outside the testing schedule
[13:18] <knome> because we will always need it
[13:19] <knome> it's great we have a lot of time free at the end of the cycle
[13:19] <knome> however, releases do not always happen at ideal times
[13:19] <elfy> then that is down to those needing that stuff discussed to bring it up 
[13:20] <knome> the other question is:
[13:20] <knome> is, for example, menulibre testing calls inappropriate for the xubuntu list?
[13:20] <elfy> no - why would it be 
[13:20] <knome> well,
[13:20] <knome> it's not exactly a xubuntu project :)
[13:21] <elfy> testing for xubuntu is 
[13:21] <ochosi> yeah, it's used in elementary and other distros too
[13:21] <knome> while it is connected, and it's in our seed, the xubuntu team isn't technically liable for the testing
[13:21] <knome> shouldn't the "testing for xubuntu" happen when menulibre is on the testing calendar?
[13:21] <knome> and within the testcases we have
[13:21] <elfy> surely the same can be said for nearly everything that we test
[13:24] <knome> yes
[13:25] <knome> we don't have general "please test this new abiword release" mails on the list though
[13:25] <knome> we only test it within our own testing routines
[13:25] <knome> so, the qeustion is
[13:26] <knome> should menulibre have a special position because it's developed "in-house"?
[13:26] <elfy> I guess that if someone needed something testing and it didn't impact on any planned testing then I've not too much of a problem with it
[13:26] <knome> and if yes, do we expect its testing to be scheduled with the xubuntu testing
[13:27] <knome> or do we allow it its own testing schedule, which is "test when released"
[13:27] <ochosi> knome: strange, i just received your mail wrt teams, but the earlier one about MLs was "lost" or something.. need to dig through the online archive i guess
[13:27] <knome> :)
[13:27] <ochosi> seems like the xfce-forward is a bit unreliable atm
[13:27] <elfy> in that position then xubuntu mailing list isn't the right place 
[13:28] <knome> ochosi, https://lists.ubuntu.com/archives/xubuntu-devel/2014-May/010193.html
[13:28] <elfy> but that's nto any different than us testing a bug fix for abiword is it?
[13:28] <knome> well,
[13:28] <knome> the difference is
[13:28] <knome> if we're testing a bugfix for abiword
[13:29] <knome> it's a known bug that xubuntu users/testers reported
[13:29] <knome> and something that's important for us
[13:29] <knome> the menulibre bugfix stuff is the same, except that the call was for a whole bunch of bugs
[13:29] <knome> eg. a bugfix release
[13:30] <elfy> was that NOT important to us?
[13:30] <knome> heh, of course
[13:30] <knome> let me try to rephrase
[13:30] <knome> menulibre got a new bugfix release
[13:30] <knome> and then we got the call for testing
[13:30] <knome> when abiword gets a bugfix release
[13:31] <knome> we don't get a notification, nor do we specifically test the bugfixes right after that
[13:31] <knome> but in accordance to our own testing schedule
[13:31] <knome> well, testing always happens parallely
[13:31] <elfy> no - but if someone asked me to try to fit in a specific test for abiword then I would 
[13:31] <knome> but that's different
[13:32] <knome> if abiword released 3.4.1
[13:32] <knome> or whatever
[13:32] <knome> we wouldn't test the 3.4.1 release
[13:32] <knome> we'd check if it generally works
[13:32] <elfy> mmmm
[13:32] <knome> and if the bugs we have experienced were fixed
[13:32] <knome> now,
[13:32] <knome> menulibre got a similar release
[13:32] <knome> for "some" reason, all the bugs fixed were experienced by us
[13:33] <knome> but the call was for that menulibre release
[13:33] <knome> for that time only
[13:33] <knome> not something we'd have to keep regularly checking
[13:33] <elfy> if 3.4.1 got released after we'd done the call that included abiword - then nothing would specifically be done till the next cycle
[13:33] <knome> elfy, exactly
[13:33] <knome> elfy, and if it got released before we tested it
[13:33] <knome> elfy, we would wait until we hit the abiword dates on the schedule
[13:33] <elfy> then we test what is in the daily at that point
[13:34] <elfy> yes 
[13:34] <knome> or we wouldn't wait
[13:34] <knome> because we didn't know a new version was out
[13:34] <knome> we'd just notice it when we test
[13:34] <knome> and notice those bugs were gone
[13:34] <elfy> but - we try to be flexible - if someone says something about something specific
[13:34] <knome> sure
[13:34] <knome> as i said, there's always parallel stuff going on
[13:34] <knome> regardless of the testing schedule
[13:34] <knome> now the question is
[13:35] <elfy> so I really don't understand your point here :)
[13:35] <knome> is menulibre important enough, and
[13:35] <knome> is the bug release minor enough
[13:35] <knome> to be okay to allow parallel testing, even if it was during some other scheduled testing
[13:35] <knome> and possibly:
[13:36] <knome> is the people who do the scheduled tests the only people who do testing at all
[13:36] <knome> because there might be somebody who is specifically interested about menulibre testing
[13:36] <knome> <-
[13:36] <elfy> who knows 
[13:36] <elfy> all I *know* is who reports things
[13:36] <knome> but doesn't *necessarily* take part in all scheduled tests
[13:36] <knome> <- kind of
[13:37] <knome> yeah, we don't know :)
[13:37] <elfy> look 
[13:37] <elfy> I really don't understand what you're getting at - frankly I'm not that worried about what we test - as long as team is happy that what needs to be tested
[13:38] <elfy> what I do worry about is a free for all - when everyone and his dog sends testing calls to the list
[13:38] <knome> lol
[13:38] <elfy> it's really simple 
[13:38] <knome> i wouldn't consider sean "everyone and his dog" ;)
[13:38] <elfy> well no - but you know what I mean 
[13:39] <knome> i do
[13:39] <knome> i haven't seen much calls for testing that have been irrelevant though
[13:39] <elfy> and is seems to me that you're just trying to make it sound ok for Sean to do what he did
[13:39] <knome> no, not really...
[13:39] <knome> i guess i personally think it's okay
[13:39] <elfy> if team thinks that - then that's fine - but I don't and I won't put up with being kept oput of the loop on testing
[13:39] <knome> but if we want that out of the list, i completely understand that too
[13:39] <elfy> and if it keeps happening then I'll just go
[13:40] <knome> well, we don't want that
[13:40] <knome> i agree that sean should have asked you first
[13:40] <elfy> it is really simple - communication was abysmal last cycle - and it looks exactly the same at the moment from where I'm sitting
[13:40] <ochosi> sergio-br2: LO mimes are done, so only apps/128 is missing for that piece...
[13:41] <sergio-br2> great
[13:41] <knome> elfy, as ochosi asked, would you be fine if all calls for testing went through you then?
[13:42] <knome> elfy, i'm just weighing options, i'm not deciding anything, don't worry :)
[13:42] <knome> (i don't even have the power to do so anymore)
[13:42] <elfy> and I'll say the same thing again - let's see what happens in the meeting 
[13:42] <knome> how will the meeting make a difference?
[13:42] <knome> decisions about mailing lists?
[13:43] <elfy> yep 
[13:43] <elfy> and trello perhaps 
[13:43] <knome> bluesabre's mail would have been automatically accepted anyway
[13:43] <elfy> because if that's just a we're really not going to do that - then we do need to do something 
[13:43] <knome> or he could have approved it himself if not :P
[13:44] <knome> one of the issues is clearly too much traffic on the list.
[13:44] <knome> let me fix that:
[13:44] <knome> too much irrelevant traffic
[13:45] <knome> i seriously want to find a solution that works for you and the team, and any potential people who do calls for testing
[13:47] <elfy> I'm not worried about *me* :) I just want *us* to be in a better place with regard to knowing at least the bare bones about what's going on
[13:47] <elfy> gives us all a fighting chance
[13:48] <knome> yep
[14:08] <ochosi> knome: read up on the whole ML proposal, thanks for that!
[14:08] <knome> np
[14:08] <ochosi> after reading the statistics i somewhat agree, but we should talk to all moderators about this
[14:09] <ochosi> as it will suddenly increase their workload from nearly 0 to 3 per week on average
[14:09] <knome> all current moderators, or all moderators that were moderators when we started talking about this?
[14:09] <knome> well, 0 is inexisting
[14:09] <knome> it's probably 1 now
[14:09] <ochosi> well i'd want all of them to "sign up" for this
[14:10] <knome> and more if we count those mails we need to discard
[14:10] <knome> sure
[14:10] <knome> but tbh, i believe the policy will take care that the workload will decrease
[14:10] <ochosi> hopefully yes
[14:11] <ochosi> actually, as an example of the past, #xfce-dev was closed a longer while ago
[14:11] <ochosi> because there was so much random noise there
[14:11] <ochosi> after a year it could be re-opened
[14:11] <knome> mhm
[14:11] <ochosi> and has been okay since then
[14:11] <knome> yep
[14:12] <ochosi> even if it might become busier/noisier again, there was a long/er term effect
[14:12] <ochosi> so i'm generally +1 on this
[14:12] <knome> yes
[14:12] <knome> i hate to say this, but there seems to be a group of people who are the root of the random noise
[14:31] <a5m0> how can i get lightdm to have the correct resolution and correctly show my dual-monitor wallpaper? (xubuntu 14.04)
[14:31] <ochosi> a5m0: this is the development channel, for support questions ask in #xubuntu
[17:10] <brainwash> ochosi: logind hibernate policy has been finally adjusted
[17:10] <brainwash> http://cgit.freedesktop.org/systemd/systemd/commit/?id=301f9684e6465df5d0590f6c571fe3229ded966d
[17:12] <ochosi> guess that'll land in ubuntu at some point automatically
[17:12] <brainwash> once ubuntu switches to systemd completely
[17:16] <brainwash> ochosi: can we merge https://code.launchpad.net/~thad-fisch/xubuntu-default-settings/migrate-kb-shortcuts ?
[17:16] <brainwash> and what about https://code.launchpad.net/~thad-fisch/xubuntu-default-settings/remove-leftover-conffile ? del the branch?
[17:28] <ochosi> brainwash: kb-shortcuts branch merged, the other one i'm not sure we really need...
[17:29] <brainwash> first we would need to close the lp report
[17:35] <ochosi> you could extend your MR to also fix https://bugs.launchpad.net/ubuntu/+source/xubuntu-default-settings/+bug/1311090
[17:35] <ochosi> that seems more important actually
[17:36] <brainwash> but why extend if the first one is somewhat obsolete?
[17:36] <brainwash> it happened during the development phase
[17:37] <ochosi> yeah, you can also just fix the latter and remove the other branch
[17:39] <brainwash> maybe
[17:39] <brainwash> I also forgot about the non working kb shortcut issue :/
[17:41] <brainwash> the problem is that the user config file is created based on the xubuntu AND Xfce one
[17:41] <brainwash> which differ slightly
[17:41] <brainwash> key-wise
[17:42] <ochosi> how do they differ and what's the problem exactly?
[17:42] <ochosi> is there a bugreport already?
[17:43] <ochosi> brainwash: you can delete your remove-leftover.. branch now
[17:44] <brainwash> e.g. xubuntu uses alt+f5 to maximize a window and alt+f10 is not mapped anymore
[17:44] <brainwash> but the normal Xfce kb shortcut xml assigns alt-f10 to maximize window
[17:44] <brainwash> so the user xml will contain alt+f5 and alt+f10 for maximize window
[17:45] <knome> assign all unassigned keys to a script that plays a "meow" sound!
[17:45]  * knome hides
[17:45] <brainwash> 2 entries for the same command
[17:45] <brainwash> now the user tries to reassign it, but only one entry will be deleted and a new one created
[17:46] <brainwash> the new one will be ignored
[17:46] <ochosi> do you have a solution for that already?
[17:46] <ochosi> (other than dropping xubuntu shortcuts)
[17:47] <knome> do not inherit xfce shortcuts?
[17:47] <knome> :)
[17:49] <brainwash> maybe it's a simply prefix issue
[17:49] <brainwash> because we store our xubuntu related configs in /etc/xdg/xdg-xubuntu
[17:50] <brainwash> so the user config file should be only created based on this file
[17:52] <brainwash> it's an easy fix I guess
[17:53] <ochosi> bbl
[17:54] <brainwash> we can ignore already "corrupted" xml files?
[17:54] <brainwash> just tell the user to delete it, so it will be re-created properly?
[17:55] <brainwash> one could add some sort of clean up mechanism, but that's maybe overkill
[17:56] <brainwash> and it won't be accepted upstream, so we'll have to carry it downstream :)
[19:06]  * amigamagic pc says: "eeeeh!?" when he press ALT+F13