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