HiddenDjinn | question, does apt replace apt-get in trusty or in xenial? | 06:19 |
---|---|---|
flocculant | knome:re OEM - flocculant brought this up some time ago and was put of caring by knome who did a good job | 07:34 |
flocculant | HiddenDjinn: xenial - and it's not replaced as such, just added | 07:36 |
HiddenDjinn | flocculant: ok, thanks | 07:37 |
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:39 |
HiddenDjinn | s/not really why/not really sure why/ | 07:40 |
HiddenDjinn | fixed that for you | 07:40 |
flocculant | and by adding things - I mean making testing harder - not the OEM thing - which I cared about once ;) | 07:41 |
HiddenDjinn | oem thing? | 07:43 |
HiddenDjinn | i dropped out of the linux world for a bit...i think i need background | 07:43 |
flocculant | HiddenDjinn: a discussion that happened while I was asleep | 07:45 |
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 | 07:46 |
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:09 |
* flocculant suggests that we add lock/suspend testing to the post install test which currently doesn't test much | 08:11 | |
flocculant | !team | ^^ | 08:11 |
ubottu | ^^: akxwi-dave, bluesabre, dkessel, flocculant, jjfrv8, knome, krytarik, micahg, Noskcaj, ochosi, pleia2, slickymaster and Unit193 | 08:11 |
dkessel | makes sense, +1 | 08:12 |
flocculant | knome: re OEM - at least in vm - reboot to end user crashes ... | 08:13 |
flocculant | flexiondotorg: before I start digging around - should oem work in a vm? just getting black screen here ... | 08:15 |
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:30 |
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. | 08:35 |
akxwi-dave | flocculant: agree +1 | 10:22 |
ochosi | knome, bluesabre: we should have a brief discussion at some point about an inactive team members cleanup | 11:44 |
bluesabre | alrighty | 11:44 |
flocculant | flexiondotorg: thanks | 11:58 |
flocculant | ochosi bluesabre - thoughts on adding lock to a testcase? | 11:58 |
flocculant | can't see a problem with it tbh - better than not knowing *when* it failed | 11:59 |
knome | ochosi, i'm around for that now for example | 12:04 |
knome | tbe, now would be a very good time even | 12:05 |
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:06 |
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:07 |
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:08 |
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:09 |
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:10 |
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:11 |
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:12 |
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:13 |
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:14 |
* 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:15 |
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:16 |
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:17 |
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:18 |
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:19 |
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:20 |
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:21 |
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:22 |
knome | ochosi, bluesabre: ^ | 12:23 |
ochosi | knome: sry, had to leave | 13:03 |
ochosi | i have another 4min window *now* | 13:03 |
ochosi | :) | 13:03 |
ochosi | and i'm in said channel (alone) | 13:04 |
knome | no you're not | 13:04 |
jjfrv8 | flocculant, +1 to the lock/suspend testing | 13:12 |
flocculant | back | 16:03 |
akxwi-dave | front | 16:20 |
akxwi-dave | :-) | 16:21 |
flocculant | sideways shuffle | 16:21 |
akxwi-dave | old man shuffle.... | 16:21 |
flocculant | \o/ | 16:21 |
flocculant | mp done for suspend/lock | 16:36 |
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:37 |
akxwi-dave | :-) approved... | 16:39 |
flocculant | super :) | 16:40 |
flocculant | akxwi-dave: all done - on tracker now | 16:47 |
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:49 |
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:51 |
flocculant | hence grabbing a1fa into here the other day :) | 16:52 |
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:30 |
flocculant | https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1656399/comments/7 | 18:43 |
ubottu | Launchpad bug 1656399 in light-locker (Ubuntu) "Unable to unlock Xubuntu XFCE session after suspend." [Undecided,Confirmed] | 18:43 |
flocculant | *appears* to be lightdm this time | 18:43 |
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:48 |
* flocculant wonders if it started failing with 1.21.2-0ubuntu1 - the one I can't appear to find | 18:52 | |
flocculant | bluesabre: also robert ancell doesn't appear to be online so I can't ping him - maybe you will see him about later | 19:02 |
flocculant | caught him in -desktop | 20:36 |
flocculant | should have known he would want lightdm.log | 20:51 |
flocculant | hopefully they'll be able to add whatever broke to regression tests for locking functionality | 20:52 |
flocculant | paraphrasing r_ancell | 20:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!