[08:55] bluesabre: can you have a look at http://pad.ubuntu.com/thunar please - made a start, really think we should get this moving along :) [08:55] as soon as you're ok - I'll get the testcase on the tracker and then calls out [11:39] knome: going to do an mp for our cd build times - so whichever way we end up going - if indeed we do - the builds are done really early UTC [11:40] or at least I think I've found the right thing to do mp for :D [11:56] :) [19:14] akxwi-dave: so quite quickly then - release notes [19:15] renamed it to https://wiki.ubuntu.com/Xubuntu/Testing/ReleaseNote [19:15] :-) [19:15] planning to make that a 'rolling' thing [19:15] sounds good [19:16] that takes more than 1 person getting fed up with it :D [19:16] well 2 of usat least [19:16] if at least a couple of us could take it in turns - kind of week on week off - to try our best to keep it current [19:17] that would be awesome [19:17] as picard would say.. "make it so" [19:17] I would like to be able to ping the url to testers/tracker [19:17] so that they know what's up [19:18] then - at release - we can just copy current testing to that name - ie yakkety [19:18] sound sensible [19:19] mostly - the important thing is - if you change the rolling one - change the date in the 'wiki warning' [19:19] Current edit state - 26.04.2016 [19:19] thing ^^ [19:19] kk [19:19] in English ... [19:19] :p [19:20] yes sir o7 [19:20] :-) [19:20] akxwi-dave: irc sessions looks as full as last cycle ... [19:20] won't do that unless we have a few say yay :) [19:20] 2 or 3 then [19:21] yea [19:21] I would rather 20 turn up and say sod all and read things to be honest [19:22] thats one of the reasons i thought of the small vids.. for those that may not be comfatable with irc [19:22] akxwi-dave: also - unlikely I'll bother setting up trello given little package setting up and no b1 [19:22] akxwi-dave: yup - that's a nicely positive thing for sure :) [19:23] might be worth you and I having a 1 to 1 on that before you do it - I can mail or pm phone number if you like [19:24] or we can vid or pad or ... [19:24] or you can pm me your number - whatever :~) [19:24] yep no prob mate.. [19:25] :) [19:25] see pm then [19:26] no rush on that [19:27] sorry had dog jumping on me.. sill thing shouldn't be jumping she has an op on her leg [19:27] akxwi-dave: re release note - I'll not be doing anything to changelogs till the last minute [19:28] I'm also going to run through the contr docs to make sure nothing says 'we WILL do' [19:29] akxwi-dave: last thing - wiki - xubuntu one [19:29] I have draft http://wiki.xubuntu.org/qa/isotesting [19:29] which I believe covers that simply [19:30] anything else you can think of which would help - put it on the blueprint as a task [19:30] thats very nice :-) [19:30] so much more simple for peeps [19:30] I'd like for us to have a set of basic pages there for testers [19:31] and on x.org wiki - we have some control :) [19:31] that always helps :-) [19:32] given that you're brave enough to do the vids - least I can do is make wiki pages from notes - so use the ubuntu.pad thing and I will do that :D [19:32] yea :) [19:33] deffo.. will do .... started on that need to type up,, [19:33] \o/ [19:33] should have #startmeeting for this :p [19:34] also get knome to do me a !qateam factoid to ping people :D [19:34] i'm gunna copy an paste it to g docs for me .:-) [19:34] well - in my logs now :D [19:34] thanks Dave :) [19:35] akxwi-dave: one more thing [19:35] yep [19:36] started trying to sort our 'extra' thunar testcase before I do the deal and shout out - have a butchers at http://pad.ubuntu.com/thunar [19:37] mostly notes amongst instructions - if you can see where I'm going - try and fiddle a bit for bluesabre (sean) [19:37] it's really easy to write these things when it is in your head [19:38] shame ali1234 isn't here to look [19:38] krytarik or Unit193 could though :p [19:41] aye.. got a fresh install onb real hardware to do testing.. will bash it about [19:42] * flocculant has gone to kvm - some vbox update killed vbox [19:43] ouch [19:44] yup [19:44] done for me :D [19:45] also been looking at the gnome tool [19:45] for a simple test - as long as we work out where to remove the ~/home file from [19:46] something really simple for a drive by tester [19:46] kind of a " do this rm path" deal [19:47] BUT really need to be sure that krytarik doesn't trash his ~home :p [19:47] so plans [19:47] :) [19:48] unlike the webmaster that deleted all the sites his company hosted.. [20:19] flocculant, PM me what you want in the factoid [20:20] flocculant: I think transform the release notes to a 'rolling' thing could be great ;) [20:24] nairwolf: then I assume you're happy to help make that happen [20:24] everyone thinks that everything is a great idea - unfortunately 99% of people assume that they can just wait for things to happen [20:27] !qateam | flocculant [20:27] flocculant: akxwi-dave, slickymaster, flocculant, knome [20:27] Yes, I think I would be able to help [20:27] Actually, you want to update the release notes every week, right ? If it's possible to create a task planning to do that, that would be great [20:28] This week, I will be in holidays, so away from the computer, and I will not be able to follow new bugs or other things. [20:31] knome: \o/ [20:31] thanks :) [20:32] np [20:32] nairwolf: not possible to plan it - depends on what turns up on 1 - tracker, 2 - the other tracker or 3 - bug reports :) [20:32] and naturally, PM me again if you want changes to it [20:32] it's a WIP thing [20:32] ok, flocculant. this will be discussed tomorrow during the meeting, right ? [20:32] knome: ack - unless you happen to see changes :D [20:32] flocculant, yep, on channel is good too [20:36] yep [20:36] nairwolf: nope - not on agenda [20:36] its' really a QA issue - which QA will decide on outside of any meeting [20:37] people reading the list will become aware of that [20:37] ok, so I will be informed of that [20:38] Most of time, I don't really have any opinion. I'm just observing and trying to do the most I can. [20:39] nairwolf: yup :) [20:39] when it's a discussion thing - add your points for sure [20:40] only time it is a team thing we tend to [TEAM] in topic [20:40] Yes, if it's relevant, I will do it. If it's something I don't have any experience, it's difficult to know which is the best choice. [20:40] yep [20:40] basically [20:41] if it = work [20:41] Yes, I've already seen that when you discussed about the media manager [20:41] only say it's a really good idea when will to do the work :) [20:42] sorry ? [20:42] and by thay, the list you talked was xubuntu-devel, right ? [20:42] nairwolf: aah s/will/willing [20:42] s/thay/the way [20:42] yea - dev list [20:43] ok [20:43] https://lists.ubuntu.com/archives/xubuntu-devel/2016-April/011145.html [20:44] for instance - happy to get 1000's of ideas [20:44] 13 people get to decide [20:46] only knome has answered to this mail. Maybe you've discussed about that here (#xubuntu-devel), but I wasn't here. [20:47] Sometimes I think it's pretty hard to follow each discussion and ideas if it's mixed between email and irc. I suppose I should read irclogs each day in order to follow the development ? [20:47] s/the development/discussions [20:48] nairwolf: only other comment was on IRC from bluesabre - 'yup - that's fine with me' [20:48] paraphrasing [20:49] Ok, I suppose it will be more developed tomorrow during the meeting. [20:50] Don't worry [20:53] nairwolf: no [20:53] it's not even on the agenda - I *might* mention it - but it's not a discussion item :) [20:55] "milestone participation" is written at : https://wiki.ubuntu.com/Xubuntu/Meetings/ [20:58] nairwolf: mea culpa [20:59] ish [20:59] nairwolf: no - it's under announcements :D [21:01] cos I am bad man ;) [21:01] hello aaronraimist [21:03] hehe, now I see that ;) [21:03] hello flocculant! Do you know what the status of this bug is? https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1568604 [21:03] Launchpad bug 1568604 in xserver-xorg-video-intel (Ubuntu) "Mouse cursor lost when unlocking with Intel graphics" [High,Confirmed] [21:04] aaronraimist: It's still present on my system [21:05] aaronraimist: it's still an issue [21:06] and not really something we can actually fix afaik - [21:06] though we can SRU the fix [21:07] flocculant: what is SRU ? [21:07] stable release update [21:08] nairwolf: if the fix showed up at the end of the wily cycle - we'd do nothing [21:09] if the fix shows up for the xenial cycle - it will likely land [21:09] same as the thunar issues [21:09] yes, but we still need to fix it [21:09] bluesabre told me it's specific to Xubuntu [21:10] aaronraimist: assume you are with intel driver then [21:10] flocculant: yes [21:10] nairwolf: yes - but if the problem was during a 9 month cycle - fixing it does not mean the fix would land for that release [21:10] !sru [21:10] Stable Release Update information is at http://wiki.ubuntu.com/StableReleaseUpdates [21:10] hoping :) [21:12] ok, thanks ;) [21:12] thanks flocculant ;) [21:12] nairwolf, we're aware certain bugs need fixing - repeating it won't make them fixed [21:13] aaronraimist: sorry - left channel then ... so best thing you can do here is https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1568604/+affectsmetoo [21:13] Launchpad bug 1568604 in xserver-xorg-video-intel (Ubuntu) "Mouse cursor lost when unlocking with Intel graphics" [High,Confirmed] [21:14] and make sure you are subscribed to it - when something is around which fixes the issue - then it'll get a specfic tag added - proposed-fix or something [21:14] flocculant: Yeah I already have done that, I just didn't know if there was anything else I could do. Who is responsible for fixing that issue? [21:15] at that point there is a fix in -proposed which you can try [21:15] this confirms fixes for everyone [21:15] aaronraimist: it's upstream - we think it is with xserver - or at least I do [21:16] I'm on yakkety - so am watching updates - I'll move my laptop over to yakkety - then talk to our tech team [21:16] it's not forgotten :) [21:17] knome: not sure that nairwolf was talking about more than the mechanics of getting a fix landed there :) [21:25] yes, that's right, flocculant explained what I said correctly. Thank you [21:28] aaronraimist: as far as your bug comment goes - http://changelogs.ubuntu.com/changelogs/pool/main/x/xserver-xorg-video-intel/xserver-xorg-video-intel_2.99.917+git20160325-1ubuntu1/changelog we appeared to start seeing the issue after beginning of March [21:28] flocculant: the link you gave me is really interesting ;) [21:28] nairwolf: sru one ? [21:28] yes, sru one [21:28] ack [21:29] basically in a normal cycle now - 9 months - unlikely to see vague fixes landing [21:30] aaronraimist: and the last lightlocker change was december - so applying a bit of logic and hope ... [21:32] aaronraimist: if you feel adventurous enough - I actually confirmed locally that setting intel to use uxa instead of sna stopped the problem [21:33] I've never used a non-LTS version, I've started to 14.04 and now, I'm one 16.04 [21:33] But, I will move to Yakkety when it will be released [21:34] For a non-LTS version, if there is a security issue, I suppose it's something updated, right ? [21:34] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815135#30 and http://askubuntu.com/questions/225356/how-can-i-enable-the-sna-acceleration-method-for-intel-cards-under-ubuntu-12-04 I just changed sna to uxa in the file instead [21:34] Debian bug 815135 in xserver-xorg-video-intel "No cursor displayed" [Normal,Open] [21:35] nairwolf: well - I'd not move from an LTS to a normal if I ran LTS as production - I'd just have a testing partition [21:35] I'm on yakkety already obviously [21:41] flocculant: That does appear to fix it for me too [21:42] I used LTS as production because it was the first time I used Linux. But now, I think I can follow normal releases. [21:43] or, I can use yakkety like you maybe [21:43] aaronraimist: awesome - nice to get some confirmation of that - can you post to the LP bug again [21:43] I can confirm that uxa thing [21:44] nairwolf: ok - well what you need to bear in mind here is that in 2 or 3 months I'll have a xenial, broken yak, another broken yak and the one I'm using as installs :p [21:45] aaronraimist: thanks for looking into this btw :) [21:46] flocculant: you use them in different partitions ? [21:46] nairwolf: the way I work doesn't really work well if you need PC to actually do things for a job :) [21:46] all I NEED is music and vids mounted :p [21:47] nairwolf: I have *just* today cleared 4 broken installs/partitions [21:54] I do not use my personal computer for a job, but I want something stable. Or without annoying bug. I do not have enough memory to use different partition for 2 os. So, I'm testing with VM or with my second computer. The second computer isn't used, so it's just something to test distribution on real hardware. [21:54] See you tomorrow for the meeting, I'm gonna sleep soon. [21:55] nairwolf: hdd or memory is the problem? [21:59] flocculant, let's do it here then.. [21:59] yup [22:00] so you'd like to see results from the QA tracker, right? [22:00] knome: so we know what we both want to achieve I Think [22:00] I would prefer to see tracker result [22:00] the QA tracker xmlrpc interface needs work :| [22:01] assuming I get the mp sorted - *I* or !qa would know that the image actually does boot [22:01] before that is done, i don't think it's sensible to pull out the data from that [22:01] those auto tests are cool - but [22:01] I have booted and installed from an image the autotest has failed [22:02] I trust them not [22:02] so - if !qa isn't convinced of that - my position would be a real sync and install [22:03] I can commit to doing that [22:03] right [22:03] personally [22:03] well, [22:03] we can show the build result anyway [22:03] yup [22:03] if we want [22:03] that is trivial enough [22:03] but getting data out of the QA tracker... oh my.. [22:03] knome: generally in my experience if file size is <190kb something is wring [22:04] s/wring/wrong [22:04] heh [22:04] right [22:04] probably, less line [22:04] +s [22:04] yea [22:04] krytarik - got anything to add to buildlog sizes? [22:05] knome: I thought getting tracker info might be pants ... :( [22:05] let's put it this way [22:05] working with the xmlrpc backend code isn't horribly hard [22:05] but it's not something i want to dig into [22:05] :) [22:06] fair enough [22:06] if we could get somebody from the general QA community at least a bit interested in that... [22:06] yea [22:06] the last time i worked with that, it was like [22:06] knome: ok so how about this then [22:06] do one request [22:06] you get information bit A [22:06] then do another request with that bit [22:06] and you get information bit B [22:07] *we* have a file somewhere that !qa can access [22:07] then repeat until you get your information bit K [22:07] *we* set yay or nay [22:07] hmm... [22:07] dev.tracker reads that? [22:07] we can integrate that directly to dev. [22:07] would it be true/false/null for each day? [22:08] if yay+yay=gree,. yay+nay=amber, nay+nay=red [22:08] green [22:08] oh right, multiple votes [22:08] or nay+yay [22:08] or do you mean the other would be the build log? [22:08] knome: forget logs [22:08] ok [22:09] so what are the two different things? [22:09] if that was simpler - then as long as I can mp the cron [22:09] I can commit to booting and installing while the kettle blois [22:09] as i said, the build log is tricial [22:09] boils [22:09] *trivial [22:10] that's not a/the problem [22:10] iso tracker stuff is [22:10] no need if we go this way [22:10] ok [22:10] then explain: you said yay+yay [22:10] what are the data points? [22:10] all we would need to do is commit to editing a file (or even leaving it as it is) [22:11] knome: moving to http://pad.ubuntu.com/xubuntuqa-y-cycle [22:11] k [22:11] right at the bottom [22:12] oh right, the two images [22:12] >__< [22:12] would something like "always light green until confirmed, after which green/red/orange" ? [22:13] resetting at midnight [22:13] or should the default assumption be the status of the previous day? [22:13] my mp does 1am for daily/2am for trusty [22:13] well think midnight as build time [22:14] forget the time thing for now [22:14] we can set the cron on dev. to anything [22:14] so if we commit to updating file by 8am ish - by 10 am the tracker will be current - just about the same time as current build time [22:15] knome: ftr any cron I talk about will be cd build (for logs) [22:16] we just need to make the *file* both -website and -qa writable [22:16] is that a simpler method? [22:17] the simplest method for me - considering we want some data shown on dev - is that we create an UI where you change the stuff you want to show [22:17] at this point, it would be touchable by anyone who has a password [22:17] wfm [22:18] specifically when we do that, dev. doesn't need to poke any external source [22:18] that's better imo [22:18] it has the status on its database, so it doesn't need any cron [22:18] except the resetting stuff [22:18] well, which is automatic too [22:18] we have the control then [22:19] (it just checks if there is a status for today) [22:19] my cron *issue* is making sure I can sync locally when I get up [22:19] which is a seperate issue from -team's [22:19] but that's not dev.'s issue? [22:20] nope [22:20] ack [22:20] don't get me wrong... i want to support stuff as good as i can [22:20] but i'm mostly only worried about the work i need to do :D [22:20] I'll do the mp - then talk to adam conrad [22:20] i'll try to get this implemented early next week [22:20] knome: yup :) [22:20] you are in !qa [22:20] :p [22:20] or tomorrow if i'm productive [22:20] now [22:20] sure, but that's a different worry :P [22:21] this you do have a worry over :) [22:21] of course i always have worries over many things :P [22:21] but related to this specific issue, my main concern is to get the dev. code in order [22:22] http://i.imgur.com/IHJvTWr.png [22:22] yeah? [22:22] I'd REALLY like it in that line :~) [22:22] indeed, it will be there [22:22] \o/ [22:22] or do you mean the status itself? [22:22] flocculant: I have ssd so I don't have so much space. But maybe I should be able to reserve some place in the second ssd I have, I'll see [22:23] knome: 64:green/amber/red 32:green/amber/red [22:23] is my vision [22:23] ok, what's amber? [22:23] knome: one arch failed [22:24] but... 64 is one arch [22:24] so why 64 would have amber if 32 failed? [22:24] because 1 failed [22:24] (since you can see that 32 is red) [22:24] oh yea [22:24] :D [22:24] mmm [22:24] so my vision is [22:24] so green/red then :) [22:25] light green -> unconfirmed status (from last confirmed status) [22:25] green -> confirmed pass [22:25] light red -> unconfirmed fail [22:25] red -> confirmed fail [22:25] that for both of the arches separately [22:25] and unconfirmed is automatic, so you only have two statuses to worry about in the UI [22:26] knome: brb [22:26] mhm [22:33] knome: ok [22:34] so then unless *someone*edits file to equal something other than pass - icons are both green? [22:34] see you tomorrow, good night [22:34] is that what you're saying? [22:34] flocculant, unless nobody edits, then the icons are light green/red, based on the last confirmed status [22:35] so if you confirmed pass today, tomorrow it'd be light green until you confirm anything [22:35] (=assuming same status) [22:35] then darker? [22:36] darker when confirmed [22:36] ok [22:36] so think light as in 0.5 opacity (or so) [22:36] - so just to tie this up now [22:36] assuming build [22:36] assuming pas [22:36] dark colour [22:36] no [22:36] :D [22:37] * flocculant pours beer [22:37] i'll write something on the pad [22:37] knome: you write stuff on pad [22:37] ha ha [22:39] ok, there's all the alternatives now [22:39] yup there now [22:39] assuming it's "tuesday" now [22:39] yep [22:40] and "always assume build is up" [22:40] unless you want to do something else [22:43] knome: that looks good to me - thanks for working through what we can do in-house here :) [22:43] and tia for getting it on the tracker :p [22:43] sure [22:43] and we can do more [22:43] in certain limits [22:43] but let's get this done first.. [22:45] meh [22:46] what? :D [22:46] how the hell did I manage to find this to pull from lol [22:46] this? :P [22:46] the cron thingy [22:46] :D [22:46] ;) [22:49] oh meh - this is just a maze in launchpad ... [22:50] :) [22:50] * flocculant just ask infinity where to pull from :p [22:50] da finger :P [22:54] anyway - once that's done all we should really worry about is dev daily - so shouldn't make any difference to the bones of what we talked about [22:54] just means that at some point - hiccup [22:57] :) [23:31] knome: ok mp done, hopefully desc of change makes some sense https://code.launchpad.net/~flocculant/ubuntu-cdimage/x-build-time/+merge/293489 [23:35] flocculant, looks good enough [23:36] :) [23:36] can do no more I suppose [23:36] indeed [23:38] knome: I assume that this doesn't stop us proving [23:38] no [23:39] assumed not - stupid question really :) [23:40] and only slickymaster and akxwi to tell for the time being [23:41] when live