[06:19] question, does apt replace apt-get in trusty or in xenial? [07:34] knome:re OEM - flocculant brought this up some time ago and was put of caring by knome who did a good job [07:36] HiddenDjinn: xenial - and it's not replaced as such, just added [07:37] flocculant: ok, thanks [07:39] knome: further - given that testing we get for normal iso's is pretty pathetic so not really why anyone would think adding things is useful [07:39] s/not really sure [07:39] flocculant: i got you [07:40] s/not really why/not really sure why/ [07:40] fixed that for you [07:41] and by adding things - I mean making testing harder - not the OEM thing - which I cared about once ;) [07:43] oem thing? [07:43] i dropped out of the linux world for a bit...i think i need background [07:45] HiddenDjinn: a discussion that happened while I was asleep [07:46] installing system - without user data - user adds that at first boot - like you get when you buy a pc pre-loaded windows [07:46] flocculant: ok...contemplating sleep myself, soon [08:09] ochosi bluesabre - some I suppose useful info - I appeared to have an iso kicking about here from 3rd Jan - lock was broken there [08:11] * flocculant suggests that we add lock/suspend testing to the post install test which currently doesn't test much [08:11] !team | ^^ [08:11] ^^: akxwi-dave, bluesabre, dkessel, flocculant, jjfrv8, knome, krytarik, micahg, Noskcaj, ochosi, pleia2, slickymaster and Unit193 [08:12] makes sense, +1 [08:13] knome: re OEM - at least in vm - reboot to end user crashes ... [08:15] flexiondotorg: before I start digging around - should oem work in a vm? just getting black screen here ... [08:30] knome: one more OEM point - while you say we don't support it - we don't say that anywhere and OEM install is there on our iso just like it is anyone else's [08:35] flocculant Last time I tested, yes it does, [08:35] But I'm seeing some regressions in Ubiquity when testing on Friday night. [10:22] flocculant: agree +1 [11:44] knome, bluesabre: we should have a brief discussion at some point about an inactive team members cleanup [11:44] alrighty [11:58] flexiondotorg: thanks [11:58] ochosi bluesabre - thoughts on adding lock to a testcase? [11:59] can't see a problem with it tbh - better than not knowing *when* it failed [12:04] ochosi, i'm around for that now for example [12:05] tbe, now would be a very good time even [12:06] flocculant, re: OEM: yes, i understand it's one more thing to test - but also yes, it's on our ISO whether we want it or not [12:07] flocculant, and iirc i didn't say we don't want it, it wasn't the highest priority then (and it still isn't) [12:07] flocculant, i might recall wrong as well though :P [12:07] :D [12:07] but yes, the problem is testing, but it's also a problem if somebody does an OEM install and then the end user is left with a completely broken or awkward system [12:08] i don't know if we can hide the OEM option either? [12:08] indeed [12:08] i mean, completely remove it from xubuntu [12:08] though oem install is something that we'd not be supporting 'personally' so would be a case of report it [12:08] yes... at least primarily [12:09] not sure whether that's possible [12:09] my gut feeling is that most of the issues with OEM comes from upstream anyway [12:09] i'm pretty sure we can't [12:09] and aren't qualified enough to look [12:09] :) [12:09] you and me both then ;) [12:09] yep ;) [12:10] easy enough to add it to the testcase list - and make it optional or something [12:10] so i guess the least thing we could do is run the OEM installation once or twice (not per cycle or within regular testing - literally just once or twice) and report any issues we find [12:10] and yeah, optional testing could work as well, as long as we make it clear that it's probably the least important thing and the fact that it is a test doesn't mean it's supported - or will be [12:10] we could have a 'Final BETA test' like we currently have for core [12:11] eg - just sits there all cycle adding up as tests get run [12:11] i'm thinking the OEM install is most useful with LTS's anyway [12:11] but [12:11] hmmh, not sure if we want to put more stuff on the final beta [12:11] it's already quite busy [12:12] my point re testing remains - if 1 or 2 people are testing it only on vm - what point is there in that [12:12] not only for testing, but if bugs appear, it's likely that the other bugs will be always higher priority [12:12] true [12:12] well Beta or something - just flinging ideas about atm [12:12] but then i'm not sure how much hardware is really concerned with the OEM stuff [12:12] i mean it's a regular install, you only flip one bit and leave one software thing for after the installation [12:12] well what oem is going to send a vm? [12:13] or why would you oem install a vm? [12:13] normally, you wouldn't [12:13] i'm just trying to think of anything related to hardware that could break OEM [12:13] and can't come up with anything [12:14] in other words, hardware-related stuff happens regardless of OEM [12:14] and then we really get into makeing sure that 'our' minimum specs are good - if we test oem it should install and run satisfactorily on our minimum [12:14] sure, but again, it's the same installation really [12:14] yes [12:14] only the personal data input is moved after the installation [12:14] but sure, maybe once a cycle - or once an LTS cycle [12:15] * knome checks our minimum specs [12:15] but if some oem or charity came along and decided they were going to chuck xubuntu oem on a bunch of machines they have for charity and it fails to run - that's our problem isn't it? [12:15] we've said it works for Xubuntu [12:15] we offer anything without liability... [12:16] yea - I know that ;) [12:16] if we look at the "xubuntu at..." series, we can find many orgs are doing something like this with xubuntu [12:16] all I'm saying is that ^^ is something we need to consider amongst eveerything else on the subject [12:16] i don't think they are using OEM tbh, but... [12:16] absolutely [12:17] yea I know - which is where my original 'shoudl we do this' came from : [12:17] ) [12:17] we say our minimum to install/try is 256MB [12:17] and to use is 512MB [12:17] i've considered many times what is the point of having two numbers anyway [12:17] mmm [12:17] if you try with 256MB, are you *really* going to get a 256MB extra piece of memory to run it? [12:17] flocculant, I am in favor of adding that test [12:18] I'd not want to run firefox and some other app at the same time on 512MB [12:18] me neither [12:18] I'd have no screen in no time at all :D [12:18] but what is bearable is subjective [12:18] yea [12:18] and we do word it like: [12:18] knome, install with 256, run with 512... don't imagine that's a typical use case [12:18] Once installed, you should have at least 512 MB of memory. [12:19] bluesabre, my point is, if you try/install with any amount less than the minimum to run, are you really going to add more memory after trying/installing? [12:19] personally I'd be for upping that [12:19] let's take that for the council meeting as well to hear what ochosi has to say [12:20] you'd be nuts to do that - you'd add the memory and then think mmm what can I install I couldn't before I guess [12:20] then at least pop those both to the same level at 512MB [12:20] flocculant, exactly [12:20] knome, nope [12:20] frankly I think we should be saying 1G [12:20] anyway [12:20] i don't have time for a real meeting, but a 5min thing [12:20] that's our recommended [12:20] i'm @work atm [12:20] let's do a 5min for the team member stuff then [12:20] here or want to take it privatE? [12:21] (privacy of concerned persons etc) [12:21] * flocculant wanders off till later [12:21] flocculant, hf and ttyl :) [12:21] yup [12:21] about more this week to cover point release [12:22] knome: maybe private, but the ppl in question should mostly have received notice previously [12:22] invited you two to a channel [12:23] ochosi, bluesabre: ^ [13:03] knome: sry, had to leave [13:03] i have another 4min window *now* [13:03] :) [13:04] and i'm in said channel (alone) [13:04] no you're not [13:12] flocculant, +1 to the lock/suspend testing [16:03] back [16:20] front [16:21] :-) [16:21] sideways shuffle [16:21] old man shuffle.... [16:21] \o/ [16:36] mp done for suspend/lock [16:37] akxwi-dave: if you've time https://code.launchpad.net/~flocculant/ubuntu-manual-tests/1656882/+merge/314860 [16:37] if not it will ping slickymaster :) [16:39] :-) approved... [16:40] super :) [16:47] akxwi-dave: all done - on tracker now [16:49] and failed test on tracker too ;) [16:49] :-) must admit, I always forget about lock/suspend as its the first thing i turn off on any laptop... so never use it [16:51] not something I ever do unless someone else says it is broken ... [16:51] and if people are running dev but not telling anyone - we don't know [16:52] hence grabbing a1fa into here the other day :) [18:30] ochosi bluesabre appear to have found the lock culprit [18:30] grabbed old lightdm packages and worked through them till it stopped working [18:43] https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1656399/comments/7 [18:43] Launchpad bug 1656399 in light-locker (Ubuntu) "Unable to unlock Xubuntu XFCE session after suspend." [Undecided,Confirmed] [18:43] *appears* to be lightdm this time [18:48] bluesabre: I assume you can set the importance on that bug from undecided to something entirely more suitable - like critical or something :p [18:52] * flocculant wonders if it started failing with 1.21.2-0ubuntu1 - the one I can't appear to find [19:02] bluesabre: also robert ancell doesn't appear to be online so I can't ping him - maybe you will see him about later [20:36] caught him in -desktop [20:51] should have known he would want lightdm.log [20:52] hopefully they'll be able to add whatever broke to regression tests for locking functionality [20:53] paraphrasing r_ancell