[05:46] <infinity> New ISOs being respun for all flavours for the "no CD eject" bug.
[05:46] <infinity> I intend for these to be the images we release tomorrow, so some quick smoketesting to make sure they're all sane would be great.
[05:47] <infinity> They should all spit out with 20150326 build numbers.
[05:48] <infinity> Also, if anyone has spare cycles to help out ubuntustudio with basic smoketesting, I'm not sure if zequence is around.
[09:39] <mgedmin> balloons, I hear you're the one to bother about https://bugs.launchpad.net/ubuntu-qa-website/+bug/1418383
[09:40] <mgedmin> tl;dr: I cannot login to iso.qa.ubuntu.com for several months now (but I could in the past)
[09:40] <mgedmin> this smells like some confusion in the Drupal user database?  where my local account isn't linked to the SSO account correctly?
[11:10] <pitti> jibel: how easy is it to disable the triggering of armhf/ppc64el jobs for the time being?
[11:10] <pitti> IMHO we should do that, me clicking away the queue for hours isn't going to help anything
[11:10]  * pitti does the click-o-mania right now, but that's insane
[11:13] <jibel> pitti, I asked psivaa to try my script, if it's a permission issue he should be able to do it
[11:13] <pitti> jibel: ah, thanks
[11:13] <pitti> much better
[12:01] <davmor2> jibel: I'm trying uefi install of oem again now see if it was something freak or more serious
[12:22] <pitti> jibel: how can we disable new armhf/ppc64el jobs, i. e. the triggering from the x86 ones? in the jenkins job config or do we need a bzr commit/rollout?
[12:23] <davmor2> jibel: definitely and issue on UEFI + secureboot, I'll try uefi in virtualbox if that fails too then it is a UEFI if not I'll try turning secureboot off and run an install on hw
[13:02] <jibel> davmor2, so OEM is broken on UEFI + secure boot, but not on UEFI without SB or BIOS?
[13:05] <davmor2> jibel: not tried uefi without it fails dismally in virtualbox
[13:06] <davmor2> jibel: I'm going to knock off secure boot on my laptop and try it there after Lunch
[13:06] <jibel> davmor2, and a normal installation with UEFI + SB is successful?
[13:06]  * jibel trying to understand the scope of the problem
[13:07] <davmor2> jibel: normal + SB is fine, I've done 3 installs on that system so far only oem is playing up
[14:14] <davmor2> jibel: so broken on UEFI with no SB too
[14:15] <davmor2> jibel: looks like the oem removal bit breaks so you get a system that is part oem part user
[14:17] <davmor2> jibel: unity-settings-deamon crash trying to file it now
[14:26] <davmor2> jibel: bug 1436861
[14:36] <primes2h> bug #1436861
[14:39] <davmor2> it's private still as it is from a crash report
[14:39] <davmor2> lets fix that
[14:41] <davmor2> jibel: bug 1436861
[16:00] <jibel> davmor2, I don't have this crash but an Xorg crash instead with an OEM installation
[16:01] <davmor2> jibel: yeap I got an xorg crash too, I think it is because x is restarted for lightdm
[16:03] <jibel> davmor2, so we have "OEM install is broken" and "cannot eject CD" anything else?
[16:04] <jibel> I tried non-english, lvm, custom partionning, free software only, ... looks ok
[16:04] <davmor2> keyboard us and your keyboard installed
[16:05] <jibel> that too but not really annoying, in my case Fr was first
[16:05] <davmor2> jibel: https://bugs.launchpad.net/bugs/1434091
[16:05] <jibel> davmor2, with desktop too
[16:05] <jibel> not only mini
[16:06] <davmor2> jibel: yeah at the time it was only effecting mini.iso though the desktop cd caught up with the archives I guess
[16:20] <davmor2> jibel: cd eject issue is fix in the latest image
[16:20] <jibel> davmor2, really? what fixed it
[16:20] <jibel> ?
[16:20] <davmor2> well I say "fixed" it appears now and sometime the enter key works :)
[16:21] <elfy> I'd say 'fixed' too :p
[16:21] <davmor2> jibel: cyphermox  fixored it
[16:21] <jibel> ah yeah, casper, I see it
[16:22] <davmor2> elfy: keyboard selector showing up for you now too?
[16:22] <elfy> I hope not - we don't do that stuff in Xubuntu since the debacle with ibus at 14.04
[16:24] <elfy> davmor2: the only time I boot someone else's image is if I'm trying to see if issues we see are global or not
[16:25] <cyphermox> half-fixored it
[16:25] <davmor2> elfy: I thought the initial keyboard selector in ubiquity bug was filed by you maybe I was dreaming
[16:25] <davmor2> cyphermox: it's as broken as it was before the regression
[16:26] <cyphermox> well, the enter key never seems to work?
[16:26] <elfy> davmor2: if it was filed in 2014 during lts dev - you're probably right
[16:26] <davmor2> cyphermox: okay slightly worse then but at least similar :)
[16:27] <davmor2> elfy: hahaha
[16:28] <davmor2> jibel: I'm concentrating on i386 at the minute 64bit seems mostly done
[16:29] <jibel> davmor2, I'm doing i386 too, and will do a bunch of server tests. results of of automated tests are suspicious
[16:29] <davmor2> jibel: I bet it is the TTY7 issue
[16:29] <jibel> davmor2, nope, system doesn't start at all
[16:30] <davmor2> jibel: hmmm that's not so good
[16:31] <jibel> cyphermox, can you fix the reboot after install in VMs too? currently it just hangs
[16:34] <davmor2> jibel: you on the latest image?
[16:35] <jibel> davmor2, yes
[16:35] <davmor2> cyphermox: oh and bug 1436861
[16:35] <jibel> yes, it matches
[16:36] <jibel> it = checksums
[16:36] <jibel> davmor2, OEM is clearly broken, on i386 and the end user setup I've an account for the end user and the temporary oem user
[16:36] <jibel> cyphermox, ^
[16:37] <davmor2> jibel: I didn't think uefi worked on i386
[16:37] <jibel> davmor2, it doesn't, i386 in BIOS mode
[16:38] <davmor2> jibel: hmmm I didn't have that on bios only on uefi
[16:39] <davmor2> cyphermox: confirmed enter key definitely does nothing :(
[16:40] <cyphermox> yeah, I'm fighting it right now
[16:40] <cyphermox> fwiw, I probably am not intelligent enough to deal with the unity-settings-daemon bug you mentioned, i think it's for somebody else
[16:41] <davmor2> cyphermox: man you deal with the installer now it's all yours ;)  Kinda critical bug too as it is OEM mode that is broken
[16:41] <cyphermox> is it installer?
[16:42] <cyphermox> isn't it a bug in unity-settings-daemon?
[16:42] <davmor2> cyphermox: yeap user setup from OEM mode
[16:43] <elfy> I do feel your pain - but I'm really glad this is global and not Xubuntu :p
[16:43] <cyphermox> well, sure, but I think you'd find it explodes anywhere.
[16:43] <davmor2> cyphermox: so you install, then you enter oem mode, click on prepare for end user, reboot and the bug happens in the end user setup part
[16:43] <cyphermox> right
[16:44] <cyphermox> it's gsd and all of that though, I think you want to push it to the desktop team, someone might be able to get to the bottom of it quicker than I can
[16:44] <davmor2> cyphermox: no I blame you, you are completely free to annoy other devs with it ;)
[16:45] <cyphermox> at the point you're running prepare from OEM you're running ubiquity, yes, but in a pretty standard session, so it might well break even if you don't run oem-setup at all
[16:45] <cyphermox> hahah
[16:46] <jibel> cyphermox, bug 1436937
[16:46] <cyphermox> jibel: I suspect when I get the eject/reboot thing right it will fix the hangs in VM too... they weren't hanging before, no?
[16:46] <jibel> cyphermox, before it switched to a console and you could press enter to reboot
[16:47] <cyphermox> jibel: I mean between the just rebooting and not showing the prompt or enter, and the time I "fixed" that
[16:47] <jibel> cyphermox, no it didn't work on recent images
[16:48] <cyphermox> in other words, my fix for the eject is incomplete or otherwise broken, because it causes the hangs
[16:48] <jibel> ok, got it
[16:48] <cyphermox> and I more or less know why, after showing the prompt some systemd bits are trying to unmount /cdrom and just looping
[16:48] <cyphermox> I just haven't found what tries to do this, so not sure how to fix it
[16:50] <jibel> ah systemd again, easy victim :)
[16:50] <cyphermox> :)
[16:51] <elfy> ha ha
[16:51] <jibel> cyphermox, don't kick me from the internet again next time I doubt of your fixes :P
[16:51] <cyphermox> hihihi