[02:10] <imgbot> === IMAGE 191 building (started: 20150506-02:10) ===
[03:40] <imgbot> === IMAGE 191 DONE (finished: 20150506-03:40) ===
[03:40] <imgbot> === changelog: http://people.canonical.com/~ogra/touch-image-stats/191.changes ===
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
[07:54] <Saviq> trainguards, is it expected that dist-upgrade from PPAs doesn't really work? the 1001 priority for overlay made it so that, for example: http://pastebin.ubuntu.com/10995761/
[07:56] <Saviq> citrain tool might work because it disables the archive before upgrading?
[08:08] <sil2100> Saviq: hey! I think to answer this question I would have to poke infinity first
[08:09] <Saviq> sil2100, sure, just trying to pre-empt any unforeseen problems - at the very least people need to be informed how to deal with that
[08:09] <Saviq> sil2100, because if they just go add-apt-repository silofoo, the dist-upgrade won't work
[08:21] <Mirv> Saviq: weird
[08:32] <Mirv> sil2100: are teams branching for vivid automatically or should they be pushed? I mean, the first two phone related wily landings are now brewing
[08:32] <Mirv> sil2100: it'd seem like so at least for the indicator-messages and indicator-network, so I guess teams are doing that correctly
[08:33] <Mirv> on the other hand, those are both on desktop too so it's obvious they need the branches
[08:53] <sil2100> Mirv: I think we need to discuss that still
[08:57] <Mirv> Saviq: I can confirm your problem. this is a very recent thing (related to wily release?) since I was successfully upgrading + testing last week still.
[08:58] <Mirv> http://pastebin.ubuntu.com/10996141/
[08:58] <Saviq> Mirv, yes, there's a new prefs file in /etc/apt/preferences.d/
[08:59] <sil2100> Mirv, Saviq: the archive pinning was enabled only yesterday
[09:00] <sil2100> That's why it's a recent change
[09:05] <Mirv> citrain tool doesn't work either
[09:06] <Mirv> jibel: ^ QA needs to be aware that silo upgrades currently don't work (by default) either via apt or citrain tool
[09:06] <Mirv> so if one trusts the citrain tool the device is not really upgraded
[09:07] <jibel> Mirv, if by "doesn't work" you mean silos must be pinned with a higher score than the overlay PPA, it's part of our silo testing instruction
[09:07] <jibel> s
[09:08] <jibel> Mirv, citrain tool must be fixed indeeed
[09:11] <Mirv> jibel: oh, yes I mean that. then no problem, excellent!
[09:12] <jibel> Mirv, np, thanks for the heads up. The public doc has not been updated, fixing it.
[09:12] <Mirv> filed bug #1452190
[09:12] <ubot5> bug 1452190 in phablet-tools (Ubuntu) "citrain tool needs to pin the silo with higher score than overlay PPA" [Undecided,New] https://launchpad.net/bugs/1452190
[09:16] <jibel> Mirv, FYI https://wiki.ubuntu.com/LandingTeam/SiloTestingGuidelines#Install_silos_with_overlay_PPA_enabled
[09:33] <pete-woods> trainguards: hi guys. any chance of getting my silo request (line 58) allocated? or have I missed something?
[09:35] <sil2100> pete-woods: it looks like we have no free silos right now
[09:36] <pete-woods> sil2100: ah right, that explains it then!
[09:36] <sil2100> pete-woods: so until we have some free, there's no possibility of allocating one...
=== sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: low on vivid silos. Ubuntu-rtm gates closed.
[09:36] <pete-woods> frustrating when half the silos are "ready to build"
[09:37] <sil2100> Yeah...
[09:38] <pete-woods> although I kinda think that silos should be dynamically allocated by the citrain system
[09:38] <sil2100> Kaleo, dbarth_, greyback__, rsalveti: hey! I see you guys have assigned silos that are not built yet even
[09:38] <pete-woods> as opposed to being a static sresource
[09:38] <sil2100> pete-woods: it's one of the goals, we have plans of having ephemeral silos in the nearest future
[09:39] <pete-woods> nice!
[09:39] <sil2100> But it's still something we don't have
[09:39] <pete-woods> yeah, I understand you guys are super busy holding all this stuff together, while at the same time trying to make newer stuff
[09:40] <greyback__> sil2100: ah I got silo38, I must have missed the notification, thanks
[09:40] <sil2100> I think the ephemeral PPA task is actually on CI team's plate, so we just need to wait for them to find time
[09:42] <sil2100> jibel, davmor2: how's the 'delta' testing of the ubuntu-rtm image going?
[09:42] <jibel> sil2100, we are doing a full run, there are too many updates to just to a delta
[09:43] <jibel> sil2100, overall it's going well, there is a crash in HERE T&C when launched from the wizard
[09:43] <cjwatson> slangasek,sil2100,ogra_: On the nusakan crontab issue: the only good reason for VCS/live divergence right now is that system-image needs to append a few things to the crontab, which don't make sense in lp:ubuntu-cdimage because they require tools from elsewhere.  I very strongly believe that that needs to be split out; as a first step, I would suggest getting a new "system-image" user created on nusakan, and then we can move all the ...
[09:44] <cjwatson> ... system-image stuff across to there and it can have its own crontab
[09:44] <cjwatson> infinity: Not sure I understand the question.  Live filesystem builds aren't really "in" an archive - they have an archive, but it's a source rather than a target.
[09:45] <jibel> sil2100, almost 60% done
[09:45] <cjwatson> slangasek,sil2100,ogra_: (then, at some point before precise goes out of support, we can first move system-image into prodstack with devopsolution, then cdimage)
[09:45] <sil2100> jibel: crash? Didn't we fix that last time with the oxide upload?
[09:45] <jibel> sil2100, it has been fixed, it a slightly different case
[09:45] <jibel> +is
[09:46] <sil2100> cjwatson: hm, I wouldn't mind splitting out the system-image stuff to its own crontab, although I must say that I'm only using these parts on the cdimage user anyway
[09:47] <cjwatson> sil2100: I know, but they don't belong in the cdimage user
[09:48] <cjwatson> sil2100: system-image was (IMO wrongly) deployed under the same user, probably because it was expedient
[09:48] <cjwatson> sil2100: But there's really no good reason that it needs to be, and splitting it out to a separate user would be a good first step towards splitting it out to a separate machine
[09:49] <sil2100> +1
=== greyback__ is now known as greyback
=== pedronis_ is now known as pedronis
=== MacSlow is now known as MacSlow|lunch
=== chihchun is now known as chihchun_afk
[12:11] <rsalveti> sil2100: I didn't allocate my silos, they were actually removed before the spreadsheet reset
[12:11] <sil2100> rsalveti: ah, ok :)
[12:11] <rsalveti> sil2100: so feel free to clean silo 34 and 36
[12:19] <jibel> sil2100, on the spreadsheet, how is the request id generated for clicks and tarballs, it is missing on some lines
[12:19] <jibel> ?
=== _salem is now known as salem_
[12:25] <sil2100> jibel: it's generated by a trainguard by a button-press, but I didn't do that as I knew the scripts weren't re-targetted
[12:25] <sil2100> jibel: are you retargeting now?
[12:26] <sil2100> rsalveti: ACK
[12:28] <sil2100> rsalveti: thanks for the info :)
=== MacSlow|lunch is now known as MacSlow
[12:34] <jibel> sil2100, I'm fixing the bot to create the cards for me
[12:35] <jibel> sil2100, but without a request id there is no way to differentiate landings
[12:36] <sil2100> jibel: I will be setting those as I was before if the bot will be retargetted - as mentioned, normally I was setting the UID everytime I saw the entry but didn't see any sense now since the scripts anyway didn't work
[12:36] <sil2100> One moment
[12:36] <jibel> sil2100, maybe we could just use a version number instead?
[12:37] <jibel> sil2100, since G + H + a version should be unique
[12:37] <jibel> and easier to parse by a human than a timestamp
[12:39] <sil2100> For the UID?
[12:39] <sil2100> What version number would you want to use?
[12:39] <sil2100> Do you use the UID number as a human, or only in scripts?
[12:51] <jibel> sil2100, for clicks it would be the version of the click package, for custom and device the same version that is on the image. If it makes sense. For standard silos, we can get the version from the PPA but for non-package landing it is nowhere
[12:54] <sil2100> Well, the idea is that the UID is generated by a landing team member in the similar way as we assign silos, so that we still keep control of what lands
[12:54] <sil2100> And I didn't want to diverge the UID mechanics from what we had in the main sheet
[12:54] <jibel> sil2100, ack, no problem.
[14:44] <boiko> is the latest vivid-proposed image broken on krillin for anyone else or is it just me?
[15:10] <infinity> cjwatson: Well, yes, there is no real "target", but there's the source where it's built, as you say.  And if you configure extra_ppas via the json/API, then request a cdimage build, you get build-in-primary, wich those PPAs configured.  If you use EXTRA_PPAS="foo bar", you get foo and bar as PPAs, but the livefs built in foo, rather than primary.  That's the bit I was saying was unintuitively different.
[15:10] <infinity> cjwatson: (And, indeed, is potential motivation to use EXTRA_PPAS instead of configuring the livefs via json, in case one wants, say, to be able to update livecd-rootfs/live-build in their PPA_
[15:11] <infinity> )
[15:14] <cjwatson> infinity: Oh, right - the archive is set in the requestBuild call, so you could reasonably change cdimage.livefs.live_build_lp_kwargs to try to fetch that from the livefs metadata if EXTRA_PPAS isn't set.
[15:16] <infinity> cjwatson: Yeah, one could.  I still think "use the first PPA" is a magic behaviour, though.  Probably breaking out an ARCHIVE= that mirrors the API's archive= would make more sense, for when people really want the build to happen elsewhere.  (it also means you can build in ARCHIVE= without it being configured in the final product via extra_ppas)
[15:16] <infinity> cjwatson: And I'll probably do that.  But was poking you to see if you had a good argument for the current behaviour before I break it. :P
[15:16] <cjwatson> infinity: http://paste.ubuntu.com/10997753/
[15:17] <cjwatson> infinity: I think this is a reasonable default, but I have no problem with you adding ARCHIVE= that overrides it.  At the time I did this we didn't have a standard archive reference syntax.
[15:17] <cjwatson> But now we do, so we might as well use it.
[15:24] <fginther> slangasek, were you able to find what you needed regarding trunk branch transition to wily? If it helps to discuss over a hangout, I'm available
[16:00] <jibel> sil2100, can you add the same headers to the 'Tarballs' tab than the pending tab?
[16:01] <jibel> sil2100, row 3 of the pending sheet
[16:03] <sil2100> jibel: hm, ok, I think I'll make it look exactly the same as the first sheet
[16:05] <jibel> sil2100, works for me, I'd need uids for every new row too, otherwise the entry will be ignored
[16:12] <sil2100> Sure, for the new ones I'll make sure we assign those :)
[16:28] <dobey> fginther: hi. are all the config/job updates for wily done?
[16:31]  * sil2100 drives home in a few mins
=== alan_g is now known as alan_g|EOD
[17:32] <fginther> dobey, we're still waiting on ISOs to be available to finish the work, but I can go ahead and move lp:unity-scope-click to wily if it's a blocker
[17:34] <dobey> oh ok, so there are no jenkins slaves set up for wily yet?
[17:34] <fginther> dobey, done, do you need an MP re-run?
[17:34] <fginther> dobey, the builders are setup for wily
[17:35] <dobey> i don't need an MP re-run, no. i'm just wondering so i can get landings through
[18:07] <dobey> fginther: can you move lp:ubuntuone-credentials to wily too?
[18:08] <dobey> oh i guess maybe lunch time over there now :)
[18:09] <fginther> dobey, done
[18:09] <fginther> and yes, your first ping found me at lunch
[18:10] <ogra_> he has people-tracking-pings ?
[18:10]  * ogra_ makes a note to get a pingshield 
[18:10] <fginther> scary, isn'tit
[18:10] <dobey> heh
[18:10] <dobey> skynet is here.
[18:11] <dobey> fginther: hmm, we do have an MP for lp:unity-scope-click that was created on friday, which doesn't seem to have been picked up by ps-jenkins bot still.
[18:11] <dobey> fginther: https://code.launchpad.net/~kyrofa/unity-scope-click/utilize_cmake_extras/+merge/258049
=== ljp is now known as lpotter
[18:15] <fginther> dobey, ack. I'll ask the current vanguard to take a look as it's unrelated to the original topic we were on from yesterday...
[18:16] <dobey> ok
[18:16] <dobey> thanks
[18:16] <fginther> cihelp, please take a look at dobey's request on no CI for https://code.launchpad.net/~kyrofa/unity-scope-click/utilize_cmake_extras/+merge/258049
[18:17] <cprov> fginther: on it
[18:17] <fginther> thanks
=== om26er_ is now known as om26er
=== boiko_ is now known as boiko
[19:36] <dobey> cprov: any luck with that btw? i see it still hasn't been picked up yet
[19:39] <cprov> dobey: yup, https://code.launchpad.net/~kyrofa/unity-scope-click/utilize_cmake_extras/+merge/258049 just finished
[19:40] <dobey> cprov: ah ok, thanks!
[19:42] <cprov> dobey: I am not sure if the otto failure is genuine ... might be related with the missing ISO for wily.
[19:42] <cprov> dobey: err, s/might be/is
[19:43] <dobey> yeah
[19:43] <dobey> but i would expect those to fail anyway
[19:43] <dobey> they've always had problems with restarting unity8 and such
[19:52] <ogra_> imgbot, map 191
[19:52] <imgbot> krillin rtm version: 191 maps to mako version: 225"
[19:52] <imgbot> krillin rtm version: 191 maps to generic_x86 version: 217"
[19:52] <ogra_> imgbot, map 191 vivid
[19:52] <imgbot> mako ubuntu version: 191 maps to krillin version: 204"
[19:52] <imgbot> mako ubuntu version: 191 maps to generic_x86 version: 193"
[19:52] <ogra_> jhodapp, ^^
[19:52] <jhodapp> ogra_, nice :)
[19:53] <jhodapp> imgbot, map 186
[19:53] <imgbot> krillin rtm version: 186 maps to mako version: 220"
[19:53] <imgbot> krillin rtm version: 186 maps to generic_x86 version: 212"
[19:53] <ogra_> (note it defaults to RTM)
[19:54] <jhodapp> ogra_, how do you do vivid?
[19:54] <ogra_> append vivid to the request
[19:54] <ogra_> imgbot, map 186 vivid
[19:54] <imgbot> mako ubuntu version: 186 maps to krillin version: 199"
[19:54] <imgbot> mako ubuntu version: 186 maps to generic_x86 version: 188"
[19:55] <jhodapp> ogra_, perfect, thanks
[19:55] <ogra_> i'll switch vivid to the default after RTM is gone
[19:55] <rsalveti> nice
[19:55] <ogra_> i should perhaps do that for #snappy too ;)
[19:56] <jhodapp> ogra_, +1
[20:24] <dobey> trainguards: can i get silos for lines 65/66, or we don't have silos available?
[20:30] <robru> dobey: ah, there is just one available. which one do you want first?
[20:33] <dobey> robru: 65, it'll go through fast
[20:52] <robru> dobey: sorry for the delay, 36 is ready
[20:53] <dobey> just started the build :)
[21:10] <nik90> hey guys, is there a document/link which shows all hotfixes that are making its way into OTA-3.5 considering that QA is testing it this week?
[21:10] <jhodapp> imgbot, map 180 vivid
[21:10] <imgbot> mako ubuntu version: 180 maps to krillin version: 193"
[21:10] <imgbot> mako ubuntu version: 180 maps to generic_x86 version: 182"
[21:11] <pmcgowan> nik90, https://launchpad.net/canonical-devices-system-image/+milestone/ww19-ota
[21:11] <nik90> pmcgowan: ah thnx :)
[21:11] <pmcgowan> np
[21:37] <robru> dobey: sigh, I just noticed there are 6 silos that are assigned but totally idle (never built, ppas empty). I'll free those and assign your other one
[21:38] <robru> dobey: no qa for 36?
[21:38] <robru> actually I guess that makes sense for wily.
[21:39] <dobey> robru: it's a simple change that only adds something to the autopilot helpers, the branch is from qa team, and no phone images for wily
[21:39] <robru> dobey: right, thanks
[21:39] <robru> publishing
[21:39] <dobey> thanks
[21:40] <dobey> i'll deal with the other one in the morning i guess. need to go now :)
[21:40] <robru> dobey: ok, it's22 when you're ready
[21:40] <dobey> k, thanks, i guess i can start the build now anyway, as that's easy :)
=== robru changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Ubuntu-rtm gates closed. Please ping us when you are ready for a silo.
=== robru changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: Ubuntu-rtm gates closed. Please ping trainguards when you are ready for a silo.
[21:43] <oSoMoN> trainguards: hey, can I have a silo for line 67, please?
[21:45] <robru> oSoMoN: https://youtu.be/rL5ZVljj4vg
[21:45] <oSoMoN> :)
[21:46] <robru> oSoMoN: ok, silo 4 prepped for you
[21:46] <oSoMoN> robru, thanks man
[21:46] <robru> oSoMoN: you're welcome
[21:47] <robru> alex-abreu: you around? I freed up some silos, but won't assign your requests until you confirm you're around to use them.
=== salem_ is now known as _salem
[22:57] <alesage> trainguards not finding jhodapp's qtubuntu-media changes in silo 25, instead dialer-app: http://pastebin.ubuntu.com/11000786/ , something I missed?
[22:58] <robru> alesage: dialer-app is coming from stable-phone-overlay, not silo 25.
[22:58] <alesage> robru I missed a memo :) , can you instruct?
[22:58] <robru> alesage: still looking, one sec
[22:59] <robru> alesage: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-025/+packages not sure what's going on exactly, the package is there in vivid
[23:01] <robru> alesage: so stable-phone-overlay is a blessed PPA that allows us to continue doing "vivid development" without actually destabilizing the official vivid archive. stuff published there gets rolled into phone images but not into desktop or server iimages.
[23:02] <alesage> robru, this change should appear in a fresh flash?  or. . . ?
[23:02] <robru> alesage: basically that's a red herring, it just means that dialer-app has been published since the last time an image was built.
[23:02] <robru> or at least since the image you're using was built
[23:03] <alesage> robru, hmpf sorry this overlay concept is new to me
[23:04] <alesage> robru, is the citrain tool the correct one to use in this case?
[23:04] <robru> alesage: no worries, it's just a PPA like any other, but it has special privileges.
[23:04] <robru> alesage: yeah it should be the same as far as I know
[23:04] <alesage> robru, o got it ok
[23:04] <robru> alesage: can you try like "adb shell sudo apt-get install qtubuntu-media" or something? that package is in the PPA and it's newer than what's in the overlay, I'm not sure why citrain tool won't install it
[23:04] <alesage> robru, but I think I'm missing the 25 intended change, if that makes sense
[23:04] <alesage> right ok one sec
[23:04] <robru> alesage: yeah, still trying to figure thatout
[23:06] <alesage> robru http://pastebin.ubuntu.com/11000879/
[23:06] <alesage> possibly something newer came in and preempted?
[23:06] <robru> alesage: oh, the overlay must have pinned it...
[23:06] <alesage> aha
[23:07] <robru> slangasek: ^^ can you comment on that paste? seems lower version from overlay PPA is winning over silo ppa version.
[23:07] <robru> alesage: for now try "adb shell sudo apt-get install qtubuntu-media=0.7.1+15.04.20150428.1-0ubuntu1" and that should unblock you for testing that silo
[23:07] <alesage> robru, many thanks
[23:08] <robru> alesage: you're welcome
[23:29] <slangasek> robru: hah oh boy
[23:29] <slangasek> robru: yes, that's an unexpected side effect of the overlay being pinned
[23:30] <robru> slangasek: what should we do? I guess citrain tool probably should disable overlay PPA, shouldn't it? since it also disables updates from main archive
[23:30] <slangasek> no, the overlay ppa has to be enabled
[23:30] <slangasek> the citrain tool could remove the pin
[23:30] <robru> how do I go about that?
[23:30] <slangasek> or else pin its own packages higher
[23:31] <slangasek> robru: I haven't looked at the file paths, but it'll be /etc/apt/preferences or /etc/apt/preferences.d/<something>
[23:33] <slangasek> robru: if the tool would add a higher pin for the silo, that would give the best / most consistent results
[23:34] <robru> alesage: slangasek: https://bugs.launchpad.net/ubuntu/+source/phablet-tools/+bug/1452190 heh, reported already
[23:34] <ubot5> Ubuntu bug 1452190 in phablet-tools (Ubuntu) "citrain tool needs to pin the silo with higher score than overlay PPA" [Undecided,Confirmed]
[23:54] <alex-abreu> robru, I am around
[23:54] <robru> alex-abreu: great, want a silo? ;-)
[23:54] <alex-abreu> robru, oh yes :)
[23:56] <robru> alex-abreu: ok, 31 and 32
[23:56] <alex-abreu> robru,  thx
[23:56] <robru> alex-abreu: you're welcome