[00:10] <robru> bfiller: please approve: https://code.launchpad.net/~michael-sheldon/ubuntu-keyboard/fix-1448019/+merge/257783
[00:52] <bfiller> robru: done
[00:53] <bfiller> sorry about that
[00:53] <robru> bfiller: thanks
[02:05] <imgbot> [03:40] <imgbot> [03:40] <imgbot> [04:20] <bzoltan> Mirv: it seems that the overlay PPA's QtC plugin is out of sync https://ci-train.ubuntu.com/job/ubuntu-landing-016-1-build/149/console
[04:28] <Mirv> bzoltan: there is no q-p-u in overlay, but you need to sync that ubuntu2 from archives to your trunk
[04:29] <bzoltan> Mirv: Ahh... of course. So we had a release to the archive what was not merged to the trunk... I see
[04:37] <bzoltan> sergiusens:  would you mind to give me the patch you applied on the qtcreator-plugin-ubuntu and pushed to the archive? It would make easier to fix the trunk.
[04:42] <bzoltan> sergiusens:  I see that you habe added a distro patch to the archive packge. It now blocks the CI process for the lp:qtcreator-plugin-ubuntu
[05:44] <oSoMoN> trainguards: good morning, can silo 3 be published, please?
[05:50] <Mirv> oSoMoN: sure, I'll just make sure it's configured to go to the overlay
[05:50] <Mirv> oh, this's the old silo, great :)
[05:57] <Mirv> pedronis: hi! regarding line 27 in the spreadsheet, what should be done about it, removing? the two MP:s listed there are 404 like I wrote in there 2 weeks ago.
[05:57] <Mirv> https://code.launchpad.net/~pedronis/account-polld/supp-sha384-512-certs/+merge/256477 + https://code.launchpad.net/~pedronis/ubuntu-push/automatic-into-vivid/+merge/256535
[06:09] <oSoMoN> Mirv, thanks!
[06:17] <tvoss> good morning
[06:25] <Mirv> good morning tvoss
[06:26] <tvoss> Mirv, hey there :)
[06:29] <Mirv> fixing your "MP" to be MP instead of branch
[07:10] <pedronis> Mirv: yes, they can be removed
[07:34] <Mirv> pedronis: thanks
[08:41] <mzanetti> sil2100, hey there. Do you know whom I have to ping to grant permissions for silo building/landing to someone?
[08:43] <sil2100> mzanetti: hey, I can add that person if anything
[08:44] <sil2100> Is that person trained in the train? ( ;) )
[08:44] <mzanetti> sil2100, I gave him a walkthrough, not sure if there's a requirement to get a walkthrough from you guys
[08:44] <mzanetti> sil2100, talking about tsdgeos (aacid on launchpad) here
[08:45] <sil2100> Ah, sure, let me add him
[08:45] <mzanetti> perfect, thanks
[08:45] <mzanetti> I'll assist his first few landings
[08:46] <sil2100> mzanetti: he should be now train-enabled
[08:46] <mzanetti> nice. thanks :)
[08:46] <sil2100> yw ;)
[08:49] <alan_g> trainguards I'm working through the release process for Mir 0.13 and have reached the point of adding a line to the CI spreadsheet. But it seems to be read-only and I note the topic says there are problems. Am I blocked? Or can you help?
[08:52] <sil2100> alan_g: hey! So, to have access to the spreadsheet you need to be added as a lander
[08:52] <alan_g> sil2100: ok, how does that happen?
[08:52] <sil2100> alan_g: I can do that for you - have you been trained on the usage by someone?
[08:53] <sil2100> The usage of the CI Train
[08:53] <alan_g> I have document I'm fixing as I go
[08:54] <sil2100> alan_g: you should be added now, remember about the https://wiki.ubuntu.com/citrain/LandingProcess documentation
[08:55] <sil2100> I'll try browsing through it today and making sure it's 100% up to date
[08:56] <alan_g> sil2100: thanks, have access and am adding that step (and reference) to the Mir doc
[08:56] <Mirv> sil2100: can you join #ubuntu-app-devel?
[09:00] <sil2100> Mirv: what's up?
[09:01] <Mirv> sil2100: see there, a developer having a problem on desktop
[09:01] <Mirv> (14.04)
[09:20] <Mirv> ogra_: is "allow whoopsie to be permanently turned off" goind to land to rtm-14.09 or can the line be removed?
[09:22] <Mirv> rsalveti: will "Upstream fixes and optimizations" (libhybris) land to rtm-14.09 or can the line be removed?
[09:22] <Mirv> I'd guess not but checking before removing
[09:22] <ogra_> Mirv, thjats waiting fro a fix to whoopsie ... seb128 kind of led that bug in the end ... not sure where we stand, but i suspect whoopsie wont be fixed before the hotfix OTA anymore
[09:23] <seb128> ogra_, yeah, not likely going to be fixed before the next ota update
[09:24] <ogra_> Mirv, kick it :)
[09:24] <Mirv> ogra_: thanks!
[09:27] <Mirv> sil2100: somehow we seem to hit a cap at silo 037, ie claims that no silos left
[09:27] <sil2100> huh
[09:28] <sil2100> Let me check that
[09:30] <Mirv> I just changed 30 -> 40 the number of production silos in metadata...
[09:30] <Mirv> it's probably not affecting anything as it was at just 30
[09:31] <sil2100> Ah, I think I know what's wrong
[09:36] <sil2100> Uh oh, I think I see a bug in the train code
[09:40] <rvr> pstolowski: ping
[09:44] <sil2100> wtf
[09:54] <pstolowski> rvr, pong
[09:55] <rvr> pstolowski: Hey
[09:55] <pstolowski> rvr, hi! what's up?
[09:55] <rvr> pstolowski: I cannot downgrade libunity-scopes3
[09:55] <rvr>  *** 0.6.9+15.04.20150429~rtm-0ubuntu1 0
[09:55] <rvr>         500 http://ppa.launchpad.net/ci-train-ppa-service/landing-003/ubuntu-rtm/ 14.09/main armhf Packages
[09:56] <rvr> pstolowski: I guess the original package is only available in the image and not in the archives :-/
[09:56] <pstolowski> rvr, sudo apt-get install libunity-scopes3=0.6.9+15.04.20150126~rtm-0ubuntu1 did this for me (on clean image + rtm silo 3; not dist-upgraded)
[09:57] <pstolowski> rvr, (I had to apt-get update)
[09:57] <pstolowski> rvr, ^ that's what you miss I think
[09:57] <rvr> Ahhh, that's it
[09:57] <rvr> Yeah
[10:00] <greyback_> sil2100: hey, is train ready for landing to wiley yet?
[10:00] <greyback_> if not, should I just wait? Or do we land to an overlay ppa of some kind?
[10:05] <mzanetti> also, if I select "vivid" in the spreadsheet now, this will go to the vivid phone image afaict. in which case, do we need QA signoff?
[10:06] <sil2100> greyback_: it's not open for wily yet... but there are chances the phone will stay focused only on vivid
[10:06] <sil2100> But I need more info to confim that
[10:07] <sil2100> mzanetti: if you target vivid the it's targetted for the nearest vivid OTA release
[10:07] <greyback_> sil2100: ok, thanks for clarifying
[10:10] <greyback_> sil2100: vivid need QA signoff?
[10:10] <sil2100> greyback_: yeah...
[10:10] <greyback_> sil2100: ack
[10:43] <sil2100> Mirv: this prepare_silo issue is absurd
[10:44] <sil2100> Mirv: I checked the code, checked with cyphermox-test and every test I make shows that find_first_available should just properly return silo 38
[10:45] <sil2100> Mirv: I even ran a python snippet from find_first_available and it just worked
[10:45] <Mirv> sil2100: hmm, is it possible 38/39/40 would be marked as allocated even though according to spreadsheet they're not?
[10:46] <Mirv> sil2100: oh, but find_first_available returns 38..
[10:46] <sil2100> Mirv: no, I checked that too, the dirs are empty
[10:46] <Mirv> weird
[10:46] <Mirv> someone has decided 37 should be enough for everybody
[10:46] <sil2100> Mirv: well, it *should* return 38 - the snippet I ran returns 38, all code shows it should but in prepare_silo it just seems to return None or ''
[10:46] <sil2100> Still looking
[10:49] <tsdgeos> trainguards: i'm going to need a silo for row 64 if possible to drive my first landing \o/
[10:51] <sil2100> tsdgeos: the train is misbehaving and doesn't want to assign moar silos ;) Debugging it now
[10:51] <tsdgeos> sil2100: i see, thanks :)
[11:12] <didrocks> cihelp: hey! since yesterday ps-trusty-desktop-i386-1 is stopped, and I can't get it restarted, mind having a look? (it's a jenkins node used in s-jenkins)
[11:29] <sil2100> Mirv: so, to get a better understanding of what is going on, I added some debug info to the train but now of course we need to wait for webops to redeploy it
[11:29] <sil2100> Mirv: and they don't have time right now
[11:29]  * sil2100 loves how swift the debugging is with the current model
[11:37] <Mirv> sil2100: ok...
[11:38]  * sil2100 needs to go for lunch
[11:39] <sil2100> Mirv: in the meantime there's not much we can do
[11:50] <Mirv> right
[11:56] <cwayne> sil2100, davmor2 heya, just added a line to the spreadsheet for clicks/tarballs for the twitter trending scope to be updated in the store
[11:56] <cwayne> should be really fast to test, all that was changed was some error checking
[11:56] <jibel> cwayne, thanks, I'll create a card
[12:05] <mzanetti> cihelp: I think I'd need a new exception for the licensecheck: https://code.launchpad.net/~mzanetti/unity8/inputinfo-plugin/+merge/258241
[12:24] <jibel> cwayne, re twitter-trends LGTM, I get a completely blank scope for some hashtags but it's the same behaviour with 1.0.9
[12:24] <jibel> cwayne, when do you plan to release a new custom tarball for RTM?
[12:25] <cwayne> jibel, today :)  just building and writing up what's changed
[12:25] <cwayne> jibel, also thanks, I'll upload new twitter to the store
[12:49] <rsalveti> sil2100: yes, feel free to remove it (libhybris)
[12:49] <rsalveti> Mirv: ^
[13:11] <Mirv> rsalveti: thanks
[13:34] <bzoltan> sergiusens: ping
[13:35] <sergiusens> bzoltan: pong
[13:37] <bzoltan> sergiusens: I have merged your ninja upload of the qtc plugin :) to our trunk and we have pushed 6 important usability and security fixes. Would you be able to help us to SRU the latest release to 15.04?  In a way or an other the app devs will get this change.
[13:37] <bzoltan> sergiusens: because if I do not SRU these fixes then I have to push itto the SDK PPA and direct the developers on Vivivd to use the PPA
[13:39] <sergiusens> bzoltan: I can't SRU, I'm not a core dev
[13:39] <ogra_> you really have to fix that
[13:39] <cjwatson> err that's entirely orthogonal
[13:39] <ogra_> that too :)
[13:40] <cjwatson> although ubuntu-ui-toolkit is in main, so in this specific case it does matter :)
[13:40] <sergiusens> cjwatson: oh, nice; I need to learn the process then; but that means bzoltan can also do that
[13:40] <sergiusens> ah, there
[13:40]  * sergiusens needs to read that wiki page again
[13:41] <bzoltan> cjwatson:  it is the qtcreatot-plugin-ubuntu in this case... the austin sprinters have found couple of issues
[13:41]  * cjwatson tries to view /~sergiusens/+participation, gets annoyed enough to go and attack https://bugs.launchpad.net/launchpad/+bug/1409680
[13:50] <mzanetti> cihelp, ping :)
[13:51] <ev> mzanetti: please don't use contextless pings
[13:51] <ev> don't ask to ask :)
[13:52] <mzanetti> ev, well, I asked before and didn't get a reply.
[13:52] <mzanetti> so I wanted to find out if someone is actually subscribed to this
[13:53] <mzanetti> ev, so my question was if I could get an exception added to the licensecheck in jenkins
[13:53] <mzanetti> https://jenkins.qa.ubuntu.com/job/unity8-vivid-amd64-ci/840/console
[14:00] <om26er> rsalveti, re: silo 30 for push. Does it strictly need to be tested on krillin or Arale is fine ?
[14:02] <ev> mzanetti: is that legally compatible?
[14:03] <mzanetti> ev, it's upstream Qt
[14:03] <mzanetti> ev, basically I coped code from a merge proposal to Qt because we need it now already
[14:03] <mzanetti> copied
[14:03] <didrocks> cihelp: 2nd try: since yesterday ps-trusty-desktop-i386-1 is stopped, and I can't get it restarted, mind having a look? (it's a jenkins node used in s-jenkins)
[14:03] <mzanetti> ev, here's the diff: https://code.launchpad.net/~mzanetti/unity8/inputinfo-plugin/+merge/258241
[14:04] <rsalveti> om26er: arale is fine
[14:04] <mzanetti> ev, I *think* it's fine, as the Qt packages we use have the same things in them. That said, IANAL
[14:15]  * didrocks feels ignored…
[14:16] <ogra_> /ignore didrocks
[14:16] <didrocks> ogra_: see! :)
[14:17] <ogra_> heh
[14:18] <greyback_> trainguards: can I get a reconfigure on vivid silo 37 plz (spreadsheet row 12)
[14:18] <sil2100> greyback_: on it
[14:18] <greyback_> cheers
[14:19] <sil2100> greyback_: did you guys abort the silo build? Just be sure not to abort the jenkins build jobs before the packages are uploaded to the PPA
[14:19] <sil2100> The train is fragile in that regard ;)
[14:20] <greyback_> sil2100: guilty as charged ;)
[14:20] <greyback_> but no packages were generated, I aborte pretty quickly
[14:21] <sil2100> greyback_: let's hope nothing got broken, since if it's cancelled during package preparation then it leaves stale files that can get in the way of building again ;) But a reconfigure should wipe things clean for us I guess
[14:21] <didrocks> sil2100: hum, that's handled, isn't it? (aborting the jenkins build, the transaction is committed at the end and all uploads happen in the end)
[14:21] <didrocks> and all states files are removed
[14:22] <greyback_> sil2100: let's hope so. I'll let you know :)
[14:23] <sil2100> didrocks: right now it's a bit fragile, the build job gets confused when the scripts are killed in the middle of preparing source packages, before their upload
[14:23] <didrocks> sil2100: argh, it was done before to be transactional on that regard and generate stamped files at the end (while cleaning everything which didn't get stamped and cleaning), that changed, ok
[14:25] <om26er> rsalveti, also any other TestPlan you want to be run except for ubuntu-push ? The testing instructions are missing on the Spreadsheet
[14:25] <rsalveti> om26er: just ubuntu-push
[14:29] <ev> mzanetti: cool, I've confirmed that it is a licence compatible change, and have created a task for it on our vanguard board
[14:30] <ev> we're a bit shorthanded on that today, so it may be a little while, but rest assured the request is with us
[14:30] <fginther> didrocks, someone will have a look before too long and back to you
[14:30] <mzanetti> ev, awesome, thanks.
[14:30] <didrocks> fginther: thanks!
[14:31] <sil2100> Mirv: ...aaand it seems that it suddenly magically works, now it sees the other silos
[14:31] <sil2100> Mirv: I didn't touch anything even
[14:37] <pete-woods> sil2100: FYI the network indicator RTM silo from earlier is tested now. just waiting on QA
[14:37] <sil2100> pete-woods: \o/ excellent, thanks
[14:37] <sil2100> john-mcaleely: hey! How's the device tarball going?
[14:38] <john-mcaleely> sil2100, still in progress
[14:43] <sil2100> cwayne: I see the twitter trend scope passed QA - is that the only change that would land in the new custom tarball?
[14:45] <cwayne> sil2100, nope, see the line below that in the spreadsheet :)
[14:46] <sil2100> cwayne: ah! :) No question then!
[14:46] <cwayne> sil2100, :)
[14:54] <om26er> pedronis, Hi! How long is it normally supposed to take for a Telegram push notification to appear ?
[14:54] <pedronis> om26er: should be quick
[14:54] <pedronis> ralsina_: ^
[14:55] <ralsina_> om26er: seconds
[14:56] <om26er> ralsina_, hmm take ~10-15 seconds. That normal I guess ?
[14:56] <ralsina_> om26er: that's more or less what it takes, yes
[14:56] <ralsina_> om26er: some days it's a bit faster :-)
[14:57] <om26er> ralsina_, would love to see it faster :)
[14:57] <ralsina_> om26er: the bottleneck is usually between telegram server's and ours, IIRC
[14:58] <om26er> ralsina_, right, the notifications in the app are instant, so probably the problem is on our end
[14:59] <ralsina_> om26er: to get the push, telegram has a server that forwards the message to ours. That extra step takes a few seconds, karni knows best
[15:02] <jibel> rvr, what is the status of rtm/silo 0
[15:02] <jibel> ?
[15:04] <om26er> pedronis, how can I verify bug 1446584 fix ?
[15:05] <pedronis> om26er: I need to go afk, rsalveti can explain that as well
[15:11] <rsalveti> om26er: you can verify via syslog, if powerd got a lock or not (in a delta of 5 minutes)
[15:11] <rsalveti> I added that info to the bug
[15:11] <rsalveti> Easy way to check for the bug:
[15:11] <rsalveti> $ tail -f /var/log/syslog | grep powerd
[15:11] <rsalveti> Then look for acquire/release SysState. It shouldn't happen when flight mode is enabled. When either cellular data or wifi is enable, you should see that at every 5 minutes, as it's the default delta for push-client.
[15:12] <om26er> rsalveti, ok, thanks.
[15:46] <Mirv> sil2100: hmmm..
[15:47] <om26er> sil2100, is spreadsheet functional again or do we need to request manual landings ?
[15:47] <sil2100> om26er: it's ok now... at least for now
[15:47] <sil2100> ;)
[15:47] <sil2100> Mirv: yeah, anyway the bug itself was completely crazy, looked like something not really code related
[15:57] <rvr> mandel: ping
[16:01] <sil2100> cwayne: any news on the custom tarball? :)
[16:02] <cwayne> davmor2, ^
[16:02] <davmor2> sil2100: yes it's custom and a tarball
[16:03] <sil2100> Custom tarball for RTM? The queue only mentiones vivid
[16:04] <cwayne> this ball of tar is quite custom indeed
[16:04] <cwayne> yeah, it's RTM, i built the same for vivid as well though, so that we could do a 2-for-1 :)
[16:04] <davmor2> sil2100: happy now
[16:05] <sil2100> hm, ok, since I was confused since the spreadsheet said 'not ready yet' still ;)
[16:05] <cwayne> oops sorry, ill edit
[16:06] <cwayne> i swear i'd changed it already
[16:06] <cwayne> guess not
[16:14] <tedg> Are their wily silos? It doesn't seem a selection in the spreadsheet.
[16:15] <tedg> Can I just write in ubuntu/wily ?
[16:20] <rvr> jibel: Approving silo 0
[16:20]  * tedg just did it
[16:21] <jibel> rvr, thanks, only bit missing is a device tarball now
[16:24] <sil2100> Damn
[16:24] <sil2100> mandel: ping
[16:25] <sil2100> mandel: we have a problem - silo 000 in RTM was built from https://code.launchpad.net/~mandel/location-service/back-port-1441619/+merge/258072 , which is Rejected
[16:25] <sil2100> mandel: we would need the silo rebuilt with https://code.launchpad.net/~rsalveti/location-service/syncing-vivid/+merge/258127 instead ;/
[16:25] <jibel> sil2100, does that mean we have to retest it?
[16:25] <sil2100> We just probably wasted QA cycles damn it
[16:26] <sil2100> jibel: I would have to do a comparison to see if they're source-identical
[16:26] <sil2100> Let me check that
[16:26] <sil2100> But I'm a bit irritated
[16:26] <jibel> sil2100, could this check be done *before* the silo can even be marked ready for QA?
[16:27] <jibel> sil2100, and if it is  not fully approved, then it cannot be marked for QA.
[16:27] <sil2100> jibel: I think it was in the past, but people protested since their workflow was to sometimes test stuff in the silo before top-approving branches
[16:28] <sil2100> jibel: well, the perfect solution would be hard to do with the spreadsheet
[16:28] <jibel> sil2100, it wouldn't block dev workflow
[16:28] <sil2100> What we could do is add a check for Rejected merges
[16:28] <sil2100> Rejected or Superseeded
[16:28] <jibel> sil2100, it would just prevent people from marking a silo ready for QA while it isn"t
[16:28] <sil2100> And inform during build-time about those
[16:28] <sil2100> jibel: yeah, you can't easily do that with the spreadsheet
[16:29] <jibel> sil2100, I don't want to add an extra manual task for such a thing that is clearly what computer are good at.
[16:29] <jibel> plus a bunch of 's' in the sentence :)
[16:30] <rsalveti> sil2100: I did rebuitl with that
[16:30] <rsalveti> maybe the spreadsheet reverted something
[16:30] <sil2100> rsalveti: you did? Did you reconfigure after changing in the spreadsheet?
[16:31] <sil2100> Since the config still shows the old MR
[16:31] <rsalveti> weird
[16:32] <sil2100> rsalveti: are the two branches code-identical?
[16:32] <rsalveti> sil2100: nops
[16:32] <rsalveti> https://code.launchpad.net/~rsalveti/location-service/syncing-vivid/+merge/258127 is the right one
[16:33] <sil2100> Crap
[16:33] <rsalveti> and is the one that produced the package that is in that ppa
[16:34] <sil2100> rsalveti: ah, indeed, the build log says so too
[16:34] <sil2100> rsalveti: now this is a mystery
[16:35] <sil2100> rsalveti: ok, so the silo is configured with the old branch but the build job indeed used the new branch
[16:36] <sil2100> rsalveti: maybe someone reconfigured the silo after your build and at that time the spreadsheet reverted itself, so it reconfigured it to the old branch
[16:37] <sil2100> rsalveti: could you make sure the spreadsheet row for this landing has the correct MPs and source pkgs? I'll reconfigure it then, watch-only and publish
[16:37] <jibel> sil2100, so it's all good and no retest, right?
[16:41] <rsalveti> sil2100: it's just this MR
[16:41] <rsalveti> so just use that
[16:41] <rsalveti> no more src package
[16:42] <sil2100> ACK
[16:42] <sil2100> jibel: yeah
[16:42] <jibel> sil2100, now we really need a device tarball
[16:42] <jibel> john-mcaleely, ^ any news?
[16:42] <sil2100> john-mcaleely: ping ^
[16:43] <sil2100> rsalveti: thanks for clearing it up o/
[16:43] <john-mcaleely> jibel, sil2100 fixed build running on capomastro now
[16:43] <sil2100> \o/
[16:43] <john-mcaleely> so, 45 mins away
[16:43] <jibel> john-mcaleely, good, thanks!
[16:43] <pmcgowan> nice
[16:43] <sil2100> john-mcaleely: you still need to test it then, right?
[16:43] <john-mcaleely> that's in the 45 min eta
[16:44] <john-mcaleely> takes around 30 mins to do the testplan :-)
[16:44] <jibel> sil2100, when there is a device tarball, davmor2 will be done with the validation of the custom, can you start a build and will do the validation device bits directly on the promotion candidate
[16:44] <john-mcaleely> (if this build fails, I have a tested, locally built, tarball ready to go
[16:44] <jibel> s/will/we will/
[16:45] <sil2100> jibel: yeah, I'll just build a new image once we have silo 000 in the archives
[16:45] <sil2100> Actually...
[16:45] <sil2100> hm
[16:45] <robru> tedg: congrats on getting the first wily silo: http://people.canonical.com/~platform/citrain_dashboard/#?q=wily
[16:45] <robru> (14)
[16:45] <sil2100> slangasek, cjwatson: I published indicator-network to 14.09 a while ago and it didn't appear in -proposed
[16:46]  * tedg does a wily dance
[16:46] <tedg> robru, Thanks!
[16:46] <robru> tedg: you're welcome
[16:46] <jibel> sil2100, well, wait until we have the 2 tarballs
[16:46] <sil2100> jibel: those can land afterwards, they're not part of the rootfs anyway
[16:46] <jibel> sil2100, fine
[16:46] <cjwatson> indicator-network 0.5.1+15.04.20150505~rtm-0ubuntu1 in 14.09 (Cannot copy DDEBs to a primary archive)
[16:47] <sil2100> huh?
[16:47] <cjwatson> that's odd, I thought we removed that check recently
[16:48] <cjwatson> oh, not entirely
[16:48] <sil2100> cjwatson: strange, since we published packages today to rtm already, maybe infinity re-enabled something when he was working on wily?
[16:48] <cjwatson> no, that was re-enabled a while back
[16:48] <cjwatson> you probably published stuff that was built before we switched that back on
[16:49] <slangasek> cjwatson: does that mean the silo will need to be rebuilt?
[16:49] <cjwatson> no
[16:49] <cjwatson> but it needs somebody to reconfigure the ubuntu-rtm archive
[16:49] <sil2100> cjwatson: it's a new silo, it got built today actually
[16:49] <cjwatson> which would be, let's see
[16:49] <sil2100> cjwatson: assigned and built today
[16:50] <cjwatson> oh look, techboard
[16:50] <cjwatson> slangasek: oh hai
[16:50] <slangasek> :-)
[16:50] <slangasek> point me at the button
[16:50] <cjwatson> slangasek: archive = lp.distributions['ubuntu-rtm'].main_archive; archive.build_debug_symbols = True; archive.lp_save()
[16:50] <cjwatson> in "lp-shell production devel"
[16:51] <sil2100> devel rulz
[16:51] <sil2100> Why is it still devel, I never had any issues with that right now, would love it to become the new stable version
[16:51] <cjwatson> sil2100: then I guess we might need to redo the publish step manually, or can you retrigger that from your end nowadays?
[16:51] <cjwatson> API guarantee, although basically the whole system is broken there
[16:51] <sil2100> cjwatson: I think we can retrigger it from the train, since I think it would just re-publish then
[16:51] <slangasek> cjwatson: http://pastebin.ubuntu.com/10990880/
[16:52] <cjwatson> wut
[16:52] <slangasek> you tell me ;)
[16:52] <cjwatson> slangasek: could you 'rm ~/.launchpadlib/api.launchpad.net/cache/*wadl*' and try again?  possibly old cached wadl
[16:53] <slangasek> old cached wadl, not the finest of whiskeys
[16:53] <slangasek> cjwatson: same error
[16:53] <cjwatson> slangasek: you're definitely using devel?
[16:53] <slangasek> I'm definitely typing 'lp-shell production devel' :)
[16:54] <slangasek> $ lp-shell production devel
[16:54] <slangasek> E: ipython not available. Using normal python shell.
[16:54] <slangasek> Connected to LP service "https://api.launchpad.net/" with API version "devel":
[16:54] <slangasek> Note: LP can be accessed through the "lp" object.
[16:54] <slangasek> >>>
[16:54] <cjwatson> slangasek: ok, sod it, try https://launchpad.net/ubuntu-rtm/+archive/primary/+admin
[16:54] <cjwatson> check "Build debug symbols", save
[16:54] <slangasek> Not allowed here
[16:55] <sil2100> Uh oh
[16:55] <cjwatson> ah, I totally misread the security adapter
[16:55] <cjwatson> needs webops
[16:55] <slangasek> ok :)
[16:55] <cjwatson> or wgrant when he wakes up, but that probably won't be for a few hours
[16:56] <cjwatson> so you can point them at either of those methods, but the web UI is probably less confusing
[16:58] <slangasek> cjwatson, sil2100: 09:58 < seelaman> slangasek: done
[16:59] <sil2100> \o/
[16:59] <sil2100> Thanks, let me try a re-publish
[17:01] <om26er> Mirv, re qtdeclarative silo, did you compare autopilot test results with previous version ?
[17:08] <sil2100> cjwatson, slangasek: could you check if the packages got published correctly this time?
[17:08] <om26er> sil2100, do you know ? ^
[17:09] <sil2100> om26er: hm, I have no info regarding that, I guess only Mirv would know
[17:09] <cjwatson> sil2100: seems to have been
[17:09] <om26er> sil2100, is he EOD ?
[17:09] <sil2100> om26er: but usually he does that
[17:09] <sil2100> om26er: yes, it's around 20-21 at his place now
[17:11] <cjwatson> wgrant: I have a branch in progress to fix the reason the above was a problem, but I'm about to EOD.  Will submit it tomorrow
[17:23] <slangasek> sil2100: I've committed the changes for daily phone builds, now fixing up the live crontab
[17:24] <slangasek> sil2100, ogra: now, whose local change to the crontab is this?:
[17:24] <slangasek> # do not build RTM on weekends, so we get two days of testing without forced reboots
[17:25] <slangasek> #02 3 * * 1-5  DIST=ubuntu-rtm/14.09 for-project ubuntu-touch cron.daily-preinstalled --live
[17:25] <slangasek> the crontab is in VCS, please make changes there
[17:25] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150505-db7b5bd.changes
[17:25] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150505-db7b5bd.tar.xz
[17:25] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150505-db7b5bd.ods
[17:25] <john-mcaleely> sil2100, jibel ^
[17:25] <john-mcaleely> for your QA pleasure
[17:25] <slangasek> (for everything except temporary disabling of jobs during milestone builds)
[17:26] <sil2100> jibel: ^
[17:26] <sil2100> slangasek: ah, hm, it's an old change
[17:27] <john-mcaleely> i remember that being introduced
[17:27] <john-mcaleely> ages ago
[17:27] <john-mcaleely> ~August last year?
[17:27] <sil2100> slangasek: but yeah, all the other changes I was always editing it directly on nusakan, had no knowledge of a VCS
[17:27] <slangasek> yeah, improperly ;)  if this is the policy, somebody should commit it to lp:ubuntu-cdimage
[17:27] <ogra_> slangasek, please dont !
[17:28] <slangasek> ogra_: don't what?
[17:28] <ogra_> the crontab ion VCS is only an example one
[17:28] <slangasek> ogra_: that is false
[17:28] <ogra_> dont merge them
[17:28] <ogra_> no, that is how it was always handled
[17:28] <slangasek> ogra_: no, it is *not*
[17:29] <slangasek> and if this was the impression that you had, that explains why the live instance is so badly out of sync
[17:29] <john-mcaleely> sil2100, if you need the tarball pushing, ping me on telegram if I'm |away
[17:29] <ogra_> slangasek, well ... ask infinity or cjwatson
[17:29] <sil2100> john-mcaleely: uh oh I don't have a telegram account! Maybe davmor2 could do that though!
[17:29] <ogra_> cronab is the one thing weher the live version supesedes the one in the branch
[17:29] <john-mcaleely> there's always an sms to the mobile in the corp. dir then :-)
[17:30] <ogra_> because it might have ad-hoc changes for milestones etc
[17:30] <slangasek> infinity, cjwatson: can you please either confirm my understanding of nusakan's crontab, or refute it? :)
[17:30] <slangasek> infinity, cjwatson: since ogra_ and I seem to have a very different understanding of the intended crontab management
[17:30] <ogra_> we used to sync it every now and then, but the production one is always been master
[17:31] <ogra_> (oh, and no, i dont know who commented the line )
[17:33] <sil2100> ogra_: I commented it the line of RTM auto-builds some time ago
[17:33] <sil2100> Once we stopped landing stuff there
[17:33] <ogra_> sil2100, yeah, i surely commented it too at some point :)
[17:33] <infinity> slangasek: I think that in theory you're right, but years of practice going back several machines probably mirrors ogra's understanding better.
[17:33] <ogra_> but i dont know if in this particular case since it was an on/off thing for the last weeks
[17:33] <infinity> slangasek: I certainly don't commit temp changes (like commenting during milestones), but adding/removing things should definitely be committed so they're not lost.
[17:34] <ogra_> right
[17:34] <slangasek> right
[17:34] <ogra_> thats what i meant with "syncing every now and then"
[17:34] <slangasek> and "it's been that way since August" is not a temp change
[17:35] <ogra_> surely not :)
[17:35] <ogra_> and it should have been synced
[17:35] <infinity> We have a lot more cooks dangling limbs in that pot than we used to, so a firmer policy wouldn't hurt at this point.
[17:35] <slangasek> ogra_: ok, so I'm not sure what you were telling me to "don't" do
[17:35] <dobey> cihelp: can we get lp:unity-scope-click landing/MP configuration updated to land on wily now?
[17:36] <slangasek> I never said I was overwriting the crontab, I said I was fixing it :P
[17:36] <ogra_> slangasek, i thought you asked about the line being commented
[17:36] <sil2100> Just to come out of this clean: I did not have access to nusakan back then ;p
[17:36] <ogra_> that bit shouldnt go into VCS
[17:36] <slangasek> ogra_: ah. no, I was asking about the schedule change
[17:36]  * sil2100 is innocent
[17:36] <ogra_> i wasnt aware the additions to the line had not landed
[17:38] <slangasek> infinity, sil2100: btw we have three different branches we want phone dailies of for the moment (14.09, vivid+overlay, and shortly wily), and the crontab is rather full as far as scheduling goes; I'm proposing that we just build them all in parallel at the same time, I think launchpad should be able to scale out fine to handle it and it beats me having to pick arbitrary different times for each bu
[17:38] <slangasek> ild
[17:38] <fginther> dobey, I expect this to be done today. We're in the middle of the process of adding the wily chroots and updating the job configs to use wily
[17:39] <sil2100> slangasek: makes sense if launchpad can handle that by itself
[17:39] <ogra_> slangasek, yeah, that scheduling is surely overruled by LP nowadays, it stems still from having only one builder
[17:39] <infinity> slangasek: Yeah, timing really doesn't matter anymore, except for when people want the images to appear.
[17:39] <sil2100> We don't really care about the specific time and/or priority what builds first I suppose
[17:39] <dobey> fginther: ok
[17:39] <infinity> slangasek: Pick a time that's good for the people who'll be testing them and jam them all in together, IMO.
[17:40] <slangasek> sil2100: this way they should all build in parallel, and all appear within a half hour of each other
[17:40] <ogra_> yeah, we used to pick it in a way that the autopilot tests had run when we started the landing team meeting in the past
[17:40] <infinity> slangasek: Maybe delay by a minute or two, so the slightly-broken locking protocol in cdimage doesn't get more broken. :P
[17:40] <slangasek> infinity: I thought the locking protocol was sane between different images
[17:41] <ogra_> but given we only do that twice a week now it isnt that important anymore when these tests show up ... i guess thats a QA question now
[17:41] <infinity> slangasek: There's one specific lock that's a bit touchy, and I've not hunted down why.  It doesn't actually break images, but it does end up with a counter being off-by-one, which hitches up the mirror sync (a non-issue for touch, but then it breaks server builds later).
[17:42] <infinity> Well, it doesn't break the image it's building when the lock/unlock fails, I mean.  It obviously breaks anything that relies on mirror consistency.
[17:43] <infinity> slangasek: I'm about 99% sure it's an uncaught exception or something, but on the off chance that it's also racy, I'd rather stagger the starts by a minute just to be safe until I know what's wrong and know it's fixed.
[17:43] <slangasek> sil2100: crontab mangling done.  The vivid daily builds will start immediately, but the importer isn't yet set up to pull them in; I assume that we are going to want to point ubuntu-touch/rc-proposed at these as soon as OTA 3.5 is done
[17:43] <slangasek> (when is that done?)
[17:45] <sil2100> slangasek: OTA-3.5 will be done this week, we're closing the gates in a few minutes and building our first promotion candidate
[17:45] <slangasek> infinity: ok, done
[17:46] <slangasek> sil2100: ok.  as soon as ota 3.5 is out the door, let me know and I can help finagle the channel configs
[17:46] <ogra_> sil2100, oh, i guess you want wily support for the bot too ?
[17:46] <sil2100> slangasek: sure thing, thanks for making this happen ;)
[17:46]  * ogra_ will try to make up some time for that tomorrow 
[17:47] <sil2100> ogra_: hm, I wonder, we could but I wouldn't say it's top priority as per what olli said we're all concentrating on vivid as there are no plans for wily phones
[17:47] <sil2100> Ok, maybe I'll rephrase it
[17:47] <ogra_> well, there will be wily snappy phone builds i guess
[17:47] <ogra_> not really for usage though
[17:48] <sil2100> I'll be good to have for sure, but not a priority ;)
[17:48] <ogra_> ok :)
[17:48] <tedg> sil2100, and thinks should land in wily before landing on vivid.
[17:48] <tedg> things
[17:48] <ogra_> tedg, i fear that wont always work
[17:48] <sil2100> tedg: yeah, it's not so easy...
[17:48] <ogra_> i.e. if you have dependencies on something thats only in wily
[17:48] <slangasek> we won't release a phone from wily, but it's still better to keep the trunk from getting completely overgrown with weeds
[17:48] <ogra_> for sure
[17:49] <davmor2> john-mcaleely: sil2100 I can ping john on telegram :)
[17:49] <sil2100> davmor2: thanks ;)
[17:49] <ogra_> but you shouldnt focus your trunk on wily featuresets
[17:49] <ogra_> (which might be hard for the Qt bits)
[17:49] <sil2100> slangasek: we need to finally discuss what to do with landings, if we do that auto-dual-landing thing for projects where we can
[17:50] <sil2100> Or we just again allow 2 trunks to form - one for stable and one for devel
[17:50]  * sil2100 needs either a clear decision from higher-ups or the decision power here
[17:50] <sil2100> ;)
[17:51] <sil2100> ogra_, jibel: kicking off the rtm image
[17:51] <tedg> Doesn't every project already have a stable branch?
[17:51] <tedg> I mean, that seems like standard operation...
[17:51] <sil2100> tedg: yes, the RTM one
[17:51] <pmcgowan> sil2100, woot
[17:52] <tedg> sil2100, Heh, for really new projects I guess :-)
[17:52] <tedg> Most of mine have a set for LTSes and the such as well.
[17:52] <sil2100> pmcgowan: once this image builds QA should be done with device tarball sign-off, so john-mcaleely can then press the button and we'll have the first promotion candidate ready for QA
[17:54] <pmcgowan> ack
[17:54] <infinity> cjwatson: When you wrote the EXTRA_PPAS integration for cdimage, was there a reason you opted for first_ppa = archive, instead of a separate BUILD_ARCHIVE variable or something?
[17:55] <imgbot> [17:55] <ogra_> \o/
[17:55] <infinity> cjwatson: It seems a bit unintuitive that a build in the primary archive will stay in the primary archive if I use extra_ppas in the json config, but will build in a PPA if I used EXTRA_PPAS on cdimage.
[17:58] <slangasek> sil2100: yes, we certainly do need to get that sorted out
[18:30] <slangasek> infinity: so I need to set EXTRA_PPAS=ci-train-ppa-service/stable-phone-overlay:1000 now for the pinning, right?
[18:32] <infinity> slangasek: 1001
[18:32] <slangasek> ok
[18:42] <sil2100> Ok, I need to go away now or I lose my head
[18:42] <sil2100> See you o/
[18:43] <sil2100> davmor2: please ping john-mcaleely once the tarball passes sign-off ;)
[18:43] <sil2100> davmor2: I see the rootfs for #273 finished, but the image still needs some time to appear
[18:43] <sil2100> But he can push it whenever you're ready
[18:44] <davmor2> sil2100:  I might
[18:44] <sil2100> (the tarball that is)
[18:44] <davmor2> om26er: is testing it when he get's it flashed he took it while I was at tea :)
[19:02] <davmor2> sil2100: so om26er is pinging john-mcaleely via telegram \o/ my work here is done
[19:03] <sil2100> \o/
[19:03] <sil2100> john-mcaleely: tarball can be released \o/
[19:03] <john-mcaleely> davmor2, om26er thank you
[19:03] <sil2100> davmor2, om26er: thanks guys!
[19:03] <john-mcaleely> sil2100, want the device tarball pushed then ? :-)
[19:03] <sil2100> john-mcaleely: hm, wait
[19:03] <sil2100> It should be safe now, right?
[19:03]  * john-mcaleely waiting
[19:03] <sil2100> Since the rootfs finished building, but the image wasn't imported yet
[19:04] <sil2100> ogra_: you think it would be safe to push a new device tarball at such a state? I'm always worried about some races or such
[19:06] <ogra_> sil2100, well, check if the importer already runs
[19:06] <ogra_> i usually stop the importer in such cases to not accidentially cause havoc
[19:07] <ogra_> if it already runs i wouldnt challenge it and wait the few mins
[19:12] <sil2100> Yeah, it's running
[19:12] <john-mcaleely> aha
[19:12] <sil2100> john-mcaleely: let's wait for the importer to stop running
[19:12] <john-mcaleely> ok
[19:12] <john-mcaleely> ping me here when it's done sil2100
[19:12] <sil2100> Shouldn't take long
[19:12] <ogra_> usually it doesnt run more than 30min
[19:12] <sil2100> john-mcaleely: sure, thanks :)
[19:13] <ogra_>  1258 ?        R     15:29 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images
[19:13] <ogra_> already 15 min in ...
[19:20] <imgbot> [19:20] <imgbot> [19:20] <ogra_> sil2100, go wild
[19:20] <ogra_> or rather john-mcaleely ^^^
[19:20] <charles> heh
[19:28] <sil2100> john-mcaleely: !
[19:28] <sil2100> john-mcaleely: as ogra_ said, importer finished - please push teh buttonz
[19:28] <sil2100> :)
[19:31] <john-mcaleely> sil2100, button pushed
[19:31] <john-mcaleely> sil2100, tarball published
[19:31] <sil2100> \o/
[19:31] <sil2100> john-mcaleely: thanks!
[19:31] <john-mcaleely> yw
[19:32] <sil2100> om26er, ToyKeeper, davmor2, alesage: #274 should be available soon, which is the promotion candidate for this week :)
[19:32]  * sil2100 goes off
[19:32] <sil2100> See you tomorrow
[19:32] <om26er> sil2100, thanks
[19:33] <ToyKeeper> Thanks.
[22:01] <fginther> slangasek, I need to pick up a conversation we started earlier. Generally when opening a new release, CI updates all of the pre-merge CI jobs to test trunk with the new devel release (i.e. lp:unity8 will go from vivid builds to wily), but it sounds like we need to take a much different approach now?
[22:01] <wgrant> cjwatson: Huh, I didn't know that check existed :/
[22:15] <slangasek> fginther: hmm yes.  going to the wiki to refresh my memory on prior art
[22:27] <fginther> slangasek, for some more backgroun: the approach in the past was to automatically move trunks to the new release and then if necessary create an SRU branch on demand. For utopic, we only had 1 SRU branch.