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