=== Eisbrecher_xnox is now known as xnox
=== psivaa-off is now known as psivaa
=== ara is now known as Guest56630
[11:55] <bjf> xnox, any progress on that "installer bug"?
[12:03] <xnox> bjf: yes and no. Haven't reproduced the failure.
[12:03] <xnox> bjf: and my local utah setup, no longer at all works.
[12:13] <cking> xnox, has utah changed (again?)
[12:14] <xnox> cking: there was stable release in june this year. and i'm assured that's what running in production, however it no longer provisions VMs in my local setup as it used to.
[12:14] <xnox> cking: also
[12:15] <xnox> bjf: cking: "<plars> Eisbrecher_xnox: looks like I can produce this problem on VM with latest trusty now that we have them"
[12:16] <xnox> bjf: it's not utopic unique. (at least in terms of guest)
[12:16] <bjf> xnox, ack
[12:17] <bjf> xnox, i'm also confused by the "now that we have them" part of that statement and wonder "why didn't you have them before?"
[12:19] <xnox> bjf: for some time we didn't have trusty dailies built (due to contention with precise dailies, it's first time we have .5 release) thus at first it was blocked on to moving building cds from nusakan into launchpad.
[12:19] <xnox> bjf: the launchpad bit is complete, and all images are build by launchpad buildd farm now.
[12:19] <bjf> xnox, ah, ok, makes sense
[12:19] <xnox> bjf: however, UTAH was searching for /daily-live/trusty-desktop-amd64.iso
[12:20] <xnox> bjf: whereas stable dailies are published in /trusty/daily-live/trusty-desktop-amd64.iso
[12:20] <xnox> bjf: top-level /daily-live/ is for devel series only, that is utopic now. And hence utah didn't pick up the new images when they started to be generated.
[12:21] <xnox> bjf: (well there is an extra subdir for image build number & current)
[12:24] <bjf> xnox, what do you need at this point to make progress? do you need help from plars and nuclearbob for the utah side?
[12:26] <xnox> bjf: i don't know if nuclearbob works on utah. I've been directed at ev, psivaa, plars, doanac.
[12:27] <xnox> bjf: in the mean time, I am investigating how to provision and run tests without UTAH in between.
[12:27] <bjf> xnox, if you would like utah help, i'm happy to go have a chat with evan
[12:27] <xnox> bjf: e.g. using a simple pxeboot provisioning and test provision/collection. Which should work with VMs and bare-metal alike.
[12:29] <xnox> bjf: i don't care much about utah. The hard-pressing thing is that: (a) bootspeed tests are not executed (b) power tests are not executed (c) utopic desktop daily tests has not run since 20th of May (thus not migrated from pending -> current)
[12:30] <cking> xnox, the weakness does seem to be at the utah side of things
[12:33] <bjf> xnox, i agree with you. i would hope that you could repro the issue outside of utah but if you can't we should get them involved
[12:35] <bjf> xnox, is there any additional information they can provide to you which would help debug this? if they provided you with access to a system in this particular state?
[12:38] <xnox> bjf: access to utah server, from which i can trigger utah provisioning runs would be useful, yes. Since my local utah setup is non-operation (as in it doesn't get as far as ci.ubuntu.com utah runs get to)
[12:38] <xnox> bjf: and it's not like current utah production server does anything useful =) given all tests timeout and don't run.
[12:39] <xnox> it's interesting that trusty 14.04.0 test run today, shows the in-ability to unmount /target ( https://jenkins.qa.ubuntu.com/job/trusty-desktop-amd64-smoke-default/163/artifact/log/utah-24420-install.log/*view*/ )
[12:40] <xnox> based on artifacts there, i believe the machine did install and reboot was requested.
[12:41] <xnox> but the target machine never showed up with working ssh server open.
[12:41] <xnox> https://jenkins.qa.ubuntu.com/job/trusty-desktop-amd64-smoke-default/163/artifact/log/utah-server-ssh.log/*view*/
[12:51] <psivaa> xnox: just going through the backlog.. re: 'current utah production server does anything useful =) given all tests timeout' we have server iso installations running ok 
[12:51] <psivaa> xnox: the issue we are facing is only pertainning to desktop iso's
[12:51] <psivaa> xnox: the issue only started when we upgraded the production servers from precise-> trusty
[12:57] <bjf> psivaa, that's a completely different story than we have been getting
[12:57] <bjf> psivaa, we've been told that the problem is with the installer when installing on the test system
[12:57] <bjf> psivaa, it sounds like you are saying that after you updated your infrastructure it started failing
[12:58] <psivaa> bjf: well as you know the 'failing' has been for quite a long time and there was one or two installer issues two in between
[12:59] <psivaa> bjf: when i checked last time, it wasn't alone the installer thats at fault.
[12:59] <psivaa> bjf: and that was a couple of weeks ago 
[13:00] <bjf> psivaa, how do we all come together on this and get the tests running again?
[13:00] <psivaa> bjf: manual installation went fine. and i tried a preseeded installation too and that worked too, outside of utah
[13:00] <bjf> psivaa, so how did the finger get pointed at the installer?
[13:01] <psivaa> bjf: as i said there were installer bugs too in between even with manual installation. but i *think that got fixed now
[13:01] <psivaa> (the finger pointed earlier might not have folded :))
[13:02] <bjf> psivaa, so what is the current issue(s) that need to be addressed to get the tests running again?
[13:03] <psivaa> bjf: the current issue was (when i checked about a week and half ago) that utah installation of desktop goes on a loop on trusty production servers and instead of  rebooting to login screen after the install, it starts the installation again. 
[13:04] <bjf> psivaa, and where do you believe that issue exists? is it utah?
[13:05] <psivaa> bjf: i'd start from utah for a fix. but not ruling out any changes in the installer side that could make utah server to think that the installation is complete
[13:06] <psivaa> s/complete/not complete/
[13:07] <bjf> psivaa, ok, lets start with utah. who works on utah these days?
[13:09] <psivaa> bjf: so I think utah is now basically in  maintenance mode awaiting deprecating, in light of the ci-airline development. doanac, plars and myself in our team do the fixes as we see fit. 
[13:09] <psivaa> this appear to be a complicated issue and there fore outside my capability
[13:15]  * cking wonders how many infrastructure development iterations are required to get something working for at least 2 cycles w/o breaking
[14:15] <apw> psivaa, i thought we used the same framework for the SRU validation, is this going to cause issues qualifying .5 ?
[14:20] <psivaa> apw: for kernel SRU, we dont use utah. for precise iso testing we dont use utah either. so should not affect precise .5. Not sure if anyone is using it for SRU validation of the other packages
=== fmasi is now known as Guest75332
[19:35] <jdstrand> rsalveti (and rtg): did the apparmor signal/ptraces patches make it into phone images yet?
[19:36] <rsalveti> jdstrand: yes
[19:36] <jdstrand> rsalveti: I was looking at https://launchpad.net/ubuntu/utopic/+source/linux-mako, but didn't see it in the changelog. is that expected?
[19:37] <jdstrand> oh, I see it in 3.4.0-5.30
[19:37] <jdstrand> rsalveti: nm, thanks!
[19:37] <jdstrand> it got hidden due to the ftbfs entry
[19:41] <jdstrand> rsalveti: thanks for that testing btw :)
[19:43] <rsalveti> jdstrand: np!
[22:01] <awe_> sforshee, could you or someone on your team take a look at: https://bugs.launchpad.net/ubuntu/+source/linux-mako/+bug/1337753
[22:01] <ubot5> Ubuntu bug 1337753 in wpa (Ubuntu) "[mako] can not create an ad-hoc network" [Medium,Incomplete]
[23:15] <xevious> This isn't a kernel development question, but regarding internal kernel operations: when would it be necessary to manually use the sync command line utility? Shouldn't any pending writes be flushed when I run `losetup -d /dev/loopX` or `dmsetup remove exampledevice`? What types of operations could a user perform that the kernel wouldn't automatically sync? Can you provide examples of when I would need to run the sync command?