[01:15] <robru> sergiusens, sure
[01:15] <robru> kgunn, oh ok
[01:16] <robru> kgunn, ok you got silo 5
[01:16] <robru> sergiusens, you got silo 10
[01:19] <sergiusens> thanks
[01:19] <sergiusens> tools always get 10
[01:19] <robru> hehe, luck of the draw!
[01:21] <kgunn> robru: thank you sir
[01:22] <robru> you are both welcome. sorry for the delay there I was afk
[01:31] <sergiusens> slangasek: hey, there's a merge conflict with your MRs; I'm guessing it's the changelog; do you want me to merge separately or in one stance? if you remove the changes from debian/changelog the train will generate one from the commit message set on the MR/MP
[01:32] <slangasek> sergiusens: it is the changelog; happy to have the changelog entries removed to make the merge work; what's the best way forward?
[01:32] <slangasek> sergiusens: they certainly don't need to be separate merges, so whatever's best to fix up the merge, let's do it
[01:33] <sergiusens> slangasek: just revert them
[01:33] <slangasek> sergiusens: updated lp:~vorlon/phablet-tools/sane-adb-shells/ with changelog dropped - is that enough, or should I be dropping both changelog entries?
[01:34] <sergiusens> slangasek: drop both, or you'll only get that one entry
[01:34] <slangasek> phooey ;)
[01:34] <slangasek> sergiusens: done
[01:35] <sergiusens> thanks, building now
[01:49] <cwayne_> cihelp ping
[01:49] <cjohnston> cwayne_: that's not very helpful...
[01:50] <cwayne_> cjohnston, having some issues with the jenkins job http://s-jenkins.ubuntu-ci:8080/job/savilerow-trusty/25/console, seems its not actually pulling the latest rev somehow
[01:53] <cwayne_> as in, it's missing some files in the tarball that i know are in the branch..
[01:53] <cjohnston> cwayne_: "revno:6"
[01:54] <cwayne_> cjohnston, right but it's missing the entire src/system/custom/lib dir
[01:54] <cwayne_> which is there if a do a fresh branch
[01:57] <cjohnston> cwayne_: seems like "tar Jcvf custom.tar.xz -C src/ system/"  may be an issue
[01:57] <cjohnston> to me (not knowing anything about whats going on), it doesn't look like there would be a src/ and system/
[01:58] <cwayne_> it's making the tarball itself fine though, it's just missing src/system/custom/lib
[01:58] <cwayne_> it's got src/system/custom/everything-else
[01:59] <cjohnston> cwayne_: is there a problem running it manually?
[02:00] <cwayne_> cjohnston, nope
[02:01] <cwayne_> just now ran it on a fresh branch
[02:02] <fginther> cjohnston, cwayne_, any chance someone did a push --overwrite on this?
[02:02] <cjohnston> fginther: it the branch seems to have it
[02:02] <cjohnston> + ls src/system/
[02:02] <cjohnston> custom
[02:03] <cjohnston> ahh, I see what your saying..
[02:04] <fginther> care if I retry a build after wiping the workspace?
[02:04] <cjohnston> +1
[02:04] <imgbot> [02:05] <fginther> cwayne_, any harm in trying a clean rebuild?
[02:05] <cwayne_> fginther, none at all
[02:07] <fginther> nice, jenkins throws an exception trying to delete /home/ubuntu/jenkins/workspace/savilerow-trusty/src/system/custom/click/com.ubuntu.developer.alecu.qr-code/current. I'll check the host
[02:12] <fginther> cwayne_, the console looks like it found lib this time
[02:12] <cwayne_> fginther, awesome, thanks!
[02:12] <cwayne_> must've been a push --overwrite or something weird
[02:13] <fginther> cjohnston, cwayne_ 'current' was a symlink. I've seen a few jenkins bugs related to issues with symlinks
[02:13] <cwayne_> ah, could be
[02:13] <cwayne_> could we setup this job to always do a fresh branch?
[02:15] <cjohnston> seems like the job should only be firing when there is a code change
[02:15] <fginther> cwayne_, that might work, or the job may have to do some cleanup before it finishes
[02:17] <fginther> cwayne_, the job does a poll of the bzr tree, if the workspace is left in a bad state, the pollling may not go well
[02:18] <cwayne_> fginther, yeah, that makes sense
[02:18] <cwayne_> i can try and add some cleanup
[02:19] <cwayne_> thanks for the help fginther
[02:22] <fginther> and he leaves
[02:22] <fginther> cjohnston, /me thinks cwayne should be introduced to the jenkins charm
[02:22] <cjohnston> hehe
[02:31] <sergiusens> doanac: hey, care to run the andy job against https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28 ?
[03:34] <imgbot> [03:34] <imgbot> [04:12] <Mirv> morning
[06:21] <Mirv> didrocks: bzoltan1 has set uitk to be tested but it'd need a packaging ack: http://162.213.34.102/job/landing-018-2-publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+14.04.20140331-0ubuntu1.diff
[06:22] <didrocks> Mirv: good to me, +1 :)
[06:22] <Mirv> thanks
[06:22] <Mirv> bzoltan1: re: your notes from other channel, this is your last chance to discuss if there's still some doubt on your mind :)
[06:23] <Mirv> apparently sdk team has found a flakiness happening in clock app tests that shouldn't be coming from UITK, and sometimes all tests pass
[06:23] <Mirv> but I guess the confusion was about why it's not flaky on the test infra or something
[06:24] <bzoltan1> Mirv: correct
[06:25] <bzoltan1> Mirv:  the only flaky test is the ubuntu_clock_app.tests.test_stopwatch.TestStopwatch.test_click_clock_center_with_stopwatch_started_must_stop_it and the ubuntu_clock_app.tests.test_timer.TestTimer.test_delete_preset_must_remove_from_presets_list
[06:26] <bzoltan1> Mirv:  that means, that 2 out of 8 run failed ...
[06:27] <bzoltan1> Mirv: http://paste.ubuntu.com/7187031/ http://paste.ubuntu.com/7187032/
[06:28] <Mirv> bzoltan1: ok. I guess we can assume at this point, especially as your people have studied it quite a lot, that it shoudn't be coming from UITK
[06:28] <didrocks> bzoltan1: this test was never flaky beforehand, did you work with QA?
[06:28] <bzoltan1> Mirv:  I really do not think it has anything to do with the UITK
[06:28] <didrocks> Mirv:  we didn't have those testing failing over 20 runs
[06:28] <bzoltan1> didrocks: Mirv: we worked with elopio
[06:29] <didrocks> Mirv: so I think we should reallly have jibel's team expertise first
[06:29] <bzoltan1> didrocks:  I am not happy with that .. .but not landing the UITK will cause bigger issues soon
[06:29] <Mirv> bzoltan1: what did elopio have to say?
[06:29] <didrocks> bzoltan1: yeah, so then, you put the pain in the CI team to get the things fixed?
[06:30] <bzoltan1> didrocks: Mirv: elopio said that he has been running clock tests on his mako with image 270 and the 18 silo ppa for one hour with no failures like 12 times
[06:30] <didrocks> cihelp: seems that the tests don't unlock the screens?
[06:30] <Mirv> didrocks: it'd be good to understand as much as possible. I know I can't replicate test infra results myself, for example yesterday notes-app failed for me consistently but ok on test infra.
[06:30] <bzoltan1> didrocks: Mirv ^^
[06:30] <didrocks> bzoltan1: with your new UITK?
[06:30] <Mirv> yes, silo 18 is the new UITK
[06:30] <bzoltan1> with image 270 and the 18 silo ppa
[06:30] <Mirv> bzoltan1: that sounds good at least
[06:30] <didrocks> bzoltan1: ah, so this is good to me
[06:31] <bzoltan1> Mirv: yes it does ... but I hate to see different test results than the dashboard shows
[06:31] <bzoltan1> didrocks: I am confident, but I would like to see what the CI's dashboard shows
[06:31] <Mirv> bzoltan1: so maybe a mental note to ask from elopio how he runs the tests, to try to get as good results in the future?
[06:32] <Mirv> bzoltan1: that'll come with CI Airlines only unfortunately, getting the test infra to do the current manual work..
[06:32] <bzoltan1> Mirv: That is what I will do when elopio comes online
[06:32] <didrocks> bzoltan1: like, if only you got it, someone else rerun it multiple times without getting it, knowing how hard and subtle flaky issues we can have, yeah, that's fine
[06:32] <didrocks> plars: no email on the phone ML where #270 failed completely?
[06:32] <Mirv> ok, but 12 times no failures from elopio is good enough, and I already know no other failures were found
[06:33] <didrocks> so… I was telling…
[06:33] <didrocks> bzoltan1: ah, so this is good to me
[06:33] <didrocks> bzoltan1: like, if only you got it, someone else rerun it multiple times without getting it, knowing how hard and subtle flaky
[06:33] <didrocks> issues we can have, yeah, that's fine
[06:33] <didrocks> plars: no email on the phone ML where #270 failed completely?
[06:33] <didrocks> did you get my messages?
[06:34] <Mirv> depending on who you're asking from, yes I saw those three messages twice now
[06:34] <didrocks> ok, I'm lagging/disconnected…
[06:36] <Mirv> bzoltan1: published. it'll go to release team's unapproved queue, since it's also seeded on ubuntu/xubuntu/edubuntu desktop images
[06:39] <bzoltan1> Mirv:  Cool. Please ping me when I can merge to the trunk...
[06:40]  * bzoltan1 goes and starts to prepare the next landing :)
[06:40] <Mirv> sure
[07:01] <sil2100> Morning everyone
[07:01] <sil2100> didrocks: so, in the end, we decided to drop the PHONECON ruleset as defined during vUDS?
[07:05] <bzoltan1> Mirv:  who should we ping from th release team to approve the UITK package?
[07:05] <didrocks> good morning sil2100
[07:05] <didrocks> sil2100: seems so…
[07:06] <didrocks> sil2100: also as we can't have any good test results for quite a while…
[07:06] <didrocks> sil2100: do you feel better today?
[07:06] <sil2100> didrocks: smoketest infra problems again? :(
[07:07] <sil2100> didrocks: a bit, yes - I guess the cold and fever are slwoly giving up
[07:11] <Mirv> morning sil2100!
[07:12] <Mirv> bzoltan1: just hang around at #ubuntu-release and you can ask generally if you're in a hurry or if it seems it takes extra amount of time for them to review it. in general they go in the order of uploads, see https://launchpad.net/ubuntu/trusty/+queue?queue_state=1&queue_text= for the queue
[07:18] <didrocks> sil2100: I don't know, we need to wait for the CI team
[07:18] <didrocks> sil2100: however, the previous days, no crashers reported (due to the image…)
[07:21] <sil2100> :|
[07:30] <tvoss> sil2100, didrocks silo 20 is tested and good from my side. Would appreciate a round of exploratory testing
[07:30] <sil2100> tvoss: sure, let me take a quick look
[07:30] <tvoss> sil2100, thx
[07:37] <sil2100> hm, strange, latest image doesn't boot for me, I wonder if I need to reflash or something
[07:38] <sil2100> I mean, it boots but no unity8 can be seen
[07:39] <didrocks> sil2100: I'm upgrading, will tell you in a few :)
[07:40]  * didrocks reboots
[07:40] <didrocks> sil2100: anything in upstart logs?
[07:42] <didrocks> sil2100: yeah, reproducing
[07:42] <didrocks> (process:2351): GLib-GIO-ERROR **: Settings schema 'com.canonical.Unity.Launcher' is not installed
[07:43] <sil2100> Yeah, I see the same, you think this can be the root cause?
[07:43] <didrocks> it is
[07:43] <didrocks> gsettings segfaults when the schema isn't available
[07:43] <sil2100> Oh, how lovely
[07:43] <didrocks> it's intended… :/
[07:43] <didrocks> ok, so the schema is shipped by /usr/share/glib-2.0/schemas/com.canonical.Unity.gschema.xml
[07:44] <didrocks> so libunity-core-6.0-9
[07:45] <didrocks> "Drop unity-core based scopes in scopes plugin, expose attributes to shell"
[07:45] <didrocks> I wonder if it's not what retained it into the image
[07:46] <didrocks> and yeah
[07:46] <didrocks> working then
[07:47] <didrocks> plugins/Unity/Launcher/backend/launcherbackend.cpp:        QGSettings gSettings("com.canonical.Unity.Launcher", "/com/canonical/unity/launcher/");
[07:47] <didrocks> so, it needs a dep on libunity-core
[07:47] <sil2100> hm, why was this dropped from the image?
[07:47] <didrocks> yep
[07:48] <sil2100> Did we seed it then somehow? Since I don't see in the package diff any updates that could have dropped it
[07:48] <didrocks> see my previous line
[07:48] <didrocks> it was pulled by the scopes
[07:48] <didrocks> not anymore
[07:48] <sil2100> Ah, right, -plugin-scopes, damn, I'm blind
[07:49] <sil2100> didrocks: should I poke Saviq to include the dep, or should we do it ourselves? A dep in unity8 I guess?
[07:50] <didrocks> sil2100: no, I'm doing an upload
[07:50] <sil2100> ACK
[07:50] <didrocks> sil2100: didn't merge it back though, as I think the proper fix is to remove the schema from that package
[07:50] <didrocks> have it on its own
[07:50] <didrocks> and dep on that
[07:52] <didrocks> Saviq: once you read that ^
[07:53] <didrocks> 7.84+14.04.20140327.1-0ubuntu2 uploaded
[07:54] <didrocks> cihelp: unping on latest image not providing results. Would be good though to know about the previous one though
[07:55] <psivaa> didrocks: ack, looking at it now
[07:55] <didrocks> thanks psivaa :)
[07:58] <sil2100> Let me drink some meds to be less coldish for the meeting
[07:59] <didrocks> oki
[08:02] <didrocks> Saviq: let's talk about the best strategy, as we'll have click vs non click, maybe having unity8 shipping its own schema will make rather sense (as there is no more unity-common)
[08:10] <Saviq> sil2100, didrocks, I don't think we should need it...
[08:10]  * Saviq greps
[08:10] <didrocks> Saviq: you do in plugins/Unity/Launcher/backend/launcherbackend.cpp
[08:11] <Saviq> ah right
[08:11] <Saviq> we share the same launcher list
[08:11] <didrocks> yep
[08:11] <didrocks> I think with click, it doesn't make sense anymore, wdyt?
[08:11] <Saviq> didrocks, you uploaded a fix directly, did you? and now we should fix in our trunk?
[08:12] <Saviq> didrocks, we won't only support click
[08:12] <didrocks> Saviq: yeah, but I think it's not really a fix (to depend on libunity-core for that)
[08:12] <Saviq> didrocks, when we move to desktop
[08:12] <didrocks> Saviq: yeah, but unity7 will never support click
[08:12] <didrocks> so I guess having 2 list of launcher icon + handling the transition would make sense
[08:12] <Saviq> didrocks, mhm
[08:13] <Saviq> but now we'd need to handle the transition one way... and then the other... :|
[08:13] <psivaa> didrocks: the apparent failures with 270 is due to a dashboard issue of mixing results from prev runs. trying to sort that out
[08:13] <Saviq> didrocks, can we patch-aid it with the dep for now, and fix it properly through a bug?
[08:13] <didrocks> Saviq: just one way I would say
[08:13] <didrocks> Saviq: that works as well for me
[08:13] <didrocks> psivaa: oh?
[08:14] <Saviq> didrocks, it's not just us, we'd need to let customization know that the key changed and such
[08:14] <Saviq> and put that key in a schema somewhere (ubuntu-touch-schemas?)
[08:14] <didrocks> Saviq: oh right customization, let's do baby-steps then
[08:14] <didrocks> Saviq: let me propose a branch then :)
[08:14] <psivaa> didrocks: yea, http://ci.ubuntu.com/smokeng/trusty/touch/mako/270:20140331.1:20140331/7488/ubuntu_filemanager_app/ shows the passed ones and the failed prev run of the same image
[08:14] <didrocks> Saviq: in few minutes :)
[08:14] <Saviq> didrocks, thanks
[08:14]  * Saviq files a bug then
[08:21] <ogra_> imgbot, status 271
[08:21] <imgbot> Image 271 test results on mako - Total: 134, Pass: 110, Crashes: 4, Rate: 80%
[08:22] <ogra_> urgh
[08:25] <davmor2> didrocks: todays image is a bit ummm broken for me
[08:25] <didrocks> davmor2: yeah
[08:25] <didrocks> davmor2: I uploaded a new unity8
[08:25] <davmor2> didrocks: admittedly I can only find one fault with it
[08:25] <davmor2> didrocks: oh so it's all your fault :P
[08:26] <didrocks> davmor2: no
[08:26] <didrocks> davmor2: I pushed the fixed
[08:26] <didrocks> we can maybe wait 4 minutes and discuss in the meeting? :p
[08:27] <sil2100> ;)
[08:27] <davmor2> sil2100: \o/ you feeling better dude?
[08:30] <ogra_> at least all tests have 80%
[08:30] <ogra_> thats something  :P
[08:33] <davmor2> ogra_: and I can't break the image at all it is 100% daveproof "Ship it!" ;)
[08:33] <ogra_> haha
[08:33] <ogra_> well xnox uploaded a change to adb
[08:34] <ogra_> i know he ran AP tests with it but he most likely didnt test screen unlock
[08:38] <sil2100> davmor2: more or less
[09:01] <Mirv> popey: davmor2: is this the one, can I get some AP test report or such on it? http://s-jenkins.ubuntu-ci:8080/job/camera-app-click/48/artifact/out/com.ubuntu.camera_2.9.1.258_armhf.click
[09:07] <popey> Mirv: ack
[09:08] <popey> davmor2: are you guys saying unity doesn't start on #271 ?
[09:09] <davmor2> popey: that is correct you just get a black screen
[09:09] <popey> works here
[09:09] <popey> phablet   2546  9.7  6.6 431676 125564 ?       Ssl  10:06   0:17 unity8
[09:09] <popey> current build number: 271
[09:09] <popey> how odd.
[09:09] <davmor2> didrocks: ^
[09:10] <Mirv> popey: you have better #271 than us
[09:10] <popey> bet this is because my phone was rw when i updated
[09:10] <popey> probably some lib that is still hanging around from #270?
[09:11] <Laney> Are the calendar-app AP tests known to be dodgy when run locally?
[09:12] <popey> Laney: not that I'm aware, bugs welcome.
[09:13] <Laney> hmm
[09:13] <Laney> lemme see
[09:18] <davmor2> ogra_: https://bugs.launchpad.net/ubuntu/+source/android/+bug/1287208
[09:18] <ogra_> davmor2, thanks
[09:27]  * didrocks reboots to previous kernel
[09:31] <Laney> Mirv: When you run the calendar-app tests using that recipe you gave me yesterday, does test_monthview_go_to_today_prev_year work for you?
[09:39] <didrocks> tvoss: Laney: seb128: mhr3:  Mirv: sil2100: going to stop CI train to move to prodstack in few minutes (of course, current builds aren't be stopped)
[09:39] <didrocks> expect the downtime to be < 10 minutes
[09:39] <seb128> didrocks, ok
[09:39] <seb128> great
[09:39] <Laney> ok, good luck!
[09:39] <didrocks> thanks :)
[09:39] <tvoss> didrocks, good luck
[09:40] <didrocks> will tell you when I shut down jenkins
[09:40] <mhr3> thx for headsup
[09:40] <seb128> Laney, having fun with autopilot since yesterday it seems ... is all that only to test your qt patch from the other day?
[09:40] <Laney> ues
[09:40] <Laney> yes
[09:40] <Laney> velocity!
[09:40] <seb128> crazyness
[09:40] <seb128> you patched a "leaf" api
[09:40] <Laney> anyway the same thing happens with the old version of qtdeclarative
[09:43] <sil2100> didrocks: ACK :)
[09:43] <Laney> so Not My Problem™
[09:43] <didrocks> Laney: yeah, just don't regress the image, only what we ask :)
[09:43] <didrocks> don't fix stuff you can't/are not supposed to fix :)
[09:44] <Laney> it's just disturbing when things are different locally vs. in CI
[09:44] <didrocks> Laney: yeah, agreed :/
[09:44]  * seb128 impressed by Laney's perseverance
[09:44] <seb128> I wouldn't have bothered to run all autopilot tests for a 1 liner to a tz function
[09:44] <Laney> haha
[09:58] <Mirv> Laney: it did succeed yesterday when I tested new UITK, ie calendar-app 12 tests passed (if I'm reading the correct line). but it's not like unheard that running AP tests locally does not easily yield same results as on the test infra
[09:58] <Laney> mmm
[09:59] <Mirv> I guess the normal "pass" is "same result as without the update" when doing the local tests
[09:59] <popey> Mirv: camera passes, stick it in the store and I'll get it approved
[10:03] <Mirv> popey: ok
[10:11] <Mirv> popey: it says package scan took too long, and that one should check status at https://myapps.developer.ubuntu.com/dev/api/click-scan-complete/93/
[10:12] <popey> Mirv: i cant see that ☹
[10:12] <Mirv> before that it did say it got submitted to https://myapps.developer.ubuntu.com/dev/api/click-upload/com.ubuntu.camera/
[10:12] <popey> or that
[10:12] <Mirv> well it does say "Please check the status later at...", so I wonder who much later
[10:12] <Mirv> we might need sergiusens then
[10:13] <popey> yeah, i don't have the creds for that account, so can't see it
[10:13] <davmor2> Morning all
[10:14] <didrocks> Mirv: seb128: Saviq: sil2100: tvoss: mhr3: thostr_: stopping jenkins for the migration
[10:14] <sil2100> didrocks: ok, good luck ;p
[10:14] <Saviq> didrocks, have fun!
[10:14] <didrocks> will try :p
[10:15] <sil2100> ;)
[10:16] <seb128> didrocks, ok
[10:16] <Mirv> popey: ok, I experimented what happens if I retry, and it worked.. Please check out the application at: https://myapps.developer.ubuntu.com/dev/click-apps/506/.
[10:16] <popey> Mirv: i see it now
[10:17] <popey> Mirv: approved it
[10:17] <Mirv> nice!
[10:25] <didrocks> all is transition, we have an issue on librarian firewall FYI
[10:34] <didrocks> waiting on webops to check/open the firewall FYI
[10:35] <Saviq> didrocks, seems there's a problem with SSO
[10:35] <Saviq> didrocks, it redirected me to https://job/landing-002-1-build/build?delay=0sec
[10:35] <didrocks> Saviq: please don't run anything for now
[10:35] <didrocks> Saviq: sso was working for me
[10:35] <didrocks> though
[10:35] <Saviq> didrocks, sure, just saying
[10:36] <didrocks> Saviq: let me unlog and relog
[10:36] <Saviq> didrocks, it logged me in fine, but redirected to the wrong url
[10:36] <Saviq> once, at least
[10:37] <plars> didrocks: on 270 I was trying to rerun some things into late last night, and was hopeful that the previous failed attempts was just due to a typo in the test list
[10:37] <plars> didrocks: but I fell asleep before it finished, so I didn't get to see until now, sorry
[10:38] <plars> didrocks: I'm still not sure what happened there, but it looks like there is something wrong in the current image too
[10:38] <didrocks> ev: I don't know why Saviq has that, seems that the juju charm was executed right?
[10:38] <plars> didrocks: nothing changed in the ci code that could explain it though (no new unlocker or anything)
[10:38] <didrocks> plars: ok, no worry, just an email on the ML next time :)
[10:39] <didrocks> ev: may be the callback from sso side is wrong?
[10:39] <plars> didrocks: sorry, intendted to
[10:39] <didrocks> Saviq: weird, I'm redirected to the right url here
[10:39] <didrocks> Saviq: let me try from another one
[10:39] <didrocks> Saviq: yeah, working :/
[10:40] <didrocks> Saviq: and same from https://ci-train.ubuntu.com//job/landing-015-1-build/build?delay=0sec
[10:40] <didrocks> Saviq: can you unlog/retry?
[10:40] <ev> didrocks: that'd be surprising, given it redirected me just fine
[10:40] <Saviq> didrocks, yeah let me try again
[10:40] <didrocks> ev: yeah
[10:41] <didrocks> I tried 3 configurations here
[10:41] <Saviq> didrocks, ok, can't repro any more
[10:41] <ev> yay
[10:41] <didrocks> Saviq: can we blame you or your browser? :p
[10:41] <didrocks> realistically, keep us posted if you see so
[10:41] <didrocks> so…
[10:42] <ev> it's one to watch out for though
[10:42] <ogra_> stop using oxide :P
[10:42] <Saviq> didrocks, you can
[10:42] <ev> I doubt that came from nowhere
[10:42] <didrocks> ev: agreed, let's see if more people get it
[10:42] <didrocks> everything is back but the firewalling
[10:42] <didrocks> so as long as you don't prepare or watch a build, you can resume working :)
[10:42] <didrocks> (so publication + m&c)
[10:48] <didrocks> 12:48:05        moon127 | didrocks, I've getting branch reviewed now.  I would expect ~20 mins to land it on the firewall and make
[10:48] <didrocks>                         | live.
[10:48] <didrocks> Saviq: seb128: Mirv: sil2100: thostr_: mhr3: tvoss: ^
[10:49] <didrocks> Laney: ^
[10:49] <didrocks> (so, you can publish, m&c, just not build/watch)
[10:49] <Laney> neat
[10:49] <Mirv> ok
[10:50] <sil2100> ACK
[10:50] <didrocks> 12:49:58        moon127 | didrocks, we've rushed that one through, and I can wget that file on the jenkins instance
[10:51] <didrocks> so all should be back to normal, feel free to build things :)
[10:51] <didrocks> Saviq: seb128: Mirv: sil2100: thostr_: mhr3: tvoss: Laney ^
[10:51] <sil2100> Yessss
[10:51] <sil2100> ;)
[10:51] <Laney> yay for cloud
[10:51] <sil2100> Thanks o/
[10:51] <tvoss> \o/
[10:51] <Laney> lemme try to publish qtdeclarative
[10:53] <Saviq> \o/
[10:53] <sil2100> didrocks: it seems I don't have permissions on the new jenkins to do builds!
[10:53] <didrocks> Laney: some packages failed to build?
[10:53] <Laney> did they?
[10:53] <didrocks> sil2100: did you check the ubuntu-unity box?
[10:54] <Saviq> "saviq is missing the Job/Build permission" ;(
[10:54] <sil2100> hm, right, it didn't even ask me that, just redirected instantly, let me relog
[10:54] <Laney> I believe spreadsheet is false false false
[10:54] <sil2100> didrocks: it doesn't allow me to
[10:54] <Saviq> sil2100, /me too, logging out and back in doesn't help
[10:54]  * Saviq goes to login.ubuntu.com
[10:54] <Mirv> sil2100: also check to login from top right corner
[10:54] <sil2100> didrocks: when I press 'login' then I just instantly get logged in without any prompts
[10:55] <Mirv> hmm, yeah same here
[10:55] <sil2100> Mirv: just did that
[10:55] <didrocks> Saviq: sil2100: do you have the teams you are in checkbox?
[10:55] <Laney> didrocks: I got redirected to 'job' after SSOing
[10:55] <didrocks> Laney: ^
[10:55] <Laney> known?
[10:55] <sil2100> didrocks: which checkbox? I have no checkboxes
[10:55] <Laney> is that what they are saying?
[10:55] <didrocks> Laney: jobs?
[10:55] <Laney> Firefox can't find the server at job.
[10:55] <Saviq> denied :|
[10:55] <didrocks> ev: around? ^
[10:56] <Laney> https://job/landing-008-1-build/build?delay=0sec
[10:56] <Mirv> Laney: try again, I got the same the first time
[10:56] <didrocks> Laney: hum, where are you clicking?
[10:56] <sil2100> didrocks: when I press 'log in' I instantly get logged in, without any checkboxes
[10:56] <didrocks> argh, so it's a real issue
[10:56] <Saviq> didrocks, it's not asking for the team membership for some reason
[10:56] <Laney> build, SSO 2fa prompt, bogus redirect
[10:56] <Mirv> didrocks: first time double clicking from spreadsheet it goes to https://job/ somehow after a couple of redirects
[10:56] <Laney> I didn't notice the checkboxes I'm afraid
[10:56] <Mirv> the next time works
[10:56] <Laney> Mirv: I bet if you log out and back in it does it again
[10:56] <didrocks> ev: really need you here ^
[10:57] <Laney> anyway it works if you're already authenticated
[10:57] <Laney> just the error on first login
[10:57] <ev> hi
[10:57] <Laney> (notwithstanding the permissions check that I didn't notice, sorry)
[10:57] <didrocks> so first login is an issue?
[10:57] <moon127> didrocks, hi
[10:57] <didrocks> hey moon127
[10:57] <Laney> lemme try re-logging-in
[10:57] <didrocks> so it seems first login is failing for everyone
[10:57] <didrocks> and redirect to https://job/landing-008-1-build/build?delay=0sec for instance
[10:58] <ev> didrocks: they shouldn't see the page with checkboxes as ci-train.u.c is in the SSO whitelist
[10:58] <didrocks> ev: ah, ok
[10:58] <sil2100> ev, didrocks: then how can I get my permissions correctly now?
[10:58]  * didrocks tries in a anonymous session
[10:58] <Laney> hmm I didn't get the 'job' thing that time
[10:58] <didrocks> Mirv: are the permissions working then?
[10:59] <Laney> perhaps that only happens the first time you log in
[10:59] <didrocks> ok, so here, on a anonymouse section, I login
[10:59] <didrocks> then, I'm redirected
[10:59] <didrocks> but unlogged
[10:59] <didrocks> I reclick on "signing in"
[10:59] <Laney> ah no, I got it in a new browser that time
[11:00] <didrocks> and I have rights
[11:00] <didrocks> Laney: but then, do you have the right perms to run jobs?
[11:00] <Laney> didn't try yet
[11:00] <Mirv> "timo-jyrinki is missing the Job/Build permission"
[11:00] <didrocks> do you mind trying? (my user has more rights, so unsure it maps)
[11:00] <Mirv> didrocks: ^
[11:00] <Laney> I want to publish 008 so let me see what happens
[11:01] <Mirv> tried watch only in landing-011
[11:01] <didrocks> moon127: ev: ok, so it seems the teams attributes are not send to jenkins
[11:01] <Laney> yeah same as that
[11:01] <didrocks> moon127: ev: and there is another issue on first login (doesn't redirect to the right url)
[11:04] <didrocks> Mirv: Saviq: sil2100: seb128: Laney: tvoss: meanwhile, if you have any requests, proxy it to me, I can handle the pushing buttons
[11:04] <Laney> ok, please publish 008 then
[11:04] <Laney> actually I'm not sure how that works for direct uploads
[11:04] <Laney> I guess it's publish and clean, no merge
[11:04] <seb128> didrocks, noted, I'm going to have a few in the afternoon, thanks
[11:07] <didrocks> (done)
[11:07] <Laney> thanks!
[11:08] <didrocks> I found the issue on perms
[11:08] <didrocks> I can fix it, some secs
[11:11] <didrocks> ok
[11:11] <didrocks> so guys, can you retry?
[11:12] <Mirv> didrocks: works! https://ci-train.ubuntu.com/job/landing-011-1-build/1/console
[11:12] <didrocks> Laney: Mirv? ^
[11:12] <didrocks> phew :)
[11:12] <sil2100> Indeed, works \o/
[11:12] <didrocks> only the "first blank redirect remains in the list for now". Otherwise, you are all good to click in what you need :)
[11:13] <didrocks> Laney: seb128: mhr3: tvoss: Saviq: ^
[11:13] <Laney> nice work didrocks
[11:13] <seb128> didrocks, thanks, well done!
[11:14] <tvoss> didrocks, nice one :)
[11:14] <didrocks> yw, thanks for your patience (took a little bit longer than wanting, but hopefully, didn't block anyone for too long)
[11:15]  * didrocks kicks an image build to celebrate that
[11:15] <didrocks> (with the fixed unity8)
[11:15] <Saviq> \o/
[11:17] <sil2100> didrocks: so, PPA for silo 20 had the unity-scopes-api package already removed over an hour ago and running 'Build' with 'watch only' still makes the job look for unity-scopes-api in the PPA
[11:17] <didrocks> sil2100: ah, the fix for Qt5.2 probably created this
[11:19] <sil2100> How can I workaround this ;)?
[11:19] <imgbot> [11:23] <didrocks> sil2100: reading the code?
[11:23]  * didrocks looks
[11:23] <didrocks> but sorry, other requests…
[11:23] <didrocks> hum
[11:24] <didrocks> sil2100: can you provide the trace?
[11:24] <didrocks>         for pkg in src_ppa.getPublishedSources(distro_series=series, status="Published"):
[11:24] <didrocks> so I guess it's still published
[11:26] <didrocks> hum
[11:26] <didrocks> unity-scopes-api is a branch right?
[11:26] <didrocks> have you reconfigure to remove it?
[11:27] <davmor2> didrocks: so 271 mostly works by the look of it so just making unity8 work by default to fix that :)
[11:27] <didrocks> seems so
[11:27] <didrocks> you reconfigured it
[11:27] <didrocks> (answering as you are not around)
[11:29] <sil2100> Yeah, I was looking in the code myself
[11:29] <sil2100> didrocks: tvoss reconfigured it yesterday already, I did that today as well
[11:29] <didrocks> weird
[11:29] <sil2100> Since I thought it might somehow help
[11:29] <didrocks> after the reconfigure
[11:29] <didrocks> we still have unity-scopes-api.project
[11:30] <didrocks> if this bug was real, we would have it a lot more before
[11:32] <didrocks> sil2100:         # remove all files related to sources that are not in the configuration anymore
[11:32] <didrocks> oh
[11:32] <didrocks> sil2100: did you remove in the ppa
[11:32] <didrocks> and then run reconfigure? :/
[11:32] <sil2100> didrocks: what I did was:
[11:33] <sil2100> didrocks: in the morning I removed the package from the PPA and just press 'rebuild'
[11:33] <didrocks> why did you remove the package from the PPA?
[11:33] <didrocks> rather than reconfiguring?
[11:33] <sil2100> didrocks: after and hour I retried that, it was still looking for the project, so I reconfigured and reran build again
[11:33] <sil2100> didrocks: because tvoss said he reconfigured it yesterday
[11:34] <didrocks> seems he didn't :/
[11:34] <sil2100> And that this package in the PPA was somehow only a leftover after something
[11:34] <didrocks> sil2100: no, the reconfigure removes the package
[11:34] <didrocks> that's why the source isn't cleaned from the config
[11:34] <didrocks>         for (source, version, rev, branch) in packageinppamanager.get_all_packages_uploaded():
[11:34] <didrocks>             if source not in all_silo_projects:
[11:34] <didrocks> see prepare-silo
[11:35] <tvoss> didrocks, sil2100 I'm confused, what did I do wrong?
[11:36] <didrocks> tvoss: seems you didn't rerun the reconfigure job after removing the MP for unity-scopes-api
[11:36] <sil2100> tvoss: not sure, you mentioned that you reconfigured silo 20 yesterday, right?
[11:36] <tvoss> sil2100, yup, I might have done something wrong ... not sure what, though
[11:37] <didrocks> well, anyway, there is a way to patch the code to prevent that I guess
[11:38] <sil2100> Not sure what went wrong as well that the package .project file remained, hm
[11:41] <popey> psivaa: why am I not seeing a newer build of calendar in jenkins than 222 on 28/3? trunk has 226.
[11:43] <Laney> didrocks: is publishing working?
[11:43] <Laney> wait
[11:43] <Laney> I forgot unapproved :P
[11:43] <Laney> ignore me
[11:43] <didrocks> Laney: tssss :p
[11:43] <psivaa> popey: mind pasting the jenkins link pls?
[11:43] <didrocks> Laney: it's a potential failure though
[11:43] <Laney> it is in there
[11:43] <didrocks> ah ok :)
[11:43] <didrocks> so the rsync is working :)
[11:43] <popey> psivaa: http://s-jenkins:8080/job/calendar-app-click/
[11:43] <didrocks> (I checked it, but good that we have a real life confirmation :p)
[11:44] <psivaa> popey: thx. looking
[11:44] <popey> ta
[11:45] <didrocks> sil2100: wdyt about that? http://paste.ubuntu.com/7189309/
[11:46] <psivaa> popey: this job has been manually triggered mostly by balloons in the recent past. so the absence of that appears to be the reason :)
[11:46] <popey> psivaa: ah, can you press the same buttons?
[11:47] <sil2100> didrocks: looks ok, a bit safer in case of such hick-ups as today ;D
[11:47] <sil2100> Thanks!
[11:48] <didrocks> sil2100: ok, pushing and putting that in production, then rerunning configure
[11:48] <Saviq> sil2100, reconfigure silo 015 please? needed to add thumbnailer there
[11:49] <psivaa> popey: sure, done. still pending the slaves to be free to execute
[11:50] <sil2100> Saviq: ok
[11:51] <popey> psivaa: thank you.
[11:51] <psivaa> yw
[11:52] <didrocks> sil2100: hum
[11:52] <didrocks> doesn't seem to have worked
[11:53] <sil2100> didrocks: so... maybe the previous reconfigure really helped?
[11:53] <sil2100> I mean
[11:53] <sil2100> Not helped, but worked?
[11:53] <sil2100> And allowed_components_from_previous_config doesn't have what we need?
[11:53] <didrocks> sil2100: it didn't and still don't
[11:54] <sil2100> Saviq: reconfigured
[11:54] <Saviq> sil2100, thanks
[11:54] <Saviq> didrocks, upload fails https://ci-train.ubuntu.com/job/landing-002-1-build/3/console ?
[11:55] <Saviq> twice already
[11:55]  * sil2100 looks
[11:55] <Mirv> hmm
[11:56] <didrocks> firewall again
[11:56] <didrocks> moon127: still around?
[11:56] <didrocks> moon127: uploading to the ppa from the machine fails
[11:56] <didrocks> (traditional dput ppa:…)
[11:56] <didrocks> seems like launchpad firewall rules are really compartimentend
[11:56] <didrocks> ev: ^
[11:57] <sil2100> :(
[11:59] <didrocks> sil2100: oh one sec, on unity-scopes-api
[11:59] <didrocks> I think I tried "actions"
[11:59] <didrocks> instead of scopes
[12:02] <didrocks> sil2100: it's like if rmtree wasn't working
[12:02] <didrocks> Saviq: so moon127 isn't around and there is no vanguard on #webops :/
[12:02] <sil2100> o_O
[12:03] <moon127> didrocks, Saviq - looking
[12:03] <didrocks> sil2100: I'm pretty sure there are some permissions issues as well
[12:03] <moon127> didrocks, can you just confirm that is dput ftp rather than ssh
[12:04] <didrocks> moon127: yeah, it's dput ftp
[12:05] <sil2100> That would be strange..!
[12:07] <didrocks> sil2100: OSError: [Errno 2] No such file or directory: 'unity-scopes-api'
[12:07] <didrocks> hum, maybe I'm not in the right dir
[12:08] <didrocks> sil2100: yeah, found the issue
[12:08] <sil2100> clean_source looks ok?
[12:08] <didrocks> sil2100: I'm not in the silo path when cleaning
[12:09] <sil2100> uh, so how did that work before? :o
[12:10] <moon127> didrocks, firewall change is live
[12:10] <sil2100> Saviq: ^ can you retry?
[12:10] <didrocks> moon127: thanks!
[12:10] <didrocks> Saviq: you should be good now
[12:10] <didrocks> sil2100: it never worked at this stage I guess
[12:19] <didrocks> sil2100: phew: https://ci-train.ubuntu.com/job/landing-020-1-build/7/console
[12:20] <sil2100> didrocks: thank you! I see the change to silo_path ;)
[12:20] <didrocks> sil2100: yeah, while cd, better to change for a better name :)
[12:20] <sil2100> A lot of changes, just hope it doesn't break anything else ;p
[12:21] <sil2100> hah, sure
[12:21] <sil2100> :)
[12:21] <didrocks> sil2100: it's just Ctrl + D -> rename config_path to silo_path
[12:23]  * didrocks waits on Saviq's source package creation to finish to see the uploads
[12:24] <didrocks> hum
[12:24] <didrocks> moon127: seems it didn't work
[12:24] <sil2100> ;/
[12:24] <didrocks> moon127: default dput to a ppa is ftp though, right?
[12:25] <didrocks> [ppa]
[12:25] <didrocks> fqdn                    = ppa.launchpad.net
[12:25] <didrocks> method                  = ftp
[12:25] <didrocks> incoming                = ~%(ppa)s/ubuntu
[12:25] <didrocks> login                   = anonymous
[12:25] <didrocks> from dput.cf
[12:28] <didrocks> or… /me has a terrible doubt
[12:28] <didrocks> moon127: is dput installed on the machine?
[12:29] <moon127> didrocks, checking - fwiw I can open an ftp connection to ppa.launchpad.net manually
[12:29] <moon127> ha ha it is not!!
[12:29] <didrocks> it's weird, it was pulled from other depends
[12:29] <didrocks> not sure what is different on that machine
[12:29] <didrocks> ok, I'm adding it explicitely in the charm then
[12:30] <didrocks> moon127: mind installing it meanwhile?
[12:30] <moon127> didrocks, sure
[12:30] <didrocks> thanks :)
[12:30] <didrocks> and then, let's reretry :p
[12:30] <moon127> done
[12:30] <rsalveti> ogra_: didrocks: hey, did we find what broke 271?
[12:30] <rsalveti> just saw the email
[12:30]  * didrocks retries
[12:30] <didrocks> rsalveti: yeah, a schema not installed
[12:31] <didrocks> and so gsettings segfaults
[12:31] <didrocks> (libunity-core got dropped from the scopes)
[12:31] <didrocks> but unity8 is using the schema
[12:31] <rsalveti> oh, interesting
[12:31] <didrocks> which is in libunity-core
[12:31] <ogra_> rsalveti, all fixed already
[12:31] <didrocks> #272 should be ready soon
[12:31] <rsalveti> thought it could be kernel, android or something I did :-)
[12:31] <ogra_> 272 is already building
[12:31] <rsalveti> great
[12:31] <didrocks> rsalveti: ahah, not that low :p
[12:32] <rsalveti> great :-)
[12:32] <ogra_> hmm, i should add buildinfo to imigbots status command
[12:34] <Mirv> lots of click app updates will be in the next image :)
[12:34] <ogra_> fun
[12:41] <didrocks> sil2100: seems that process-cpp can be published, right?
[12:43] <didrocks> Saviq: 2014-04-01 12:42:43,995 WARNING A version (12.10.2+14.04.20140324.is.12.10.2+14.04.20140320-0ubuntu1) is available at the destination archive for that component but is not in the destination branch which is still at 12.10.2+14.04.20140324-0ubuntu1. You need to ensure that your version contains the fix in the destination or you can force rebuild to bypass the check.
[12:43] <didrocks> I need to run with "don't care" :p
[12:43]  * didrocks reruns
[12:44] <imgbot> [12:44] <imgbot> [12:45] <ogra_> there we go
[12:45] <didrocks> great :)
[12:45] <didrocks> welcome back libunity-core!
[12:46] <ogra_> ah, and there is the camera-app too
[12:46] <didrocks> yep :)
[12:46] <ogra_> oh, whats that initramfs change
[12:47]  * didrocks reflashes to retry before sending an email to the ML
[12:49]  * davmor2 ota updates 
[12:49] <dbarth> didrocks: sorry, but silo 7 seems different: it has no build button anymore
[12:49] <dbarth> https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=25
[12:49] <didrocks> dbarth: hum, someone copied and paste and mess with the spreadsheet I guess :/
[12:50] <dbarth> honestly i don't think i messd that cell up
[12:50] <didrocks> dbarth: I restored the formula from another silo
[12:50] <didrocks> dbarth: can be anyone :p
[12:50] <dbarth> thanks didrocks!
[12:50] <didrocks> yw
[12:54] <davmor2> didrocks: so ota from 271 to 272 gives me a working phone from a working phone.  I'm just flashing 271 see if the manual route does work
[12:55] <didrocks> davmor2: manual route, being?
[12:55] <didrocks> davmor2: system-image-cli?
[12:55] <davmor2> didrocks: yeap
[12:55] <didrocks> davmor2: ok, keep me posted
[12:55] <didrocks> you just run system-image-cli
[12:55] <didrocks> and then reboot your phone
[12:55] <didrocks> right?
[12:56] <davmor2> ogra_: ^ system-image-cli -d 0 isn't it?
[12:57] <ogra_> probably with the channel
[12:57] <didrocks> davmor2: I don't think you need -d 0
[12:57] <ogra_> but yeah
[12:57] <didrocks> just system-image-clic
[12:57] <didrocks> cli*
[12:57] <didrocks> you don't need a full download
[12:57] <ogra_> -d 0 forces a full image reinstall
[12:57] <didrocks> yeah
[12:57] <didrocks> we don't want that
[12:57] <ogra_> i would always run it with -v
[12:57] <davmor2> ogra_: thanks
[12:57] <ogra_> else it stays completely quiet
[12:57] <didrocks> davmor2: so, just system-image-cli -v
[12:58] <ogra_> (which is irritating since it can take a while)
[12:58] <davmor2> didrocks: indeed
[13:15] <ev> didrocks: are we all good on the prodstack move?
[13:15] <didrocks> ev: still need to check that dput is working
[13:15] <didrocks> https://ci-train.ubuntu.com/job/landing-002-1-build/6/console
[13:15] <didrocks> is the last trial
[13:16] <davmor2> didrocks, ogra_: well that seems to of updated now to see if I get a shell
[13:17] <didrocks> davmor2: excellent!
[13:17] <davmor2> didrocks, ogra_: I do http://paste.ubuntu.com/7189617/
[13:17] <davmor2> video and music still in place too woohoo!!!!
[13:17] <didrocks> heh
[13:20] <tedg> In silo 1 I've got a "url-dispatcher is in the UNAPPROVED queue" - how do I fix that?
[13:20] <didrocks> tedg: get the release team to approve it :)
[13:21] <didrocks> they are reviewing the queue regularly
[13:21] <didrocks> so, it should be ping-less :)
[13:21] <tedg> Okay, where do I see that queue?
[13:21] <didrocks> everything that is seeded in any flavor (but Touch) is getting in UNAPPROVED
[13:22] <didrocks> tedg: https://launchpad.net/ubuntu/trusty/+queue?queue_state=1
[13:23] <ogra_> or by being in the #ubuntu-release channel ... the queuebot there announces package states
[13:23] <tedg> Ah, interesting.
[13:24] <tedg> I was surprised it didn't show up on the source package page.
[13:26] <Saviq_> didrocks, this really doesn't work still https://ci-train.ubuntu.com/job/landing-015-1-build/6/console :|
[13:26] <didrocks> tedg: as long as it's not approved, you can kick it back and reaccept with the same version
[13:26] <tedg> didrocks, Not sure what that means?
[13:26] <didrocks> Saviq: argh, I was looking at the another landing (longer)
[13:27] <didrocks> yeah, so seems the upload doesn't work
[13:27] <didrocks> grrrr
[13:28] <didrocks> Saviq: I'm asking the webops vanguard, they told it was opened…
[13:32] <Saviq> :|
[13:33] <Saviq> didrocks, it looks like -build jobs are much slower now, any idea?
[13:35] <sil2100> Hardware differences, but I would expect it to be for the better
[13:35] <didrocks> Saviq: I don't control the architecture at all anymore
[13:36] <didrocks> Saviq: so yeah, I would say hardware difference, but I agree with your feeling
[13:36] <cjwatson> tedg: accepted now, sorry for the delay
[13:36] <Saviq> didrocks, kthx
[13:36] <tedg> cjwatson, Great! Thanks!
[13:37] <mhr3> sil2100, silo for 27 pls?
[13:39] <sil2100> mhr3: oh, something set to ready?
[13:39] <sil2100> mhr3: let me look
[13:39] <sil2100> Oh, something new
[13:40] <sil2100> mhr3: assigning
[13:40] <mhr3> ty
[13:41] <sil2100> mhr3: silo 13
[13:45] <didrocks> psivaa: plars: do we have full test results on image #270 now?
[13:46] <plars> didrocks: no, there was a problem with the reruns I tried at the end - just ignore those
[13:46] <plars> didrocks: 271 was already in progress though
[13:46] <didrocks> plars: so, we will never have test results on #270?
[13:47] <didrocks> knowing it was the first one for the crash files
[13:47] <didrocks> and #271 is lost
[13:48] <plars> didrocks: I can try to pull something off for 270
[13:48] <didrocks> I thought psivaa was working on that since this morning
[13:48] <plars> didrocks: at worst, I can run them locally on a mako if you like
[13:48] <plars> oh, maybe - psivaa is that right?
[13:48] <didrocks> so maybe check with him?
[13:49] <psivaa> didrocks: plars: i was trying to get the dashboard right, which i could not
[13:50] <plars> psivaa, didrocks: so I do have one idea how to do it. Let me give it a shot. If it works then I may have an idea how we can make it an option for reruns
[13:50] <plars> make image id an option that is
[13:50] <didrocks> plars: great!
[13:50] <plars> didrocks: and if all else fails, I'll just kick off a local run and confirm that all of those missing ones look ok
[13:50] <didrocks> Saviq: seems I didn't get traction on the speed regression :/
[13:50] <didrocks> plars: ok, thanks!
[13:51] <Saviq> didrocks, yeah I saw that, it took an hour to prep silo 002, that's rather bad :|
[13:51] <Saviq> even if it built as many packages as it did
[13:51] <didrocks> Saviq: I don't even have ssh access anymore to it… so really can't help
[13:51] <Saviq> didrocks, I understand, just saying that we need to talk to someone that can
[13:52] <didrocks> that's what I tried, ev has good connexion with them, so maybe him…
[13:52] <ev> hm?
[13:52] <Saviq> didrocks, do you have logs from previous silo 002 preps? to check how much it took there?
[13:53] <didrocks> ev: see our discussion with webops
[13:53] <didrocks> Saviq: I have to restart jenkins for that, and I'm afraid some people will try to reprepare from it
[13:53] <didrocks> Saviq: without having any links
[13:53] <popey> psivaa: http://s-jenkins:8080/job/calendar-app-click/106/console it failed.. any idea why?
[13:53] <didrocks> Saviq: I meant, keeping previous links
[13:53] <psivaa> popey: 1 sec pls
[13:54] <Saviq> didrocks, :/
[13:54] <didrocks> Saviq: I can temporarly if you know what you want to check
[13:54] <Saviq> didrocks, yeah, just want to find a build-002-1-build
[13:54] <didrocks> Saviq: started
[13:54] <Saviq> didrocks, that prepared the whole thing
[13:54] <didrocks> tell me once I shut down :p
[13:54] <ev> didrocks: I think we need to go beyond just saying it's slower. Can we instrument the code to provide timings?
[13:55] <didrocks> ev: jenkins itself gives timing, and Saviq has exactly the same set
[13:55] <ev> oh great, so where is it taking longer?
[13:55] <ev> I didn't see that in the #webops chat
[13:56] <didrocks> ev: the build part to prepare source packages
[13:56] <didrocks> I restart the previous jenkins for Saviq to gives more infos
[13:56] <ev> just build? It's not debootstrapping or anything?
[13:57] <ev> or hitting apt in any way
[13:57] <didrocks> ev: I don't have finer grain
[13:57] <didrocks> so we won't be able to compare
[13:57] <didrocks> between old and new infra
[13:57] <ev> it builds a package cache after the first run, no?
[13:58] <didrocks> yeah
[14:00] <psivaa> popey: that appears to have been because of an rm op failing. i think i've fixed it and kicked another run.
[14:00] <Laney> You should try the -nc that I told you about before to avoid needing build-deps
[14:00] <popey> psivaa: thanks, will that happen again?
[14:01] <psivaa> popey: i dont think so because i changed the job config. (strange that it has been happening so far though)
[14:01] <popey> psivaa: ah okay, thanks.
[14:04] <psivaa> popey: the next build succeeded.
[14:05] <popey> great!
[14:06] <didrocks> Saviq: any luck? I would prefer to shutdown the old instance to avoid people getting mislead
[14:07] <Saviq> didrocks, http://pastebin.ubuntu.com/7189814/
[14:07] <Saviq> didrocks, shut it down
[14:08] <Saviq> 3 times slower for unity8, for example :|
[14:08] <didrocks> ev: ^
[14:08] <didrocks> Saviq: thanks, stopped
[14:09] <ev> hmmm interesting
[14:10] <ev> didrocks: why are those info lines different though? That seems to imply we don't quite have a like for like comparison here - that it might have actually gone down a different code path
[14:10]  * Saviq uploads the log
[14:10] <Saviq> http://paste.ubuntu.com/7189823/
[14:11] <Saviq> that's the one from the old instance
[14:11] <didrocks> ev: once is with "force rebuild" not the other one I guess
[14:11] <ev> so they're not going down separate code paths?
[14:12] <didrocks> ev: the difference is:
[14:12] <didrocks> http://paste.ubuntu.com/7189830/
[14:12] <ev> rm -rf taking a long time strikes me as strange, to say the least. There's not a lot of IO overhead in that.
[14:13] <didrocks> ev: so, one is before the other, and the function called is just doing diff -Nrup old/ new/
[14:13] <didrocks> ev: so the second one is in theory few ms faster than the first one
[14:13] <didrocks> (less checks)
[14:13] <didrocks> let's say with launchpad api call, 2s faster
[14:13] <didrocks> (while it's the contrary, it's way slower)
[14:18] <didrocks> ok, really late exercising/first break
[14:18] <didrocks> I'll probably be back on time for the meeting
[14:18] <ev> didrocks: when you get a chance, can you do the following on the canonistack instance that you were running ci-train from:
[14:18] <ev> sudo hdparm -Tt /dev/sda
[14:18] <ev> and
[14:19] <ev> dd if=/dev/zero of=/home/ubuntu/output bs=1M count=1024; rm -f ~/output
[14:19] <ev> then we can ask #webops to do the same and further isolate this problem
[14:22] <didrocks> ev: http://paste.ubuntu.com/7189886/
[14:22] <didrocks> ev: /dev/vdc1 is /var/lib/jenkins (so first matches first, second matches second)
[14:22] <didrocks> cowbuilder is in the second
[14:23] <didrocks> sil2100: if I'm late for the meeting, mind starting it?
[14:23] <sil2100> didrocks: sure :)
[14:23] <didrocks> thx :)
[14:30] <bzoltan> didrocks: sil2100: I would need a silo for a single line change in the QtC Ubuntu plugin project ... important for jono and dpm
[14:30] <dpm> bzoltan, wait, that change is not important until the other bug fix lands
[14:31] <sil2100> bzoltan: I can assign a silo, sure
[14:32] <sil2100> kgunn: hi! You can m&c line 24 if anything ;)
[14:32] <dpm> bzoltan, sil2100, let's not add a silo until bug 1297190 is addressed
[14:32] <kgunn> sil2100: yes sir!
[14:32] <sil2100> dpm: oh, too late... I guess having a silo is not a big deal anyway
[14:33] <dpm> ok, I was just trying to avoid extra work
[14:33] <sil2100> dbarth: the webbrowser oxide landing is ready for a m&c as well - if you have the moment, could you press the button? :)
[14:51] <dbarth> sil2100: will do right now
[14:53] <Saviq> didrocks, looks like platform-api didn't get uploaded? https://ci-train.ubuntu.com/job/landing-002-1-build/6/consoleFull
[14:53] <sil2100> dbarth: thanks
[15:01] <sil2100> I wonder why the autopilot landing didn't move at all since such a long time
[15:03] <ChickenCutlass> rsalveti: hangout
[15:03] <ChickenCutlass> rsalveti: oh right — your out
[15:03] <ChickenCutlass> lol
[15:15] <plars> didrocks: so it looks like something changed with permissions on /root, which is causing 'bash: /root/.bashrc: Permission denied' when the click image test tries to run a command with adb. I think we can work around it in the test, but that's why that's happening.
[15:15] <plars> didrocks: *that's why the click image test is failing
[15:15] <ogra_> plars, talk to xnox
[15:15] <ogra_> plars, adbd was changed
[15:15] <plars> ogra_: ack, thanks
[15:16] <ogra_> it now processes a login shell ... which means you get a home, locale etc for root
[15:16] <ogra_> i wouldnt expect /root/.bashrc not being writable to be a blocker for anything though
[15:16] <ogra_> that should just be a warning
[15:17] <popey> davmor2: can you replicate bug 1300847
[15:26] <Saviq> didrocks, https://ci-train.ubuntu.com/job/landing-002-1-build/8/console silo broke? :/
[15:28] <Laney> do I need to do ONLY_FREE_SILO for source package only silos?
[15:44] <Saviq> Laney, tried without it?
[15:44] <Laney> no
[15:44] <Laney> scared
[15:44] <Saviq> Laney, I assume it's published?
[15:44] <Laney> ya
[15:45] <Saviq> Laney, then just do without
[15:45] <Saviq> Laney, worst case it will fail
[15:45] <Saviq> Laney, but doubt that
[15:45] <Saviq> Laney, it will just not find any MPs, so it will just do the usual
[15:45] <Laney> I guessed it would, but wanted to confirm
[15:45] <Laney> now I have a scapegoat, so ok :P
[15:47] <plars> didrocks: ok, I still need to do the jenkins bits to make it complete, but I've done the script changes for allowing an arg to specify the revision all the way through the ci process and ran locally. It just finished up and those other tests passed just fine it seems, but there were 3 failures in ubuntu_system_settings on this run
[15:49] <sil2100> Laney: citrain is a smart system, it will bail out if something is wrong so no worries!
[15:50] <didrocks> Saviq: was is fixed?
[15:50] <didrocks> it*
[15:50] <Saviq> didrocks, let me try
[15:50] <Laney> seems to be working
[15:50] <didrocks> Saviq: I dunno, just back from exercise :)
[15:50] <didrocks> so I was asking
[15:50] <Saviq> didrocks, nope, https://ci-train.ubuntu.com/job/landing-002-1-build/9/console
[15:50] <didrocks> Laney: yeah, it should do the right thing
[15:51] <didrocks> Saviq: hum
[15:51] <didrocks> Saviq: ok, so same thing than yesterday
[15:51] <ogra_> imgbot, status 272
[15:51] <didrocks> Saviq: what leaded to that? I would be interested
[15:51] <Saviq> didrocks, not sure
[15:51] <imgbot> Image 272 for mako has not finished the tests, status is: Running
[15:51] <Saviq> didrocks, I interrupted the previous job (which I think failed to upload platform-api)
[15:51] <ogra_> slow stuff is slow  ...
[15:52] <didrocks> Saviq: yeah, seeing that, but that doesn't explain
[15:52] <didrocks> Saviq: I try to commit in an atomic way
[15:52] <Saviq> didrocks, and the next run was like that - tried to rebuild platform-api and u-s-c
[15:53] <didrocks> Saviq: yeah, I need to understand how that can happen
[15:53] <Saviq> didrocks, last reconfigure was way before that
[15:53] <didrocks> Saviq: with shell access willbe harder…
[15:53] <Saviq> didrocks, +out
[15:54] <didrocks> Saviq: right :p
[15:54] <didrocks> http://people.canonical.com/~platform/citrain/landing-002
[15:54] <Saviq> didrocks, looks like valid json
[15:54] <didrocks> Saviq: yeah, but no status
[15:54] <didrocks> I wonder how…
[15:55] <Saviq> ah
[15:55] <didrocks> Saviq: it was "building" as the status before, right?
[15:55] <Saviq> didrocks, maybe it didn't update in time?
[15:56] <Saviq> didrocks, between me interrupting the old build and starting a new one?
[15:56] <dbarth> sil2100: can i have a new silo for a doc fix (html api)?
[15:56] <dbarth> line 30
[15:56] <didrocks> Saviq: no, this is done in sync
[15:56] <Saviq> didrocks, no idea then :|
[15:57] <sil2100> dbarth: looking
[15:57] <sil2100> dbarth: sure, it's ready?
[15:57] <didrocks> Saviq: I'm trying to sync hard :p
[15:59] <sil2100> dbarth: since the ready field is not set yet ;p
[15:59] <didrocks> Saviq: think*
[16:00] <ogra_> you think you are trying to sync ?
[16:00] <didrocks> :p
[16:01] <didrocks> Saviq: I really don't get it, is it urgent? Otherwise, I'll appreciate a fresh eye to see if we do have a race
[16:01] <dbarth> sil2100: ah sorry, just setting it; i was reviewing the branch
[16:01] <didrocks> robru: around?
[16:01] <didrocks> plars: ^
[16:06] <cyphermox> rsalveti: I'd like to land mtp today; should I bother going through you guys for the citrain landing stuff or just file it myself, since I have the necessary knowledge and access? I'd just need an extra pair of eyes for additional testing before landing
[16:07] <cyphermox> well. that and I really need to write the test plan and all :)
[16:10] <sil2100> mhr3: m&c ready!
[16:18] <mhr3> sil2100, ty, cleaning
[16:39] <davmor2> popey: so no I can't replicate it I can log in no problems it gives me the wrong facebook view let me try twitter instead
[16:44] <davmor2> popey: do you ever get this closing an app http://davmor2.co.uk/~davmor2/apps-nil.png ?
[16:44] <fginther> bfiller, I just found a package ofono-phonesim-autostart error for dialer-app that prevents CI testing on the phone: https://bugs.launchpad.net/dialer-app/+bug/1300880
[16:44] <fginther> bfiller, please let me know if there is someone else I should ping
[16:44] <popey> davmor2: i rarely close apps, so no.
[16:45] <popey> kinda annoyed I can't start update-manager on #250
[16:45] <bfiller> fginther: boiko should know
[16:45] <fginther> boiko, any thoughts on https://bugs.launchpad.net/dialer-app/+bug/1300880 ?
[16:46] <bfiller> fginther: have changes been made recently to the ofono-phonesim-autostart?
[16:46] <davmor2> popey: it should in theory open it was tested on 250
[16:46] <popey> davmor2: and surely someone would have said by now!?
[16:46] <davmor2> popey: so I guess it's just you]
[16:47] <popey> bah
[16:47] <t1mp> what can cause this? 2014/04/01 18:25:21 Cannot push /home/tim/.cache/ubuntuimages/pool/ubuntu-c3473594f772b94d7a14e917124a119e3439da5658c4265077eda3b16b186f4b.tar.xz to device
[16:47] <t1mp> see http://pastebin.ubuntu.com/7190485/ I get it when I try to flash image 272
[16:48] <t1mp> where is it pushing it? maybe the partition is full? http://pastebin.ubuntu.com/7190500/
[16:48] <fginther> bfiller, it looks like the current version of the package was uploaded march 5
[16:49] <t1mp> oh, wrong channel
[16:49] <ogra_> t1mp, to /cache ...
[16:49] <fginther> bbiab
[16:49] <ogra_> (which translates to /android/cache/ on a running ubuntu)
[16:49] <boiko> fginther: hmm, that's the first time I see this error, let me take a look at the ofono-phonesim-autostart script
[16:50] <t1mp> ogra_: none                            4.0K     0  4.0K   0% /android
[16:50] <t1mp> that is weird
[16:50]  * t1mp rebooting device
[16:50] <ogra_> t1mp, /android/cache/recovery is what you want to check
[16:50] <ogra_> or just /android/cache
[16:50] <ogra_> /android is just a dir, not a partition
[16:51] <t1mp> ogra_: why is /android then listed in df?
[16:52] <t1mp> ah. it is an empty partition with other stuff mounted in it? weird
[16:52] <ogra_> check mount :)
[16:52] <popey> davmor2: ok, getting a qmlscene crash
[16:52] <ogra_> root@ubuntu-phablet:/# mount|grep " /android "
[16:52] <ogra_> none on /android type tmpfs (rw,relatime,size=4k)
[16:52] <t1mp> recovery is full with old images :s
[16:53] <ogra_> its a tmpfs ...
[16:53] <t1mp> I think I had that before and I reported a bug.
[16:53] <ogra_> just rm them
[16:53] <ogra_> (if there is a bug open already)
[16:53] <t1mp> ok, thanks
[17:10] <robru> Saviq, around? I fixed silo 2, feel free to rebuild/reconfig/whatever now
[17:14] <Saviq> robru, thank you
[17:14] <robru> Saviq, you're welcome
[17:15] <robru> Saviq, I also made it easier for us to fix this issue if it happens again, so it shouldn't take as long if it happens again. next step is to stop it from happening...
[17:15] <Saviq> robru, :)
[17:21] <popey> davmor2: had to sign out of U1 and sign back in again to get click update manager working!
[17:22] <popey> I now have 30 updates in update manager to install
[17:22] <popey> most I've ever had
[17:23] <dbarth> o/ silo 007 tested and verified; ready to publish
[17:26] <robru> dbarth, thanks
[17:28] <robru> dbarth, ok, published
[17:31] <dbarth> thanks robru
[17:31] <robru> you're welcome!
[17:32] <dbarth> ok, next silo then ;)
[17:33] <davmor2> popey: nice
[17:36] <davmor2> popey: and I bet most of them will stay in there due to the naming bug too :)
[17:41] <popey> davmor2: not on #250
[17:41] <davmor2> popey: ha nice
[17:41] <popey> its slowly chugging through them
[17:42] <davmor2> popey: oh nice so it only lists them still while the app is open close it and reopen and you get a clean list
[17:42] <pmcgowan> flappy popey is the fist app in my apps screen, very unnerving everytime
[17:42] <popey> hah
[17:42] <popey> and its broken, you may as well remove it
[17:43] <pmcgowan> right
[17:43] <pmcgowan> popey, I thought app updates got into settings, no?
[17:43] <popey> the developer was hosting it on a 30 day trial web space, and didnt pay to extend it
[17:43] <dbarth> robru: o/ i have a new silo request on line 31
[17:43] <popey> pmcgowan: nope, still not migrated over
[17:43] <dbarth> robru: this one will be of interest to you; it's an additional fix for the icon mismatches
[17:46] <robru> nice
[17:46] <robru> dbarth, just fix the URL, you have the branch not the MP
[18:03] <dbarth> uh sure
[18:03] <dbarth> robru: ok, now it's ready
[18:03] <Saviq> fginther, hey, https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/6285/console looks like some config issue?
[18:05] <robru> dbarth, oh, unity-webapps-qml is already in silo 1. Can you add that to the same silo? if they're both just two small bugfixes it will be easier than having two silos (which can lead to conflicts)
[18:11] <fginther> Saviq, hmmm, I'm a little confused by that. I understand why it's trying to install unity8-autopilot, but I don't know why it can't find the matching version of unity8
[18:11] <fginther> Saviq, let me poke
[18:12] <Saviq> rsalveti, hey, will you be able to help tweaking touch seed: http://paste.ubuntu.com/7190810/ for silo 015?
[18:12] <Saviq> rsalveti, the service is a Recommends of the image provider, so we need to seed it
[18:14] <davmor2> D'oh popey I just notice that bug is against flo I was testing on mako where it works give me 5 I'll try it on mako
[18:14] <davmor2> flo even]
[18:15] <davmor2> popey: I'm assuming it is down to desktop verses mobile web views
[18:18] <nuclearbob> cihelp: is anybody getting a core dump running ubuntu-emulator on current trusty?
[18:19] <doanac> nuclearbob: i'm running it right now and it seems functional
[18:19] <doanac> i haven't poked it too hard yet, but its booting up
[18:19] <nuclearbob> doanac: okay.  mine won't even start, so I must have a problem with my setup
[18:20] <popey> davmor2: could be, yes
[18:20] <popey> davmor2: and on mako 250, no more updates waiting :D all done and re-launched, all good
[18:21] <dbarth> robru: they are of a quite different nature, but hmm, wny not, yeah, let's do that
[18:21] <nuclearbob> I was missing an i386 gl library!
[18:21] <robru> dbarth, yeah, it will be easier, because if I assign two silos, then whichever one publishes first will force the other one to rebuild, which is annoying.
[18:22] <dbarth> robru: ok changed, and i will try to reconfigure now
[18:23] <robru> dbarth, should work, let me know if it doesnt'
[18:28] <davmor2> popey: on your flo try clicking on the word username rather than the box
[18:28] <popey> davmor2: facebook has no "username"
[18:29] <popey> fuuu. latest music app doesn't run on #250
[18:31] <davmor2> popey: here have a sad trombone
[18:31] <davmor2> sadtrombone.com
[18:35] <popey> bah, my stupid build I think
[18:56] <nuclearbob> doanac: I got the emulator fixed.  Is there a good/easy way to use it to run smoke jobs?  I'm still trying to figure out that autopilot job failure from earlier, since running without the ppa still causes the failure
[18:57] <doanac> nuclearbob: you can run the equivalent at home. that job is based on lp:ubuntu-test-cases/touch and uses ./scripts/run-smoke
[18:58] <nuclearbob> doanac: okay, I tried just copying the job, but it seems stuck on adb reboot bootloader
[18:58] <doanac> nuclearbob: hmm. sounds like the phone could be out of whack then
[18:59] <doanac> this at home or in the lab you are  doing this?
[18:59] <nuclearbob> doanac: this is at home on the emulator since my phone isn't supported any more
[18:59] <doanac> nuclearbob: this isn't going to work on the emulator yet
[18:59] <doanac> we are still working on supporting it
[19:00] <nuclearbob> doanac: okay.  So if I just have a maguro, I can't replicate this?  I guess I'll have to either hassle someone about getting a mako or get thomi to look at this when he gets here
[19:00] <doanac> nuclearbob: yeah. or log into the phone in question in the lab and poke around
[19:01] <nuclearbob> doanac: also a good idea, thanks for reminding me of that option
[19:01] <doanac> ie, rerun the job, and then access it while the job is failing
[19:01] <boiko> fginther: hey, I'm seeing that same upstart error that you saw on ofono-phonesim-autostart when trying to connect to the device via ssh on image #272
[19:01] <boiko> fginther: start: Unable to connect to Upstart: Empty address ''
[19:07] <thomi> doanac: nuclearbob: so.. perhaps we should have a call about this? Or are you guys confident that it can be sorted?
[19:08] <fginther> boiko, so ofono-phonesim-autostart isn't even installed on my device running 270. I wonder if this made it into the image on accident?
[19:08] <nuclearbob> thomi: when I tried to run the command manually, it seemed stuck until an apt-get -f install, so I'm trying the job again
[19:08] <cyphermox> robru: hey
[19:09] <cyphermox> robru: I think I have the jist of it, to fix yesterday's issue with stuff being stopped and all
[19:09] <cyphermox> http://paste.ubuntu.com/7191130/
[19:09] <boiko> fginther: it is installed when installing dialer-app-autopilot or messaging-app-autopilot
[19:09] <thomi> doanac: I thought our job was a clone of whatever the smoke tests used. How come our jobs fails but (apparently) the smoke testing job succeeds?
[19:10] <doanac> thomi: you guys do it slightly differently. you are installing all the packages up-front. we now install packages as they are needed by each test
[19:10] <doanac> but the job is failing installing ofono-ism. i'd think this would be pretty easy to re-create
[19:11] <thomi> doanac: I think that, for all our long-term sanity to remain intact, the ap-release-gatekeeper job needs some way to remain in sync with the smoke test job
[19:11] <fginther> doanac, uhh, this -> https://bugs.launchpad.net/dialer-app/+bug/1300880
[19:12] <thomi> doanac: it seems like the *only* difference is that we want to add a PPA.
[19:12] <doanac> thomi: and potentially run hooks
[19:12] <thomi> hmmm, ok
[19:12] <doanac> thomi: delete the PACKAGES parameter from your job and you'll be in sync with us
[19:13] <thomi> doanac: how does your job know when to install packages?
[19:13] <doanac> fginther: that looks like nuclearbob's issue
[19:13] <doanac> thomi: we have it coded in a testconfig file
[19:13] <doanac> we were asked to install things and uninstall per test
[19:14] <doanac> so the way daily-image testing runs, we probably just see the dialer app fail instead of seeing evyerhing fail
[19:15] <thomi> well, that's good news (kind of?)
[19:15] <thomi> at least it's not just us having this issue :)
[19:15] <doanac> misery loves company
[19:19] <boiko> fginther: nuclearbob: seems like something is wrong with upstart, this empty address error thing, but I don't see any change in upstart mentioned
[19:22] <Saviq> robru, hey, will you be able to help tweaking touch seed: http://paste.ubuntu.com/7190810/ for silo 015?
[19:22] <Saviq> robru, the service is a Recommends of the image provider, so we need to seed it
[19:31] <Saviq> cyphermox, maybe you're around and can halp with ↑?
[19:32] <cyphermox> sure
[19:32] <Saviq> that'd be the last thing to do before landing silo 015 with right edge (and plenty other goodness), other than you guys ACKing it
[19:32] <Saviq> cyphermox, would you have time to take that silo for a spin?
[19:33] <cyphermox> well, if the service is a recommends of something already in the seed you probably don't need to seed it
[19:33] <Saviq> cyphermox, we do
[19:33] <Saviq> cyphermox, recommends are not installed on touch
[19:33] <cyphermox> ah
[19:33] <Saviq> cyphermox, not when apt-get installing, even
[19:34] <cyphermox> very well, but I'm not touching the seed until things are completely landed
[19:34] <Saviq> cyphermox, I thought we'd upload it to the silo? is what we usually did?
[19:35] <cyphermox> is it?
[19:35] <Saviq> cyphermox, yeah, this way it goes into proposed together, and will only migrate when everything's good
[19:35] <cyphermox> sounds fine
[19:35] <cyphermox> is your silo already configured for this?
[19:36] <Saviq> cyphermox, I'll add to the CI train list, please reconfigure
[19:36] <robru> Saviq, oops sorry, was afk. i don't have access to change the seeds myself
[19:36] <cyphermox> ok
[19:36] <Saviq> cyphermox, done, silo 15 ready for reconfigure
[19:37] <Saviq> (and an upload)
[19:37] <Saviq> robru, no worries
[19:37] <Saviq> robru, found my victim :)
[19:42] <Saviq> robru, fwiw, I don't think there's any special access needed to change the seeds, it's just a source package as usual, afaict
[19:42] <Saviq> robru, only thing is syncing that back to bzr
[19:42] <robru> Saviq, no, the seeds are stored in a special branch, tightly controlled by the dark cabal.
[19:43] <Saviq> robru, well, yeah, lp:~ubuntu-core-dev/ubuntu-seeds/ubuntu-touch.trusty - not *that* special :D
[19:43] <Saviq> robru, but indeed you're not part of ~ubuntu-core-dev :)
[19:43] <robru> Saviq, exactly ;-)
[19:44] <Saviq> robru, cyphermox, please fight between yourselves who'll take silo 015 for a spin, I'm +2 on it
[19:44] <robru> Saviq, also, the branch isn't just a standard source package, the source package is generated from that bespoke format... i don't actually know how to do the conversion from that format into a package.
[19:44] <robru> Saviq, cyphermox : on it
[19:44] <Saviq> robru, that part's easy :)
[19:44] <cyphermox> robru: you mean reconfiguring?
[19:45] <robru> cyphermox, Saviq I thought it was ready to publish?
[19:45] <Saviq> robru, caveat: unset UPSTART_SESSION before upgrading
[19:45] <Saviq> robru, only the seed change is missing
[19:45] <cyphermox> robru: no, it would be missing the seed in the silo
[19:45] <Saviq> robru, which == apt-get install thumbnailer-service
[19:45] <Saviq> robru, and lxc-android-config won't upgrade, as usual... due to the bind-mounted things
[19:46] <robru> Saviq, what about after it's published? what happens to people who just upgrade without unsetting UPSTART_SESSION (eg, everybody)
[19:47] <cyphermox> indeed, that's important
[19:47] <Saviq> robru, not everybody, everybody upgrade via images
[19:47] <Saviq> robru, cyphermox, the adb upgrade broke the root session
[19:47] <robru> Saviq, ok, but how will the image be created if we have to unset an environment variable? who is setting this variable?
[19:47] <cyphermox> Saviq: UPSTART_SESSION part fixed in lxc-android-config, is that what you mean?
[19:47] <Saviq> cyphermox, it's fixed in the session
[19:48] <Saviq> robru, it's only a problem with adb
[19:48] <Saviq> robru, image builds fine
[19:48] <robru> ok
[19:48] <Saviq> robru, I don't think we can do anything for upgraderd
[19:48] <Saviq> upgraders
[19:49] <Saviq> as it requires installing the fixed ubuntu-touch-session and logging out / back in
[19:49] <Saviq> cyphermox, "the session" meaning ubuntu-touch-session
[19:49] <Saviq> https://code.launchpad.net/~xnox/ubuntu-touch-session/no-export-bogus-environment/+merge/213646
[19:50] <Saviq> it's a bad thing that happened, but I've no idea how to fix that without telling people to jump through a hoop or two
[19:52] <cyphermox> Saviq: is lxc-android-config already in the ppa?
[19:52] <Saviq> cyphermox, yes
[19:52] <robru> cyphermox, I have to run to a doctor's appointment, can you handle the seed change? I'll be back in 2ish hours
[19:53] <cyphermox> doh, conflict with landing 002 :(
[19:53] <cyphermox> robru: yeah, I'm on it
[19:53] <robru> cyphermox, great thanks. I can test things when I'm back if needed
[19:53] <fginther> Saviq, was there a direct archive upload of unity8?
[19:53] <robru> bbl
[19:53] <Saviq> fginther, yes
[19:53] <Saviq> cyphermox, 002 is just prep
[19:54] <Saviq> cyphermox, any conflicts with that are to be overridden
[19:54] <cyphermox> Saviq: yeah, but I don't remember this from one shot to the other
[19:54] <cyphermox> so as soon as this finishes I'll re-do the reconfig and ignore conflicts
[19:54] <fginther> Saviq, ok, that's somehow causing the CI problem, but I don't know why yet, will keep looking
[19:54] <Saviq> cyphermox, ok
[19:55] <Saviq> fginther, well, we'll only sync archive with trunk with silo 015 landing
[19:55] <Saviq> fginther, so it kind of makes sense
[19:59] <cyphermox> alright, so it's reconfigured nao
[20:04] <cyphermox> Saviq: so since you know about the thumbnailer-service...
[20:04] <cyphermox> get_thumbnail returns a string, I guess that's a path to a thumbnail file?
[20:08] <Saviq> cyphermox, truth be told I don't know enough, but I imagine so, yeah :)
[20:08] <Saviq> cyphermox, https://code.launchpad.net/~jamesh/thumbnailer/dbus-service/+merge/212347
[20:08] <Saviq> cyphermox, from grepping that, yeah
[20:27] <jhodapp> can someone make qtubuntu-media and qtvideo-node rebuild in landing silo 006?
[20:28] <plars> robru, cyphermox: given that http://ci.ubuntu.com/smokeng/trusty/touch/mako/272:20140401.1:20140331/7506/ looked pretty good, my understanding was that rerunning 270 further would be unnecessary. As for the click-image-test failure, that's been fixed up in the testcase itself and merged now
[20:32] <jhodapp> robru, can you make qtubuntu-media and qtvideo-node rebuild in landing silo 006?
[20:32] <Saviq> jhodapp, I can, new upload, I assume?
[20:32] <jhodapp> Saviq, yes
[20:32] <jhodapp> and thanks
[20:33] <Saviq> jhodapp, running https://ci-train.ubuntu.com/job/landing-006-1-build/1/console
[20:33] <jhodapp> Saviq, thank you much
[20:33] <Saviq> jhodapp, always :)
[20:39] <Saviq> cyphermox, you'll upload the seed change to the PPA will you?
[20:39] <cyphermox> yes
[20:39] <Saviq> cyphermox, ok, let me know if you need anything from me
[20:39] <cyphermox> yes
[20:40] <Saviq> I'd really like that silo to land today^Wtonight :)
[20:42] <cyphermox> Saviq: will do best I can, sorry it took a bit I had to look up how to do the package
[20:44] <Saviq> cyphermox, no worries there
[20:45] <cyphermox> so it's in progress now, I'm updating the meta package
[20:50] <cyphermox> go germinate go! :)
[21:09] <cyphermox> slangasek: so I wanted to add some code to watch signals and avoid a cancelled build run to break the config files for citrain; so I'll commit a string change for this ready state we talked about too
[21:10] <slangasek> cool
[21:23] <Saviq> cyphermox, apparently the train didn't like the powerd changelog update
[21:23] <Saviq> rsalveti, you around?
[21:24] <cyphermox> good thing that I asked for a rebuild then
[21:27] <Saviq> cyphermox, weird thing is it built fine before
[21:27] <Saviq> cyphermox, and the branch didn't change...
[21:27] <Saviq> cyphermox, so yeah, replacing rsalveti's MP with my own with the changelog fixed, and rebuilding again
[21:30] <cyphermox> robru: when you're around to take a look: https://code.launchpad.net/~mathieu-tl/cupstream2distro/cleanup-on-kill/+merge/213728   but please don't merge this right out, I want didrocks to take a good look at it too :)
[21:31] <cyphermox> Saviq: means another reconfigure? :D
[21:31] <Saviq> cyphermox, already done
[21:31] <cyphermox> ok
[21:31] <cyphermox> slangasek: https://code.launchpad.net/~mathieu-tl/cupstream2distro/silo-ready-wording/+merge/213730
[21:31] <cyphermox> robru: ^
[21:32] <cyphermox> Saviq: so u-touch-meta is in the PPA and published, so as soon as stuff is rebuilding fine and tested, I should be able to publish it
[21:33] <Saviq> cyphermox, yup
[21:33] <Saviq> cyphermox, I'll let you know when I'm ready with it, or actually when built, so that we can parallelize testing?
[21:34] <cyphermox> sure
[21:49] <fginther> Saviq, I poked some more on https://jenkins.qa.ubuntu.com/job/generic-mediumtests-runner-mako/6285/console. It appears to be failing because it can't find ubuntu-thumbnailer-impl-0. Is this known to be missing from the archive?
[21:49] <Saviq> fginther, it's only going to be there with the landing of silo 015
[21:50] <Saviq> fginther, so the error message was probably just unhelpful, but the failure was indeed expected, sorry for having you chasing ghosts
[21:52] <fginther> Saviq, no worries
[22:08] <robru> jhodapp|afk, sorry, was at the doctor.
[22:09] <robru> cyphermox, looking
[22:13] <Saviq> cyphermox, this thing must be a new check... it's the third MP I have to mangle to fix the trusty vs. UNRELEASED in changelog ;(
[22:23] <robru> Saviq, what's going on with the changelog? if you're modifying changelogs yourself you should set them as UNRELEASED and citrain will adjust it for you
[22:23] <Saviq> robru, yeah, but that seems to be a new requirement
[22:23] <Saviq> robru, we had trusty there
[22:23] <Saviq> robru, and it built fine until this evening :|
[22:24] <robru> hmm, not sure what changed, you'd have to ask didrocks about that (basically only he tinkers with that code)
[22:24] <Saviq> robru, what's more... https://code.launchpad.net/~didrocks/unity8/get-needed-dep/+merge/213619 is just syncing a change from distro...
[22:24] <Saviq> not sure I can change that to UNRELEASED...
[22:25] <robru> Saviq, well, if it's already in distro then you should leave it as 'trusty'... it should check that (comparing trunk to distro) before building. it's wrong to take a release and call it UNRELEASED.
[22:25] <Saviq> robru, yeah
[22:25]  * Saviq thinks that's all
[22:26] <Saviq> looks like we have again a concurrency (or lack of) problem... I've to wait until all packages build to find out that the last one had issues :/
[22:26] <robru> Saviq, if you watch the PPA instead of watching the jenkins build job, you should be able to see failures sooner
[22:27] <Saviq> robru, it doesn't even reach the ppa
[22:27] <Saviq> robru, because it fails when preparing packages
[22:27] <Saviq> robru, and does not upload the successful ones until all complete
[22:27] <robru> Saviq, how long does the prepare step take??
[22:28] <robru> Saviq, prepare is just building source packages, shouldn't take that long... it's the builds that are slwo
[22:28] <Saviq> robru, 16 mins
[22:28] <Saviq> robru, last one
[22:28] <Saviq> robru, with the move to prodstack... they got some 3 times slower...
[22:28] <Saviq> at least unity8 as an example :|
[22:28] <robru> oh
[22:29] <Saviq> so yeah, it's not great
[22:29] <Saviq> anyway, /me moves to the hotel, then, will follow up on that from there
[22:29] <robru> Saviq, not sure who to ping about that. surely we can assign more resources for such an important piece of infrastructure...
[22:30] <Saviq> robru, didrocks is aware, was talking to webops today, but didn't get far
[22:30] <Saviq> robru, he escalated with Evan
[22:30] <Saviq> robru, so hopefully we'll get there
[22:30] <robru> Saviq, ok, glad to hear people are on it
[22:31] <Saviq> biab
[22:51] <tedg> Can someone reconfigure silo 4 for me please?
[22:51] <tedg> And kick off a build
[22:52] <tedg> Perhaps a robru or cyphermox? ^
[22:52]  * tedg reads topic like a good IRC user :-)
[22:53] <robru> tedg, on it
[22:53] <tedg> robru, Thanks!
[22:53] <robru> tedg, you're welcome
[22:55] <cyphermox> robru: you're too fast
[22:55] <robru> cyphermox, haha. yeah, i should twiddle my thumbs longer before replying ;-)
[22:55] <cyphermox> yes :)
[22:57] <robru> tedg, building: https://ci-train.ubuntu.com/job/landing-002-1-build/15/console
[23:01] <robru> boiko, you got silo 5
[23:07] <robru> oh crap
[23:08] <robru> tedg, here is the real build for silo 4: https://ci-train.ubuntu.com/job/landing-004-1-build/1/console
[23:08] <robru> let's everybody just ignore that i rebuilt silo 2 for nothing
[23:10] <robru> Saviq, sorry, what happened in silo 2 while I was out? I see merge conflicts, and not in debian/changelog. are you working on that?
[23:10] <Saviq> robru, yeah, we were trying to resolve some weird missing symbols with mterry
[23:11] <robru> Saviq, oh, it was silo 15 that you gave +2 for.
[23:11] <Saviq> robru, last status is there's conflicts, mterry needs to resubmit the branch after resolving
[23:11] <Saviq> robru, yes
[23:11] <Saviq> robru, 002 is just a prep silo for split greeter
[23:11] <robru> Saviq, so what happened in silo 15 then? I see you got the seed there. so that's ready for publishing? cyphermox did you poke at silo 15?
[23:11] <Saviq> robru, cyphermox wanted me to rebuild and retest everything, that's ongoing
[23:11] <Saviq> robru, after having fixed the changelogs in 4 projects...
[23:12] <robru> Saviq, oh ok.
[23:12] <robru> I'm heading out for dinner soonish but I can potential come back, do some basic sanity checks, and then hit publish later tonight.
[23:13] <Saviq> robru, will let you know
[23:13] <robru> Saviq, thanks
[23:16] <robru> tedg, build failed because the revert in distro, forcing a rebuild: https://ci-train.ubuntu.com/job/landing-004-1-build/2/console
[23:39] <robru> Saviq, oh wow, just testing silo 15 for the first time, right edge looks *sliiiiick* ;-)
[23:39] <robru> anyways, off for dinner. bbl
[23:39] <Saviq> robru, it does, don't it :)
[23:49] <bregma> robru, could you do me the favour of granting a silo for line 32?