[01:28] <coffeemug> hi 16.04 solved my blank monitor problem. i have a gtx 960 ssc and a 4k and hd monitor
[01:28] <coffeemug> i first tried 14.04.3
[01:29] <coffeemug> only non fatal error i got was fecs install had failed?
[01:29] <coffeemug> i'm using the tested nvidia prop drivers and it's a lot smoother than xorg
[01:30] <coffeemug> anyhoo it's the daily build for 16.04 i'll
[01:30] <coffeemug> do i need to enable anything for system stats/feedback in xenial?
[01:32] <coffeemug> thanks folks :)
[07:53] <CountryfiedLinux> howdy
[07:54] <CountryfiedLinux> Will we be able to move the panel to the bottom when 16.04 is out?
[08:56] <lordievader> Good morning.
[11:49] <BluesKaj> Hi folks
[13:55] <jtaylor> first upgrade attempt 1404 -> 16.04 was a great success
[13:56] <jtaylor> kernel paniced during the upgrade
[13:56] <jtaylor> very weird
[13:56] <jtaylor> not sure how that can even happen
[13:57] <lotuspsychje> jtaylor: its not recommended to upgrade yet from trusty
[13:58] <lotuspsychje> jtaylor: clean install instead to test
[13:58] <jtaylor> lotuspsychje: someone has to test the upgrade
[13:59] <lotuspsychje> jtaylor: sure, but still not recommended in this stage
[13:59] <jtaylor> I'm aware of that
[14:00] <lotuspsychje> lets say you want to report a bug to 16.04 and you have some weird leftover from 14.04
[14:00] <lotuspsychje> not very effective
[14:01] <jtaylor> I'm able to figure that out, but not what could cause a panic during an upgrade
[14:01] <jtaylor> it shouldn't touch the running kernel at all
[14:19] <joumetal> jtaylor are you trying recover that installation?
[14:19] <jtaylor> joumetal: I'm currently doing so
[14:20] <jtaylor> joumetal: interesting the kernel also panics on boot
[14:20] <jtaylor> but by setting init to bash I can rerun the installation
[14:20] <jtaylor> lets see what comes out when its done
[14:22] <jtaylor> my guess is its somehow related to my lvm setup
[14:22] <jtaylor> maybe the upgraded migrated something on disk and the current kernel (4.2) could not deal with it
[14:22] <jtaylor> (or corrupted)
[14:25] <BluesKaj> jtaylor, the latest kernel for 16.04 is 4.4
[14:26] <jtaylor> but 14.04 is 4.2
[14:26] <lotuspsychje> nop
[14:26] <jtaylor> well not yet latest but soon ;)
[14:26] <lotuspsychje> !info linux-image-generic trusty
[14:26] <jtaylor> lts-wily whih will be default on the next point release
[14:26] <jtaylor> lotuspsychje: hats 14.04.0
[14:26] <jtaylor> I'm on 14.04.4
[14:27] <jtaylor> (not yet released)
[14:27] <BluesKaj> then what are you doing in #ubuntu+1?
[14:27] <jtaylor> I'm testing the upgrade to +1
[14:27] <nneul> Is there a set time in the release schedule at which point it would be safe to rely on apt-get upgrade getting you to the same state as a fresh install of the release? In particular, at what point will that apply for alphas/betas/etc. of 16.04?
[14:27] <nneul> I thought that there were still points during the early alphas where changes to the install infrastructure could result in the final install being different?
[14:28] <jtaylor> nneul: there is no set time, its always the case
[14:28] <BluesKaj> jtaylor, do you have / and /home partitions?
[14:28] <lotuspsychje> nneul: its not recommended to upgrade until final, fresh install 16.04 for testing
[14:28] <nneul> jtaylor: so it's reasonable to rely on:   (install of release on april >21) == (install of alphas + apt-get upgrade on april >21) ?
[14:29] <jtaylor> you might accumulate some stuff thats not present in a clean fresh install
[14:29] <jtaylor> but generally upgrading gets you to a very similar state
[14:29] <jtaylor> nneul: local config files might differ though as they are creted at runtime
[14:29] <jtaylor> BluesKaj: no /home, but lots of lvm partitions
[14:29] <nneul> ok, that works. those sorts of things are just normal expectations of any time you do updates...
[14:29] <nneul> Thank you!
[14:29] <lordievader> jtaylor: Is upgrading from Trusty already possible?
[14:29] <lordievader> With the -d flag or something?
[14:29] <jtaylor> lordievader: no
[14:30] <jtaylor> lordievader: possible yes, should you do it no
[14:30] <lordievader> jtaylor: Wasn't planning that ;) Having one test box is enough.
[14:32] <BluesKaj> jtaylor, if you had a /home partiton then you could install to / and simply set the mountpoint for /home during the installion partitioning phase, and you'd have an up to date clean install if you chose a daily image iso .
[14:33] <jtaylor> BluesKaj: if I did not want to test the upgrade that would be option
[14:33] <jtaylor> but I do ;)
[14:33] <jtaylor> (I expected it to fail, but not like that)
[14:34] <BluesKaj> i don't see the point of testing theupgrade proces, but that's your call
[14:36] <lordievader> BluesKaj: That path should also be tested. Quite a lot of people don't want to reinstall when going to Xenial.
[14:38]  * BluesKaj shrugs, ok lordievader be my guest, have fun :-)
[14:38] <lotuspsychje> upgrade proces will be tested by the devs too right
[14:38] <lotuspsychje> i dont see the point either
[14:38] <lordievader> I'm not saying I'm going to test is. But I am saying testing the upgrade is valuable.
[14:39] <lordievader> lotuspsychje: Most testers on iso.qa.u.c are volunteers. Probably only a handfull are developers.
[14:39] <jtaylor> lotuspsychje: upgrades depend on what is installed
[14:39] <BluesKaj> there are so any changes made everyday, i's like chasing bubbles IMO
[14:39] <lotuspsychje> against wich file would a bug be filed for an upgrade?
[14:39] <jtaylor> lotuspsychje: it is impossible to test all permutations
[14:39] <jtaylor> lotuspsychje: (also I am a dev)
[14:39] <lotuspsychje> upgrades are always tricky
[14:40] <lordievader> It is strange that iso.qa doesn't list any upgrade tests though.
[15:32] <jtaylor> hurray the borked upgrade has recovered and I have a working system :)
[15:33] <joumetal> nice
[15:34] <jtaylor> quite amazing that a 3000k package upgrade of a system actually works with only some minimal nodding
[15:36] <joumetal> did you use update-manager?
[15:36] <jtaylor> do-release-upgrade
[15:36] <jtaylor> but that paniced at an unknown state, quite early
[15:37] <jtaylor> the rest just dist-upgrade -f and install -f and some manual removals where that failed
[17:31] <Guest60557> hi
[17:32] <Guest60557> is it normal, on xenial, that a normal user can do "init 6" in  terminal?
[17:35] <joumetal> init 6 rebooted
[17:36] <Guest60557> sure, but for normal users???
[17:36] <Guest60557> on 14.04 it needs root rights
[17:37] <Guest60557> sudo init 6
[17:40] <Guest60557> i am using ubuntu-studio 16.04, and i do not understand, that "init 6" is working for a normal user ...
[17:48] <Guest60557> any idea?
[17:50] <lordievader> Ain't that polkits doing? Since desktop users can reboot a machine, I suppose the same counts for running init 6. (Which will probably be translated to systemctl reboot)
[17:53] <Guest60557> what means desktop user? in the moment a normal user can reboot or shutdown (init 0) the server ... is that normal?
[17:54] <lordievader> For a server it might be different. But for the desktop flavours of ubuntu the normal users are able to reboot the machine.
[17:54] <lordievader> Anyhow, like I'd said I'd investigate polkit for this.
[17:55] <Guest60557> since when is it normal, that a user. without su, can do init 6 or init 0?
[17:56] <lordievader> I don't know about init, but like I said a desktop user should be able to reboot a machine. And since init is replaced with systemd...
[17:58] <Guest60557> ok, since when a user can do "systemctl isolate rescue.target", for exp.,  without root permission?
[17:59] <lordievader> If polkit is setup to allow that, a user can. Have you investigated the polkit settings?
[18:00] <Guest60557> sorry, but  what is polkit?
[18:00] <lordievader> Guest60557: https://www.freedesktop.org/wiki/Software/polkit/
[18:01] <Guest60557> ok
[18:10] <Guest65238> lordievader, systemctl isolate ... .target needs root password, but init is working without password
[18:13] <Guest65238> any idea?
[19:03] <lordievader> Hmm, that is odd. Especially seeing that run levels do not really exist anymore..
[21:00] <dbarros> Unity launcher on the botton -> is it possible using current build ?
[21:00] <k1l> dbarros: no
[21:01] <dbarros> not even by a workaround?
[21:01] <k1l> there was a patch proposed but not accepted. you could compile that patch in yourself
[21:04] <k1l> https://code.launchpad.net/~feng-kylin/unity/unityshell-rotated-kylin/+merge/281182
[21:04] <k1l> this is the patch all the news sites say its already included into 16.04, but its not
[21:05] <dbarros> I see