[07:06] <pitti> Good morning
[07:57] <pitti> jibel: poor wazn, load of 9 and 6 QEMUs running in parallel..
[07:57] <pitti> (DKMS at the moment, apparently)
[07:59] <pitti> jibel: someone disabled the http_proxy setting from wazn's /etc/environment, and it seems when calling prepare-testbed from jenkins it doesn't get read (through PAM) anyway, so on alderamin/aldebaran/wazn I now added them to ~/.adtrc
[07:59] <pitti> jibel: could you please do the same on albali? I. e. append
[07:59] <pitti> http_proxy="http://squid.internal:3128"
[07:59] <pitti> https_proxy="http://squid.internal:3128"
[08:00] <jibel> Bonjour pitti
[08:01] <jibel> pitti, done
[08:17] <pitti> jibel: merci
[08:17] <pitti> jibel: bonjour!
[08:22] <jibel> pitti, do you think autopkgtest of apt timed out because a proxy is set?
[08:23] <jibel> we should also add a no_proxy=localhost
[08:26] <jibel> pitti, also for libreoffice, it fails because a chown of the test tree takes more than 100s and times out
[08:27] <jibel> do we really need all these timeouts in autopkgtest, or only 1 for the build and 1 for the test?
[08:43] <pitti> jibel: re
[08:43] <pitti> jibel: haven't looked at apt yet, next on my list
[08:43] <pitti> jibel: ah, I thought localhost was kind of implied, but sure, let's add that too
[08:44] <pitti> jibel: I didn't introduce them, but I think having *some* time out is good as sometimes copying stuff around involves tar | scp | tar etc. which can easily hang indefinitely
[08:55] <jibel> pitti, I know you didn't, but there are timeouts for nearly every action, which is probably too much e.g for dir copies or chown, I hardly see how these commands can block
[08:57] <jibel> I'll increase the short timeout to see if it makes libreoffice test go further
[08:57] <pitti> *nod*
[09:09] <pitti> jibel: I added no_proxy=localhost to .adtrc on the usual three and pushed a commit to also transition $no_proxy to the VMs
[09:10] <jibel> pitti, added to .adtrc and pulled on albali
[09:10] <pitti> jibel: merci
[09:12] <pitti> jibel: and FTR, yay for fixing the precise-lts-backports upgrades
[09:12]  * pitti looks at the remaining failures
[09:28] <davmor2> Morning all
[09:35] <pitti> jibel:         output_file = '/tmp/obsolete_conffiles.log'
[09:35] <pitti> jibel: how does that become a jenkins artifact?
[09:35] <pitti> jibel: does it just attach /tmp/*.log or do I need to register new files somewhere?
[09:36] <jibel> I think it's hardcoded somewhere :/
[09:36] <pitti> jibel: I want to make the conffile test more verbose, and add old/new files (perhaps a diff) as a new /tmp/conffile_prompts.log
[09:36] <jibel> in UpgradeTestBackendSSH.py
[09:36] <pitti> ./AutoUpgradeTester/UpgradeTestBackendSSH.py:        self._copyFromImage("/tmp/obsolete_conffiles.log", self.resultdir)
[09:36] <pitti> I only see that
[09:37] <pitti> does that apply to LXC as well?
[09:37] <jibel> pitti, it does
[09:37] <pitti> because these tests do get obsolete_conffiles.log
[09:37] <pitti> jibel: ah, ok; thanks!
[09:37] <pitti> # find /etc -name '*.dpkg-dist'
[09:37] <pitti> /etc/default/bind9.dpkg-dist
[09:37] <pitti> I found it, but it's still nicer to see it right away in jenkins
[09:37] <pitti> (reproduced locally in a chroot, I meant)
[09:38] <pitti> but there are half a dozen files in /etc named "bind9", it's too obtuse ATM
[09:39] <jibel> pitti, I should copy to a /tmp/result in the guest and copy that instead of individual files and preserve the directory tree structure, at least in the name
[09:42] <pitti> jibel: right, that should be easy; queueing that
[09:48]  * pitti pushes another commit that fixes upgrade-ubuntu-quantal-saucy-desktop-{i386,amd64}
[10:01] <pitti> jibel: do you know why test_dpkgdist does all that dance with copying stuff to /tmp ?
[10:02] <pitti> jibel: it would seem much more useful to me to compare the whitelist against the original paths, and print out the list comparison with that
[10:02] <pitti> jibel: in other words, do you mind if I completely rewrite that? (I have a work item "fix conffile upgrade test" anyway)
[10:31] <pitti> jibel: I pushed r94 for that, it just puts the diffs into the main log now
[10:31]  * pitti looks into the actual bind issue now
[10:45] <jibel> pitti, sorry was otp, it is just to collect them after the test
[10:45] <jibel> pitti, but it cannot work because conffiles = glob.glob('/tmp/*.dpkg-dist') is executed on the host :/
[10:47] <pitti> jibel: yeah, I think with r94 it's more useful
[10:48] <pitti> http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-tasks-amd64/30/console
[10:48] <pitti> jibel: of course now the tests fail due to the libgcc mess, but it also has the conffile prompt
[10:48] <pitti> jibel: no diff in this case as .dpkg-dist and /etc/default/bind9 are indeed identical, but I tested it on my workstation where I do have some changed conffiles
[10:49] <pitti> http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-server-tasks-amd64/30/artifact/results/bootstrap.log is better
[10:55] <rbasak> https://jenkins.qa.ubuntu.com/job/trusty-adt-php5/106/ looks like an infrastructure related issue.
[10:55] <rbasak> Is there anything I should be doing about this, or anybody I should be pinging? Or is this something that someone already keeps an eye out for?
[10:55] <pitti> rbasak: already handled
[10:55] <rbasak> Ah great. Thanks!
[10:55] <pitti> rbasak: it's because of the botched libgcc1 which breaks *everything* in trusty now
[10:56] <rbasak> Ah
[10:56] <pitti> we'll wait for the fixed gccgo to go in, then retry everything
[10:56] <pitti> see #u-devel backscroll
[10:56]  * rbasak looks
[10:56] <pitti> rbasak: it's not just php, there are a bazillion failures
[10:56] <pitti> jibel is currently looking why it wasn't held back in -proposed
[11:01] <rbasak> Thanks. That's an interesting/enlightening read.
[11:27] <pitti> jibel: darn, and I was soo close on http://d-jenkins.ubuntu-ci:8080/view/Upgrade/
[11:27] <pitti> the latter two failures should work as well now, after libgcc
[11:29] <jibel> pitti, nice. and from the logs I cannot find why it libgcc has been promoted :/ now reading the code of britney
[11:29] <jibel> I: [Fri Feb 14 09:42:55 2014] - Requested autopkgtest for glib2.0_2.39.4-0ubuntu1 (NEW gccgo-4.9 1:4.9-20140213-0ubuntu1)
[11:29] <jibel> I: [Fri Feb 14 09:44:03 2014] - Collected autopkgtest status for glib2.0_2.39.4-0ubuntu1: RUNNING
[11:29] <jibel> Copying: gccgo-4.9/4.9-20140213-0ubuntu1
[11:30] <jibel> for example, glib triggered by gccgo, correctly identified as running but gccgo has been copied anyway
[12:03] <pitti> jibel: I moved precise-i386.qcow2 away (to *.old) on alderamin, as they are ancient (may last year), and dist-upgrading them takes very long
[12:03] <pitti> jibel: I was hoping the job would rebuild them, but http://d-jenkins.ubuntu-ci:8080/view/Upgrade/job/upgrade-ubuntu-precise-trusty-desktop-i386_vm/29/console is just sitting there without any noticeable progress (or started processes)
[12:04] <pitti> jibel: does precise-{i386,amd64}.qcow2 need to be maintained/updated  manually then? (I can do that)
[12:10] <pitti> jibel: ah, I have a ubuntu-kvm-i386-precise/tmpDdXOIt.qcow2, apparently it's rebuilding now (just curious that I don't have a kvm/qemu process), so nevermind
[12:11] <jibel> pitti, no maintenance required, it is all created by vm-builder
[12:13] <jibel> pitti, although the resulting VM may require an update from time to time otherwise the dist-upgrade at the beginning of the test can take a while
[12:13] <jibel> I have a script somewhere to automate this
[12:13] <pitti> jibel: right, that's why I blew it away and let it rebuild
[12:13] <pitti> (well, I kept the previous .qcow until they get rebuilt)
[12:14] <pitti> ah, and there it is, a fresh precise-i386.qcow2 \o/
[12:14] <pitti> not 12.04.2 but .4 now
[12:25] <brain_> hi all
[15:07] <disc0tech> test
[16:05]  * balloons waves happy friday to all
[16:27] <roadmr> balloons: haha don't forget the <3
[16:29] <balloons> roadmr, :-) May cupid's arrow find it's way to all the loves in your life
[16:29] <roadmr> thanks <3
[17:27] <DanChapman> evening folks
[17:27] <elfy> g'evening :)
[19:57] <Letozaf_> balloons, hi
[20:45] <balloons> Letozaf_, hello
[20:47] <Letozaf_> balloons, hi I have a quite strange problem with reminders-app I uninstalled it and now I am unable to install it again I get: http://paste.ubuntu.com/6933106/ the fact is that I cannot find this qtdeclarative5-evernote0.1 anywhere, have you idea how to fix it ?
[20:47] <balloons> Letozaf_, apt-get update?
[20:48] <Letozaf_> balloons, I tried and it does not work, I have been trying a lot of stuff but nothing worked
[20:49] <Letozaf_> balloons, I was thinking to try on a new Trusty install on my notebook to see if it gets installed, because on my PC there is not way to get it installed
[20:49] <balloons> Letozaf_, likely the dependencies are not correct
[20:49] <balloons> so it's a packaging issue
[20:49] <balloons> it's pulling from the ppa
[20:50] <Letozaf_> balloons, yes I know but I cannot find the way to fix this :(
[20:50] <balloons> so, you can force install it anyway, odds are it will work. We have to look at what the package is called now
[20:53] <Letozaf_> balloons, ok I will try to force install
[21:22] <balloons> Letozaf_, any luck?
[21:23] <Letozaf_> balloons, no :(
[21:23] <balloons> Letozaf_, ok, let's look @ the packaging
[21:41] <balloons> Letozaf_, https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/daily?field.series_filter=trusty. you can see the version in there for the plugin
[21:41]  * Letozaf_ is looking at the link
[21:45] <Letozaf_> balloons, I do not see this qtdeclarative5-evernote0
[21:45] <Letozaf_> balloons, and I have already the evernote plugin installed
[21:45] <Letozaf_> account-plugin-evernote
[21:46] <balloons> ok, I removed the package and got the same issue
[21:46] <Letozaf_> balloons, argh!
[21:46] <balloons> Letozaf_, it's a good thing
[21:47] <balloons> it confirms it's a packaging issue
[21:47] <Letozaf_> balloons, good ?
[21:47] <balloons> bug filing time
[21:47] <Letozaf_> balloons, oh! now I understand what you ment with good
[21:47] <Letozaf_> balloons, ok so I will report a bug on this issue, ok?
[21:52] <Letozaf_> balloons, bug 1280459
[21:52] <balloons> Letozaf_, yes :-)
[22:17] <bfiller> balloons: we're getting a failure on an integration test on the latest image. any ideas on this? was previously working fine http://pastebin.ubuntu.com/6933841/
[22:17] <bfiller> autopilot test that is
[22:21] <balloons> bfiller, does the test use the uitk emulator?
[22:22] <bfiller> balloons: let me check, here is the full log. getting tons of introspection errors http://pastebin.ubuntu.com/6933871/
[22:26] <balloons> bfiller, the toolkit, the toolkit emulator, and autopilot have all changed within the past 24 hours
[22:26] <bfiller> balloons: yup, this broke something
[22:26] <balloons> I take it the codebase did not right?
[22:27] <bfiller> balloons: it's failing on this line: get_proxy_object_for_existing_process(pid) which looks like it's imported from from autopilot.introspection import get_proxy_object_for_existing_process
[22:28] <bfiller> balloons: the code did change in camera-app, but nothing at all that would affect this test
[22:28] <bfiller> balloons: but I'm getting blamed :)
[22:29] <balloons> bfiller, well first things first. Let's pull the old code and run with the new stuff and see what happens
[22:29] <bfiller> balloons: apparently that works, rsalveti tried it. where can I get the previous camera-app package to try?
[22:31] <rsalveti> bfiller: http://ports.ubuntu.com/pool/universe/c/camera-app/
[22:31] <balloons> rsalveti, bfiller I was going to checkout the old code and run it.
[22:31] <rsalveti> previous package is from 06-Nov
[22:31] <balloons> going to grab the code now, reproduce locally and go
[22:31] <balloons> rsalveti, oO why so old?
[22:32] <balloons> do we know what revno the package was built from?
[22:32] <rsalveti> bfiller might know :-)
[22:32] <rsalveti> hm, let me check the changelog
[22:32] <bfiller> rsalveti: let me check trunk
[22:32] <bfiller> trunk here btw https://code.launchpad.net/~phablet-team/camera-app/trunk
[22:33] <rsalveti> yeah, a lot was done that is test related since then
[22:33] <rsalveti> mostly porting to python3
[22:33] <rsalveti> balloons: rev 225
[22:33] <bfiller> ahah
[22:33] <bfiller> I see the problem
[22:33] <balloons> ahh I see omer did a py3 port in between
[22:34] <bfiller> rev 229
[22:34] <bfiller> omer added the test that is failing now
[22:34] <bfiller> so it was never being run previous to this release
[22:34] <bfiller> but I did build from trunk and test it a few days ago and it was working
[22:35] <balloons> unittest.loader.ModuleImportFailure.camera_app.tests.test_gallery_integration
[22:35] <balloons> I pulled trunk and hmm.. ohh, unity 8 :-)
[22:36] <rsalveti> bfiller: just fix it lol
[22:37] <rsalveti> let's land a new version
[22:37] <rsalveti> haha
[22:37] <bfiller> rsalveti: skip()!!!!
[22:37] <bfiller> what
[22:37] <rsalveti> haha
[22:41] <bfiller> balloons: when do you see that ModuleImportFailure error?
[22:41] <balloons> bfiller, trying to list the tests..
[22:43] <bfiller> balloons: shows up fine for me, you need unity8-autopilot installed as well
[22:43] <balloons> yes exactly
[22:43] <balloons> I did install build deps
[22:43] <balloons> *didn't
[22:44] <balloons> is webbrowser tests still ok?
[22:44] <balloons> they use the same calls
[22:49] <balloons> phablet only.. argh
[22:50] <bfiller> balloons: browser seems ok
[23:17] <bfiller> balloons: I need to EOD, I filed this bug if you figure anything out: https://bugs.launchpad.net/camera-app/+bug/1280485
[23:17] <balloons> bfiller, :-) I'm in the same boat
[23:17] <bfiller> balloons: in the mean time, I'm going to skip the test to unblock the image promotion
[23:18] <balloons> bfiller, since you filed a bug, no worries
[23:18] <bfiller> balloons: thanks, have a good weekend
[23:18] <balloons> rsalveti is correct.. it looks like this never ran
[23:18] <balloons> and it's not systematic, so it's just camera
[23:18] <balloons> enjoy bfiller
[23:23] <phillw> balloons: ping