=== 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: -
Mirvcyphermox: 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
Mirvdidrocks: hi! I think "Result directory doesn't exists, exiting!" is what keeps from getting green at the moment06:08
didrockshey Mirv!06:09
didrocksMirv: oh, where is this?06:09
didrocksMirv: I saw some more FTBFS as well06:09
Mirvfor example
* didrocks looks06:09
didrocksweird, there is a head one06:10
didrocksmaybe it's archived under trusty06:10
didrocksMirv: can you try rerun a small check run?06:11
didrocksI tried to add trusty06:11
Mirvdidrocks: ok, trying06:13
didrocksMirv: I guess on the FTBFS, platform-api needs to be rebuilt so that unity-mir can be rebuilt and the unity8 should be fine06:13
Mirvdidrocks: right the one robru filed06:15
Mirvdidrocks: yay we have familiar looking problems too
didrocksBuild was aborted06:19
didrocksAborted by Timo Jyrinki06:19
didrocksMirv: robru filed the FTBFS? did he try to rebuild platform-api then?06:20
Mirvdidrocks: as you can see it was hanged for 1.5 hours with DHCP lines only06:20
Mirvrobru: I don't think he did, he claimed that the complain of a dependency is actually fulfilled in archives06:21
didrocksMirv: it's happening everywhere? or only on some machines?06:21
didrocksMirv: well, I doubt soyuz is lying on the dep :)06:21
didrocksI guess robru didn't dig :(06:21
Mirvdidrocks: that seemed top be radeon only06:21
didrocksit's obvious that the issue is platform-api06:21
didrocksMirv: hum, let me see the snapshot on radeon06:22
didrocksok, same time than others06:22
didrocksI can remove and revert to yesterday's snapshot for now06:22
Mirvrunning check on services stack now06:24
didrocksMirv: oh, in fact, moving unity-mir to the mir stack was a bad idea after all06:25
didrocksbecause platform depends on mir06:25
didrocksand unity-mir depends on platform06:25
didrocksI didn't think about it06:25
didrocksSaviq: we'll revert and remove to unity8 stack ^06:25
didrocksI'm retrying unity-mir stack06:25
didrocksok, qtubuntu and all the sensors/hud are failing due to that06:26
didrocksMirv: let's release today with that, and move back unity-mir then06:27
Mirvmeanwhile switching from services to some else06:27
didrocksso, building06:27
didrocksrestarting as well platform for qtubuntu-sensors06:32
Mirvdidrocks: ok, still getting the results directory complaint:
Mirvthat result should be yellow according to the subtasks06:54
didrocksMirv: ok, the subdir isn't created06:54
didrocksjibel: salut! we don't create the result subdir automatically, right? (for the -check job)06:55
didrocksMirv: let me fix that manually06:55
didrockshum, that's not the issue06:56
* didrocks looks at the code06:56
jibeldidrocks, sorry I miss context, which result subdirectory, where?06:56
didrockshum SEARCHPATH=${BASEDIR}/${JOBNAME}/configurations/axis-label/${NODENAME}/builds/06:57
didrocksthat's what doesn't exist06:57
jibeluh, it is jenkins territory and it should have created it.06:58
jibeldidrocks, I'll check in 5 min06:58
didrocksyeah, no configurations/06:58
didrocksjibel: thanks!06:58
didrocks(in /var/lib/jenkins/jobs/cu2d-qa-head-2.2check/)06:58
didrocksMirv: let's monitor the FTBFS meanwhile :)06:59
didrocksI guess I don't read the right parameter, no configurations/ in /var/lib/jenkins/jobs/cu2d-qa-saucy-2.2check/ either07:00
jibeldidrocks, machines that were testing raring have been reassigned to head and the name of the AP nodes changed07:08
jibeldidrocks, you must change     apmachines: autopilot-intel qa-nvidia-gtx66007:08
jibelto the name of the new nodes07:08
jibeldidrocks, in cupstream2distro-config/stacks/head/*cfg that is07:08
didrocksjibel: stupid me…07:09
didrocks(well, I didn't do that change, but yeah)07:09
didrocksjibel: /var/lib/jenkins/jobs/cu2d-qa-saucy-2.2check/ doesn't have this configurations?07:09
didrocksdo I read the shell badly? :)07:10
didrocksMirv: changing the config07:10
jibeldidrocks, in
jibelexecution step 307:10
jibelline 10: for machine in autopilot-intel qa-nvidia-gtx660; do07:11
didrocksjibel: oh, it's a REST request07:11
didrocksjibel: ok, I was on the FHS07:11
didrocksjibel: thanks, and sorry for the stupid issue :/07:13
jibeldidrocks, np07:13
didrocksMirv: ok, all redeployed07:15
didrocksMirv: so, current -check job should still fail because of that, but next one should be fine07:15
didrocksMirv: I'm relaunching qa just to test07:16
jibeldidrocks, I added a note to MovingNewRelease07:26
didrocksjibel: thanks :)07:26
Mirvdidrocks: I guess it kind of worked now, ie. to that problem07:28
Mirvthe radeon just failed almost all the tests07:28
didrocksMirv: yeah, I'm seeing that07:29
didrocksvila: mind helping there?07:29
didrocksMirv: there are still 2 tests failing on autopilot, can you have a look with upstream?07:30
viladidrocks: shoot07:30
didrocksvila: seems radeon is failing all the tests07:30
viladidrocks: ouchy,  for machine in autopilot-intel qa-nvidia-gtx660; do that's bad :-/07:30
didrocksvila: we have 98 failures on it07:30
didrocksvila: and 2 failures on the other machines07:30
viladidrocks: url ?07:30
Mirvnow we start to actually see how's the autopilot 1.4 branch like07:31
didrocksMirv: right!07:31
didrocksMirv: btw, it seems packaging list still needs to be updated for some stacks07:31
didrockssdk and hud?07:31
didrocksMirv: mind doing it? feel free to push/relaunch :)07:31
Mirvdidrocks: I will, in a bit07:32
viladidrocks: 2 on qa-intel, 4 on -nvidia, 98 on radeon, pretty messy07:33
didrocksvila: isn't it? :/07:34
didrocksvila: same on previous run:
vilaand the durations are... really different07:34
didrocksvila: however, the machine is fine:
vilaat least - readeon fails fast ;)07:34
didrocksfor indicators07:34
vilathis is for autopilot itself right ?07:35
vilasounds like an isolation issue to me, one test fails to cleanup properly and the following ones break07:37
didrocksvila: that's more than probable07:37
vilaurgh, 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
didrockssil2100: hey! how are you?07:41
didrocksvila: an unity crash file?07:41
sil2100didrocks: morning!07:41
didrocksvila: oh, thinking about it07:41
Mirvrerunning hud tests07:41
vilastill reading the console07:41
sil2100Autopilot problems?07:42
didrocksvila: do we have the proprietary driver install on it?07:42
didrocksjibel: do you remember which driver we were using on ati? ^07:42
didrockssil2100: yeah, some just for one machine, Mirv is redeploying the latest package updates needed07:43
viladidrocks: meh, no idea07:43
jibeldidrocks, nouveau, fglrx didn't compile earlier in the realease and we never move to the proprietary driver07:43
didrockssil2100: 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 failing07:43
didrockslike QA ;)07:43
viladidrocks: yup, sounds like the most sensible thing to do07:43
Mirvdidrocks: yeah starting from QA makes sense07:43
didrocksjibel: ok, and so, we were fine with the free driver07:44
Mirvpinging QA07:44
didrocksvila: I guess it's a hint for you, look if xorg/lightdmin failed ^07:44
viladidrocks, Mirv : if nothing else, if it's related to the X server, the tests should fail far earlier with better messages07:44
jibeldidrocks, mostly fine, the main issue was the machine hanging when it switches from Mir to Xorg07:45
didrocksvila: I can list you a lot of should :)07:45
sil2100didrocks: ok, is QA the one with stable results?07:45
didrocksjibel: yeah, but other stacks (like, when Mir wasn't enabled), we were good running unity tests IIRC07:45
didrocksand that we didn't switch back and force from it07:45
didrockssil2100: well, all the ones that are stopped should have stable results07:46
viladidrocks: 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 fixes07:46
didrocksvila: that's why we have people first deciphering for him07:46
didrocksas we have to cope with what we have07:46
didrocksand fix timely first07:46
didrocksto get back on productoin07:46
didrockssil2100: so, everywhere it's red and not running :)07:47
viladidrocks: 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 later07:47
didrocksvila: indeed, so then, send the email to people that we are going to improve the platform and not deliver anything meanwhile07:47
Mirvfiled bug #1244089, please update if you've anything to add to the description07:48
ubot5bug 1244089 in Autopilot "Autopilot 1.4 trusty AP test errors" [Critical,New] https://launchpad.net/bugs/124408907:48
Mirvgood news! indicators stack tested itself fine :)07:49
viladidrocks: 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
sil2100Mirv: I'm looking at hud now though07:50
viladidrocks: still looking on qa-radeon- itself for additional evidence07:50
didrocksvila: would be interesting to know if there was a crash07:50
didrocksyou have those infos07:50
Mirvsil2100: I'm already there, I added a few packages already07:50
sil2100Mirv: extra-packages needed for hud, ok07:51
viladidrocks: /var/crash is empty07:51
didrocksvila: ok :(07:51
Mirvsil2100: relaunching hud now after redeploy07:51
viladidrocks: why the sad face ?  I'd rather have autopilot fixed than one more fix in the ci infra :0)07:52
didrocksvila: well, I doubt the issue is in AP07:52
didrocksvila: why is it failing only on radeon? AP isn't hw specific07:52
Mirvanyway. we have the first autopilot-running stack ready to publish, which is definitely progress. others running so let's see.07:52
didrocksso either something changed in the way it access the hw and we don't have the setup on that machine07:53
viladidrocks: it could a timing issue07:53
Saviqdidrocks, k07:53
didrocksvila: can be, yeah, and if the cleanup isn't good…07:53
vilaha crap looking at the wrong place07:53
Mirvhmm the green indicators tests indicate failing tests in the log, though (at the end)07:54
Mirvunity.tests.test_panel.PanelHoverTests.test_hovering_indicators_open_menus: FAIL etc07:54
sil2100Many FAIL but SUCCESS07:56
viladidrocks: ?07:56
viladidrocks: not sure I know how to read that07:57
didrocksWARN  2013-10-24 07:18:25 unity.gdk <unknown>:0 compiz: Fatal IO error 11 (Resource temporarily unavailable) on X server :0.07:58
didrocksnot sure that's good07:58
sil2100On webapps it seems ERROR __init__:64 - Unity doesn't appear to be running, exiting.07:58
Mirvok hud is now back in the league of "properly" failing07:59
Mirvsil2100: same in hud08:00
viladidrocks: what happened with the containers there ?08:01
sil2100Mirv: I wonder if that's a problem with autopilot introspecting unity or just really unity doesn't start08:02
didrocksvila: there?08:04
didrocksvila: can you rephrase this? I can't parse you08:05
vilawhat happened with the containers on qa-radeon-7750 ?08:05
vilathe 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 failures08:06
vilaurgh, no they were against the current one, gee, that's confusing08:07
vilathere is a hanging.trusty-i386-20131024-0008 container, where is that coming from and why aren't we using it ?08:08
didrocksvila: yeah, it was hanging this morning (no ui started), so I needed to mv it first thing08:09
sil2100didrocks, Mirv: argh, today I might be late for the morning meeting, so just assign a lot of stuff to me if anything08:09
didrocksvila: I was planning to check for it once we have at least the first pass running08:09
sil2100Mirv: I'll be looking at the webapps part08:10
didrocksvila: as we know that yesterday's container was working08:10
didrockssil2100: ok08:10
didrockssil2100: https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0Au6idq7TkpUUdGNWb0tTVmJLVzFZd0doV3dVOGpWemc#gid=0 is assigned to you08:10
didrocksSaviq: dude, really ask to packagers when you add a packaging change…08:13
didrocksSaviq: https://code.launchpad.net/~elopio/unity8/autopilot-1.3/+merge/192440 isn't going to work08:13
didrocksSaviq: it will block unity8 to proposed until you the dep is fixed08:13
Saviqdidrocks, and it won't be?08:13
Saviqdidrocks, ah, it won't of course..08:13
Saviqdidrocks, sorry, I just woke up...08:14
didrocksSaviq: really, all packaging changes should involves a core dev ;)08:14
viladidrocks: 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
didrocksMirv: do you have the link for vila? ^08:14
Saviqdidrocks, is there a process other than us finding one? maybe a team we could assign reviews to?08:14
didrocksSaviq: on another note, I can't (again) :/ refind the fix for AP tests on unity8…08:14
didrocksSaviq: good point, I would say pinging there until the oakland sprint08:15
didrocksSaviq: then, we can discuss about team assignement and so on08:15
* sil2100 prepares to upgrade his device08:15
Saviqdidrocks, which fix? lxc-android-config / unity-mir? still not released08:15
didrocksSaviq: no, the one in AP unity8 tests themselves08:16
didrocksthe one we did on Thursday08:16
ubot5Ubuntu bug 1240801 in unity8 (Ubuntu) "autopilot unity8 fails with "No GSettings schemas are installed on the system"" [Low,Fix committed]08:16
Mirvdidrocks: just a second08:16
didrocksSaviq: thanks!08:17
Saviqdidrocks, how's it going, btw - when do we expect trusty to be good enough to start releasing into it?08:17
didrocksSaviq: we hope today, but issues on some components FTBFS and AP 1.4 having some tests failing08:18
Mirvsil2100: any idea how the unity problem could be debugged?08:19
Saviqdidrocks, mhm08:19
didrocksMirv: sil2100: so, what I see is: someone doing the mir transition, the other one debugging the AP issues + FTBFS08:19
didrocksMirv: sil2100: we can exchange if you prefer08:19
didrocksMirv doing the mir transition08:19
didrocksand sil2100 the debugging08:19
didrockswhat do you both prefer?08:20
Mirvfine, sil2100 might know more about the lxc debugging08:20
didrocksok, so exchanging08:20
Mirvvila: before switching to the older container I got this hang:
didrockssil2100: Mirv: done :)08:21
Mirvdidrocks: so, libmirserver8 now?08:21
didrocksMirv: indeed! 8 is a good number :-)08:21
didrocksbut can't wait for 9 :p08:22
Mirvis it then stable?! :)08:22
didrocksheh, let's hope so! ;)08:22
* sil2100 doubts that08:22
MirvI mean ABI stable, that is08:22
didrocksMirv: you're dreaminggggg ;)08:22
didrocksMirv: so, I guess apart from u-s-c (didn't check), everything else should be ready08:23
didrocksas per my relaunch this morning08:23
Mirvupdating package lists for platform and unity808:23
ogra_popey, mind testing #4 ? (its good on maguro)08:29
popeyalready done08:29
popeylooks good08:29
didrocksasac: you froze!08:32
elopiodidrocks, Saviq: Why can't we have autopilot 1.3 and 1.4 while we update the tests?08:37
elopioAutopilot 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
Saviqelopio, because they're not installable in parallel08:37
Saviqelopio, you can't install both autopilot-1.3 and autopilot-1.4 on the same machine - because they're different versions of the same package08:38
elopiohum, that's going to be a problem.08:38
Saviqelopio, yeah, we'd need autopilot 1.4 to be autopilot1408:39
elopioSaviq: 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
Saviqelopio, *I* think it's fine to just bump and adapt08:40
elopioas 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
elopiohowever 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
elopiobut I'm going to bed now. I'll ask tomorrow to see how can I help updating the tests.08:45
didrockssil2100: psivaa: please pair together ;)08:55
psivaadidrocks: ok08:56
didrocksthanks! good luck guys08:56
Mirvdidrocks: 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.gz09:06
didrocksMirv: 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
Mirvdidrocks: no need, seems upstream problem so solving with them while trying to get phone tests09:10
didrocksok, great!09:10
ogra_didrocks, asac, popey image 4/20131023 promoted09:12
didrocksogra_: \o/09:12
* popey mails09: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 309:37
didrockspsivaa: Mirv: sil2100: FYI, radeon deprovisionned.09:39
asaci have a question... are we still producing saucy-updates images?09:39
asacdidrocks: did you finish seb feedback?09:40
ogra_asac, not atm09: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 ones09:42
didrocksasac: seb is in Canada, not online yet09:43
didrocksasac: I'll grab him later on09:43
asacdidrocks: i want to be there :)09:45
didrocksasac: ok, will get you in, let's try to catch09:46
ogra_asac, what do you want in canada ...09:54
ogra_its full of canadians !09:54
viladidrocks: 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 again10:08
didrocksvila: ok, it's a start :)10:09
viladidrocks: right, I will hand it to ... dang, didn't copy from the hangout, paste the nick again ?)10:09
viladidrocks: this should be reproducible locally with the same or similar card by that guy right ?10:10
asacogra_: you mean test 101? or promote it?10:11
asacso the reason we do saucy-updates is to pipeclean our infrastructure and process10:12
ogra_asac, 101 is fine (iirc there was only the udevd change for maguro)10:12
asacwe should do a few builds there10:12
asacand then promote10:12
asacand then move on to T10:12
asacand promote T images to stable channel :)10:12
ogra_101 was the first one in there10:12
ogra_huh ?10:12
asacright. so that ones is in the bank10:12
ogra_T images to stable channel ?10:13
ogra_stable is saucy10:13
ogra_T is in development10:13
asacthats what people might believe :)10:13
ogra_well, thats what we have10:13
ogra_you cant call an in-development thing "stable"10:14
ogra_especially since you break the rolling model then10:14
xnoxogra_: 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 series10:14
xnoxogra_: something 1-2 months into the T cycle, or when ready.10:14
ogra_not a milestone image in the middle of a dev release10:14
asacogra_: thats ONE way to see it, yes. anyway, lets not talk about that now. let me first talk with folks10:14
didrocksvila: probably yeah10:15
asacabiout our saucy updates etc.10:15
ogra_if you really want to change that i'm highly opposed10:15
ogra_that adds massive confusion10:15
ogra_saucy updates need to go to the stable channel10:15
ogra_built from saucy-updates :)10:15
viladidrocks: 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
didrocksvila: mlankhorst10:17
viladidrocks: thanks ;)10:17
vilahttp:// if I keep relogin some tests succeed10:17
Mirvyay, error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs10:54
Mirvbreaks my pbuilder usage10:54
ubot5Debian bug 727540 in libept1.4.12 "aptitude: symbol lookup error: aptitude: undefined symbol: _ZNK7tagcoll4coll4FastISsSsE13getTagsOfItemERKSs" [Grave,Open]10:56
viladidrocks: 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
didrocksvila: for that, you need to stay on latest run11:09
didrocksvila: cd /var/lib/lxc/trusty-i386-20131024-0008/run11:09
didrocksedit target-override/usr/local/bin/run-autopilot.sh11:10
sil2100Add -S to the end of the command11:10
didrocksSHUTDOWN=1 -> change to 011:11
didrockssil2100: oh, -S?11:11
sil2100We had the same problem during our debugging, jibel proposed this and it works11:11
sil2100didrocks: in the xdg/autostart file11:11
didrocks    -S|--noshutdown)11:11
didrocks        SHUTDOWN=011:11
didrocks        shift;;11:11
didrocksahah ;)11:11
didrocksso, let's use the option rather11:12
didrocksedit target-override/etc/xdg/autostart/autopilot.desktop11:12
didrocksand add the -S at the exec line11:12
didrocksthen sudo lxc-start -n <container>11:12
viladidrocks, sil2100 : thanks11:14
asacjibel: looking at http://people.canonical.com/~j-lallement/touch/changes/20131022.html there seem to be a bunch of changelog items not availabe11:17
asacdo you know?11:17
Mirvdidrocks: 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 PPA11:18
didrocksMirv: sure, feel free :)11:21
vilaDo you guys know how to find which kind of graphic driver is installed on qa-radeon-7750 ?11:28
Mirvcheck if dpkg -l | grep fglrx shows something installed11:30
Mirvif not, it's using open drivers11:31
Mirvor simply /var/log/Xorg.0.log11:32
* didrocks goes for a run11:33
cjwatsonMirv: Do you have trusty-proposed enabled?11:38
cjwatsonI guess you might reasonably have it *inside* the chroot11:39
Mirvcjwatson: no, but right I could enable it11:39
cjwatsonMirv: No, don't11:40
cjwatsonMirv: You mean it's broken in trusty?11:40
Mirvcjwatson: I got it via pbuilder-dist trusty create done today + adding daily-build PPA + trying to build11:41
cjwatsonMirv: So you have libept1.4.12 1.0.9?11:42
Mirvlet me log in there11:42
cjwatsonThere's a 1.0.10 in trusty-proposed, but it's blocked on build failures on two architectures11:43
Mirvcjwatson: aha, it seems pbuilder-dist (or my old configuration of it somewhere) enables -proposed, so that's why I have 1.0.1011:44
cjwatsonThat's actually sensible *inside* a pbuilder11:44
vilaMirv: darn didn't notice your message until now. no fglrx, no mesa11:45
vilaMirv: what should I search for in X.org.0.log ?11:45
Mirvvila: mm maybe "X.Org Video Driver" and then before that what's the module name11:45
vilaMirv: there are a bunch of messages starting with (II) RADEON(0)11:45
cjwatsonI mean, in general we build packages against -proposed and so test builds should do likewise11:45
vilaha, hold on11:45
Mirvvila: ok, radeon tells already that's it's the default (open) driver, not fglrx11:46
Mirvand not vesa either, so the correct driver gets loaded11:46
vilaMirv: which are the corresponding packages ?11:46
* cjwatson blocks libept in -proposed until we figure this out11:47
cjwatsonIt might just need an aptitude rebuild11:48
Mirvvila: xserver-xorg-video-radeon/ati, the 3D part comes from mesa packages11:48
vilaX.org Video Driver: 14.1... "glx" will be loaded by default "xmir" not laded "dri2", glamoregl...11:48
cjwatsonBut that will be messy while libept has failed builds in -proposed11:48
vilaMirv: xserver-xorg-video-radeon/ati neither are installed11:49
Mirvvila: oh, sorry, can you find "Loading /usr/lib/xorg/modules/drivers/" in there somewhere?11:50
cjwatsonMirv: 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 doing11:51
cjwatsonMirv: Is it blocking you or can it wait a day or so?11:51
Mirvcjwatson: sure, this is not any sort of blocker for me11:51
vilaMirv: libglx11:51
Mirvvila: that should come from "extensions", not "drivers"11:51
Mirvvila: actually a simple search for lower-case "drivers" in the file should do11:52
vilaMirv: no copy/paste is a reaaaaaal pain11:52
vilaMirv: ha ! Can access via ssh under rootfs, pfew, some sanity restored11:58
Mirvvila: you're not saying you find all of those from Xorg.0.log? :)12:00
vilaMirv: I do12:01
Mirvvila: 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
Mirvvila: 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
Mirvvila: thanks :)12:02
vilaMirv: indeed ;) Sorry, took me a minute to get from ssh access to copy/paste restored ;)12:03
Mirvvila: 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
Mirvvila: so no visible problems starting the X there12:04
vilaMirv: pfew, learning is always painful :) First time diagnosing an X issue on a remote host with a KVM, every step hurts ;)12:06
vilaMirv: so, summary, the config seems correct and uses the open driver.12:06
vilaMirv: now to find how to tell otto to collect Xorg.0.log[.old]12:08
vilaMirv: will that be in otto sources and its associated config (where is that ?) ?12:09
Mirvvila: I'm not familiar with otto so far either12:10
vilaMirv: ack, thanks, negative feedback is so much better than none ;) (#ubuntu-desktop laaags ;)12:11
vilajibel: where should I look to tell otto to collect Xorg.0.log[.old] ?12:11
Mirvdidrocks: 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
jibelvila, http://bazaar.launchpad.net/~otto-dev/otto/testsuite_autopilot-unity/view/head:/config12:14
jibelvila, add them to ARTIFACTS12:14
vilajibel: thanks !12:14
Mirvdidrocks: 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
vilajibel: will do a mp later, where should I look for that locally ? Or is that something that comes from jenkins ?12:17
jibelvila, the branch is pulled from LP because we wanted to prevent people from doing what you're intending to do12:20
vilajibel: he he12:20
jibelvila, so MP is the way to go12:20
Mirvyay, libmirclient4 too12:22
Mirvand relaunching unity8 build since it failed because of unity-mir transition12:24
vilajibel: 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/19249412:28
jibelvila, you can test, but not in production12:28
vilajibel: lp-propose is weird... is lp:otto/autopilot the right target ?12:28
vilajibel: qa-radeon-7740 is isolated from production right now to diagnose12:29
vilajibel: and so far the issues revealed by otto *had* to be diagnosed in production12:30
vilajibel: and I've already been quite vocal about how bad I think that is :)12:30
Mirvdidrocks: because of the libmirclient bump we'd also need xserver-xorg-xmir update?12:31
didrocksMirv: argh :/12:40
didrocksMirv: right12:40
didrocksSaviq: FYI, we are delayed by this ^12:41
Saviqdidrocks, k12:42
didrocksasac: as well ^12:42
didrocksasac: new bumps (without warning) from the mir team, both client and server and xserver-xorg-xmir then needs an update12:42
didrocksasac: so, work from the morning -> voided12:42
jibelvila, 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
jibelvila, or set TS_BRANCH to a test branch before calling run_otto_job from a jenkins job12:45
vilajibel: thanks, already running from jenkins12:45
jibelvila, or propose a patch to accept a local testsuite directory as well12:46
viladidrocks: 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
didrocksvila: ok, so clearly a Xorg issue12:51
viladidrocks: yes, one more case where a test run breaks the ci infra with no way to guard against :-/12:53
asacdidrocks: client bump?12:55
asacnot good12:55
didrocksvila: indeed12:55
asacdidrocks: see with mir team if they wantt o back out12:55
didrocksasac: 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 ABI12:55
didrocksasac: they pulled, they don't want to rollback without duflu12:55
didrocks(which is in AU timezone)12:55
asacnot sure12:55
asaccant we just revert that part?12:56
asacwe just want to go back to the revision before this happened12:56
didrocksthat would mean push --overwrite12:56
asacdidrocks: not realy12:56
didrocksas they want to keep their branch1 in pull order with branch 212:56
asacrevert commit basically12:56
asacwell, is it really about wishes in this case?12:56
didrocksasac: they overwrote your revert because they want to have this """workflow"""12:56
didrocksI don't want to restart this war12:57
didrocks(basically lp:mir was pushed with --overwrite)12:57
didrocksbecause history was messy from their standpoint12:57
asacthats insant12:57
asacthey pushed overwrite?12:58
asactahts not good12:58
viladidrocks: revert/commit is different from pull --overwrite, the history clearly shows who reverted what12:58
ogra_instantly insane ?12:58
asacdidrocks: can we move on with other parts like apps etc.12:58
vilagrr push --overwrite12:58
asacand just decslare unity etc. blocked because of this until we have discussed and sorted?12:58
didrocksasac: no, apart from emptying the ppa12:58
asacdidrocks: we have a bunch of things that were not build against this, no?12:58
didrockswhich means another 2/3 hours to rebuild everything without mir12:58
asacdidrocks: right. but feels with mir we wont proceed either12:59
didrocksasac: everything was rebuilt and dep on platform-api12:59
didrockswhich pulls it12:59
asacits an uncoordinated client ABI bump12:59
asacwe cant roll that12:59
asacthat would defeat any discussion we did so far12:59
didrocks14:59:07     alan_g | didrocks: ok - let me grab usc12:59
asaci suggest: empy the ppa, stop unity and mire12:59
didrocksasac: on #ubuntu-mir ^12:59
asacthen go with the rest and land those things nicely12:59
asacwho is usc?13:00
asacdidrocks: ok can we proceed like above? its a delay for us, but it is just the consequence we have to endure13:00
didrocksMirv: can you backout mir from the ppa, with platform-api, unity-mir?13:00
didrockswe can't release any of those until mir is coordinated13:00
asacdidrocks: 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
didrocksasac: I don't see kgunn online yet13:01
asacempy ppa, rebuild evrything else13:01
cjwatsonYou know it's possible to forbid push --overwrite on a branch, right?13:01
asacthen do the simple landings all night and morning13:01
asacdidrocks: right. dont need to wait13:01
asacdidrocks: we can post moretem with him13:01
didrockscjwatson: with the append mode only, we did that on some projects, then flamewar started, but we can envision forcing it again right13:01
cjwatsonFair enough13:01
didrocksasac: yeah, just be aware that we are talking about 3h of delay until the first stack is ready to be pushed13:02
Mirvdidrocks: ok, so removing mir and the rebuild platform-api unity-mir against old one?13:03
didrocksMirv: in fact, we can't rebuild platform-api and unity-mir as they build-dep against latest mir13:04
asacdidrocks: i know13:05
asacdidrocks: but thats life. i will send a mail to kgunn etc. explaining that this also delays other landings by half a day13:05
didrocksMirv: ok, so please disable platform-api, unity-mir, and mir13:05
Mirvdidrocks: 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 ppa13:05
didrocks(disable from the config)13:06
didrocksthanks ;)13:06
didrocksasac: FYI ^13:06
asacdidrocks: right. and then lets schedule landings at best by stack so all the leave things and indicators can go in again13:06
didrocksMirv: oh, while we are at it, please move then unity-mir back to unity8 :)13:06
didrocksat least, we'll win that :p13:06
didrocks(speaking of stacks)13:07
Mirvdidrocks: ok13:07
Mirvdone (deployed + packages removed from PPA) - except didrocks please deploy mir because of the lightdm access problem again13:13
didrocksMirv: you didn't change anything in the branches, right? You can deploy with -US13:14
didrocksMirv: to not need access to the branches13:14
Mirvdidrocks: right, I've always used -U. thanks.13:14
Mirvso done13:14
didrocksthanks ;)13:15
viladidrocks: 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 host13:22
viladidrocks: what's the command to do that and what are the pitfalls (set DISPLAY ? something else ?)13:22
viladidrocks: install xx packages13:23
didrocksvila: you can change the autopilot job in /usr/local/bin/ to start autopilot with "autopilot run <list of tests failing>"13:23
viladidrocks: which /usr/local/bin  ?13:24
didrocksvila: the one in the container13:24
viladidrocks: I want to *avoid* the container. the  server needs to be run with valgrind --track-origins=yes --error-limit=no /usr/bin/Xorg :013:25
didrocksvila: not sure then13:25
vilatoo many steps to get that working inside the container13:25
* vila sighs13:26
vilaok, 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 time13:28
viladidrocks: what's the risk to not run those tests on radeon ?13:29
didrocksvila: we won't know if unity7 still runs on radeon hw13:29
didrocksor mir13:29
didrockswhich is pretty bad13:29
didrocksev: asac: do you think someone else can help vila? ^13:29
viladidrocks: given that we don't even know what the cause is we're far from an ETA for the fix13:29
vilaand until there is a fix, you're exposed to regressions13:30
didrocksvila: right, but I don't think we should cut our testing because we don't have the energy…13:30
asacvila: didrocks: hard to say. i dont know where we are stuck.13:31
viladidrocks: it's more about waste of energy than about energy per se, there are just too many unknowns here for me to be efficient13:31
asacour test machine is broken?13:31
didrocksthe radeon one has a xorg segfault when running the tests13:31
vilaasac: some tests triggers a X crash13:31
asacupstream has no radeon to reproduce?13:31
asacwho is actually xorg maintainer?13:32
vilaasac: He didn't say, #ubuntu-desktop13:32
asacwhoever that is should help out13:32
ogra_did you involve tjaalton or mlankhorst yet ?13:32
asacgo for our xorg folks.13:32
vilaogra_: yes, see #ubuntu-desktop, I finally managed to get it to the lab13:33
seb128they just want a valgrind log of the issue since they don't get it locally, what's wrong with that,13:33
vilahe's hacking there right now13:33
vilabut that's only half of the equation13:33
ogra_ah, good then13:34
vilathe 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 run13:34
asacvila: whats the other half? seems like folks are investigating now13:34
asacvila: isnt that part solved for intel etc. machines?13:34
asaccant you spy what they do?13:34
vilaI do13:34
vilacd /etc/X11 ; rm X ;)13:35
vilasounds good13:35
asacso solved? :)13:35
vilawhat 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 there13:36
vilahacking on what is put inside the container is insane13:36
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 packages13:37
vilais where I stopped, I *can* go ahead and lurk and find but this is getting ridiculous, just tell ne13:37
didrockswhat is getting ridiculous?13:38
didrocksvila: I told you how to get the autopilot command runs inside the container?13:38
didrocksoutside, I don't think you can13:38
didrocksthere is no X, nor lightdm installed13:38
didrocksit's a server install13:39
didrocksI don't see what's harder being inside the container though, I told you how to remove the timeout and how to start by hand13:40
didrocksthen, you have a command line inside as you would have outside13:40
vilaright and it took me alsmost 2 hours to get the Xorg.0.log...13:41
viladidrocks: and since the machine has just been rebooted anyway...13:42
didrocksvila: I don't think anyone apart from you and mlankhorst are on the machine13:42
vilaof 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 of13:43
vilaisolation is about involving less pieces13:44
didrocksvila: as long as you reinstall the machine afterwards13:44
viladidrocks: already mentioned in #ubuntu-desktop13:44
didrocksgreat then :)13:45
vilaand now he's blocked on how to run the tests and I still have no answer13:45
vilanot to mention I'm late for the ci standup13:45
didrocksvila: is it all my fault? Can we depassionate this discussion?13:45
didrocksand be professional, thanks13:45
didrocksvila: so, we always run autopilot within inside the session13:46
viladidrocks: never said it was your fault, I'm asking questions which don't get answered, anybody with knowledge that I lack can answer13:46
didrocksI told and showed you how to do it in an autostarted way in the container13:46
didrocksAFAIK, apart from using basic Linux knowledge13:46
didrocksmeaning looking at gnome-session env var13:46
vilaand I said I wanted to avoid that to simplify the diagnosis13:46
didrocksexporting those13:46
didrocksand running "autopilot run <list of tests>13:46
didrocksI don't think, we have an automagic job doing that13:47
vilawill get back to it after the standup13:47
didrocksvila: and yes, I figured that our myself, nobody answered me, so I can be wrong13:47
didrocksjust trying to assess what the others are doing13:47
didrocksand apply to this new case13:48
didrocksogra_: do you think you have bandwith to work on the emulator support right now? (an old landing ask)13:59
ogra_which one13:59
didrocksogra_: can we land that without the hud branch in comment?13:59
didrockslanding ask, line 14314:00
ogra_hmm, not sure thats still needed14:00
ogra_xnox, ^^^14:00
ogra_that merge is clearly the wrong one14:01
xnoxdidrocks: ogra_: if anything w.r.t. emulator is from saucy, it's all obsolete and should be dropped.14:01
ogra_right, thought so14:01
xnoxogra_: i had a recent branch proposal for lxc-container-config (re-prepose)14:01
didrocksok, dropping then14:02
xnoxogra_: 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 updated14:02
xnoxogra_: https://code.launchpad.net/~xnox/ubuntu/trusty/lxc-android-config/add-generic-rules/+merge/19233114:02
ogra_ah, i have seen that one before :)14:03
* ogra_ will update line 14314:03
ogra_or not ... since it is gone14:04
xnoxwell, didrocks just dropped it =)14:04
xnoxogra_: imho i need to upload stuff for the emulator. (a) it's not affecting other images (b) we need it urgently14:05
didrocksxnox: yeah, just file a new one14:05
ogra_xnox, yes, please go ahead with that one14:05
didrockswhen you are read :)14:05
didrocksxnox: and yeah, sounds good14:05
ogra_i'll care for the spreadsheet14:05
didrocksogra_: just write it for tracking14:05
didrocksogra_: I postponed most of the landing to image 614:06
didrocksso that we kick image 5 first14:06
ogra_would be hard to kick image 6 before 5 anyway :P14:07
* didrocks trust ogra_ to make magic!14:10
renato_fginther, all tests passing: https://code.launchpad.net/~renatofilho/ubuntu-ui-toolkit/fix-1236464/+merge/19049614:13
renato_now the only missing problem is jenkins :D14:14
fgintherrenato_, 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 failures14:15
renato_I did not see that, is not related with my mr but I need to ask the SDK guys to look14:16
fgintherrenato_, Ack, This branch now builds/tests with trusty, perhaps that introduced a regression...14:17
fgintherrenato_, just throwing an idea out there14:17
=== elopio_ is now known as elopio
elopiorenato_: fginther: the otto failures are because otto is in autopilot 1.414:58
elopiothe rest jobs are using autopilot 1.3.14:59
elopiodidrocks: do you have some minutes to talk about that ^ ?14:59
didrockselopio: so, if we take trunk for the others components, all will be fine with autopilot 1.4?15:00
elopiodidrocks: no, all will be failing :)15:00
didrocksah, so autopilot 1.4 was pushed to trunk without tests being updated by the QA team?15:01
didrocksok, so I think we're going to remove autopilot 1.4 from the ppa15:01
didrocksblacklist it for now15:01
didrocksand have all projects running with 1.315:01
elopiodidrocks: yes. So what about this:15:01
didrockselopio: they did break backward compatibility? were you informed?15:01
didrocksasac: FYI ^15:02
* sergiusens thought those days were past us now15:02
elopiodidrocks: yes, it's not backwards compatible, and on QA we all knew.15:03
didrockselopio: can I say "sigh" ;)15:04
sergiusenselopio, ack, so you are aware that all the tests need to be migrated in parallel?15:04
didrocksthere are also community core apps15:04
sergiusensI don't think devs are going to be happy doing that when backwards compatibility was requested the last time this was needed15:04
elopioit's a change to throw an exception instead of returning None in case the element we are looking for is not present.15:04
didrockstests done people not at canonical, and not being backward compatible isn't nice15:04
elopiodidrocks: but we are currently working on updating all of them.15:05
didrockselopio: right, but don't push to trunk before it's ready please15:05
didrockselopio: can you revert your trunk to last version in ubuntu15:05
didrocksor last version compatible?15:05
elopiodidrocks: autopilot's trunk?15:05
didrockselopio: yeah15:05
elopioI don't have access to that, that's thomi. But can't you take autopilot 1.3's branch?15:06
sergiusenselopio, can you make ap 1.3 coinstallable with 1.4?15:06
elopiosergiusens: 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
didrockselopio: we want trunk to be in a good state and not changing our configuration for upstream15:07
elopiolet me tell you to see if you agree, or we should change the course of action.15:07
sergiusenselopio, ack, we do coinstalls for most transitions btw15:07
sergiusenssf->mir as an example15:07
elopioso, the first step we were doing was to make the apps -autopilot deb package depend on << 1.315:08
elopiothen, we wanted to ask you to install 1.4 on all the runners.15:08
elopiothat would block all landings until the tests are updated.15:09
elopioso, we update the tests, set the dependency to >= 1.4, and everything would be green again.15:09
didrockselopio: 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 done15:09
elopioI didn't expect otto to be already on 1.4, so the first step was terrible :)15:09
didrockselopio: well, we take trunk15:09
didrocksif trunk ships to something not ready, it's upstream to ensure that it's not merged15:10
elopioyes, I didn't know about that, I suppose thomi didn't either.15:10
didrocksit's the case for more than a year :)15:10
elopioI guess it would not have problems changing trunk to be 1.315:10
didrockselopio: yeah, please do that for now15:10
didrockslp:autopilot pointing to 1.315:10
didrockselopio: then, it's the autopilot package breaking -autopilot debs15:11
elopiodidrocks: I'll tell him as soon as he starts.15:11
didrocksso that one needs to express a Breaks: unity8-autopilot (<< version with the fix>15:11
didrocksand so on15:11
didrockselopio: I can do it if needed15:11
didrockselopio: so changing from ~autopilot/autopilot/trunk to ~autopilot/autopilot/1.3?15:12
elopiodidrocks: well, that's what you suggested. Sounds good for me, I don't know if thomi will have something against that.15:12
elopioI suppose not. And we can always go back if things go wrong, right?15:13
didrockselopio: right15:13
didrockselopio: done, can you sync with him? :)15:13
didrockselopio: then, same, please don't merge anything for 1.4 compatibility on projects15:13
didrocksjust be ready to flip the switch on the same day15:14
didrocksgetting us aware15:14
didrocksand we do the transition in one shot15:14
didrocks(even if I think autopilot should really understands they have to be backward compatible now)15:14
didrockssil2100: I've switch lp:autopilot back to 1.3, can you please rekick an autopilot build for the ppa?15:14
elopiodidrocks: yes, I will discuss with him. But now it's not clear for me how to move forward.15:15
elopiodo you want all the projects to have a branch 1.4 ready at the same time?15:15
didrockselopio: yeah, and we flip the switch for the transition the same day15:16
didrockshaving a landing ask for it15:16
elopiodidrocks: ok, this is blocking me so I think I will spend today updating everywhere.15:16
elopioballoons: ^^15:16
didrockselopio: thanks :)15:17
elopiodidrocks: 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
balloonsok so autopilot stays 1.3 until everything is ready for 1.4, then we'll transition at once, n'est pas?15:17
didrocksballoons: exactement!15:18
didrockselopio: that's fine as well15:19
didrockselopio: but you need to tell you breaks (<< 1.3)15:19
elopiodidrocks: 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
didrockselopio: 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
elopiorenato_: the tests should pass after sil2100 rebuilds the ppa.15:42
fgintherelopio, ack. ping me when that's ready and I'll rebuild the job15:43
didrockssil2100: kenvandine: robru: joining?16:00
didrocksplars: ^16:05
plarsdidrocks: ack, brt16:05
elopiodidrocks, 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
didrockselopio: we just removed it from the ppa, so I think there is an autopilot ppa16:52
didrocksogra_: \o/16:54
=== alan_g is now known as alan_g|EOD
vilabug #124432417:11
ubot5bug 1244324 in glamor-egl (Ubuntu) "glamor-egl crashes when running autopilot tests" [High,Triaged] https://launchpad.net/bugs/124432417:11
ogra_== Build #5 done ===17:43
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
cjohnstonnik90: that doesn't sound like a CI related question19:00
nik90cjohnston: but it is related to app updates landing in the platform?19:00
cjohnstonThat still sounds like a development related question19:02
josephtnik90: fwiw, please use 'cihelp' rather than '@ci'.  The latter was causing us some issues.19:03
josephtcjwatson: do you have any thoughts on nik90's question? ^19:05
fginthernik90, that's a question better suited for #ubuntu-touch19:05
fgintherpopey, do you know the answer to nik90's ? ^19:07
sil2100elopio: ok, it seems the QA stack got stuck because of autopilot-gtk/-qt19:11
nik90fginther: okay. I will also ask on ubuntu-touch19:12
nik90josepht: okay, didnt see the updated channel header. P19:15
elopiosil2100: not sure what that means. Do you need us to help with something?19:29
cjwatsonjosepht: not really, it's not up to me19:32
cjwatsonclick packages only depend on "the system" and that gets updated by system image updates19:32
sil2100elopio: no, but hm, I noticed that Didier retargetted lp:autopilot to lp:autopilot/1.319:33
sil2100elopio: are you guys aware of that?19:34
sil2100I need to do the same for -gtk and -qt then19:35
cjwatsonsergiusens: click-sync seems unhappy19:35
sil2100Anyway, I'll e-mail you guys about that anyway later on19:35
elopiosil2100: we are. We are updating the tests to autopilot 1.4 so we can release 1.4 without breaking anything.19:35
sergiusenscjwatson, yes, I logged on to ask you about that19:36
sil2100elopio: awesome - so I did the same for autopilot-qt and autopilot-gtk, so now trunk series is the same as 1.319:36
sergiusenscjwatson, do you know of any changes going on in the infra? It's a proxy error that I see; wasn't aware of the proxy19:36
elopiosil2100: thank you.19:36
sil2100elopio: once 1.4 is ready, we just need to retarget trunk series again19:36
cjwatsonsergiusens: not that I've heard of19:37
sergiusenselopio, 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 comments19:37
cjwatsonsergiusens: but I have no involvement in the store side19:37
sergiusenscjwatson, I'll talk to beuno; that said it's safe to disable for now19:37
elopiosergiusens: it was there originally when I refactored the code. I didn't see a reason for it so I removed it.19:37
sergiusenselopio, 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 toolkit19:38
elopiothen it started failing on the phones and Mirv pointed out the reason I put on the comment.19:38
cjwatsonsergiusens: I'm about to vanish again and don't really mind the cron mail for now :)19:38
sergiusenscjwatson, ok, if you don't mind; I'm ok with it19:38
cjwatsonwould prefer to leave it enabled so that you can fix by pushing to its branch if necessary ...19:38
sergiusenscjwatson, ack; but to confirm, there's no transparent or real proxy required now, right?19:39
elopiosergiusens: Mirv replied to the email thread.19:40
cjwatsonsergiusens: I don't know19:40
sergiusenselopio, yeah, but I was just talking to steve before; QT_SELECT is set19:41
cjwatsonhonestly don't know enough about the setup to answer that19:41
sergiusenselopio, did it fail when calling from the sdk? or did you always use phablet-test-run; that's the bits I'm missing19:41
sergiusenscjwatson, I'll talk to the backend guys19:41
elopiosergiusens: 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
elopiobut I can make a quick branch to throw to jenkins and see if it's working now.19:44
sergiusenselopio, great, please do; I really think it's not needed19:45
sergiusenscjwatson, if you are still there; can you see if there are any proxy envvars on snakefruit?19:46
sergiusensshouldn't be picked up by the cron though...19:46
elopiosergiusens: https://code.launchpad.net/~elopio/ubuntu-ui-toolkit/launch_qmlscene/+merge/19257619:49
sergiusenselopio, this runs the test out of the box?19:50
sergiusenselopio, if it passes, don't forget to remove the dep on dpkg-dev19:50
elopiosergiusens: 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
sergiusenselopio, if it fails next step is to look at how that runner is setup on jenkins19:51
elopiobut I would confirm with Mirv before.19:51
elopiosergiusens: ack. I'll keep you guys posted on the email thread.19:51
cjwatsonsergiusens: neither in ubuntu-archive's default environment nor in its crontab19:59
sergiusenscjwatson, yeah, just trying to figure out why the resp comes from a squid on localhost:312820:00
sergiusenswhen downloading the actual package20:00
thomisil2100: ping?22:01
sil2100thomi: pong!22:02
thomisil2100: hey man - just wondering if you know why the autopilot trunk series was changes to point to the 1.3 branch?22:02
sil2100thomi: 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 trunk22:03
sil2100thomi: no idea why he didn't just modify cu2d-config instead22:03
thomisil2100: OK. I realise it's not your fault, but it would have been nice if someone told me22:03
sil2100thomi: since when I appeared it was already like that, I decided to do the same temporarily for -qt and -gtk as well...22:03
thomiI'm changing it back now, because it makes it impossible for people to easily get the 1.4 source code22:03
thomiok, I'm changing them all back then :)22:04
sil2100hmmm, oh, ok, so maybe I'll prepare a cu2d-config switch then22:04
thomiif you guys want 1.3 in trusty, I think you ought to change the cu2d config22:04
sil2100thomi: switch back autopilot-qt and -gtk if you have a moment ;)22:04
thomisil2100: I will :)22:05
sil2100thomi: sorry about that, elopio was aware of that it seems (probably didrocks told him)22:05
thomithanks man22:05
thomithat's OK, I found out in the end.22:05
sil2100I didn't know what was the rationale so I decided to keep it until Didier pops up ;D22:05
thomiI'm changing the project maintainer to be the Qa team, so this can't happen again22:05
josephtthomi: the bug I mentioned yesterday turned out to be in pyjunitxml not autopilot.  Patch submitted.22:21
thomijosepht: awesome :)22:42
xnoxIs 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!