[02:17] <arsonist> hello all, while upgrading the Ubuntu GNOME Desktop i386 for Trusty Daily iso, the upgrade manager stops working and  displays a message saying that it failed to download the repository information with the following output:       W:Failed to fetch http://extras.ubuntu.com/ubuntu/dists/trusty/main/source/Sources  404  Not Found [IP: 91.189.92.152 80]
[02:17] <arsonist> , W:Failed to fetch http://extras.ubuntu.com/ubuntu/dists/trusty/main/binary-i386/Packages  404  Not Found [IP: 91.189.92.152 80]
[02:17] <arsonist> , E:Some index files failed to download. They have been ignored, or old ones used instead.
[02:17] <arsonist> I am using a VM to run the test, this happens after running the update manager while it is checking for updates. Does anybody have the same problem or some info about it? Thank you!
[02:19] <arsonist> ps: the internet connection works fine
[03:04] <arsonist> it was a connection problem after all
[06:12] <jibel> Good morning
[08:03] <pitti> elopio: would you mind reviewing https://code.launchpad.net/~pitti/autopilot-gtk/build-gdbus-binding/+merge/194459 ?
[08:03] <pitti> elopio: it's rather straightforward, but as we require peer review for everything..
[08:11] <elfy> morning DanChapman
[08:15] <elopio> pitti: it looks good. I tried it and the two files where generated.
[08:15] <elopio> however, I just know a little about cmake. If you might also want a review from somebody that knows more about it.
[08:15] <elopio> if it's straightforward, maybe it's not necessary.
[08:15] <DanChapman> morning elfy :-)
[08:18] <jibel> DanChapman, elfy good morning
[08:19] <DanChapman> Good morning jibel o/
[08:19] <jibel> DanChapman, Ubiquity tests found bug 1249207 :)
[08:20] <pitti> elopio: well, it works under sbuild and with a local mkdir build && (cd build && cmake .. && make -j4), and passes tests; I got that from r8, so it already was in place in the past, so it's good enough for me
[08:20] <pitti> elopio: (and cmake is a mystery for me too, FWIW
[08:20] <pitti> elopio: thanks
[08:20] <pitti> elopio: I'll wait for the PS jenkins run to be triple sure
[08:21] <elopio> pitti: I top approved it.
[08:22] <elopio> if jenkins doesn't like it, it will not land.
[08:22] <DanChapman> jibel, awesome! it's working :-) is the 10.97.254.2 a private IP? I can't access it
[08:23] <elfy> hi jibel
[08:23] <elfy> well that's good to hear - I'm just waiting to see what occurs with my images
[08:24] <jibel> DanChapman, yes it is. Jobs are published to jenkins.qa.u.c (e.g https://jenkins.qa.ubuntu.com/job/ubiquity_ap-edubuntu_devel_daily-test_english_default/) but the view is not created
[08:25] <jibel> I cannot do it myself, I'm waiting for someone to proceed with the creation of the view.
[09:10] <DanChapman> jibel, thats cool. I can see on jenkins jobs like this https://jenkins.qa.ubuntu.com/job/ubiquity_ap-xubuntu_devel_daily-test_english_custom_install/ but it looks like it's trying to run all the tests and not just the custom_install. Are these not the correct views?
[09:14] <jibel> DanChapman, ah, TESTNAME= , so it runs everything that matches ubiquity_autopilot_tests.tests.* . stupid me :)
[09:14] <jibel> I'll fix that
[09:14] <DanChapman> :-)
[09:25] <jibel> DanChapman, fixed in r53
[09:25] <jibel> of the runner that is
[09:26] <DanChapman> jibel lovely :-)
[09:34] <jibel> r54 fixes an unbound variable
[11:08] <davmor2> Morning all
[11:16] <davmor2> balloons: to return the favour of getting ping while not actually here ;)  On calendar I notice that the save toolbar on events wouldn't stay visible when you drop the keyboard and wouldn't rise to click save.  Pretty sure it is still there I'll have a look after though
[13:20] <davmor2> balloons: yes so create a new event in the calendar definitely doesn't keep the chrome bar in play
[14:09] <helmut> hi. the autopkgtest wiki page points here. is there a standard way to require the source of a different package (in the most recent version) to be available?
[14:13] <davmor2> pitti: ^ is this something you can help with at all?
[14:13] <pitti> helmut: apt-get source <pkgname> :)
[14:13] <helmut> pitti: ok. fine.
[14:16] <helmut> can you also tell me whether some infrastructure (on debian or ubuntu) regularly(?) runs those tests and exports the results in a 1) http browsable or 2) notifyable (email?) way?
[14:16] <helmut> I didn't find anything using google and nothing on jenkins.d.n either.
[14:17] <helmut> afaik ubuntu uses it for package migration and debian is in the process to do the same.
[14:17] <jibel> helmut, tests run in the Ubuntu QA lab and results are published on https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/
[14:17] <helmut> thanks
[14:18] <jibel> helmut, last uploader is notified on failure
[14:18] <jibel> by email
[14:22] <helmut> getting used to working with dep8 probably takes some time, but it really looks promising. thanks for the work on it and your answers.
[16:29] <DanChapman> jibel, quick question so once all the views have been created will the individual jobs for each flavor be collated to display on the ubiquity_ap-*_devel_daily_run result for each flavor??
[16:32] <MissJule> Hi, I'm new to ISO testing, just installed Ubuntu 14.04 and noticed that the selected keyboard layout isnt there anymore when I boot the freshly installed system, had to add it manually again. where to report this? which package?
[16:37] <MissJule> I read the "FindRightPackage" page but I'm still confused...
[16:37] <jibel> DanChapman, I didn't set it up this way, but that's a good idea to aggregate results of downstream jobs. I'll update the configurations
[16:40] <balloons> MissJule, hmmm
[16:40] <balloons> indicator-keyboard something or other.. let's see
[16:41] <balloons> indeed.. indicator-keyboard it is
[16:43] <MissJule> thank you balloons!
[16:43] <balloons> yw MissJule :-) ty!
[17:04] <DanChapman>  jibel, cool :-) it will make it easier to see the jobs as a whole
[17:07] <DanChapman> balloons, did you see the ubiquity tests caught its first bug today :-)
[17:07] <balloons> oO nice!
[17:07] <balloons> I did not actually
[17:08] <DanChapman> balloons, bug 1249207
[17:10] <balloons> nicely done!
[17:15] <jibel> DanChapman, there is something odd with the results of custom_install tests. They return empty junit xml
[17:15] <jibel> something like:
[17:15] <jibel> <testsuite errors="0" failures="0" name="" tests="0" time="0.000">

