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