| === ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - Type: "cihelp" for help | Landing instructions: http://paste.ubuntu.com/6292280/ | Known issues: - | ||
| Mirv | cyphermox: yes I tried to stare at the commits enough starting from 1.3 common ancestor. I now checked with upstream and they agree with one exception that is WIP and not critical to releasing 1.4. | 04:26 |
|---|---|---|
| Mirv | didrocks: hi! I think "Result directory doesn't exists, exiting!" is what keeps from getting green at the moment | 06:08 |
| didrocks | hey Mirv! | 06:09 |
| didrocks | Mirv: oh, where is this? | 06:09 |
| didrocks | Mirv: I saw some more FTBFS as well | 06:09 |
| Mirv | for example http://10.97.0.1:8080/view/cu2d/view/Head/view/Indicators/job/cu2d-indicators-head-2.2check/466/console | 06:09 |
| * didrocks looks | 06:09 | |
| didrocks | weird, there is a head one | 06:10 |
| didrocks | maybe it's archived under trusty | 06:10 |
| didrocks | Mirv: can you try rerun a small check run? | 06:11 |
| didrocks | I tried to add trusty | 06:11 |
| Mirv | didrocks: ok, trying | 06:13 |
| didrocks | Mirv: I guess on the FTBFS, platform-api needs to be rebuilt so that unity-mir can be rebuilt and the unity8 should be fine | 06:13 |
| didrocks | right? | 06:13 |
| Mirv | didrocks: right the one robru filed | 06:15 |
| Mirv | didrocks: yay we have familiar looking problems too http://10.97.0.1:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/48/console | 06:16 |
| didrocks | Build was aborted | 06:19 |
| didrocks | Aborted by Timo Jyrinki | 06:19 |
| didrocks | ? | 06:19 |
| didrocks | Mirv: robru filed the FTBFS? did he try to rebuild platform-api then? | 06:20 |
| Mirv | didrocks: as you can see it was hanged for 1.5 hours with DHCP lines only | 06:20 |
| Mirv | robru: I don't think he did, he claimed that the complain of a dependency is actually fulfilled in archives | 06:21 |
| didrocks | Mirv: it's happening everywhere? or only on some machines? | 06:21 |
| didrocks | Mirv: well, I doubt soyuz is lying on the dep :) | 06:21 |
| didrocks | I guess robru didn't dig :( | 06:21 |
| Mirv | didrocks: that seemed top be radeon only | 06:21 |
| didrocks | it's obvious that the issue is platform-api | 06:21 |
| didrocks | Mirv: hum, let me see the snapshot on radeon | 06:22 |
| didrocks | ok, same time than others | 06:22 |
| didrocks | I can remove and revert to yesterday's snapshot for now | 06:22 |
| didrocks | (done) | 06:23 |
| Mirv | running check on services stack now | 06:24 |
| didrocks | Mirv: oh, in fact, moving unity-mir to the mir stack was a bad idea after all | 06:25 |
| didrocks | because platform depends on mir | 06:25 |
| didrocks | and unity-mir depends on platform | 06:25 |
| didrocks | I didn't think about it | 06:25 |
| didrocks | Saviq: we'll revert and remove to unity8 stack ^ | 06:25 |
| didrocks | I'm retrying unity-mir stack | 06:25 |
| didrocks | ok, qtubuntu and all the sensors/hud are failing due to that | 06:26 |
| Mirv | right.. | 06:27 |
| didrocks | Mirv: let's release today with that, and move back unity-mir then | 06:27 |
| Mirv | meanwhile switching from services to some else | 06:27 |
| didrocks | https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5155357 | 06:27 |
| didrocks | so, building | 06:27 |
| didrocks | restarting as well platform for qtubuntu-sensors | 06:32 |
| Mirv | didrocks: ok, still getting the results directory complaint: http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-2.2check/313/console | 06:54 |
| Mirv | that result should be yellow according to the subtasks | 06:54 |
| didrocks | Mirv: ok, the subdir isn't created | 06:54 |
| didrocks | jibel: salut! we don't create the result subdir automatically, right? (for the -check job) | 06:55 |
| didrocks | Mirv: let me fix that manually | 06:55 |
| didrocks | hum, that's not the issue | 06:56 |
| * didrocks looks at the code | 06:56 | |
| jibel | didrocks, sorry I miss context, which result subdirectory, where? | 06:56 |
| didrocks | jibel: http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-2.2check/313/console | 06:56 |
| didrocks | hum SEARCHPATH=${BASEDIR}/${JOBNAME}/configurations/axis-label/${NODENAME}/builds/ | 06:57 |
| didrocks | that's what doesn't exist | 06:57 |
| jibel | uh, it is jenkins territory and it should have created it. | 06:58 |
| jibel | didrocks, I'll check in 5 min | 06:58 |
| didrocks | yeah, no configurations/ | 06:58 |
| didrocks | jibel: thanks! | 06:58 |
| didrocks | (in /var/lib/jenkins/jobs/cu2d-qa-head-2.2check/) | 06:58 |
| didrocks | Mirv: let's monitor the FTBFS meanwhile :) | 06:59 |
| didrocks | I guess I don't read the right parameter, no configurations/ in /var/lib/jenkins/jobs/cu2d-qa-saucy-2.2check/ either | 07:00 |
| jibel | didrocks, machines that were testing raring have been reassigned to head and the name of the AP nodes changed | 07:08 |
| jibel | didrocks, you must change apmachines: autopilot-intel qa-nvidia-gtx660 | 07:08 |
| jibel | to the name of the new nodes | 07:08 |
| jibel | didrocks, in cupstream2distro-config/stacks/head/*cfg that is | 07:08 |
| didrocks | jibel: stupid me… | 07:09 |
| didrocks | (well, I didn't do that change, but yeah) | 07:09 |
| didrocks | jibel: /var/lib/jenkins/jobs/cu2d-qa-saucy-2.2check/ doesn't have this configurations? | 07:09 |
| didrocks | do I read the shell badly? :) | 07:10 |
| didrocks | Mirv: changing the config | 07:10 |
| jibel | didrocks, in http://10.97.0.1:8080/view/cu2d/view/Head/view/QA/job/cu2d-qa-head-2.2check/configure | 07:10 |
| jibel | execution step 3 | 07:10 |
| jibel | line 10: for machine in autopilot-intel qa-nvidia-gtx660; do | 07:11 |
| didrocks | jibel: oh, it's a REST request | 07:11 |
| didrocks | jibel: ok, I was on the FHS | 07:11 |
| didrocks | jibel: thanks, and sorry for the stupid issue :/ | 07:13 |
| jibel | didrocks, np | 07:13 |
| didrocks | Mirv: ok, all redeployed | 07:15 |
| didrocks | Mirv: so, current -check job should still fail because of that, but next one should be fine | 07:15 |
| didrocks | Mirv: I'm relaunching qa just to test | 07:16 |
| jibel | didrocks, I added a note to MovingNewRelease | 07:26 |
| didrocks | jibel: thanks :) | 07:26 |
| Mirv | didrocks: I guess it kind of worked now, ie. to that problem | 07:28 |
| Mirv | the radeon just failed almost all the tests | 07:28 |
| didrocks | Mirv: yeah, I'm seeing that | 07:29 |
| didrocks | vila: mind helping there? | 07:29 |
| didrocks | Mirv: there are still 2 tests failing on autopilot, can you have a look with upstream? | 07:30 |
| vila | didrocks: shoot | 07:30 |
| didrocks | vila: seems radeon is failing all the tests | 07:30 |
| vila | didrocks: ouchy, for machine in autopilot-intel qa-nvidia-gtx660; do that's bad :-/ | 07:30 |
| didrocks | vila: we have 98 failures on it | 07:30 |
| didrocks | vila: and 2 failures on the other machines | 07:30 |
| vila | didrocks: url ? | 07:30 |
| Mirv | now we start to actually see how's the autopilot 1.4 branch like | 07:31 |
| didrocks | vila: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/54/ | 07:31 |
| didrocks | Mirv: right! | 07:31 |
| didrocks | Mirv: btw, it seems packaging list still needs to be updated for some stacks | 07:31 |
| didrocks | sdk and hud? | 07:31 |
| didrocks | Mirv: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/ | 07:31 |
| didrocks | Mirv: mind doing it? feel free to push/relaunch :) | 07:31 |
| Mirv | didrocks: I will, in a bit | 07:32 |
| vila | didrocks: 2 on qa-intel, 4 on -nvidia, 98 on radeon, pretty messy | 07:33 |
| didrocks | vila: isn't it? :/ | 07:34 |
| didrocks | vila: same on previous run: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/53/ | 07:34 |
| vila | and the durations are... really different | 07:34 |
| didrocks | vila: however, the machine is fine: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/57/ | 07:34 |
| vila | at least - readeon fails fast ;) | 07:34 |
| didrocks | for indicators | 07:34 |
| vila | this is for autopilot itself right ? | 07:35 |
| vila | sounds like an isolation issue to me, one test fails to cleanup properly and the following ones break | 07:37 |
| didrocks | vila: that's more than probable | 07:37 |
| vila | urgh, may be a bit more involved than that, I see successes intermixed with failures but many 'Cannot connect to X server :0' and ' BAMF: DBusException('Connection is closed',)' | 07:40 |
| didrocks | sil2100: hey! how are you? | 07:41 |
| didrocks | vila: an unity crash file? | 07:41 |
| sil2100 | didrocks: morning! | 07:41 |
| didrocks | vila: oh, thinking about it | 07:41 |
| Mirv | rerunning hud tests | 07:41 |
| vila | still reading the console | 07:41 |
| sil2100 | Autopilot problems? | 07:42 |
| didrocks | vila: do we have the proprietary driver install on it? | 07:42 |
| didrocks | jibel: do you remember which driver we were using on ati? ^ | 07:42 |
| didrocks | sil2100: yeah, some just for one machine, Mirv is redeploying the latest package updates needed | 07:43 |
| vila | didrocks: meh, no idea | 07:43 |
| jibel | didrocks, nouveau, fglrx didn't compile earlier in the realease and we never move to the proprietary driver | 07:43 |
| didrocks | sil2100: Mirv: but I think still one of you should start working on the real first results we have and ping upstream to get back to 0 tests failing | 07:43 |
| didrocks | like QA ;) | 07:43 |
| vila | didrocks: yup, sounds like the most sensible thing to do | 07:43 |
| Mirv | didrocks: yeah starting from QA makes sense | 07:43 |
| didrocks | jibel: ok, and so, we were fine with the free driver | 07:44 |
| Mirv | pinging QA | 07:44 |
| didrocks | vila: I guess it's a hint for you, look if xorg/lightdmin failed ^ | 07:44 |
| vila | didrocks, Mirv : if nothing else, if it's related to the X server, the tests should fail far earlier with better messages | 07:44 |
| didrocks | lightdm* | 07:44 |
| jibel | didrocks, mostly fine, the main issue was the machine hanging when it switches from Mir to Xorg | 07:45 |
| didrocks | vila: I can list you a lot of should :) | 07:45 |
| sil2100 | didrocks: ok, is QA the one with stable results? | 07:45 |
| didrocks | jibel: yeah, but other stacks (like, when Mir wasn't enabled), we were good running unity tests IIRC | 07:45 |
| didrocks | and that we didn't switch back and force from it | 07:45 |
| didrocks | sil2100: well, all the ones that are stopped should have stable results | 07:46 |
| vila | didrocks: yeah, but that one generates a lot of noise and force unaware people to spend time deciphering, thomi welcomes that kind of input and is eager to do the related fixes | 07:46 |
| didrocks | vila: that's why we have people first deciphering for him | 07:46 |
| didrocks | as we have to cope with what we have | 07:46 |
| didrocks | and fix timely first | 07:46 |
| didrocks | to get back on productoin | 07:46 |
| didrocks | production* | 07:46 |
| didrocks | sil2100: so http://10.97.0.1:8080/view/cu2d/view/Head/view/All/, everywhere it's red and not running :) | 07:47 |
| vila | didrocks: right, there is a balance to be found between fire fighting and improving, doing only the former means we'll never be able to do the later | 07:47 |
| didrocks | vila: indeed, so then, send the email to people that we are going to improve the platform and not deliver anything meanwhile | 07:47 |
| sil2100 | \o/ | 07:48 |
| Mirv | filed bug #1244089, please update if you've anything to add to the description | 07:48 |
| ubot5 | bug 1244089 in Autopilot "Autopilot 1.4 trusty AP test errors" [Critical,New] https://launchpad.net/bugs/1244089 | 07:48 |
| Mirv | good news! indicators stack tested itself fine :) | 07:49 |
| vila | didrocks: infinite shades of grey between white and black ;) In that specific case I think autopilot has enough data to act so *we* can focus on other things but hey, that's only MHO ;) | 07:49 |
| sil2100 | Mirv: I'm looking at hud now though | 07:50 |
| vila | didrocks: still looking on qa-radeon- itself for additional evidence | 07:50 |
| didrocks | vila: would be interesting to know if there was a crash | 07:50 |
| didrocks | you have those infos | 07:50 |
| Mirv | sil2100: I'm already there, I added a few packages already | 07:50 |
| sil2100 | Mirv: extra-packages needed for hud, ok | 07:51 |
| vila | didrocks: /var/crash is empty | 07:51 |
| didrocks | vila: ok :( | 07:51 |
| Mirv | sil2100: relaunching hud now after redeploy | 07:51 |
| sil2100 | ACK | 07:51 |
| vila | didrocks: why the sad face ? I'd rather have autopilot fixed than one more fix in the ci infra :0) | 07:52 |
| didrocks | vila: well, I doubt the issue is in AP | 07:52 |
| didrocks | vila: why is it failing only on radeon? AP isn't hw specific | 07:52 |
| Mirv | anyway. we have the first autopilot-running stack ready to publish, which is definitely progress. others running so let's see. | 07:52 |
| didrocks | so either something changed in the way it access the hw and we don't have the setup on that machine | 07:53 |
| vila | didrocks: it could a timing issue | 07:53 |
| Saviq | didrocks, k | 07:53 |
| didrocks | vila: can be, yeah, and if the cleanup isn't good… | 07:53 |
| vila | ha crap looking at the wrong place | 07:53 |
| Mirv | hmm the green indicators tests indicate failing tests in the log, though http://10.97.0.1:8080/job/autopilot-trusty-daily_release/57/label=qa-intel-4000/console (at the end) | 07:54 |
| Mirv | unity.tests.test_panel.PanelHoverTests.test_hovering_indicators_open_menus: FAIL etc | 07:54 |
| sil2100 | Interesting | 07:55 |
| sil2100 | Many FAIL but SUCCESS | 07:56 |
| vila | didrocks: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/54/label=qa-radeon-7750/artifact/results/logs/gnome-session.log ? | 07:56 |
| vila | didrocks: not sure I know how to read that | 07:57 |
| didrocks | WARN 2013-10-24 07:18:25 unity.gdk <unknown>:0 compiz: Fatal IO error 11 (Resource temporarily unavailable) on X server :0. | 07:58 |
| didrocks | not sure that's good | 07:58 |
| sil2100 | On webapps it seems ERROR __init__:64 - Unity doesn't appear to be running, exiting. | 07:58 |
| Mirv | ok hud is now back in the league of "properly" failing | 07:59 |
| Mirv | sil2100: same in hud | 08:00 |
| vila | didrocks: what happened with the containers there ? | 08:01 |
| sil2100 | Mirv: I wonder if that's a problem with autopilot introspecting unity or just really unity doesn't start | 08:02 |
| didrocks | vila: there? | 08:04 |
| vila | qa-radeon-7750 | 08:04 |
| didrocks | vila: can you rephrase this? I can't parse you | 08:05 |
| vila | what happened with the containers on qa-radeon-7750 ? | 08:05 |
| vila | the job you asked me to look at seems to have run against an old container when there are older jobs against newer containers (including autopilot upgrades) with less failures | 08:06 |
| vila | http://10.97.0.1:8080/job/autopilot-trusty-daily_release/label=qa-radeon-7750/62/ | 08:07 |
| vila | urgh, no they were against the current one, gee, that's confusing | 08:07 |
| vila | there is a hanging.trusty-i386-20131024-0008 container, where is that coming from and why aren't we using it ? | 08:08 |
| didrocks | vila: yeah, it was hanging this morning (no ui started), so I needed to mv it first thing | 08:09 |
| sil2100 | didrocks, Mirv: argh, today I might be late for the morning meeting, so just assign a lot of stuff to me if anything | 08:09 |
| didrocks | vila: I was planning to check for it once we have at least the first pass running | 08:09 |
| sil2100 | Mirv: I'll be looking at the webapps part | 08:10 |
| didrocks | vila: as we know that yesterday's container was working | 08:10 |
| didrocks | sil2100: ok | 08:10 |
| didrocks | sil2100: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=0 is assigned to you | 08:10 |
| didrocks | Saviq: dude, really ask to packagers when you add a packaging change… | 08:13 |
| didrocks | Saviq: https://code.launchpad.net/~elopio/unity8/autopilot-1.3/+merge/192440 isn't going to work | 08:13 |
| didrocks | Saviq: it will block unity8 to proposed until you the dep is fixed | 08:13 |
| Saviq | didrocks, and it won't be? | 08:13 |
| Saviq | didrocks, ah, it won't of course.. | 08:13 |
| Saviq | didrocks, sorry, I just woke up... | 08:14 |
| didrocks | Saviq: really, all packaging changes should involves a core dev ;) | 08:14 |
| didrocks | involve | 08:14 |
| vila | didrocks: right, but something is not working now, I'd rather investigate that in case reverting to a previous container introduced some skew, which job was hanging ? | 08:14 |
| didrocks | Mirv: do you have the link for vila? ^ | 08:14 |
| Saviq | didrocks, is there a process other than us finding one? maybe a team we could assign reviews to? | 08:14 |
| didrocks | Saviq: on another note, I can't (again) :/ refind the fix for AP tests on unity8… | 08:14 |
| didrocks | Saviq: good point, I would say pinging there until the oakland sprint | 08:15 |
| didrocks | Saviq: then, we can discuss about team assignement and so on | 08:15 |
| * sil2100 prepares to upgrade his device | 08:15 | |
| Saviq | didrocks, which fix? lxc-android-config / unity-mir? still not released | 08:15 |
| didrocks | Saviq: no, the one in AP unity8 tests themselves | 08:16 |
| didrocks | the one we did on Thursday | 08:16 |
| Saviq | https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1240801 | 08:16 |
| ubot5 | Ubuntu bug 1240801 in unity8 (Ubuntu) "autopilot unity8 fails with "No GSettings schemas are installed on the system"" [Low,Fix committed] | 08:16 |
| Mirv | didrocks: just a second | 08:16 |
| didrocks | Saviq: thanks! | 08:17 |
| Saviq | didrocks, how's it going, btw - when do we expect trusty to be good enough to start releasing into it? | 08:17 |
| didrocks | Saviq: we hope today, but issues on some components FTBFS and AP 1.4 having some tests failing | 08:18 |
| Mirv | sil2100: any idea how the unity problem could be debugged? | 08:19 |
| Saviq | didrocks, mhm | 08:19 |
| didrocks | Mirv: sil2100: so, what I see is: someone doing the mir transition, the other one debugging the AP issues + FTBFS | 08:19 |
| didrocks | Mirv: sil2100: we can exchange if you prefer | 08:19 |
| didrocks | Mirv doing the mir transition | 08:19 |
| didrocks | and sil2100 the debugging | 08:19 |
| didrocks | what do you both prefer? | 08:20 |
| Mirv | fine, sil2100 might know more about the lxc debugging | 08:20 |
| didrocks | ok, so exchanging | 08:20 |
| Mirv | vila: before switching to the older container I got this hang: http://10.97.0.1:8080/job/autopilot-trusty-daily_release/48/label=qa-radeon-7750/console | 08:20 |
| sil2100 | Oh! | 08:20 |
| sil2100 | Ok | 08:20 |
| didrocks | sil2100: Mirv: done :) | 08:21 |
| Mirv | didrocks: so, libmirserver8 now? | 08:21 |
| didrocks | Mirv: indeed! 8 is a good number :-) | 08:21 |
| didrocks | but can't wait for 9 :p | 08:22 |
| Mirv | is it then stable?! :) | 08:22 |
| sil2100 | ...;p | 08:22 |
| didrocks | heh, let's hope so! ;) | 08:22 |
| * sil2100 doubts that | 08:22 | |
| Mirv | I mean ABI stable, that is | 08:22 |
| sil2100 | :< | 08:22 |
| didrocks | Mirv: you're dreaminggggg ;) | 08:22 |
| didrocks | Mirv: so, I guess apart from u-s-c (didn't check), everything else should be ready | 08:23 |
| didrocks | as per my relaunch this morning | 08:23 |
| Mirv | updating package lists for platform and unity8 | 08:23 |
| ogra_ | popey, mind testing #4 ? (its good on maguro) | 08:29 |
| popey | already done | 08:29 |
| popey | looks good | 08:29 |
| ogra_ | awesome | 08:29 |
| didrocks | asac: you froze! | 08:32 |
| elopio | didrocks, Saviq: Why can't we have autopilot 1.3 and 1.4 while we update the tests? | 08:37 |
| elopio | Autopilot 1.4 has a big API change that throws an exception where it previously returned None, and that will make some tests fail, probably on all the projects. Thomi said that the right thing to do is make sure we are currently using 1.3 on all suites, and then propose branches with the bump to 1.4 once we have update the tests. | 08:37 |
| Saviq | elopio, because they're not installable in parallel | 08:37 |
| elopio | *updated. | 08:38 |
| Saviq | elopio, you can't install both autopilot-1.3 and autopilot-1.4 on the same machine - because they're different versions of the same package | 08:38 |
| elopio | hum, that's going to be a problem. | 08:38 |
| Saviq | elopio, yeah, we'd need autopilot 1.4 to be autopilot14 | 08:39 |
| elopio | Saviq: so, what's the strategy, bump autopilot and have all the tests failing for a while, or change the package to be autopilot14? | 08:40 |
| Saviq | elopio, *I* think it's fine to just bump and adapt | 08:40 |
| elopio | as long as we don't need to land the fixes on all the projects at once, that doesn't sound bad for me. | 08:43 |
| elopio | however blocking the project with '<< 1.4 can't be satisfied' until the tests are updated sounds a litte more correct from the tests point of view. | 08:45 |
| elopio | but I'm going to bed now. I'll ask tomorrow to see how can I help updating the tests. | 08:45 |
| didrocks | sil2100: psivaa: please pair together ;) | 08:55 |
| sil2100 | o> | 08:55 |
| psivaa | didrocks: ok | 08:56 |
| didrocks | thanks! good luck guys | 08:56 |
| Mirv | didrocks: hmmh, I launched unity-system-compositor build to update the dependencies but it FTBFS:s https://launchpadlibrarian.net/154869368/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.1%2B14.04.20131024-0ubuntu1_FAILEDTOBUILD.txt.gz | 09:06 |
| didrocks | Mirv: I'm working on the radeon failure with vila, do you need me on that one or you investigate? | 09:09 |
| didrocks | (you can parallelize the phone test at least) | 09:09 |
| Mirv | didrocks: no need, seems upstream problem so solving with them while trying to get phone tests | 09:10 |
| didrocks | ok, great! | 09:10 |
| ogra_ | didrocks, asac, popey image 4/20131023 promoted | 09:12 |
| popey | super | 09:12 |
| didrocks | ogra_: \o/ | 09:12 |
| * popey mails | 09:12 | |
| === vrruiz_ is now known as rvr | ||
| ogra_ | popey, hmm, 1023.changes would have been the right one ... 22 and 22.1 were image 2 and 3 | 09:37 |
| popey | damnit | 09:37 |
| didrocks | psivaa: Mirv: sil2100: FYI, radeon deprovisionned. | 09:39 |
| sil2100 | ACK | 09:39 |
| asac | i have a question... are we still producing saucy-updates images? | 09:39 |
| asac | didrocks: did you finish seb feedback? | 09:40 |
| ogra_ | asac, not atm | 09:41 |
| ogra_ | (we can if you want one) | 09:41 |
| ogra_ | asac, though i guess we should first make a decidion about #101 before building new ones | 09:42 |
| didrocks | asac: seb is in Canada, not online yet | 09:43 |
| didrocks | asac: I'll grab him later on | 09:43 |
| Mirv | ack | 09:43 |
| ogra_ | *decision | 09:45 |
| asac | didrocks: i want to be there :) | 09:45 |
| didrocks | asac: ok, will get you in, let's try to catch | 09:46 |
| didrocks | him* | 09:46 |
| ogra_ | asac, what do you want in canada ... | 09:54 |
| ogra_ | its full of canadians ! | 09:54 |
| asac | hehe | 09:58 |
| vila | didrocks: the kvm was a good hint, tests lead to session crashes, lightdm is displayed, if I connect manually, the current test catches up things are moving ;) Until it crashes again | 10:08 |
| didrocks | vila: ok, it's a start :) | 10:09 |
| vila | didrocks: right, I will hand it to ... dang, didn't copy from the hangout, paste the nick again ?) | 10:09 |
| vila | didrocks: this should be reproducible locally with the same or similar card by that guy right ? | 10:10 |
| asac | ogra_: you mean test 101? or promote it? | 10:11 |
| asac | so the reason we do saucy-updates is to pipeclean our infrastructure and process | 10:12 |
| ogra_ | asac, 101 is fine (iirc there was only the udevd change for maguro) | 10:12 |
| asac | we should do a few builds there | 10:12 |
| asac | and then promote | 10:12 |
| asac | and then move on to T | 10:12 |
| ogra_ | right | 10:12 |
| asac | and promote T images to stable channel :) | 10:12 |
| ogra_ | 101 was the first one in there | 10:12 |
| ogra_ | huh ? | 10:12 |
| asac | right. so that ones is in the bank | 10:12 |
| ogra_ | T images to stable channel ? | 10:13 |
| ogra_ | stable is saucy | 10:13 |
| ogra_ | T is in development | 10:13 |
| asac | thats what people might believe :) | 10:13 |
| ogra_ | well, thats what we have | 10:13 |
| ogra_ | you cant call an in-development thing "stable" | 10:14 |
| ogra_ | especially since you break the rolling model then | 10:14 |
| xnox | ogra_: the plan was at one point migrate stable to T series. Thus to exercise "channel upgrade" | 10:14 |
| ogra_ | stable should be a snapshot of the final release of a series | 10:14 |
| xnox | ogra_: something 1-2 months into the T cycle, or when ready. | 10:14 |
| ogra_ | not a milestone image in the middle of a dev release | 10:14 |
| asac | ogra_: thats ONE way to see it, yes. anyway, lets not talk about that now. let me first talk with folks | 10:14 |
| didrocks | vila: probably yeah | 10:15 |
| asac | abiout our saucy updates etc. | 10:15 |
| ogra_ | if you really want to change that i'm highly opposed | 10:15 |
| ogra_ | that adds massive confusion | 10:15 |
| ogra_ | saucy updates need to go to the stable channel | 10:15 |
| ogra_ | built from saucy-updates :) | 10:15 |
| vila | didrocks: You missed one of my messages ;) I didn't copy the nick name before closing the hangout, can you paste it here please ? | 10:17 |
| didrocks | vila: mlankhorst | 10:17 |
| vila | didrocks: thanks ;) | 10:17 |
| vila | http://10.97.0.1:8080/job/otto-test-radeon/label=qa-radeon-7750/ if I keep relogin some tests succeed | 10:17 |
| Mirv | yay, error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs | 10:54 |
| Mirv | breaks my pbuilder usage | 10:54 |
| Mirv | http://bugs.debian.org/727540 | 10:56 |
| ubot5 | Debian bug 727540 in libept1.4.12 "aptitude: symbol lookup error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs" [Grave,Open] | 10:56 |
| vila | didrocks: what's the trick to start the container without it shutting down after a few seconds ? (i.e. I need to use the kvm to access the graphical env which seems to require lxc-start which quit before I can achieve anything ;) | 10:56 |
| didrocks | vila: for that, you need to stay on latest run | 11:09 |
| didrocks | vila: cd /var/lib/lxc/trusty-i386-20131024-0008/run | 11:09 |
| didrocks | edit target-override/usr/local/bin/run-autopilot.sh | 11:10 |
| sil2100 | Yes | 11:10 |
| sil2100 | Add -S to the end of the command | 11:10 |
| sil2100 | ;) | 11:10 |
| didrocks | SHUTDOWN=1 -> change to 0 | 11:11 |
| didrocks | sil2100: oh, -S? | 11:11 |
| sil2100 | We had the same problem during our debugging, jibel proposed this and it works | 11:11 |
| sil2100 | didrocks: in the xdg/autostart file | 11:11 |
| didrocks | -S|--noshutdown) | 11:11 |
| didrocks | SHUTDOWN=0 | 11:11 |
| didrocks | shift;; | 11:11 |
| didrocks | ahah ;) | 11:11 |
| sil2100 | ;) | 11:11 |
| didrocks | so, let's use the option rather | 11:12 |
| didrocks | edit target-override/etc/xdg/autostart/autopilot.desktop | 11:12 |
| didrocks | and add the -S at the exec line | 11:12 |
| didrocks | then sudo lxc-start -n <container> | 11:12 |
| vila | didrocks, sil2100 : thanks | 11:14 |
| asac | jibel: looking at http://people.canonical.com/~j-lallement/touch/changes/20131022.html there seem to be a bunch of changelog items not availabe | 11:17 |
| asac | do you know? | 11:17 |
| Mirv | didrocks: do you think I can merge https://code.launchpad.net/~mterry/unity-system-compositor/mir-fixes/+merge/192042 manually? I've tested it builds with the daily-build PPA | 11:18 |
| didrocks | Mirv: sure, feel free :) | 11:21 |
| Mirv | thanks | 11:22 |
| vila | Do you guys know how to find which kind of graphic driver is installed on qa-radeon-7750 ? | 11:28 |
| Mirv | check if dpkg -l | grep fglrx shows something installed | 11:30 |
| Mirv | if not, it's using open drivers | 11:31 |
| Mirv | or simply /var/log/Xorg.0.log | 11:32 |
| * didrocks goes for a run | 11:33 | |
| cjwatson | Mirv: Do you have trusty-proposed enabled? | 11:38 |
| cjwatson | I guess you might reasonably have it *inside* the chroot | 11:39 |
| Mirv | cjwatson: no, but right I could enable it | 11:39 |
| cjwatson | Mirv: No, don't | 11:40 |
| cjwatson | Mirv: You mean it's broken in trusty? | 11:40 |
| cjwatson | (non-proposed) | 11:40 |
| Mirv | cjwatson: I got it via pbuilder-dist trusty create done today + adding daily-build PPA + trying to build | 11:41 |
| cjwatson | Mirv: So you have libept1.4.12 1.0.9? | 11:42 |
| Mirv | let me log in there | 11:42 |
| cjwatson | There's a 1.0.10 in trusty-proposed, but it's blocked on build failures on two architectures | 11:43 |
| Mirv | cjwatson: aha, it seems pbuilder-dist (or my old configuration of it somewhere) enables -proposed, so that's why I have 1.0.10 | 11:44 |
| cjwatson | That's actually sensible *inside* a pbuilder | 11:44 |
| vila | Mirv: darn didn't notice your message until now. no fglrx, no mesa | 11:45 |
| vila | Mirv: what should I search for in X.org.0.log ? | 11:45 |
| Mirv | vila: mm maybe "X.Org Video Driver" and then before that what's the module name | 11:45 |
| vila | Mirv: there are a bunch of messages starting with (II) RADEON(0) | 11:45 |
| cjwatson | I mean, in general we build packages against -proposed and so test builds should do likewise | 11:45 |
| vila | ha, hold on | 11:45 |
| Mirv | vila: ok, radeon tells already that's it's the default (open) driver, not fglrx | 11:46 |
| Mirv | and not vesa either, so the correct driver gets loaded | 11:46 |
| vila | Mirv: which are the corresponding packages ? | 11:46 |
| * cjwatson blocks libept in -proposed until we figure this out | 11:47 | |
| cjwatson | It might just need an aptitude rebuild | 11:48 |
| Mirv | vila: xserver-xorg-video-radeon/ati, the 3D part comes from mesa packages | 11:48 |
| vila | X.org Video Driver: 14.1... "glx" will be loaded by default "xmir" not laded "dri2", glamoregl... | 11:48 |
| cjwatson | But that will be messy while libept has failed builds in -proposed | 11:48 |
| vila | Mirv: xserver-xorg-video-radeon/ati neither are installed | 11:49 |
| Mirv | vila: oh, sorry, can you find "Loading /usr/lib/xorg/modules/drivers/" in there somewhere? | 11:50 |
| cjwatson | Mirv: I can probably work on this, but I need to finish clearing out the insanely complex perl transition from -proposed first so that I can see what I'm doing | 11:51 |
| cjwatson | Mirv: Is it blocking you or can it wait a day or so? | 11:51 |
| Mirv | cjwatson: sure, this is not any sort of blocker for me | 11:51 |
| cjwatson | OK | 11:51 |
| vila | Mirv: libglx | 11:51 |
| Mirv | vila: that should come from "extensions", not "drivers" | 11:51 |
| Mirv | vila: actually a simple search for lower-case "drivers" in the file should do | 11:52 |
| vila | Mirv: no copy/paste is a reaaaaaal pain | 11:52 |
| vila | Mirv: ha ! Can access via ssh under rootfs, pfew, some sanity restored | 11:58 |
| vila | /usr/lib/xorg/modules/drivers/ati_drv.so | 11:59 |
| vila | /usr/lib/xorg/modules/drivers/radeon_drv.so | 11:59 |
| vila | /usr/lib/xorg/modules/drivers/vesa_drv.so | 11:59 |
| vila | /usr/lib/xorg/modules/drivers/modesetting_drv.so | 11:59 |
| vila | /usr/lib/xorg/modules/drivers/fbdev_drv.so | 11:59 |
| Mirv | vila: you're not saying you find all of those from Xorg.0.log? :) | 12:00 |
| vila | Mirv: I do | 12:01 |
| Mirv | vila: ok, my guesses at Xorg.0.log contents are clearly wrong.. anyhow, you're probably using open source radeon driver. what was the actual problem you were thinking about? is there any lines having "EE" in there, if you're wondering about startup problems? | 12:02 |
| vila | http://paste.ubuntu.com/6294522/ | 12:02 |
| Mirv | vila: if you can now get the Xorg.0.log somewhere, that'd be much easier than using a human-IRC interface to grep command :) | 12:02 |
| Mirv | vila: thanks :) | 12:02 |
| vila | Mirv: indeed ;) Sorry, took me a minute to get from ssh access to copy/paste restored ;) | 12:03 |
| Mirv | vila: ok, so it's the open driver, seems to work, no (real) errors. glamoregl working, DRI2, vdpau etc point to 3D working too. | 12:04 |
| Mirv | vila: so no visible problems starting the X there | 12:04 |
| vila | Mirv: pfew, learning is always painful :) First time diagnosing an X issue on a remote host with a KVM, every step hurts ;) | 12:06 |
| vila | Mirv: so, summary, the config seems correct and uses the open driver. | 12:06 |
| vila | Mirv: now to find how to tell otto to collect Xorg.0.log[.old] | 12:08 |
| vila | Mirv: will that be in otto sources and its associated config (where is that ?) ? | 12:09 |
| Mirv | vila: I'm not familiar with otto so far either | 12:10 |
| vila | Mirv: ack, thanks, negative feedback is so much better than none ;) (#ubuntu-desktop laaags ;) | 12:11 |
| vila | jibel: where should I look to tell otto to collect Xorg.0.log[.old] ? | 12:11 |
| Mirv | didrocks: good news is that I got the u-s-c ftbfs fixed. bad news is that new tick brought libmirserver9 and u-s-c FTBFS:s again in a different way... meanwhile I'm rebuilding unity-mir to get something to test again on device, but I haven't so far had luck with the unity8 AP. | 12:13 |
| jibel | vila, http://bazaar.launchpad.net/~otto-dev/otto/testsuite_autopilot-unity/view/head:/config | 12:14 |
| jibel | vila, add them to ARTIFACTS | 12:14 |
| vila | jibel: thanks ! | 12:14 |
| Mirv | didrocks: I've assigned the new FTBFS bug to mterry (to whom the mir team assigned the previous fix too, and there was already an existing branch), so hopefully we'd have a fix for the morning at minimum. | 12:15 |
| vila | jibel: will do a mp later, where should I look for that locally ? Or is that something that comes from jenkins ? | 12:17 |
| jibel | vila, the branch is pulled from LP because we wanted to prevent people from doing what you're intending to do | 12:20 |
| vila | jibel: he he | 12:20 |
| jibel | vila, so MP is the way to go | 12:20 |
| vila | :-/ | 12:21 |
| Mirv | yay, libmirclient4 too | 12:22 |
| Mirv | and relaunching unity8 build since it failed because of unity-mir transition | 12:24 |
| vila | jibel: which means no way to test before the mp, I'm sure we can do better, but in the mean time: https://code.launchpad.net/~vila/otto/testsuite_autopilot-unity-collect-Xorg/+merge/192494 | 12:28 |
| jibel | vila, you can test, but not in production | 12:28 |
| vila | jibel: lp-propose is weird... is lp:otto/autopilot the right target ? | 12:28 |
| vila | jibel: qa-radeon-7740 is isolated from production right now to diagnose | 12:29 |
| vila | jibel: and so far the issues revealed by otto *had* to be diagnosed in production | 12:30 |
| vila | jibel: and I've already been quite vocal about how bad I think that is :) | 12:30 |
| Mirv | didrocks: because of the libmirclient bump we'd also need xserver-xorg-xmir update? | 12:31 |
| didrocks | Mirv: argh :/ | 12:40 |
| didrocks | Mirv: right | 12:40 |
| didrocks | Saviq: FYI, we are delayed by this ^ | 12:41 |
| Saviq | didrocks, k | 12:42 |
| didrocks | asac: as well ^ | 12:42 |
| didrocks | asac: new bumps (without warning) from the mir team, both client and server and xserver-xorg-xmir then needs an update | 12:42 |
| didrocks | asac: so, work from the morning -> voided | 12:42 |
| jibel | vila, merged. If it is for testing purpose on a deprovisionned machine you call directly set the right environment to define tests, packages, ... then call sudo -E otto-run <container> <path_to_testsuite> | 12:43 |
| jibel | s/call/can/ | 12:43 |
| jibel | vila, or set TS_BRANCH to a test branch before calling run_otto_job from a jenkins job | 12:45 |
| vila | jibel: thanks, already running from jenkins | 12:45 |
| jibel | vila, or propose a patch to accept a local testsuite directory as well | 12:46 |
| vila | didrocks: http://paste.ubuntu.com/6294696/ captured on the fly, not sure otto can capture the right ones in the general case (x is restarted only once for this specific case so we are ~ok here, but that may not always be true) | 12:51 |
| didrocks | vila: ok, so clearly a Xorg issue | 12:51 |
| didrocks | xorg/driver | 12:51 |
| vila | didrocks: yes, one more case where a test run breaks the ci infra with no way to guard against :-/ | 12:53 |
| fginther | morning | 12:55 |
| asac | didrocks: client bump? | 12:55 |
| asac | not good | 12:55 |
| didrocks | vila: indeed | 12:55 |
| asac | didrocks: see with mir team if they wantt o back out | 12:55 |
| didrocks | asac: right, so we are quite stuck now, I guess Mirv is trying to rebuild xserver-xorg-xmir, we'll see if that's enough of if they break the ABI | 12:55 |
| didrocks | asac: they pulled, they don't want to rollback without duflu | 12:55 |
| didrocks | (which is in AU timezone) | 12:55 |
| didrocks | who* | 12:55 |
| asac | not sure | 12:55 |
| asac | cant we just revert that part? | 12:56 |
| asac | we just want to go back to the revision before this happened | 12:56 |
| didrocks | that would mean push --overwrite | 12:56 |
| asac | didrocks: not realy | 12:56 |
| didrocks | as they want to keep their branch1 in pull order with branch 2 | 12:56 |
| asac | revert commit basically | 12:56 |
| asac | well, is it really about wishes in this case? | 12:56 |
| didrocks | asac: they overwrote your revert because they want to have this """workflow""" | 12:56 |
| didrocks | our* | 12:56 |
| didrocks | I don't want to restart this war | 12:57 |
| didrocks | (basically lp:mir was pushed with --overwrite) | 12:57 |
| didrocks | because history was messy from their standpoint | 12:57 |
| asac | wait | 12:57 |
| asac | thats insant | 12:57 |
| asac | insane | 12:57 |
| asac | they pushed overwrite? | 12:58 |
| asac | tahts not good | 12:58 |
| vila | didrocks: revert/commit is different from pull --overwrite, the history clearly shows who reverted what | 12:58 |
| ogra_ | instantly insane ? | 12:58 |
| asac | didrocks: can we move on with other parts like apps etc. | 12:58 |
| vila | grr push --overwrite | 12:58 |
| asac | and just decslare unity etc. blocked because of this until we have discussed and sorted? | 12:58 |
| didrocks | asac: no, apart from emptying the ppa | 12:58 |
| asac | didrocks: we have a bunch of things that were not build against this, no? | 12:58 |
| didrocks | which means another 2/3 hours to rebuild everything without mir | 12:58 |
| asac | didrocks: right. but feels with mir we wont proceed either | 12:59 |
| didrocks | asac: everything was rebuilt and dep on platform-api | 12:59 |
| didrocks | which pulls it | 12:59 |
| asac | its an uncoordinated client ABI bump | 12:59 |
| asac | we cant roll that | 12:59 |
| asac | that would defeat any discussion we did so far | 12:59 |
| didrocks | 14:59:07 alan_g | didrocks: ok - let me grab usc | 12:59 |
| asac | i suggest: empy the ppa, stop unity and mire | 12:59 |
| didrocks | asac: on #ubuntu-mir ^ | 12:59 |
| asac | then go with the rest and land those things nicely | 12:59 |
| asac | who is usc? | 13:00 |
| didrocks | unity-system-compositor | 13:00 |
| asac | didrocks: ok can we proceed like above? its a delay for us, but it is just the consequence we have to endure | 13:00 |
| didrocks | Mirv: can you backout mir from the ppa, with platform-api, unity-mir? | 13:00 |
| didrocks | we can't release any of those until mir is coordinated | 13:00 |
| asac | didrocks: we tell mir and unity folks that their part is stopped until we have their branches sorted, and go on with simple stuff.. | 13:00 |
| didrocks | asac: I don't see kgunn online yet | 13:01 |
| asac | empy ppa, rebuild evrything else | 13:01 |
| cjwatson | You know it's possible to forbid push --overwrite on a branch, right? | 13:01 |
| asac | then do the simple landings all night and morning | 13:01 |
| asac | didrocks: right. dont need to wait | 13:01 |
| asac | didrocks: we can post moretem with him | 13:01 |
| didrocks | cjwatson: with the append mode only, we did that on some projects, then flamewar started, but we can envision forcing it again right | 13:01 |
| cjwatson | Fair enough | 13:01 |
| didrocks | asac: yeah, just be aware that we are talking about 3h of delay until the first stack is ready to be pushed | 13:02 |
| Mirv | didrocks: ok, so removing mir and the rebuild platform-api unity-mir against old one? | 13:03 |
| didrocks | Mirv: in fact, we can't rebuild platform-api and unity-mir as they build-dep against latest mir | 13:04 |
| asac | didrocks: i know | 13:05 |
| asac | didrocks: but thats life. i will send a mail to kgunn etc. explaining that this also delays other landings by half a day | 13:05 |
| didrocks | Mirv: ok, so please disable platform-api, unity-mir, and mir | 13:05 |
| Mirv | didrocks: oh, right, they were bumped. or not the latest mir but the one before, still newer than in archive. | 13:05 |
| didrocks | + remove from the ppa | 13:05 |
| didrocks | (disable from the config) | 13:06 |
| Mirv | ok. | 13:06 |
| didrocks | thanks ;) | 13:06 |
| didrocks | asac: FYI ^ | 13:06 |
| asac | didrocks: right. and then lets schedule landings at best by stack so all the leave things and indicators can go in again | 13:06 |
| didrocks | Mirv: oh, while we are at it, please move then unity-mir back to unity8 :) | 13:06 |
| asac | etc | 13:06 |
| didrocks | at least, we'll win that :p | 13:06 |
| didrocks | (speaking of stacks) | 13:07 |
| Mirv | didrocks: ok | 13:07 |
| Mirv | done (deployed + packages removed from PPA) - except didrocks please deploy mir because of the lightdm access problem again | 13:13 |
| didrocks | Mirv: you didn't change anything in the branches, right? You can deploy with -US | 13:14 |
| didrocks | Mirv: to not need access to the branches | 13:14 |
| Mirv | didrocks: right, I've always used -U. thanks. | 13:14 |
| Mirv | so done | 13:14 |
| didrocks | thanks ;) | 13:15 |
| vila | didrocks: things are getting too complicated (to diagnose we need to run x under valgrind). To get something simpler I'd like <mlankhorst> to run only the failing test directly on the host | 13:22 |
| vila | didrocks: what's the command to do that and what are the pitfalls (set DISPLAY ? something else ?) | 13:22 |
| vila | didrocks: install xx packages | 13:23 |
| didrocks | vila: you can change the autopilot job in /usr/local/bin/ to start autopilot with "autopilot run <list of tests failing>" | 13:23 |
| vila | didrocks: which /usr/local/bin ? | 13:24 |
| didrocks | vila: the one in the container | 13:24 |
| vila | didrocks: I want to *avoid* the container. the server needs to be run with valgrind --track-origins=yes --error-limit=no /usr/bin/Xorg :0 | 13:25 |
| didrocks | vila: not sure then | 13:25 |
| vila | too many steps to get that working inside the container | 13:25 |
| * vila sighs | 13:26 | |
| vila | ok, I give up, I don't have the knowledge nor the energy to close the gap between upstream requests and the lack of reproducibility in the test env, I'm just wasting my time | 13:28 |
| vila | didrocks: what's the risk to not run those tests on radeon ? | 13:29 |
| didrocks | vila: we won't know if unity7 still runs on radeon hw | 13:29 |
| didrocks | or mir | 13:29 |
| didrocks | which is pretty bad | 13:29 |
| didrocks | ev: asac: do you think someone else can help vila? ^ | 13:29 |
| vila | didrocks: given that we don't even know what the cause is we're far from an ETA for the fix | 13:29 |
| vila | and until there is a fix, you're exposed to regressions | 13:30 |
| didrocks | vila: right, but I don't think we should cut our testing because we don't have the energy… | 13:30 |
| didrocks | right | 13:30 |
| asac | vila: didrocks: hard to say. i dont know where we are stuck. | 13:31 |
| vila | didrocks: it's more about waste of energy than about energy per se, there are just too many unknowns here for me to be efficient | 13:31 |
| asac | our test machine is broken? | 13:31 |
| didrocks | the radeon one has a xorg segfault when running the tests | 13:31 |
| vila | asac: some tests triggers a X crash | 13:31 |
| asac | upstream has no radeon to reproduce? | 13:31 |
| asac | who is actually xorg maintainer? | 13:32 |
| vila | asac: He didn't say, #ubuntu-desktop | 13:32 |
| asac | whoever that is should help out | 13:32 |
| ogra_ | did you involve tjaalton or mlankhorst yet ? | 13:32 |
| asac | right | 13:32 |
| asac | go for our xorg folks. | 13:32 |
| vila | ogra_: yes, see #ubuntu-desktop, I finally managed to get it to the lab | 13:33 |
| seb128 | they just want a valgrind log of the issue since they don't get it locally, what's wrong with that, | 13:33 |
| seb128 | ? | 13:33 |
| vila | he's hacking there right now | 13:33 |
| vila | but that's only half of the equation | 13:33 |
| ogra_ | ah, good then | 13:34 |
| vila | the other half is to run autopilot outside of the container and I don't know what needs to be setup there nor which command to run | 13:34 |
| asac | vila: whats the other half? seems like folks are investigating now | 13:34 |
| asac | vila: isnt that part solved for intel etc. machines? | 13:34 |
| asac | cant you spy what they do? | 13:34 |
| vila | I do | 13:34 |
| vila | cd /etc/X11 ; rm X ;) | 13:35 |
| vila | sounds good | 13:35 |
| asac | so solved? :) | 13:35 |
| vila | what I'm asking here is what needs to be setup *outside* of the container because the container use a snapshot so you can't hack there | 13:36 |
| vila | hacking on what is put inside the container is insane | 13:36 |
| vila | so, | 13:37 |
| vila | <vila> didrocks: what's the command to do that and what are the pitfalls (set DISPLAY ? something else ?) | 13:37 |
| vila | <vila> didrocks: install xx packages | 13:37 |
| vila | is where I stopped, I *can* go ahead and lurk and find but this is getting ridiculous, just tell ne | 13:37 |
| vila | me | 13:37 |
| didrocks | what is getting ridiculous? | 13:38 |
| didrocks | vila: I told you how to get the autopilot command runs inside the container? | 13:38 |
| didrocks | outside, I don't think you can | 13:38 |
| didrocks | there is no X, nor lightdm installed | 13:38 |
| didrocks | it's a server install | 13:39 |
| didrocks | I don't see what's harder being inside the container though, I told you how to remove the timeout and how to start by hand | 13:40 |
| didrocks | then, you have a command line inside as you would have outside | 13:40 |
| vila | right and it took me alsmost 2 hours to get the Xorg.0.log... | 13:41 |
| vila | didrocks: and since the machine has just been rebooted anyway... | 13:42 |
| didrocks | vila: I don't think anyone apart from you and mlankhorst are on the machine | 13:42 |
| vila | of course not, he did reboot, because it's easier for him to work on the host to diagnose on the host, the container is just adding useless complexity that I want to get rid of | 13:43 |
| vila | isolation is about involving less pieces | 13:44 |
| didrocks | vila: as long as you reinstall the machine afterwards | 13:44 |
| vila | didrocks: already mentioned in #ubuntu-desktop | 13:44 |
| didrocks | great then :) | 13:45 |
| vila | and now he's blocked on how to run the tests and I still have no answer | 13:45 |
| vila | not to mention I'm late for the ci standup | 13:45 |
| didrocks | vila: is it all my fault? Can we depassionate this discussion? | 13:45 |
| didrocks | and be professional, thanks | 13:45 |
| didrocks | vila: so, we always run autopilot within inside the session | 13:46 |
| vila | didrocks: never said it was your fault, I'm asking questions which don't get answered, anybody with knowledge that I lack can answer | 13:46 |
| didrocks | I told and showed you how to do it in an autostarted way in the container | 13:46 |
| didrocks | AFAIK, apart from using basic Linux knowledge | 13:46 |
| didrocks | meaning looking at gnome-session env var | 13:46 |
| vila | and I said I wanted to avoid that to simplify the diagnosis | 13:46 |
| didrocks | exporting those | 13:46 |
| didrocks | and running "autopilot run <list of tests> | 13:46 |
| didrocks | I don't think, we have an automagic job doing that | 13:47 |
| vila | will get back to it after the standup | 13:47 |
| didrocks | vila: and yes, I figured that our myself, nobody answered me, so I can be wrong | 13:47 |
| didrocks | just trying to assess what the others are doing | 13:47 |
| didrocks | and apply to this new case | 13:48 |
| didrocks | ogra_: do you think you have bandwith to work on the emulator support right now? (an old landing ask) | 13:59 |
| ogra_ | which one | 13:59 |
| didrocks | ogra_: can we land that without the hud branch in comment? | 13:59 |
| didrocks | landing ask, line 143 | 14:00 |
| ogra_ | hmm, not sure thats still needed | 14:00 |
| ogra_ | xnox, ^^^ | 14:00 |
| ogra_ | hrm | 14:00 |
| ogra_ | that merge is clearly the wrong one | 14:01 |
| xnox | didrocks: ogra_: if anything w.r.t. emulator is from saucy, it's all obsolete and should be dropped. | 14:01 |
| ogra_ | right, thought so | 14:01 |
| xnox | ogra_: i had a recent branch proposal for lxc-container-config (re-prepose) | 14:01 |
| didrocks | ok, dropping then | 14:02 |
| xnox | ogra_: which i think i will be just uploading. | 14:02 |
| ogra_ | xnox, gimme and i'll approve :) | 14:02 |
| ogra_ | xnox, or that ... but keep the spreadsheet updated | 14:02 |
| xnox | ogra_: https://code.launchpad.net/~xnox/ubuntu/trusty/lxc-android-config/add-generic-rules/+merge/192331 | 14:02 |
| ogra_ | ah, i have seen that one before :) | 14:03 |
| * ogra_ will update line 143 | 14:03 | |
| ogra_ | hmm | 14:04 |
| ogra_ | or not ... since it is gone | 14:04 |
| xnox | well, didrocks just dropped it =) | 14:04 |
| xnox | ogra_: imho i need to upload stuff for the emulator. (a) it's not affecting other images (b) we need it urgently | 14:05 |
| didrocks | xnox: yeah, just file a new one | 14:05 |
| ogra_ | xnox, yes, please go ahead with that one | 14:05 |
| didrocks | when you are read :) | 14:05 |
| didrocks | xnox: and yeah, sounds good | 14:05 |
| ogra_ | i'll care for the spreadsheet | 14:05 |
| didrocks | ogra_: just write it for tracking | 14:05 |
| didrocks | ogra_: I postponed most of the landing to image 6 | 14:06 |
| didrocks | so that we kick image 5 first | 14:06 |
| ogra_ | yep | 14:07 |
| ogra_ | would be hard to kick image 6 before 5 anyway :P | 14:07 |
| * didrocks trust ogra_ to make magic! | 14:10 | |
| didrocks | :) | 14:10 |
| renato_ | fginther, all tests passing: https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-1236464/+merge/190496 | 14:13 |
| renato_ | now the only missing problem is jenkins :D | 14:14 |
| fginther | renato_, there are some failing desktop (otto) tests. is that expected? | 14:15 |
| renato_ | fginther, please could you merge it before any other merge get merged on SDK and cause more conflicts and failures | 14:15 |
| renato_ | :( | 14:15 |
| renato_ | I did not see that, is not related with my mr but I need to ask the SDK guys to look | 14:16 |
| fginther | renato_, Ack, This branch now builds/tests with trusty, perhaps that introduced a regression... | 14:17 |
| fginther | renato_, just throwing an idea out there | 14:17 |
| === elopio_ is now known as elopio | ||
| elopio | renato_: fginther: the otto failures are because otto is in autopilot 1.4 | 14:58 |
| elopio | the rest jobs are using autopilot 1.3. | 14:59 |
| elopio | didrocks: do you have some minutes to talk about that ^ ? | 14:59 |
| didrocks | elopio: so, if we take trunk for the others components, all will be fine with autopilot 1.4? | 15:00 |
| elopio | didrocks: no, all will be failing :) | 15:00 |
| didrocks | ah, so autopilot 1.4 was pushed to trunk without tests being updated by the QA team? | 15:01 |
| elopio | yup. | 15:01 |
| didrocks | ok, so I think we're going to remove autopilot 1.4 from the ppa | 15:01 |
| didrocks | blacklist it for now | 15:01 |
| didrocks | and have all projects running with 1.3 | 15:01 |
| elopio | didrocks: yes. So what about this: | 15:01 |
| didrocks | elopio: they did break backward compatibility? were you informed? | 15:01 |
| didrocks | asac: FYI ^ | 15:02 |
| * sergiusens thought those days were past us now | 15:02 | |
| elopio | didrocks: yes, it's not backwards compatible, and on QA we all knew. | 15:03 |
| didrocks | elopio: can I say "sigh" ;) | 15:04 |
| sergiusens | elopio, ack, so you are aware that all the tests need to be migrated in parallel? | 15:04 |
| didrocks | there are also community core apps | 15:04 |
| sergiusens | I don't think devs are going to be happy doing that when backwards compatibility was requested the last time this was needed | 15:04 |
| elopio | it's a change to throw an exception instead of returning None in case the element we are looking for is not present. | 15:04 |
| didrocks | tests done people not at canonical, and not being backward compatible isn't nice | 15:04 |
| elopio | didrocks: but we are currently working on updating all of them. | 15:05 |
| didrocks | elopio: right, but don't push to trunk before it's ready please | 15:05 |
| didrocks | elopio: can you revert your trunk to last version in ubuntu | 15:05 |
| didrocks | or last version compatible? | 15:05 |
| elopio | didrocks: autopilot's trunk? | 15:05 |
| didrocks | elopio: yeah | 15:05 |
| elopio | I don't have access to that, that's thomi. But can't you take autopilot 1.3's branch? | 15:06 |
| sergiusens | elopio, can you make ap 1.3 coinstallable with 1.4? | 15:06 |
| elopio | sergiusens: we could. I'm not sure that's going to be needed. So last night I was too asleep to explain what thomi proposed and I was doing. | 15:06 |
| didrocks | elopio: we want trunk to be in a good state and not changing our configuration for upstream | 15:07 |
| elopio | let me tell you to see if you agree, or we should change the course of action. | 15:07 |
| didrocks | ok | 15:07 |
| sergiusens | elopio, ack, we do coinstalls for most transitions btw | 15:07 |
| sergiusens | sf->mir as an example | 15:07 |
| elopio | so, the first step we were doing was to make the apps -autopilot deb package depend on << 1.3 | 15:08 |
| elopio | then, we wanted to ask you to install 1.4 on all the runners. | 15:08 |
| elopio | that would block all landings until the tests are updated. | 15:09 |
| elopio | so, we update the tests, set the dependency to >= 1.4, and everything would be green again. | 15:09 |
| didrocks | elopio: on getting all -autopilot dep dep on << 1.3 won't work, if they are not cooinstallable, we still can't ship 1.4 until the transition is done | 15:09 |
| elopio | I didn't expect otto to be already on 1.4, so the first step was terrible :) | 15:09 |
| didrocks | elopio: well, we take trunk | 15:09 |
| didrocks | if trunk ships to something not ready, it's upstream to ensure that it's not merged | 15:10 |
| elopio | yes, I didn't know about that, I suppose thomi didn't either. | 15:10 |
| didrocks | it's the case for more than a year :) | 15:10 |
| elopio | I guess it would not have problems changing trunk to be 1.3 | 15:10 |
| didrocks | elopio: yeah, please do that for now | 15:10 |
| didrocks | lp:autopilot pointing to 1.3 | 15:10 |
| didrocks | elopio: then, it's the autopilot package breaking -autopilot debs | 15:11 |
| elopio | didrocks: I'll tell him as soon as he starts. | 15:11 |
| didrocks | so that one needs to express a Breaks: unity8-autopilot (<< version with the fix> | 15:11 |
| didrocks | and so on | 15:11 |
| didrocks | elopio: I can do it if needed | 15:11 |
| didrocks | elopio: so changing from ~autopilot/autopilot/trunk to ~autopilot/autopilot/1.3? | 15:12 |
| elopio | didrocks: well, that's what you suggested. Sounds good for me, I don't know if thomi will have something against that. | 15:12 |
| elopio | I suppose not. And we can always go back if things go wrong, right? | 15:13 |
| didrocks | elopio: right | 15:13 |
| didrocks | elopio: done, can you sync with him? :) | 15:13 |
| didrocks | elopio: then, same, please don't merge anything for 1.4 compatibility on projects | 15:13 |
| didrocks | just be ready to flip the switch on the same day | 15:14 |
| didrocks | getting us aware | 15:14 |
| didrocks | and we do the transition in one shot | 15:14 |
| didrocks | (even if I think autopilot should really understands they have to be backward compatible now) | 15:14 |
| didrocks | sil2100: I've switch lp:autopilot back to 1.3, can you please rekick an autopilot build for the ppa? | 15:14 |
| elopio | didrocks: yes, I will discuss with him. But now it's not clear for me how to move forward. | 15:15 |
| elopio | do you want all the projects to have a branch 1.4 ready at the same time? | 15:15 |
| didrocks | elopio: yeah, and we flip the switch for the transition the same day | 15:16 |
| didrocks | having a landing ask for it | 15:16 |
| elopio | didrocks: ok, this is blocking me so I think I will spend today updating everywhere. | 15:16 |
| elopio | balloons: ^^ | 15:16 |
| didrocks | elopio: thanks :) | 15:17 |
| elopio | didrocks: now, why would I need to add a Breaks section on the control file? Wouldn't it be enough to tell that we depend on libautopilot-qt ( >= 1.4 ) ? | 15:17 |
| balloons | ok so autopilot stays 1.3 until everything is ready for 1.4, then we'll transition at once, n'est pas? | 15:17 |
| didrocks | balloons: exactement! | 15:18 |
| didrocks | elopio: that's fine as well | 15:19 |
| didrocks | elopio: but you need to tell you breaks (<< 1.3) | 15:19 |
| elopio | didrocks: ok, I didn't get it :) I'll start with the toolkit and ask for your review, that's going to be easier. | 15:21 |
| didrocks | elopio: sure! | 15:25 |
| === gatox is now known as gatox_lunch | ||
| renato_ | elopio, fginther since the problem is nor related with the code could you merge my MR? | 15:42 |
| renato_ | *not | 15:42 |
| elopio | renato_: the tests should pass after sil2100 rebuilds the ppa. | 15:42 |
| fginther | elopio, ack. ping me when that's ready and I'll rebuild the job | 15:43 |
| didrocks | sil2100: kenvandine: robru: joining? | 16:00 |
| didrocks | plars: ^ | 16:05 |
| plars | didrocks: ack, brt | 16:05 |
| mlankhorst | hey | 16:21 |
| elopio | didrocks, sil2100: do you know where can I get libautopilot-1.4 from? | 16:39 |
| === gatox_lunch is now known as gatox | ||
| ogra_ | == Build #5 running === | 16:46 |
| didrocks | elopio: we just removed it from the ppa, so I think there is an autopilot ppa | 16:52 |
| didrocks | ogra_: \o/ | 16:54 |
| === alan_g is now known as alan_g|EOD | ||
| vila | bug #1244324 | 17:11 |
| ubot5 | bug 1244324 in glamor-egl (Ubuntu) "glamor-egl crashes when running autopilot tests" [High,Triaged] https://launchpad.net/bugs/1244324 | 17:11 |
| ogra_ | == Build #5 done === | 17:43 |
| popey | \o/ | 17:46 |
| nik90 | @ci, I heard before that the core apps which are currently present as click packages on the phone will continously be updated via the app store just like any other app. However what happens to the dependencies that these click packages depend on? Will they also be updated? | 18:58 |
| nik90 | @ci, an example in my case is the clock app which depends on the EDS. Will EDS be updated for those running the builds 101 saucy? | 18:59 |
| nik90 | @ci or should I be asking those users to upgrade to trusty build 5 for that? | 18:59 |
| cjohnston | nik90: that doesn't sound like a CI related question | 19:00 |
| nik90 | cjohnston: but it is related to app updates landing in the platform? | 19:00 |
| cjohnston | That still sounds like a development related question | 19:02 |
| josepht | nik90: fwiw, please use 'cihelp' rather than '@ci'. The latter was causing us some issues. | 19:03 |
| josepht | cjwatson: do you have any thoughts on nik90's question? ^ | 19:05 |
| fginther | nik90, that's a question better suited for #ubuntu-touch | 19:05 |
| fginther | popey, do you know the answer to nik90's ? ^ | 19:07 |
| sil2100 | elopio: ok, it seems the QA stack got stuck because of autopilot-gtk/-qt | 19:11 |
| nik90 | fginther: okay. I will also ask on ubuntu-touch | 19:12 |
| nik90 | josepht: okay, didnt see the updated channel header. P | 19:15 |
| elopio | sil2100: not sure what that means. Do you need us to help with something? | 19:29 |
| cjwatson | josepht: not really, it's not up to me | 19:32 |
| cjwatson | click packages only depend on "the system" and that gets updated by system image updates | 19:32 |
| sil2100 | elopio: no, but hm, I noticed that Didier retargetted lp:autopilot to lp:autopilot/1.3 | 19:33 |
| sil2100 | elopio: are you guys aware of that? | 19:34 |
| sil2100 | I need to do the same for -gtk and -qt then | 19:35 |
| cjwatson | sergiusens: click-sync seems unhappy | 19:35 |
| sil2100 | Anyway, I'll e-mail you guys about that anyway later on | 19:35 |
| elopio | sil2100: we are. We are updating the tests to autopilot 1.4 so we can release 1.4 without breaking anything. | 19:35 |
| sergiusens | cjwatson, yes, I logged on to ask you about that | 19:36 |
| sil2100 | elopio: awesome - so I did the same for autopilot-qt and autopilot-gtk, so now trunk series is the same as 1.3 | 19:36 |
| sergiusens | cjwatson, do you know of any changes going on in the infra? It's a proxy error that I see; wasn't aware of the proxy | 19:36 |
| elopio | sil2100: thank you. | 19:36 |
| sil2100 | elopio: once 1.4 is ready, we just need to retarget trunk series again | 19:36 |
| cjwatson | sergiusens: not that I've heard of | 19:37 |
| sergiusens | elopio, since you are here; I was looking at the history for base.py, not sure why the call to dpkg-architecture was added from the comments | 19:37 |
| cjwatson | sergiusens: but I have no involvement in the store side | 19:37 |
| sergiusens | cjwatson, I'll talk to beuno; that said it's safe to disable for now | 19:37 |
| elopio | sergiusens: it was there originally when I refactored the code. I didn't see a reason for it so I removed it. | 19:37 |
| sergiusens | elopio, oh, would be interesting to know why it was there at all, we never needed it for the app tests that did not use the ui toolkit | 19:38 |
| elopio | then it started failing on the phones and Mirv pointed out the reason I put on the comment. | 19:38 |
| cjwatson | sergiusens: I'm about to vanish again and don't really mind the cron mail for now :) | 19:38 |
| sergiusens | cjwatson, ok, if you don't mind; I'm ok with it | 19:38 |
| cjwatson | would prefer to leave it enabled so that you can fix by pushing to its branch if necessary ... | 19:38 |
| sergiusens | cjwatson, ack; but to confirm, there's no transparent or real proxy required now, right? | 19:39 |
| elopio | sergiusens: Mirv replied to the email thread. | 19:40 |
| cjwatson | sergiusens: I don't know | 19:40 |
| sergiusens | elopio, yeah, but I was just talking to steve before; QT_SELECT is set | 19:41 |
| cjwatson | honestly don't know enough about the setup to answer that | 19:41 |
| sergiusens | elopio, did it fail when calling from the sdk? or did you always use phablet-test-run; that's the bits I'm missing | 19:41 |
| sergiusens | cjwatson, I'll talk to the backend guys | 19:41 |
| elopio | sergiusens: I don't know about that either. I wasn't working on the toolkit when it started failing, and Mirv took care of adding it back. Then I just cleaned it a little making a separate function so it would be easier to change again. | 19:44 |
| elopio | but I can make a quick branch to throw to jenkins and see if it's working now. | 19:44 |
| sergiusens | elopio, great, please do; I really think it's not needed | 19:45 |
| sergiusens | cjwatson, if you are still there; can you see if there are any proxy envvars on snakefruit? | 19:46 |
| sergiusens | shouldn't be picked up by the cron though... | 19:46 |
| elopio | sergiusens: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/launch_qmlscene/+merge/192576 | 19:49 |
| sergiusens | elopio, this runs the test out of the box? | 19:50 |
| sergiusens | elopio, if it passes, don't forget to remove the dep on dpkg-dev | 19:50 |
| elopio | sergiusens: it will eventually run all the tests in jenkins in all the devices. So if it works, I would say it's safe to remove the dep. | 19:51 |
| sergiusens | elopio, if it fails next step is to look at how that runner is setup on jenkins | 19:51 |
| elopio | but I would confirm with Mirv before. | 19:51 |
| elopio | sergiusens: ack. I'll keep you guys posted on the email thread. | 19:51 |
| cjwatson | sergiusens: neither in ubuntu-archive's default environment nor in its crontab | 19:59 |
| sergiusens | cjwatson, yeah, just trying to figure out why the resp comes from a squid on localhost:3128 | 20:00 |
| sergiusens | when downloading the actual package | 20:00 |
| thomi | sil2100: ping? | 22:01 |
| sil2100 | thomi: pong! | 22:02 |
| thomi | sil2100: hey man - just wondering if you know why the autopilot trunk series was changes to point to the 1.3 branch? | 22:02 |
| sil2100 | thomi: that's a valid question! I wasn't around when this happened, but it seems this is the way in which Didier decided to force 'trusty' to use 1.3 instead of trunk | 22:03 |
| sil2100 | thomi: no idea why he didn't just modify cu2d-config instead | 22:03 |
| thomi | sil2100: OK. I realise it's not your fault, but it would have been nice if someone told me | 22:03 |
| sil2100 | thomi: since when I appeared it was already like that, I decided to do the same temporarily for -qt and -gtk as well... | 22:03 |
| thomi | I'm changing it back now, because it makes it impossible for people to easily get the 1.4 source code | 22:03 |
| thomi | :( | 22:04 |
| thomi | ok, I'm changing them all back then :) | 22:04 |
| sil2100 | hmmm, oh, ok, so maybe I'll prepare a cu2d-config switch then | 22:04 |
| thomi | if you guys want 1.3 in trusty, I think you ought to change the cu2d config | 22:04 |
| thomi | thanks | 22:04 |
| sil2100 | thomi: switch back autopilot-qt and -gtk if you have a moment ;) | 22:04 |
| thomi | sil2100: I will :) | 22:05 |
| sil2100 | thomi: sorry about that, elopio was aware of that it seems (probably didrocks told him) | 22:05 |
| thomi | thanks man | 22:05 |
| thomi | that's OK, I found out in the end. | 22:05 |
| sil2100 | I didn't know what was the rationale so I decided to keep it until Didier pops up ;D | 22:05 |
| thomi | I'm changing the project maintainer to be the Qa team, so this can't happen again | 22:05 |
| josepht | thomi: the bug I mentioned yesterday turned out to be in pyjunitxml not autopilot. Patch submitted. | 22:21 |
| thomi | josepht: awesome :) | 22:42 |
| xnox | Is platform-api going to be rebuild into trusty soon? | 22:56 |
| xnox | (as in the Ubuntu Archive) | 22:56 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!