| jibel | cjwatson, I declared trusty but I need a cloud image of trusty to build the base testing environment. I'll ping smoser | 05:12 |
|---|---|---|
| jibel | hm, and also update distro-data on all the testing nodes in the lab so they know what is the devel release. | 05:17 |
| jibel | ev, vila ^ could you check that servers in the lab are up to date? | 05:18 |
| jibel | vila, you'll need to upgrade the machines used for destkop testing to trusty and probably the ones running raring to saucy for SRUs or split in 2 pools for raring/saucy otherwise SRUs on raring will have to be done manually | 05:20 |
| jibel | vila, RT65382 | 05:30 |
| vila | jibel: ack, will raise the ticket during the standup and talk with fginther, doanac and plars | 07:00 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-touch/daily-preinstalled/20131021.1/ | 08:09 |
| ogra_ | welcome to trusty ! | 08:09 |
| didrocks | ogra_: \o/ | 08:10 |
| ogra_ | and here is the system image :) http://system-image.ubuntu.com/trusty-proposed/mako/ | 08:10 |
| didrocks | ogra_: how will http://people.canonical.com/~ogra/touch-image-stats/ behave btw? | 08:11 |
| didrocks | if we have a saucy and trusty image rebuild the same day? | 08:11 |
| ogra_ | will be crowded with the next build and fine agaiun with the one after | 08:11 |
| ogra_ | i have to do a special setup for saucy later today | 08:11 |
| didrocks | the version of the ubuntu chroot are different? | 08:11 |
| didrocks | ok | 08:11 |
| ogra_ | the paths all changed with the release | 08:11 |
| ogra_ | you mean for building ? | 08:11 |
| didrocks | no, I think we need to be clear which version is shown | 08:12 |
| ogra_ | yeah it is always the release we build for which we use fro the chroot | 08:12 |
| didrocks | ok, and we'll have a saucy/ dir? | 08:12 |
| ogra_ | we already do | 08:12 |
| ogra_ | http://system-image.ubuntu.com/ | 08:13 |
| * didrocks sees current/ | 08:13 | |
| didrocks | ogra_: I'm speaking of http://people.canonical.com/~ogra/touch-image-stats/ | 08:13 |
| ogra_ | we have saucy and trusty channels | 08:13 |
| ogra_ | yeah, that will get a saucy dir | 08:13 |
| didrocks | great :) | 08:13 |
| cjwatson | jibel: Huh, why can't you bootstrap it off the saucy image? | 08:15 |
| jibel | cjwatson, that's what I did | 08:15 |
| cjwatson | jibel: OK, I still see nothing at https://jenkins.qa.ubuntu.com/view/Trusty/view/AutoPkgTest/ though | 08:16 |
| jibel | cjwatson, autopkgtest for trusty is open, jobs that were queued are running. I'll create the views and file a ticket to do the same on the public instance | 08:17 |
| cjwatson | jibel: OK, I have a feeling proposed-migration lost its records of them so I'm inclined to remove its state and let it all retrigger | 08:18 |
| cjwatson | jibel: There should be a lot more than just mod-gearman listed in excuses and I don't see any records of it collecting any PASSes | 08:19 |
| * cjwatson nukes the state dir | 08:19 | |
| jibel | cjwatson, you should see visp as FAIL and glib2.0 as PASS | 08:19 |
| cjwatson | I do not, but sadly adt-britney loses results sometimes as previously explained | 08:20 |
| jibel | that's the 2 I used for testing | 08:20 |
| cjwatson | I don't trust it :( | 08:20 |
| jibel | cjwatson, :( I'll spend some time on it again this week. | 08:20 |
| cjwatson | Let's see if it does a better job this time round | 08:20 |
| cjwatson | jibel: Do you think you could edit https://wiki.ubuntu.com/NewReleaseCycleProcess to explain what we need to do (or notify somebody to do) when setting up new series? | 08:21 |
| cjwatson | This has become fairly critical infra so we should make sure it's up early | 08:21 |
| jibel | cjwatson, sure, I'll update it. I added a specific document to the prject auto-package-testing too. | 08:23 |
| cjwatson | Thanks | 08:24 |
| cjwatson | Should be a batch of trusty jobs re-running now | 08:24 |
| cjwatson | I'll keep an eye on p-m to try to ensure it doesn't lose them | 08:24 |
| jibel | vila, retoaded I'm creating Trusty All and Autopkgtest views on jiufeng, I'll leave others to you. | 08:29 |
| vila | jibel: please update the ticket you created so we can keep track of what is left to be done (and document the process) | 08:30 |
| jibel | vila, that's different, I'll file another | 08:30 |
| didrocks | vila: joining us? | 08:34 |
| didrocks | ev: ? | 08:34 |
| vila | didrocks: omw | 08:34 |
| vila | didrocks: ev is at the cloud sprint | 08:35 |
| jibel | vila, RT65387 | 08:36 |
| jibel | retoaded, ^ | 08:37 |
| asac | didrocks: vila: so in general i believe nothing should need to be done when we continue staying on devel-proposed ... except creating new jobs to track the OLDRELEASED-proposed | 08:53 |
| asac | that should be our goal... maybe its already like that and we are just struck by lack of phones | 08:53 |
| didrocks | asac: agreed with that goal | 08:53 |
| vila | +1 | 08:53 |
| didrocks | we are far from it, but let's focus on it :) | 08:53 |
| psivaa | didrocks: asac: ogra_: as per the build this morning. the jobs have not run yet. they are only triggered with changes to http://system-image.ubuntu.com/devel-proposed/mako/index.json | 08:54 |
| psivaa | which has not changed yet today | 08:54 |
| asac | psivaa: right. so if we had the channel moved on top ofd trusty-proposed it would have automatically happened | 08:54 |
| ogra_ | psivaa, as i said, thats still saucy | 08:55 |
| asac | psivaa: however, why wasnt build 101 from devel-proposed picked up | 08:55 |
| asac | i assume thats because we have all phones down? | 08:55 |
| ogra_ | because the phones are down ? | 08:55 |
| asac | right. so in theory nothing is wrong : | 08:55 |
| ogra_ | would be my only explanation | 08:55 |
| ogra_ | phablet-flash ubuntu-system --channel trusty-proposed --no-backup -d maguro | 08:56 |
| * ogra_ twiddles thumbs | 08:56 | |
| ogra_ | yay, my first four apps are in the appstore ! | 08:57 |
| psivaa | ogra_: asac: phones are not down there, the jobs have not been triggered yet | 08:57 |
| asac | psivaa: because 101 is too new? | 08:57 |
| asac | psivaa: its 2-3 days old: http://system-image.ubuntu.com/devel-proposed/maguro/ | 08:57 |
| ogra_ | 101 is from friday night iirc | 08:57 |
| didrocks | asac: the jenkins job failed as told | 08:58 |
| psivaa | ohh 101 is from friday? sorry looking at it now | 08:58 |
| ogra_ | the cdimage build ends up in a new dir ... | 08:58 |
| ogra_ | do you use anything from cdimage for the trigger ? | 08:59 |
| ogra_ | http://cdimage.ubuntu.com/ubuntu-touch/saucy/daily-preinstalled/ | 08:59 |
| ogra_ | (note the saucy subdir) | 08:59 |
| asac | afaik they use the index.json to trigger | 09:01 |
| asac | (from system image channels) | 09:01 |
| cjwatson | jibel: I wonder if the causes get lost on FAIL or something | 09:07 |
| cjwatson | jibel: for instance the very most recent run has: | 09:08 |
| cjwatson | lintian 2.5.19ubuntu1 FAIL lintian 2.5.19ubuntu1 | 09:08 |
| cjwatson | jibel: but I don't see lintian mentioned anywhere in excuses, not even as something triggered by another package | 09:08 |
| cjwatson | jibel: (unfortunately I didn't catch this in time to stop p-m so you could investigate in place, but perhaps that's a hint) | 09:09 |
| cjwatson | Though lintian actually first failed in the run starting at 08:37:03 | 09:10 |
| cjwatson | I mean p-m first recorded it as failing then | 09:10 |
| jibel | cjwatson, yes, I noticed that on saucy but couldn't find the cause. I also noticed results on excuses changing from PASS to FAIL without obvious reason. but I didn't find how to recreate the case locally. | 09:14 |
| jibel | cjwatson, I updated https://wiki.ubuntu.com/NewReleaseCycleProcess and added a link to the detailed documentation. | 09:15 |
| cjwatson | Thanks | 09:15 |
| cjwatson | ogra_: Any luck with image 1? | 09:45 |
| psivaa | asac: ogra_: the reason for the smoke tests failing to run 101 is due to regressions in the way we now flash the devices. | 09:45 |
| psivaa | there was a merge to not use utah for this and this is causing the issue | 09:45 |
| ogra_ | cjwatson, havent checked phonecalls yet ... and popey needs to test on mako | 09:45 |
| ogra_ | cjwatson, installs and runs though :) | 09:45 |
| ogra_ | popey, mind testing the trusty-proposed channel on your mako ? | 09:46 |
| psivaa | doanac: ^ would you be able to take a look at this the issue is only in install-and-boot | 09:46 |
| popey | ogra_: ooh, there's a new image? | 09:46 |
| ogra_ | popey, two :) onte trusty and one saucy | 09:47 |
| popey | which one do you want testing? | 09:47 |
| cjwatson | please do the trusty one first as this is blocking opening | 09:47 |
| ogra_ | popey, trusty-proposed please | 09:47 |
| popey | kk | 09:47 |
| ogra_ | just a quick smoketest should do | 09:48 |
| popey | the delay wont be my testing, it will be my current 3g connection | 09:48 |
| === vrruiz_ is now known as rvr | ||
| popey | phablet-flash: error: argument : invalid choice: 'trusty-proposed' (choose from 'cdimage-touch', 'cdimage-legacy', 'ubuntu-system', 'community') | 09:48 |
| popey | oh, typo | 09:48 |
| popey | 2% [> ] 8,183,808 368KB/s eta 8m 13s | 09:49 |
| popey | not bad on the M6 | 09:49 |
| ogra_ | cjwatson, popey, asac, didrocks, trusty is good on maguro | 09:51 |
| asac | ogra_: can you run unity8 ap? | 09:52 |
| asac | :) | 09:52 |
| didrocks | ogra_: sweet! | 09:52 |
| asac | lol | 09:52 |
| asac | ogra_: guess thats still not good on maguro | 09:52 |
| asac | oh we have 101 http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/ | 09:52 |
| asac | install-and-boot isnt happy though | 09:53 |
| asac | http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/mako/101:20131018:20131015/4775/ | 09:53 |
| * asac assumes psivaa and vila are on that | 09:53 | |
| vila | asac: I'm on cu2d for trusty withe didrocks | 09:53 |
| vila | psivaa: ^ you're on it ? | 09:54 |
| psivaa | asac: as i posted above, there was a regression in the way we provision the devices. i will have to revert the changes that doanac made in order to make the jobs proceed | 09:55 |
| * ogra_ notes that the maguro is really to slow for zombie apocalypse | 09:55 | |
| popey | i handed my 100 phone out at a conference over the weekend. took less than 5 mins for someone to crash it | 09:57 |
| ogra_ | yeah, we need to do more long term dogfooding | 09:58 |
| ogra_ | i wrote 11 webapps on the weekend ... | 09:58 |
| ogra_ | running like 5 of them at the same time makes everything go cracy | 09:58 |
| ogra_ | the backgrounded apps never save their state | 09:59 |
| ogra_ | and at times unity seems to get all confused and puts the wrong labels onto the wrong thumbnals etc | 09:59 |
| ogra_ | i had two crashes over the weekend where unity just restarted | 10:00 |
| psivaa | asac: vila: running the jobs now for 101 saucy.. i'll let you know the outcome | 10:02 |
| popey | ogra_: trusty 1 looks good here on mako | 10:20 |
| ogra_ | great | 10:32 |
| ogra_ | cjwatson, go for it then | 10:32 |
| asac | ogra_: successfully ran camera_app on #1 | 10:38 |
| asac | doing webbrowser_app now as well | 10:38 |
| asac | didrocks: ^^ | 10:38 |
| asac | (on maguro) | 10:38 |
| didrocks | great! | 10:38 |
| asac | unity is unfortunately unhappy still, right? | 10:38 |
| didrocks | asac: we'll need an iso though to plug trusty tests on desktpo | 10:38 |
| asac | at least on maguro i would think so | 10:38 |
| didrocks | desktop* | 10:38 |
| asac | didrocks: did the last day regression fix make it in for unity AP? | 10:39 |
| didrocks | cjwatson: I think that will take a while? (trying to find a backup solution) | 10:39 |
| didrocks | asac: they did | 10:39 |
| didrocks | ah | 10:39 |
| didrocks | unity8 | 10:39 |
| didrocks | not 7 | 10:39 |
| didrocks | no, it's not in | 10:39 |
| didrocks | as we didn't do any SRU-related work | 10:39 |
| asac | right. thinking about trusty. assume would come in once we start landing stuff, right? | 10:39 |
| didrocks | asac: there are 3 things to do/ensure: | 10:40 |
| didrocks | - daily-build ppa can build trusty | 10:40 |
| didrocks | - config changed by Mirv | 10:40 |
| didrocks | - otto being able to run tests on trusty (or I need to find a backup solution) -> meaning, an iso available | 10:40 |
| vila | - views updated ob jnekins (may be minor may be scripted already) | 10:41 |
| vila | *on jenkins | 10:41 |
| cjwatson | didrocks: we can probably do you a desktop build | 10:41 |
| asac | didrocks: so we depend on a desktop iso? or server? | 10:41 |
| didrocks | cjwatson: oh, that would be excellent :) | 10:41 |
| didrocks | asac: desktop | 10:41 |
| didrocks | cjwatson: and ppas can build trusty already? | 10:42 |
| cjwatson | didrocks: running | 10:42 |
| didrocks | thanks cjwatson :) | 10:42 |
| cjwatson | didrocks: er I'd have to check | 10:42 |
| didrocks | ok | 10:42 |
| cjwatson | didrocks: you could try it :) | 10:42 |
| didrocks | yeah, let's mess with it :) | 10:42 |
| didrocks | will keep you posted | 10:42 |
| * cjwatson goes to open trusty | 10:42 | |
| cjohnston | asac: are the automated tests already running or are your results from manual testing? | 10:43 |
| cjwatson | (getting coffee first so this is your last opportunity to object) | 10:43 |
| asac | cjohnston: mine are from manual, because the automatic ones seem to not run | 10:44 |
| cjohnston | asac: they don't look to be setup.. let me see if I can figure that out | 10:44 |
| asac | cjohnston: check with psivaa and vila and didrocks if there was something started to fix this already | 10:44 |
| didrocks | cjohnston: enjoy :) | 10:44 |
| asac | cjohnston: so from what i uinderstand touch_mir should be pulling devel-proposed channel | 10:44 |
| asac | cjohnston: that channel wasnt moved over, so we need to wait till stgraber gets up, then our touch_mir jobs should pick the right thing up | 10:45 |
| didrocks | [PPA ubuntu-unity-daily-build] [ubuntu/trusty] bamf 0.5.1+13.10.20131011-0ubuntu1trusty1 (Accepted) -> sounds good :) | 10:45 |
| cjohnston | ok | 10:45 |
| asac | cjohnston: build the build number will go back to 1, so maybe check what happens on dashboard then | 10:45 |
| cjwatson | didrocks: good | 10:45 |
| didrocks | cjwatson: enjoy your coffee :) | 10:46 |
| psivaa | cjohnston: fyi, saucy tests on touch devices are running but we have not set anything up for trusty yet | 10:47 |
| cjohnston | psivaa: cool.. looks like there are still MPs that need to land for trusty tests to work | 10:48 |
| psivaa | cjohnston: yea they are still in the review stage | 10:48 |
| ogra_ | asac, Saviq , unity8 still fails for me, http://paste.ubuntu.com/6276025/ is what i se printed in the unity8 log if the tests try to start | 10:52 |
| Saviq | ogra_, stale socket | 10:52 |
| ogra_ | yeah | 10:52 |
| ogra_ | i thought we had fixed that | 10:52 |
| Saviq | ogra_, no, we amended it | 10:52 |
| ogra_ | the test properly shuts down the shell | 10:52 |
| Saviq | ogra_, but if unity8 crashes - mir never removes the socket | 10:52 |
| Saviq | ogra_, it should only ever happen on unity8 crash now | 10:53 |
| ogra_ | well, thats after a proper shutdown i think | 10:53 |
| * ogra_ reboots again to watch if there is a crash happening | 10:53 | |
| Saviq | ogra_, hmm, can you rm /run/user/32011/mir_socket and clear /var/crash - and see if indeed you get the stale socket without unity8 crashing? | 10:53 |
| Saviq | or that | 10:53 |
| Saviq | ogra_, we should probably clear the socket in pre-start unity8 | 10:54 |
| ogra_ | root@ubuntu-phablet:/# ls /var/crash/ | 10:54 |
| ogra_ | _usr_bin_unity8.32011.crash | 10:54 |
| ogra_ | wow | 10:54 |
| ogra_ | it isnt even on the screen | 10:54 |
| ogra_ | and i cleared the dir when shutting down (without unity running at all) | 10:55 |
| * ogra_ tries that again | 10:55 | |
| Saviq | ogra_, how big is the crash file? | 10:55 |
| Saviq | ogra_, bug #1240866 probably | 10:55 |
| ubot5 | bug 1240866 in Unity 8 "unity8 crashed with SIGSEGV in getenv()" [High,Triaged] https://launchpad.net/bugs/1240866 | 10:55 |
| ogra_ | root@ubuntu-phablet:/# ls -l /var/crash/ | 10:55 |
| ogra_ | total 384 | 10:55 |
| ogra_ | ---------- 1 phablet whoopsie 390128 Oct 21 12:53 _usr_bin_unity8.32011.crash | 10:55 |
| asac | cjohnston: do you know why we see those bogus entries on http://reports.qa.ubuntu.com/smokeng/saucy/ | 10:56 |
| asac | cjohnston: e.g. the ones with just one date rather than normal veresion? | 10:56 |
| cjohnston | means the install failed | 10:56 |
| ogra_ | no crash this time | 10:57 |
| ogra_ | Saviq, so firing up the test definitely creates the crash file | 10:57 |
| ogra_ | seemingly on shutdown of the shell | 10:58 |
| psivaa | cjohnston: asac: i dash_ignore 'd them but since they were from the weekend we need to wait till 1330 UTC to get them removed | 10:58 |
| Saviq | ogra_, yeah, we still have a crash on shutdown indeed | 10:58 |
| asac | cjohnston: looks buggy to me at least :) | 10:58 |
| Saviq | ogra_, or do we... thought we had that fixed | 10:58 |
| asac | psivaa: right. still think the visualization could be at least improved | 10:58 |
| Saviq | ogra_, can you give me your steps? | 10:58 |
| cjohnston | asac: we don't really have a way to guess what the build number should be if we can't get it | 10:58 |
| asac | cjohnston: so those cases we cant download? | 10:59 |
| asac | cjohnston: cant get the index.json? | 10:59 |
| cjohnston | AFAIK that part was fine | 11:00 |
| ogra_ | Saviq, i flash. makes the image writable and run "phablet-test-run -n -p unity8-autopilot unity8" ... once the old shell stops i see the crash file apprear (before it prints that it starts the tests in the other terminal) | 11:00 |
| asac | cjohnston: my understanding is that we are looking at http://system-image.ubuntu.com/trusty-proposed/mako/index.json | 11:00 |
| asac | cjohnston: that one has the version info included | 11:00 |
| cjohnston | I thought we were getting the info from the device | 11:00 |
| Saviq | ogra_, /me does | 11:00 |
| asac | cjohnston: right. maybe we should use that info as well and then even compare those two infos :) | 11:00 |
| asac | as another meta test | 11:01 |
| Saviq | ogra_, did you keep the display lit? | 11:01 |
| cjohnston | ack | 11:01 |
| ogra_ | Saviq, i tried to ... | 11:01 |
| ogra_ | Saviq, it turns off when the shell goes away | 11:01 |
| Saviq | ogra_, you can always go "powerd-cli display on bright" | 11:02 |
| Saviq | ogra_, aah | 11:03 |
| ogra_ | i cant trigger a crash when just stopping and starting unity8 | 11:03 |
| ogra_ | must be the start of the test that causes it | 11:03 |
| Saviq | ogra_, bug #1240801 | 11:04 |
| ubot5 | bug 1240801 in unity8 (Ubuntu) "autopilot unity8 fails with "No GSettings schemas are installed on the system"" [Low,New] https://launchpad.net/bugs/1240801 | 11:04 |
| Saviq | ogra_, that's fixed in unity8 trunk (and only affects testing) | 11:04 |
| cjwatson | ok, trusty is open | 11:04 |
| cjwatson | will be starting autosyncs shortly | 11:04 |
| ogra_ | aha | 11:04 |
| cjwatson | and removing the proposed block shortly as well | 11:04 |
| Saviq | cjwatson, \o/ | 11:04 |
| Saviq | ogra_, export XDG_DATA_DIRS before "autopilot run unity8" | 11:04 |
| Saviq | ogra_, and it will be fine | 11:04 |
| ogra_ | Saviq, oh | 11:04 |
| Saviq | ogra_, XDG_DATA_DIRS=/usr/share autopilot run unity8 | 11:05 |
| ogra_ | phablet@ubuntu-phablet:~$ initctl stop unity8 | 11:06 |
| ogra_ | unity8 stop/waiting | 11:06 |
| ogra_ | phablet@ubuntu-phablet:~$ XDG_DATA_DIRS=/usr/share autopilot run unity8 | 11:06 |
| ogra_ | Loading tests from: /usr/lib/python2.7/dist-packages | 11:06 |
| ogra_ | Tests running... | 11:06 |
| ogra_ | and it doesnt lie :D | 11:06 |
| * ogra_ sees the unity tests on screen | 11:07 | |
| cjwatson | autosyncs starting | 11:13 |
| cjohnston | asac, psivaa they have been removed from the dash | 11:15 |
| didrocks | cjwatson: excellent! | 11:15 |
| ogra_ | asac, Saviq, http://paste.ubuntu.com/6276146/ | 11:16 |
| ogra_ | so unity8 looks pretty good | 11:16 |
| Saviq | ogra_, yeah, just one crash on startup - the getenv one | 11:16 |
| Saviq | ogra_, that test will run if you start it again | 11:17 |
| ogra_ | k | 11:17 |
| asac | ogra_: webbrowser is OK too (37 tests run) | 11:17 |
| asac | zero failure :) | 11:17 |
| asac | ogra_: so where is the udev fix :)? | 11:18 |
| asac | i want systemsettle to stop complaining | 11:18 |
| * ogra_ re-runs to prove the failure goes away | 11:18 | |
| ogra_ | asac, its in 101 | 11:18 |
| asac | ogra_: so should be in 1 too? | 11:18 |
| * asac checks top | 11:18 | |
| Saviq | Ubuntu Touch 101 ;D | 11:18 |
| ogra_ | was in trusty-proposed, i dont think it was in trusty when we built the image | 11:18 |
| asac | ogra_: hmm. 97.8 idle only | 11:18 |
| asac | pulse is going wildish | 11:19 |
| ogra_ | asac, i think it was held | 11:19 |
| asac | oh wait :) | 11:19 |
| asac | lol | 11:19 |
| asac | that was my x220 | 11:19 |
| ogra_ | heh | 11:19 |
| asac | ogra_: we still see systemsettle issues on 101 though: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/gallery-app-autopilot/ | 11:19 |
| asac | ogra_: all are still orange because of that: http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/ | 11:20 |
| asac | pretty busy | 11:20 |
| asac | here is the before run of gallery http://reports.qa.ubuntu.com/smokeng/saucy/touch_mir/maguro/101:20131018:20131015/4776/gallery-app-autopilot/493965/ | 11:20 |
| asac | doesnt hit 97% average | 11:20 |
| asac | ogra_: sure its in 101? build 1 feels quiet | 11:21 |
| ogra_ | asac, right, but no udevd issue it seems | 11:21 |
| ogra_ | looks like top is the biggest consumer in the logs | 11:21 |
| asac | ogra_: ueventd is still there though | 11:22 |
| ogra_ | yes, thats fine | 11:22 |
| asac | ogra_: the first sample always has top | 11:22 |
| ogra_ | ueventd != udevd | 11:23 |
| asac | ogra_: but why would top be so slow all of sudden? | 11:23 |
| asac | we never had this problem before | 11:23 |
| ogra_ | and it is always under 0.5% as i see it | 11:23 |
| ogra_ | dunno, but top consumes >3% | 11:24 |
| asac | right. thats new | 11:24 |
| ogra_ | that keeps us below 97% idle | 11:24 |
| ogra_ | no idea why | 11:24 |
| asac | cjohnston: did you guys ever touch the systemsettle code :)? | 11:24 |
| * asac tries to find it | 11:24 | |
| asac | cjohnston: or the parameters? | 11:24 |
| * ogra_ doubts that | 11:25 | |
| asac | ogra_: well, we see settle consistently failing after boot | 11:25 |
| asac | ogra_: either we have loads more processes | 11:25 |
| asac | or something slows it down | 11:25 |
| ogra_ | do we have crash files ? | 11:25 |
| ogra_ | hmm, no | 11:26 |
| ogra_ | doesnt look liek we do | 11:26 |
| asac | zero crashes so far on 101 | 11:26 |
| ogra_ | right | 11:26 |
| ogra_ | heh, spoke to soon :P | 11:26 |
| ogra_ | mako has one | 11:26 |
| ogra_ | maliit in andressbook-app | 11:27 |
| ogra_ | asac, aha https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-maguro-smoke-friends-app-autopilot/22/artifact/clientlogs/top_before.log/*view*/ | 11:28 |
| asac | ogra_: i think the most interesting part is likely starting from TOP DUMP (after settle run: 1) | 11:28 |
| asac | or even https://jenkins.qa.ubuntu.com/job/saucy-touch_mir-maguro-smoke-friends-app-autopilot/22/artifact/clientlogs/top_before.log/*view*/ | 11:28 |
| asac | err | 11:28 |
| asac | TOP DUMP (after settle run: 3) | 11:28 |
| ogra_ | heh | 11:28 |
| asac | thats a few minutes into the boot | 11:29 |
| asac | so everything should be started by then | 11:29 |
| asac | TOP DUMP (after settle run: 9) | 11:29 |
| asac | thats the last run. whatever makes it fail there is the problem | 11:29 |
| ogra_ | phablet@ubuntu-phablet:~$ XDG_DATA_DIRS=/usr/share autopilot run unity8 | 11:29 |
| ogra_ | Loading tests from: /usr/lib/python2.7/dist-packages | 11:29 |
| ogra_ | Tests running... | 11:29 |
| ogra_ | Ran 22 tests in 549.162s | 11:29 |
| ogra_ | OK | 11:29 |
| asac | unity8 ueventd, adbd | 11:29 |
| ogra_ | yay | 11:30 |
| asac | nice one | 11:30 |
| ogra_ | only on second run though | 11:30 |
| asac | so our current settle limit was 97.5 | 11:30 |
| asac | we now hit like 69.5 reliably | 11:30 |
| asac | on maguro | 11:30 |
| asac | err | 11:30 |
| asac | 96.5 | 11:30 |
| asac | so we only need to explain a 1% boost | 11:30 |
| asac | that could easily be unity8 because of MIR, but i somewhat feel something else is also fishy | 11:31 |
| asac | why is adbd for instance there with 1%? | 11:31 |
| asac | ogra_: seems on SF its also pretty tight | 11:32 |
| asac | http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/100:20131017:20131015/4768/calendar-app-autopilot/492569/ | 11:32 |
| asac | it like succeeeding during the last attempt | 11:32 |
| asac | but that is before the udev fix | 11:32 |
| ogra_ | http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/maguro/100:20131017:20131015/4768/calendar-app-autopilot/ | 11:33 |
| ogra_ | but it succeeded | 11:33 |
| asac | ogra_: yeah, but still very tight/late | 11:34 |
| ogra_ | and SF doesnt trigger udevd to go wiltd | 11:34 |
| ogra_ | thats a Mir issue | 11:34 |
| asac | so anything changing can make us go red | 11:34 |
| * asac doesnt like that we only getting up to 97.5 anyway | 11:34 | |
| asac | ogra_: maybe it is because we use powerd-cli screen-on ? | 11:35 |
| ogra_ | well, top always eats some | 11:35 |
| ogra_ | why would have influence the load ? | 11:35 |
| ogra_ | s/have/that/ | 11:35 |
| asac | ogra_: thats it. i turned the screen on and i suddenly see unity8 coming to the forefront of top | 11:36 |
| ogra_ | sure | 11:36 |
| asac | ogra_: and ueventd | 11:36 |
| ogra_ | has always been like that | 11:36 |
| asac | so thats the reason. if folks turn off the screen before settle,then we are green :) | 11:36 |
| ogra_ | ueventd might be other fallout of the Mir bug | 11:37 |
| asac | cjohnston: doanac: plars: ^^ | 11:37 |
| ogra_ | tvos hass a fix for that afaik | 11:37 |
| ogra_ | *tvoss | 11:37 |
| asac | ogra_: so the fact that unity8 starts consuming cycles when you turn screen on is considered a bug? | 11:37 |
| ogra_ | no | 11:37 |
| ogra_ | it has to refresh | 11:37 |
| ogra_ | the bug is that the driver under Mir spams uevents | 11:37 |
| ogra_ | that keeps traffic up in varioud places | 11:38 |
| asac | i right | 11:38 |
| asac | ack | 11:38 |
| ogra_ | not all of them can be seen | 11:38 |
| ogra_ | udevd was only one fallout | 11:38 |
| asac | ogra_: so you say there is still some noice now in ueventd that we fixed udev? | 11:38 |
| asac | ogra_: can we maybe also filter there smartly? | 11:38 |
| asac | noise | 11:38 |
| ogra_ | thimas has a possible fix that only makes the uevent spam apper when there is actual interaction | 11:38 |
| ogra_ | *thomas | 11:38 |
| ogra_ | instead of having a constant stream of 60 events per sec | 11:39 |
| asac | ok, but we can't minimize the impact on the ueventd process during a spam/attac,k on top of that? | 11:39 |
| asac | rigt | 11:39 |
| asac | i understand i think. | 11:39 |
| ogra_ | we need to kill the spam like SF does | 11:39 |
| asac | oki | 11:39 |
| ogra_ | then it should work as fast as SF and your processes shouldnt misbeahve anymore | 11:39 |
| asac | well, that would mean that its a bug and we might want to continue keeping it visible on dashboard | 11:39 |
| asac | until we have fixed maguro | 11:39 |
| ogra_ | i uploaded some HTML5 games to the shop over the weekend, zombie attach is a highly demanding game that makes a good performan.ce test | 11:40 |
| ogra_ | *zombie apocalypse | 11:40 |
| * asac installs it | 11:41 | |
| * asac always has to setup ubuntu one account | 11:41 | |
| asac | odd | 11:41 |
| ogra_ | once for shop access | 11:42 |
| * ogra_ never has to do it more than once | 11:42 | |
| ogra_ | that game runs on the edge on mako ... (runs super smooth on android btw) ... on mako it is just close to be unusable | 11:43 |
| ogra_ | on maguro i get all actions with a long delay | 11:43 |
| ogra_ | i.e. non usable at all | 11:44 |
| asac | ogra_: does it work well on android maguro? | 11:44 |
| asac | i tried it now on maguro and yes its not usable ) | 11:45 |
| ogra_ | no idea, it works well on my S4 | 11:45 |
| asac | :P | 11:45 |
| ogra_ | i have never run android on a maguro :P | 11:45 |
| ogra_ | it definitely shows we need to improve the browser performance for such stuff | 11:45 |
| ogra_ | having something like this game run smooth by trusty release might be a nice goal :) | 11:46 |
| ogra_ | (on maguro) | 11:46 |
| === alan_g is now known as alan_g|lunch | ||
| === psivaa is now known as psivaa-lunch | ||
| cjohnston | asac: I honestly have no idea about any changes to systemsettle | 12:37 |
| asac | cjohnston: all good. i think we found it | 12:41 |
| asac | plars: doanac: cjohnston: we need to not enable the screen while running it | 12:41 |
| === psivaa-lunch is now known as psivaa | ||
| asac | (systemsettle) | 12:41 |
| asac | plars: doanac: cjohnston: or rather use powerd-cli to have it off i guess | 12:41 |
| asac | systemsettle test itself should do the right thing there | 12:41 |
| plars | asac: iirc, before we added the powerd-cli display on, more things were failing | 12:45 |
| plars | asac: so just turning the display on is causing unity8 to eat cpu? | 12:46 |
| sergiusens | @ci share-app hasn't been part of the product for a while, it's tests should probably be disabled since it's installing things that can skew the test results for other components by installing abandoned/obsolete deps | 12:48 |
| === alan_g|lunch is now known as alan_g | ||
| asac | plars: its only about systemsettle | 12:54 |
| cjohnston | sergiusens: in the daily image testing? | 12:54 |
| asac | plars: that testcase itself should ensure that screen is turned off | 12:54 |
| asac | plars: every other testcase should senusre that screen is turned on and unlocked | 12:54 |
| sergiusens | cjohnston, yup | 12:54 |
| asac | e.g. its a testcase thing and systemsettle shoudl ensure we do the right thing for it | 12:55 |
| cjohnston | plars: ^ | 12:55 |
| plars | asac: the problem is, doanac found that if we don't turn the display on at the beginning, before system settle comes on, then it might not come on and tests had issues later | 12:55 |
| asac | plars: lets talk to doanac | 12:55 |
| asac | plars: turn it off | 12:55 |
| asac | turn it on after | 12:55 |
| asac | i dont think that should cause harm, but lets see | 12:55 |
| plars | sergiusens, cjohnston: ack, I'll disable share-app. It's not coming back later or anything is it? | 12:55 |
| sergiusens | plars, it's an ubuntu ui toolkit component since beginning of september | 12:56 |
| plars | sergiusens: that's what I thought, ok I'll remove it completely then | 12:56 |
| fginther | morning | 13:00 |
| === Ursinha is now known as Ursinha-afk | ||
| === Ursinha-afk is now known as Ursinha | ||
| Mirv | didrocks: ok, now ~everything is split to /saucy branches with updated Bzr-Vcs url:s for those, see doc | 13:26 |
| Mirv | I'll prepare a quick cu2d change proposal, but I'll leave it to you (for today) otherwise | 13:26 |
| didrocks | Mirv: great! the cu2d config is ready as well? | 13:26 |
| didrocks | Mirv: maybe you'll need to get in sync with fginther | 13:26 |
| fginther | didrocks, Mirv morning | 13:27 |
| didrocks | hey fginther ;) | 13:27 |
| Mirv | morning fginther | 13:30 |
| Mirv | fginther: didrocks: https://code.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/saucy_transition_misc_unity/+merge/191989 - that's a start at least, you can also modify the commit since it's under common LP username | 13:31 |
| Mirv | it covers those projects I created a /saucy for today, but not sil2100's ones that are still missing (I haven't gone through those) | 13:32 |
| didrocks | Mirv: ok great, maybe fginther, as having worked with sil2100 the other day has the othe part | 13:32 |
| cjwatson | didrocks: there are desktop images in pending, btw | 13:33 |
| didrocks | cjwatson: excellent, thanks for the head's up. I'll start trying to fetch it as soon as I can | 13:36 |
| cjwatson | didrocks: they're stuck in pending because the Windows executables on there are broken, but I expect you don't care | 13:36 |
| cjwatson | (well, s/broken/missing/) | 13:36 |
| cjwatson | didrocks: it's possible they may not work in other ways, though, as we haven't updated the installer for saucy yet | 13:37 |
| didrocks | cjwatson: I hope/try to fetch it from otto, at least, we have a base :) | 13:37 |
| cjwatson | otto? | 13:38 |
| asac | doanac: didrocks: don't wait for me. let's chat a few minutes after the meeting, i will reset the whole thing now and maybe come in after | 13:40 |
| didrocks | lp:otto, the tool we use to do desktop tests | 13:40 |
| didrocks | saucy sounds like quality for asac :p | 13:40 |
| ogra_ | runs fine on my phone | 13:41 |
| ogra_ | :P | 13:41 |
| didrocks | ahah | 13:41 |
| asac | doanac: i think NM/wpa sometimes act up and dont connect to the strongest AP here... not sure if its a threshold thing or not | 13:44 |
| asac | didrocks: ^^ | 13:44 |
| asac | (sorry, typo) | 13:44 |
| jibel | retoaded, could you add trusty to the default view too on https://jenkins.qa.ubuntu.com/ ? | 13:44 |
| retoaded | jibel, sure | 13:45 |
| didrocks | asac: oh, that would be something for cyphermox I guess | 13:45 |
| retoaded | jibel, done | 13:46 |
| jibel | retoaded, and you can remove oneiric | 13:46 |
| retoaded | jibel, ack | 13:46 |
| jibel | retoaded, thanks | 13:47 |
| retoaded | jibel, hmmmm, that seems to have broken the view | 13:47 |
| jibel | retoaded, java.lang.StackOverflowError awesome. | 13:48 |
| jibel | :( | 13:48 |
| retoaded | jibel, and I don't even have the option to delete it so I can recreate it | 13:48 |
| retoaded | hmmm, and I can re-create Oneiric since jenkins thinks it already exists (but doesn't show) | 13:52 |
| jibel | from the error I'd say it tries to access a view that it thinks exists but actually doesn't and falls in a infinite loop | 13:53 |
| retoaded | jibel, ack. got it straightened out. | 13:54 |
| jibel | retoaded, good, thanks. | 13:55 |
| retoaded | jibel, changed the default view to something else, went back into Releases, removed Oneiric (again) and it worked this time. Reset default view back to Releases. | 13:55 |
| jibel | add a note for next time you have to remove a release from that list | 13:55 |
| cyphermox | asac: do you mean on initial connection? | 13:59 |
| didrocks | retoaded: http://10.97.0.1/iso/trusty/ is grabbing pending apparently, right? | 14:03 |
| retoaded | didrocks, yes | 14:04 |
| didrocks | excellent, thanks for confirming! | 14:04 |
| asac | cyphermox: no its after a few days and suspend/resumes | 14:05 |
| asac | cyphermox: i have a repeater very close and my main router far away, but you can still see my main router here | 14:05 |
| asac | cyphermox: seems that after a few of those suspend/resumes, NM or wpa prefers the "main router" and my inet etc. goes flaki | 14:06 |
| cyphermox | we,, it's possible you can see it, but have you compared the BSSIDs to make sure which one was conected to? | 14:06 |
| cyphermox | ok | 14:06 |
| asac | yeah | 14:06 |
| asac | i see that i am connected against the wrong one | 14:06 |
| cyphermox | there's a patch I'll upload soon that changes the threshold, perhaps that will help | 14:06 |
| asac | cyphermox: so i tried using NM UI to force the BSSID close by, but seems that doesnt prevent NM to still roa mto the other | 14:06 |
| asac | feels very weird how you as a user can "force" (gues its not a real force" for BSSID | 14:07 |
| asac | cyphermox: oh there is a threshold? let me know when its there, i am happy to test | 14:07 |
| asac | hehe | 14:07 |
| cyphermox | no, it's meant to be that way -- if you specify it, it will not roam and use the BSSID you provided | 14:07 |
| cyphermox | in some cases it's quite useful | 14:07 |
| alan_g | fginther: remember setting up CI for the mir/development-branch? I just noticed that it doesn't build for armhf like lp:mir does. Was that intentional? | 14:08 |
| fginther | alan_g, no that was not intentional, If I remember right, the armhf build was added to lp:mir after the development branch job was setup. We just didn't remember to modify both branch configurations. | 14:10 |
| fginther | alan_g, that should be fixed now | 14:10 |
| alan_g | fginther: thanks. (I thought armhf had been around a lot longer. But fixed is fixed) | 14:11 |
| cjwatson | armhf in general predates mir but PPAs don't build for armhf by default and I think the mir PPA initially didn't | 14:14 |
| * alan_g meant the mir armhf build | 14:15 | |
| didrocks | http://10.97.0.1:8080/job/autopilot-trusty-setup_otto/label=qa-intel-4000/1/console | 14:20 |
| didrocks | vila: fginther ^ | 14:20 |
| didrocks | 2013-10-21 14:19:27,634 ERROR An error during creation occurred, trying to cleanup the container: The container didn't stop successfully | 14:20 |
| === alan_g is now known as alan_g|lunch | ||
| === alan_g|lunch is now known as alan_g|tea | ||
| fginther | kgunn, are you familiar with the mir branch changes that duflu is proposing? I have some questions about it | 14:44 |
| kgunn | fginther: i read thru it about an hour ago....shoot | 14:46 |
| * kgunn grabbing coffee & a fleece back in a moment | 14:46 | |
| fginther | kgunn, will any future changes be directly proposed to lp:mir, or will all the changes go into the development branch and that is merged into lp:mir when it's ready? | 14:47 |
| === alan_g|tea is now known as alan_g | ||
| kgunn | fginther: and i understand it..i think the idea is to stage everything on the development-branch...and then using a pull | 14:52 |
| kgunn | fginther: rather than a merge to get the history | 14:52 |
| fginther | kgunn, right. I'm trying to scope the amount of work needed here as a pull is not something that our tools currently support. | 14:54 |
| kgunn | fginther: its kind of interesting....i think if we every go to a truly feature development type dev environ | 14:55 |
| fginther | kgunn, It would help if I knew if we need to support other branches merging into lp:mir, or if we can lock this down to just the development branch | 14:55 |
| kgunn | that's actually what would be needed | 14:55 |
| kgunn | fginther: i'm totally ok with locking it down | 14:56 |
| kgunn | fginther: mmmm....let me backpeddal one mire | 14:56 |
| kgunn | minute rather | 14:56 |
| fginther | kgunn, I'm also not familar with all that pull is doing, so need to do a little research on my own | 14:57 |
| kgunn | fginther: i could foresee the potential need for speed, that someone might want to push to both | 14:57 |
| kgunn | fginther: altho...that would be a merge | 14:57 |
| fginther | kgunn, so other groups have proposed the trunk + feature branch development environment, but this is the first time pull has come up rather then merge | 14:57 |
| kgunn | fginther: right....i think this is all about the history of the branch being merged.... | 14:58 |
| kgunn | fginther: and i don't understand it myself....but i think this is the problem with not having downstream able to pull from something other than "trunk" | 14:59 |
| asac | didrocks: doanac: cjohnston: so what was the outcome of bringing up trusty on dashboard etc.? | 15:04 |
| doanac | asac: we are trying to get them going today. | 15:04 |
| doanac | i have 3 MPs out that the team is reviewing | 15:05 |
| asac | doanac: ok cool. sounds goodie. would love to declare "happy development" to the UE team after seeing results | 15:05 |
| didrocks | asac: ogra_: plars: robru: psivaa: cyphermox: I guess there is no need for this afternoon landing team syncing up. Let's do it tomorrow morning, we're almost there! | 15:38 |
| ogra_ | didrocks, ++ | 15:39 |
| plars | doanac: ack | 15:40 |
| psivaa | didrocks: ack | 15:47 |
| asac | didrocks: oki ... was just wondering while i was on there :) | 16:02 |
| didrocks | asac: ahah, sorry ;) | 16:03 |
| lool | Hey folks | 16:09 |
| lool | I see there's a new trusty-proposed channel | 16:09 |
| lool | with an image | 16:09 |
| lool | but it's not in devel-proposed | 16:09 |
| lool | is that intentional? | 16:09 |
| lool | after chatting with stgraber, he intends to update both devel-proposed and devel once the first trusty-proposed image is promoted to trusty | 16:29 |
| ogra_ | lool, yes, thats what we discussed a while ago | 16:31 |
| didrocks | ok, time for my daily run before it's night | 16:31 |
| * didrocks waves good evening | 16:31 | |
| ogra_ | ciao | 16:32 |
| === mdeslaur is now known as chuck_ | ||
| === chuck_ is now known as mdeslaur | ||
| === alan_g is now known as alan_g|EOD | ||
| plars | doanac: I just witnessed something that could cause us trouble | 17:08 |
| doanac | plars: i'm killing the jobs now. its too much to follow | 17:08 |
| doanac | and i found a small bug in free the devices | 17:09 |
| plars | ogra_: I was running the latest devel-proposed which I just installed locall, and connected to it with adb. Then mtp connected and as soon as the window popped up for it, adb disconnected. | 17:09 |
| plars | doanac: ^ | 17:09 |
| doanac | ah - that's bad. I think josepht has seen something like that also | 17:10 |
| plars | ogra_: I was able to reconnect just fine, but losing that connection at some points in the install/setup process could produce inconsistent results | 17:10 |
| ogra_ | plars, yes, known | 17:15 |
| ogra_ | (and we discussed it plenty of times already i think) | 17:15 |
| plars | ogra_: is there something we can do on our side to prevent that from happening? | 17:15 |
| ogra_ | the gadget device gets reset if its options change | 17:15 |
| ogra_ | yes, rework the whole sh*t | 17:16 |
| ogra_ | :) | 17:16 |
| plars | ogra_: heh | 17:16 |
| doanac | can we disable MTP on our host so it doesn't happen? | 17:16 |
| ogra_ | plars, sergiusens was looking into setting persistent properties, once we can do that we should be able to not touch the settings of the device during boot | 17:16 |
| doanac | ah - i guess not | 17:17 |
| ogra_ | doanac, no, once you change the settings of the gadget device on the phone it reconnects | 17:17 |
| ogra_ | not related ot the host side | 17:17 |
| doanac | it weird its suddenly gotten worse. but I maybe we've just been lucky up till now | 17:18 |
| ogra_ | so instead of changing the props dunamically every boot, we should use a persistent setting that onlt changes on demand (and keeps this setting over reboots) | 17:18 |
| doanac | plars: i've got to step away for a bit. I fixed a small bug in the master job. | 17:19 |
| doanac | and i'm letting the touch_sf4p run on maguro | 17:20 |
| doanac | http://10.97.0.1:8080/job/trusty-touch_sf4p-maguro-smoke-master/1/ | 17:20 |
| plars | ok | 17:20 |
| === psivaa is now known as psivaa-afk | ||
| doanac | plars: there's a bug in the unity8 tests. running "autopilot list unity8" shows a problem with unity8-autopilot/shell/tests/test_notifications.py", line 29, in <module>' | 17:56 |
| plars | doanac: that's happened several times before - something the unity8 team will have to fix | 17:57 |
| doanac | looks like we need to add python's "gi" repository | 17:57 |
| doanac | for now | 17:57 |
| plars | doanac: oh | 17:57 |
| plars | doanac: actually | 17:57 |
| plars | doanac: I looked at something with that late last week | 17:57 |
| plars | doanac: it looked like the latest phablet-tools installs gi in the autopilot dir from bzr when you run phablet-click-test-setup | 17:58 |
| plars | doanac: but the version it installs causes issues | 17:58 |
| plars | sergiusens: have you seen anything up with that? ^ | 17:58 |
| doanac | plars: that's it. i just deleted the copy phablet-click-setup created and it works | 17:59 |
| plars | doanac: iirc one of the tests is already installing the python-gi package | 17:59 |
| doanac | hmm - i had to install just now, not sure | 18:00 |
| plars | doanac: it's easy enough for us to force it to install, but if it's required then it seems odd that just the tests would require it | 18:00 |
| plars | doanac: just the unity8 tests I mean | 18:01 |
| doanac | plars: i don't think thats enough. the "gi" library under /home/phablet/autopilot/gi will take precedence | 18:01 |
| doanac | so we have to fix this in phablet-tools | 18:01 |
| plars | doanac: I know | 18:02 |
| doanac | sorry mis-read | 18:02 |
| plars | doanac: I'm just wondering if it's a package that should be there in the image | 18:02 |
| doanac | true. | 18:02 |
| doanac | a weird dep for just the test to need | 18:02 |
| doanac | the version phablet-tools grabs says its the same as i just installed. maybe the .deb extraction is messing something up | 18:04 |
| sergiusens | doanac, let me check; in any case I added that for veebers | 18:05 |
| doanac | sergiusens: here's the backtrace i just got: | 18:06 |
| doanac | Traceback (most recent call last): | 18:06 |
| doanac | File "<stdin>", line 1, in <module> | 18:06 |
| doanac | File "gi/__init__.py", line 27, in <module> | 18:06 |
| doanac | from ._gi import _API | 18:06 |
| doanac | ImportError: could not import gobject (error was: 'cannot import name _gobject') | 18:06 |
| doanac | i just did a python shell with: from gi.repository import Notify | 18:06 |
| sergiusens | doanac, let me wrap up this bug fix and I'll get to it | 18:07 |
| plars | doanac: sergiusens: could it be that phablet-click-test-setup misses the .so files in python-gi? | 18:08 |
| sergiusens | plars, most likely; which tests use python-gi now? | 18:08 |
| plars | sergiusens: unity8 for sure, possibly others | 18:09 |
| doanac | that's what it is | 18:09 |
| doanac | i just verified | 18:09 |
| plars | doanac: ack | 18:09 |
| sergiusens | doanac, if it's just unity8, let's just remove it from there | 18:10 |
| doanac | sergiusens: remove python-gi from phablet-click-setup? | 18:11 |
| sergiusens | doanac, yes | 18:11 |
| doanac | sergiusens: ack - i'll submit an MP. | 18:11 |
| doanac | plars: you want to merge python-gi into our new apconfig.py file for unity8? | 18:12 |
| plars | doanac: sure | 18:12 |
| plars | doanac: we'll just need to make sure we update phablet-tools, it won't work until we have that fix in there also | 18:13 |
| plars | doanac: we could hand-patch on phoenix for now I suppose | 18:13 |
| doanac | plars: while you are in there: 'python-mock', 'python-dateutil' are already in phablet-click-setup so we don't need those anymore | 18:13 |
| plars | doanac: ack | 18:13 |
| doanac | plars: i think we probably need to change our touch test to take an option phablet-tools branch | 18:13 |
| doanac | i think we are too reliant on it now assume what's in the distro will handle everything | 18:14 |
| sergiusens | doanac, I've been wanting it to be sort of hand copied into a ppa you control | 18:15 |
| doanac | plars, sergiusens: actually since we use a PPA for precise. the changes land there pretty fast :) | 18:17 |
| plars | doanac: sergiusens: we could make a recipe for it and just request a build for our ppa whenever we want | 18:18 |
| fginther | rsalveti, ping | 18:18 |
| doanac | sergiusens, plars: https://code.launchpad.net/~doanac/phablet-tools/click-python-gi/+merge/192031 | 18:18 |
| rsalveti | fginther: pong | 18:19 |
| fginther | rsalveti, we have a job hanging around for the qt51 build experiment. Is any of that still needed? | 18:19 |
| fginther | rsalveti, http://10.97.0.26:8080/job/ubuntu-touch-image-saucy-qt51/ | 18:19 |
| plars | doanac: and https://code.launchpad.net/~pwlars/ubuntu-test-cases/pkg-changes/+merge/192033 | 18:19 |
| rsalveti | fginther: no, that's saucy specific, so let's just disable it for now | 18:19 |
| rsalveti | and we'll probably try to migrate to 5.2 in a few weeks instead | 18:20 |
| fginther | rsalveti, somehow it created a massive file: "140737486266368 Oct 21 18:15 kcore" | 18:20 |
| doanac | plars: +1 thanks | 18:20 |
| plars | doanac: looks good to me, but I can't topapprove it | 18:20 |
| sergiusens | plars, doanac done | 18:21 |
| doanac | plars: oops - we also need to update the utah test entry for unity8 | 18:22 |
| plars | doanac: oh, right | 18:23 |
| plars | doanac: one sec | 18:23 |
| plars | doanac: I update phoenix also | 18:23 |
| plars | doanac: phablet-click-test-setup on phoenix that is | 18:23 |
| doanac | plars: just the "/usr/bin/phablet-click-test-setup"? | 18:23 |
| plars | doanac: yes | 18:24 |
| doanac | k. i've updated phablet-config on phoenix :) | 18:24 |
| doanac | we need to keep track of this - or use a proper branch. | 18:24 |
| doanac | i'll get an MP for that soon | 18:24 |
| plars | doanac: wait, what needs updating in the utah test? it installs unity8-autopilot which should already depend on python-gi right? | 18:24 |
| doanac | it doesn't | 18:24 |
| doanac | well - let me check. | 18:25 |
| doanac | n/m | 18:25 |
| doanac | plars: ^^^ - we are good to go | 18:25 |
| rsalveti | fginther: hahah, wtf | 18:27 |
| plars | fginther: impressive! | 18:30 |
| === gatox is now known as gatox_lunch | ||
| === Ursinha is now known as Ursinha-afk | ||
| sergiusens | fginther, do we have devices for core apps? | 18:43 |
| fginther | sergiusens, nope | 18:44 |
| sergiusens | fginther, would be good to run the click tests instead of deb package ones | 18:44 |
| fginther | sergiusens, agreed, I need to inquire about running these on our internal jenkins. Not sure if the split is still required | 18:45 |
| sergiusens | fginther, that would be awesome; well at least we can start looking into building them | 18:46 |
| === Ursinha-afk is now known as Ursinha | ||
| plars | sergiusens: I'm uploading a recipe for phablet-tools to build off trunk and just use {debversion}-bzr+{revno}. Any preference what I call the recipe? | 18:57 |
| === seb128_ is now known as seb128 | ||
| plars | sergiusens: that way we can just build in a ppa for us to pull, but would probably be useful to others as well for testing new phablet-tools etc | 18:57 |
| sergiusens | plars, call it what you wish; only thing is that the tests don't run on precise | 18:59 |
| sergiusens | plars, also, why not just rely on the daily release stuff? | 18:59 |
| plars | sergiusens: because it takes a while to get through that - especially if it's in manual mode as with the problem we had a while back | 19:00 |
| sergiusens | plars, manual mode, still? | 19:00 |
| plars | sergiusens: you don't think that would ever happen again? | 19:01 |
| plars | sergiusens: we were just talking about this a bit ago, having a ppa for ci to use for things like this, which we could control when we build for it and what we put there | 19:01 |
| sergiusens | plars, the concept of daily release came up (I've been told) because the recipe system wasn't enough | 19:01 |
| sergiusens | plars, if people start using recipe builds it sort of beats the purpose; I feel we are just circumventing a problem here | 19:02 |
| plars | sergiusens: this is not for official builds, this is just so that image smoke testing can update phablet-tools quickly as needed for things that need to be fixed quickly to keep ci from slowing down | 19:02 |
| sergiusens | plars, ack, feel free to create it | 19:03 |
| === gatox_lunch is now known as gatox | ||
| plars | asac: is there really any difference between what's in the saucy build vs the trusty build? | 19:27 |
| plars | right now that is? | 19:27 |
| jdstrand | lool: hey, are we supposed to be asking for permission to upload now? if so, may I upload this simple update: http://paste.ubuntu.com/6279220/ | 20:41 |
| cjwatson | jdstrand: lool is on vacation | 20:43 |
| fginther | plars, we have a way to automatically dput new phablet-tools packages to a ppa on each commit to trunk | 20:46 |
| fginther | plars, the advantage is that the dput occurs as soon as the commit to trunk is made instead of waiting for the recipe to daily build | 20:48 |
| jdstrand | cjwatson: thanks | 20:52 |
| jdstrand | asac: ^ | 20:52 |
| jdstrand | lool: nm | 20:54 |
| * lool whistles | 20:56 | |
| lool | jdstrand: truth is I'm not sure what you need right now :-) | 20:56 |
| lool | but I guess safe uploads to trusty with heads up to landing team would be ok | 20:57 |
| jdstrand | yeah, it isn't clear yet. I'll wait for asac | 20:58 |
| jdstrand | lool: thanks! and you should be vacationing now :) | 20:58 |
| * lool & | 20:58 | |
| jdstrand | :) | 20:58 |
| === ev changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: - Type: "cihelp" for help | Britney is set to block all uploads, use lp:~ubuntu-touch-release/britney/hints-ubuntu-touch to override | Known issues: - | ||
| plars | ev: :) | 21:29 |
| ev | :-P | 21:29 |
| plars | ev: stupid irc clients | 21:29 |
| ev | I'm not a fan of the entire protocol. | 21:29 |
| ev | that reminds me, I need to sign up for an irccloud account to make it someone else's problem | 21:29 |
| asac | doanac: cjohnston: how is the trusty bring up going? | 23:13 |
| asac | ev: ? | 23:13 |
| doanac | asac: we have jobs configured but they are buggy. i think i just fixed the issue. | 23:14 |
| doanac | i'm running a local test right now | 23:14 |
| doanac | moving the powerd-cli call around was causing an adb-shell call to hang | 23:14 |
| sergiusens | doanac, hey | 23:21 |
| sergiusens | doanac, was just testing the edge intro thing; you can probbaly remove the reboot completely as it's not needed at all | 23:22 |
| sergiusens | doanac, as soon as you change the config, it gets out of your way | 23:22 |
| doanac | sergiusens: ah - that's even better! | 23:22 |
| doanac | i'll update the MP | 23:23 |
| sergiusens | doanac, ah, thought you might of left; I copy/pasted to the mp | 23:23 |
| doanac | sergiusens: cool. i'm about to eat, but will address tonight. | 23:23 |
| doanac | thanks | 23:23 |
| sergiusens | doanac, yeah, just enabled/disabled a couple of times without reboot, saw it come and go | 23:24 |
| sergiusens | so it's good to avoid the reboot :-) | 23:24 |
| doanac | yep. that increases our odds of having a good test run :) | 23:24 |
| asac | doanac: moving powercli around -> for systemsettle? | 23:27 |
| asac | doanac: i think only screen on we dont want | 23:28 |
| asac | the rest isnt really hurting us (not sure what else you run) | 23:28 |
| doanac | asac: if you don't call powerd-cli the screen won't come on (even if you call unlock_screen) and the tests fail | 23:29 |
| asac | doanac: right. thats for the AP tests | 23:29 |
| doanac | so we moved it to just before the test | 23:29 |
| asac | doanac: for systemsettle we dont want it on | 23:29 |
| asac | right | 23:29 |
| doanac | note: system-settle still looks bad | 23:29 |
| asac | doanac: is the screen off? | 23:29 |
| asac | sure? | 23:29 |
| doanac | the screen is in the process of getting there. we call system-settle shortly after booting. so its timing dependent what state the screen is in | 23:30 |
| asac | doanac: how long would the screen stay on before automatically going off? | 23:30 |
| doanac | asac: not sure. i think its a powerd setting | 23:31 |
| asac | doanac: are we still use powerd-cli active ? | 23:33 |
| asac | doanac: thats what we surely shoud call right after boot | 23:33 |
| asac | then each test calls either on or off etc. | 23:33 |
| asac | depending on what it needs | 23:33 |
| doanac | asac: I'm trying a fix that calls active and display-on right before we run unlock_screen | 23:34 |
| doanac | i'm seeing it doesn't need to happen right after boot | 23:34 |
| doanac | and then that keeps system-settle from being altered | 23:34 |
| asac | doanac: ok ... i wont hold you back. i believe getting a trusty build is more important than solving systemsettle though - in case that helps somewhat | 23:35 |
| doanac | helps a bit. I'm hoping for the best of both worlds with my patch though. | 23:36 |
| doanac | its looking good at home so far | 23:36 |
| asac | cool | 23:36 |
| * asac crosses fingers | 23:36 | |
| doanac | asac: if plars is on later tonight, we have a good shot at merging the fix and being ready to test tomorrows image | 23:37 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!