[17:16] <jibel> stgraber, BTW you might be interested by bug 1249207
[17:17] <jibel> I filed it against edubuntu-meta because I don't really where it belongs, feel free to reassign
[17:17] <jibel> +know
[17:18] <stgraber> wth is going on there...
[17:19] <stgraber> seems like I'll have to go dig into the cdimage code to see where Edubuntu is getting special cased and hits the wrong code path...
[17:24] <DanChapman> jibel I had noticed that and also some of the jobs are also are saying 'Latest Test Result (no tests)'
[17:26] <DanChapman> oh i see they are the jobs from before the name changes
[17:29] <DanChapman> jibel this is a strange one aswell https://jenkins.qa.ubuntu.com/job/ubiquity_ap-ubuntu_devel_daily-test_english_lvm/ARCH=i386,label=rabisu/lastSuccessfulBuild/artifact/results/var/local/autopilot/junit/ubiquity_autopilot_tests.tests.test_english_lvm.xml
[17:33] <DanChapman> jibel is the custom install jobs trying to run test_custom_install or test_english_custom_install? the testname for that one stayed the same with test_custom_install
[17:35] <DanChapman> I should probably change it to test_english_custom_install to match the others
[17:35] <jibel> DanChapman, ah, thanks, that explains it. I'll fix that
[18:09] <davmor2> balloons: did you get my reply by the way :)
[18:09] <balloons> davmor2, ahh yes, from this morning, sounds like you too have experienced the issue
[18:10] <davmor2> right teatime
[19:23] <elopio> balloons: my weather clean ups turned into two fixes and a new emulator for the uitoolkit.
[19:23] <elopio> but there's nobody around to approve them, so it'll have to wait for monday.
[19:37] <balloons> elopio, hehe.. funnny how that works eh?
[19:42] <elopio> balloons: yeah, now I'm not sure if I should keep stacking branches
[19:43] <elopio> who invented dependencies? we should just duplicate everything everywhere.
[19:43] <balloons> static link everything
[19:43] <balloons> perfect, done
[20:06] <elopio> robotfuel: now I'm looking at your mir demo, sorry for the dealy.
[20:06] <elopio> delay
[20:06] <elopio> what is this for?
[20:07] <robotfuel> it's for running the mir demos to for x seconds make sure there are no issues for ci
[20:07] <robotfuel> elopio: after we get data we can make sure that fps don't drop past x
[20:08] <robotfuel> elopio: you can see in the default test that it prints fps
[20:09] <elopio> robotfuel: I'm not sure how to run it.
[20:09] <elopio> $ python run_demo.py test.out
[20:09] <elopio> INFO:root:Starting mir display server.
[20:09] <elopio> ERROR:root:Unable to launch display server: [Errno 2] No such file or directory
[20:11] <robotfuel> elopio: do you have mir installed on your system?
[20:12] <Letozaf_> balloons, Hi
[20:13] <Letozaf_> balloons, I got this running apt-get dist-upgrade today: http://paste.ubuntu.com/6384066/   should I report a bug ?
[20:15] <balloons> Letozaf_, howdy
[20:16] <balloons> ohh nice.. indeed, that's a bug in the post-install script
[20:17] <balloons> new version just went up a few hours ago
[20:17] <balloons> and you have it :-)
[20:17] <balloons> file away!
[20:17] <Letozaf_> balloons, ok :D
[20:17] <wylde> Hello, I had the same issue today. I found a bug already reported on it here. https://bugs.launchpad.net/ubuntu/+source/screen-resolution-extra/+bug/1249460
[20:19] <Letozaf_> balloons, wylde ok fine so I might just mark myself affected by that bug thanks
[20:20] <balloons> perfect.. wylde you were quick to find it as well, heh
[20:20] <balloons> it's only been 3 hours
[20:35] <elopio> robotfuel: I have it now, running as system compositor
[20:35] <elopio> still the same error.
[20:37] <robotfuel> elopio: ugh sorry bad internet connection
[20:37] <robotfuel> elopio: they are sending me a new router/gateway.
[20:38] <robotfuel> elopio: try running it from tty3 as root, you don't need to run xmir
[20:38] <robotfuel> elopio: a mir demo will show there, the plan is to run it from openvt with jenkins
[20:43] <robotfuel> elopio: mir needs to be root to access the /tmp/mir_socket, that will be changing eventually
[20:54] <elopio> robotfuel: now it says: demo will start in 5 seconds
[20:54] <elopio> and then, can't get connection.
[20:54] <elopio> running from tty3 as root
[20:56] <robotfuel> is mir already running in xmir? I wonder if that could be a problem
[20:57] <robotfuel> elopio: ^
[20:59] <elopio> robotfuel: I've never done this before. How do I know if mir si running in xmir?
[20:59] <robotfuel> elopio: do you have a /tmp/mir_socket?
[21:00] <robotfuel> elopio: or is unity-system-compositor running?
[21:00] <elopio> robotfuel: no, I don't. And yes, unity-system-compositor is running.
[21:00] <elopio> $ ps aux | grep unity-system-compositor
[21:00] <elopio> elopio    9275  0.0  0.0  11756   964 pts/2    S+   15:00   0:00 grep --color=auto unity-system-compositor
[21:00] <robotfuel> elopio: a mir server is already running then
[21:01] <robotfuel> unity-system-compositor is the xmir renderer
[21:02] <elopio> robotfuel: ok, let me change that.
[21:44] <elopio> robotfuel, good news is that I could run it on my laptop
[21:44] <elopio> on tty3
[21:44] <elopio> bad news is that I thing I broke my desktop :)
[22:31] <robotfuel> elopio: let me know if I can help you fix your desktop
[22:36] <elopio> robotfuel: it was due to the nvidia drivers
[22:36] <elopio> when it was booting, it said I was writing outside hd0
[22:36] <elopio> now I'm on nouveau.
[22:37] <elopio> I still have a problem with unity, but I can continue working.
[22:38] <elopio> robotfuel: so, I think your demo idea makes a lot of sense. It's a good test
[22:38] <elopio> I think it's complex enough to be worth making tests for it. The self unit tests for this would also help understanding what it does and how.
[22:39] <elopio> I would split the main function in as many smaller functions as possible, and start adding tests for them, so we are sure that if something fails, it's mir's fault and not your script's fault.
[22:40] <robotfuel> elopio: the only thing I don't like about it is that I can't do Try: results = get_results except: (write results to file.)
[22:42] <robotfuel> elopio: so if it fails we don't write the file, but jenkins will record stdout.
[22:42] <robotfuel> and we log stderr
[22:42] <elopio> robotfuel: can't you print to a different output stream?
[22:43] <elopio> and then on finally you can save that stream to a file.
[22:44] <robotfuel> if the try fails then results doesn't exist because raise an error
[22:45] <robotfuel> I guess could write to file before raising the error.
[22:45] <robotfuel> but that's not very elegant.
[22:45] <elopio> robotfuel: well, you can configure the logging to go to std out/err, and to a file also.
[22:46] <elopio> or, you could pass a output stream to wait_for_demo_completition, and collect the results there.
[22:46] <elopio> that output stream could be one that prints to file and to std out too. I don't see it bad.