[05:56] <oSoMoN> good morning!
[05:56] <oSoMoN> trainguards: if I remove a MR from a landing request, I need to reconfigure the silo, right? Can I do that myself?
[05:57] <robru> oSoMoN: yeah you have the power.
[05:57] <oSoMoN> great, doing that now
[05:57] <robru> oSoMoN: but is it the only mr for that project?
[05:57] <oSoMoN> robru, no, there’s a bunch of MRs targetting only webbrowser-app
[05:57] <robru> oSoMoN: if you're removing the whole project, you need me to delete the ppa package. Otherwise you're good
[05:58] <oSoMoN> so I’m good :)
[05:58] <robru> oSoMoN: great
[06:00] <Mirv> good good
[08:29] <Mirv> zbenjamin: I'll free up one of my Qt silos and assign. it's not that important silo as it's not going to land as is, and I haven't heard back from the user that was supposing to test it.
[08:29] <abeato> trainguards, you can free silo 16 if needed: the change for that is now in silo 35 together with other lxc-android-config changes
[08:30] <sil2100> o/
[08:30] <sil2100> abeato: ok, let me free it up then
[08:31] <sil2100> Let's get silo 35 in then instead
[08:31] <abeato> sil2100, great
[08:31] <abeato> sil2100, 35 is already around in the spreadsheet
[08:32] <sil2100> abeato: yes, we'll have to poke QA to include 35 in their backlog though
[08:33] <sil2100> Since I see they had 16 targetted
[08:33] <Mirv> zbenjamin: you've got 002 now
[08:33] <abeato> sil2100, I think kenvandine commented in the trello catd
[08:33] <abeato> *card
[08:33] <zbenjamin> Mirv: thanks
[08:37] <abeato> sil2100, ^^ :)
[08:38] <sil2100> Let me check the request list :)
[08:38] <sil2100> ofono fixes \o/
[08:38] <sil2100> +1 on those, assigning
[08:39] <abeato> sil2100, thanks
[08:39] <sil2100> abeato: sadly we don't have enough silos to do the sync silo, so we'll just have to sync it later
[08:39] <abeato> sil2100, ok, np
[08:54] <oSoMoN_> trainguards: given the freeze coming into effect today for the overlay PPA, if a silo is awaiting QA signoff (and assuming it will pass validation), will it be included?
[08:55] <Mirv> oSoMoN_: I'm interested in that too :)
[08:55] <Mirv> oSoMoN_: I'd think QA will pick their favorites, as there may be too many for them to handle
[08:56] <Mirv> there's a UITK one bug fix coming today too into the queue
[09:14] <sil2100> Yes :)
[09:15] <sil2100> oSoMoN_: if a silo is ready and tested by the lander before the freeze, QA will sign it off during the freeze
[09:15] <sil2100> At least as many high-priority ones they can take
[09:18] <oSoMoN> sil2100, thanks for the confirmation
[12:03] <sil2100> phew...
[12:03] <sil2100> Ok, I jump out for lunch now
[12:43] <kyrofa> cihelp: I'm creating a deb package for a scope written by the Unity API team, but we don't have a publicly-accessible mailing list. Who should I use as the Maintainer?
[12:44] <kyrofa> (correction, the deb package will be created by the CI)
[12:45] <fginther> dobey, the new coverage report is actually attached to the amd64 job: https://jenkins.qa.ubuntu.com/job/unity-scope-click-wily-amd64-ci/16/
[12:46] <Ursinha> kyrofa: that is a good question, but maybe for core developers (more of a packaging policy question?)
[12:46] <kyrofa> Ursinha, so the CI doesn't care? Figured I'd start here, but if CI doesn't care you're right :)
[12:48] <Ursinha> kyrofa: well, I might be wrong, but for these I thought CI would have to accept whatever the packager/maintainer chooses :) unless that's a violation of something that a validation script would catch, but don't think that's the case
[12:48] <kyrofa> Ursinha, sounds good, thanks for the information!
[12:49] <Ursinha> kyrofa: you're welcome! :)
[13:04] <oSoMoN> ubuntu-qa: what do I need to do to have silo 15 move to "ready for testing"?
[13:11] <ToyKeeper> oSoMoN: Looks like it's third in line for triage, and QA just started work a few minutes ago.  If all the card details are correct, it should be marked ready soon.
[13:12] <oSoMoN> ToyKeeper, excellent, thanks!
[13:12] <ToyKeeper> It's weird having everyone in the same place and on the same schedule.
[13:24] <kenvandine> any plans to repurpose some of those rtm silos for vivid/wily?
[13:24] <kenvandine> sil2100, ^^
[13:24] <kenvandine> it's unlikely we'll be pushing much of anything to 14.09
[13:24] <dobey> fginther: ah, ok. thanks
[13:24] <kenvandine> maybe keep a couple around for important hotfixes, just in case
[13:25] <ogra_> once the next OTA is out RTM is completely dead
[13:25] <dobey> kenvandine: well, i guess in two weeks there won't be anything ever going there
[13:25] <vrruiz> jhodapp: ping
[13:25] <kenvandine> right
[13:25] <jhodapp> vrruiz, pong
[13:25] <vrruiz> jhodapp: I was testing silo 25, media-hub
[13:25] <kenvandine> and between now and then it is unlikely anything will need to go there
[13:25] <kenvandine> so we should repurpose those silos :)
[13:26] <jhodapp> vrruiz, ok
[13:26] <kenvandine> i'd vote to keep a few just in case and reconfigure the rest :)
[13:26] <vrruiz> jhodapp: I can crash it going back and forth.
[13:26] <vrruiz> jhodapp: Some tries are needed, though.
[13:26] <jhodapp> vrruiz, and you're sure that doesn't happen without my silo?
[13:34] <cjwatson> kenvandine: They can't be repurposed, but more Ubuntu ones could be created.
[13:35] <kenvandine> cjwatson, bummer... i was hoping they could just be changed to be ubuntu again
[13:35] <cjwatson> kenvandine: It's not a big deal.
[13:36] <kenvandine> now with wily and vivid we're always running out for ubuntu
[13:36] <kenvandine> and we have all these idle silos for rtm
[13:36] <cjwatson> When you say "again", they weren't for Ubuntu to start with. :-)
[13:36] <kenvandine> you know what i mean :-D
[13:37] <cjwatson> Just wanted to thoroughly squash the notion of changing the distribution on an existing archive. :-)
[13:38] <cjwatson> Anyway, if the landing team wants to create some more silos, I don't mind reconfiguring them to the standard settings before they're inserted into citrain.
[13:43] <sil2100> kenvandine: we'll have more silos, I already poked slangasek yesterday to get the overall silo count to ~60
[13:51] <ogra_> sil2100, you should probably start to spread that across multiple spreadsheets :)
[13:52] <kenvandine> not more spreadsheets!
[13:52] <ogra_> keeps the chance that at least one isnt broken :)
[13:52] <sil2100> hah!
[13:52] <sil2100> Excellent idea, let's DO THIS
[13:52] <ogra_> lol
[13:53] <sil2100> ;)
[13:53] <jhodapp> vrruiz, did you try to make sure you can't crash it like this without silo 25?
[13:56] <vrruiz> jhodapp: I tried with stable, and doesn't happen
[13:59] <jhodapp> vrruiz, ok well thanks for testing...I'll have a new device to test on tomorrow that'll actually work...I've been relying on other people to test my fixes
[14:01] <kalikiana> ping cihelp, how do I get the screencast for https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2494/#showFailuresLink ?
[14:03] <ev> kalikiana: we don't offer that anymore since sunsetting otto
[14:03] <ev> kalikiana: is there a reason why you couldn't see this by reproducing locally?
[14:03] <kalikiana> ev: well, yes, because I can't :-)
[14:04] <kalikiana> that's what I've always used the screencasts for
[14:04] <ev> kalikiana: you can't reproduce locally?
[14:04] <kalikiana> ev: yes
[14:05] <kalikiana> so what is the recommended workflow?
[14:05] <ev> sorry, in a meeting; will reply shortly
[14:06] <kalikiana> okay
[14:06] <kalikiana> thanks
[14:09] <mandel> sil2100, can you give me a hand with a ppa build issue, I'm not at expert in this things => https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/284/console
[14:09] <sil2100> mandel: looking
[14:09] <mandel> sil2100, thx
[14:10] <sil2100> mandel: ah, hm, tricky situation
[14:10] <mandel> sil2100, just what I did not want to read..
[14:11] <sil2100> mandel: so probably we'll have to deploy a quick fix for the train... the problem here is that it seems that from this trunk you released packages to wily already, and now you want to release something to vivid
[14:12] <sil2100> mandel: releasing to wily caused the version number to be addressed for 15.10, and now while releasing another version the train wants to give it a version for vivid (so 15.04)
[14:12] <sil2100> mandel: the dch tool by default doesn't allow adding a new version that is smaller than the previous one
[14:12] <sil2100> mandel: we might need to redeploy a fix for the train that would force dch to use the --force-bad-version flag
[14:13] <sil2100> mandel: but in the meantime - are you sure all your merges are targetting the right trunks? Just to double check
[14:13] <mandel> sil2100, oh.. well, that would be nice sine it is a rebuild I'd like to add to vivid to work with an abi change from udm
[14:14] <mandel> sil2100, well, it is a simple rebuild but probably cotent-hub does have a new target for vivid
[14:14] <mandel> sil2100, looking at lp:content-hub is either trunk or 14.09 which is not good (15.04 is what we want)
[14:18] <oSoMoN> vrruiz, regarding silo 15, one comment you might want to add to the card: everything in that silo should be fairly straightforward to verify (bug fixes and new features such as private browsing), except for the fix for https://launchpad.net/bugs/1277659, which will be very hard to test, as the max cache size will be adjusted dynamically for all webapps at startup time depending on the amount of free disk space
[14:19] <sil2100> mandel: hm, so first of all, you'd need to poke kenvandine about this
[14:19] <sil2100> mandel: since we don't want to have mixed up trunks
[14:19] <oSoMoN> vrruiz, in that regard a sanity code review is probably our best bet to ensure quality (and it’s already been approved by alex-abreu)
[14:19] <mandel> kenvandine, consider yourself poked ;)
[14:19] <mandel> sil2100, yes, make sense (/me runs to do the same in udm)
[14:20] <sil2100> mandel: generally one trunk should have selected version numbers - if kenvandine released something from lp:content-hub to 15.10 already, then generally it should be released to wily
[14:20] <sil2100> mandel: you could release it to wily and then sync it back to vivid
[14:20] <sil2100> (this way keeping only one trunk)
[14:20] <t1mp> kalikiana: do you know what I am missing here? http://pastebin.ubuntu.com/11264957/
[14:20] <sil2100> If that's possible of course
[14:20] <t1mp> kalikiana: normally I install the -autopilot package that I want to run the test from and then it works..
[14:21] <mandel> sil2100, once kenvandine or I fix this and reconfigure the silo and the MR for vivid and the other for trunk
[14:21]  * kenvandine reads
[14:21] <mandel> sil2100, in some cases, having to targets works better (new lib version etc..)
[14:21] <t1mp> or anyone else knows why I AP  cannot initiate any backends on a device? http://pastebin.ubuntu.com/11264957/
[14:22] <charles> trainguards, could I get row 80 in free silo ubuntu/landing-003?
[14:22] <mandel> kenvandine, I got back from vacation and wanted to land silo 09 and this happened => https://ci-train.ubuntu.com/job/ubuntu-landing-009-1-build/284/console
[14:22] <sil2100> charles: on it!
[14:23] <kalikiana> t1mp: I usually have this in my phablet-test-run invokation  -p ubuntu-ui-toolkit-autopilot -p python3-evdev -p gc
[14:23] <kenvandine> mandel, yeah we've released a new version in trunk
[14:23] <kenvandine> that isn't in the vivid overlay yet
[14:23] <kenvandine> mandel, let me branch for vivid
[14:23] <mandel> kenvandine, awesome, I'll redo the MR and reconfigure the silo
[14:25] <oSoMoN> trainguards, ubuntu-qa: oxide 1.7.8 landed in vivid as a security update, so silo 38 is not needed any longer (it can be freed), and consequently it doesn’t require QA validation (the trello card can be deleted)
[14:25] <charles> sil2100, thanks :-)
[14:25] <t1mp> kalikiana: thanks, installing python3-evdev worked
[14:25] <ToyKeeper> oSoMoN: Thanks.  :)
[14:26] <ToyKeeper> oSoMoN: We're having some pretty bad device-flashing issues at the moment so testing is stalled or at least very slowed.  :(
[14:26] <oSoMoN> :/ one silo less to test comes as good news, then!
[14:27] <kenvandine> mandel, lp:content-hub/15.04
[14:27] <mandel> kenvandine, awesome, I'll try to get the silo back on track
[14:27] <kenvandine> mandel, great, thanks!
[14:27] <vila> oSoMoN: and what about oxide-1.7.x landing in wily ?
[14:27] <sil2100> oSoMoN: ok, good to know
[14:28] <oSoMoN> vila, yes, we will need to land it in wily, I guess we’ll be requesting a silo later
[14:29] <davmor2> oSoMoN: thanks
[14:31] <mandel> sil2100, can you please reconfigure line 10 for me, I do not have the rights
[14:33] <vrruiz> oSoMoN: Ack, I'll add that
[14:34] <vila> oSoMoN: the weird thing (mentioned in my MP) is that it is in wily-proposed...
[14:34] <sil2100> mandel: on it
[14:34] <mandel> sil2100, appreciated!
[14:35] <sil2100> mandel: hmm, line 10? Are you sure? This one doesn't seem to be assigned to any silo
[14:36] <alan_g> sil2100: any progress on mir-0.13.0 sync to wily
[14:36] <oSoMoN> vila, yes, 1.7.7 is in -proposed, but it appears to be stuck there because of autopkgtest for ubuntu-system-settings-online-accounts (been stuck for 8 days). In any case we’ll want to land 1.7.8 there too
[14:36] <sil2100> alan_g: the line is still there, but we're still blocked on not enough silos... and vivid OTA fixes sadly get the priority since today is when we were closing the gates
[14:36] <mandel> sil2100, yes, it has comment from Mirv  (I was on vacation and that is the reason it did not land)
[14:36] <ev> kalikiana: http://ubuntu-test-cases-touch.readthedocs.org/en/latest/#provisioning-and-executing-autopilot-tests-for-an-mp should explain how to reproduce those tests locally. If you are still unable to do so, please ping cihelp
[14:37] <mandel> sil2100, the one with the following comment "Propagate the hash errors to the udm clients."
[14:37] <mandel> and I have silo 09 AFAIK
[14:37] <mandel> sil2100, ubuntu/landing-009 from http://people.canonical.com/~platform/citrain_dashboard/#?q=mandel
[14:37] <alan_g> sil2100: ok, thanks for the update
[14:37] <alan_g> camako: ^
[14:37] <sil2100> mandel: sadly we don't have enough silos right now to be able to assign it for you
[14:37] <sil2100> alan_g: we should have more once we close the gates for vivid
[14:38] <sil2100> alan_g: which should happen today in around an hour
[14:38] <mandel> sil2100, oh well, and why do I see ubuntu/landing-009 assigned?
[14:38] <alan_g> sil2100: :)
[14:38] <mandel> sil2100, I can wait, I'm just asking cause I'm confused
[14:38] <sil2100> mandel: landing 009 is line 28
[14:39] <sil2100> mandel: it was assigned before and no one freed it
[14:39] <mandel> sil2100, ok, can you clean that mess up then?
[14:40] <sil2100> mandel: ok, so you want silo 009 freed and instead of  that line 10 assigned?
[14:40] <t1mp> kalikiana: just to confirm,  I tried some AP tests that failed here https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/2494/#showFailuresLink
[14:40] <t1mp> kalikiana: and I cannot confirm them on neither laptop and nexus4
[14:40] <t1mp> they pass here
[14:41] <mandel> sil2100, well, silo 09 is for line 10 AFAIK, that I why I say I'm confused
[14:41] <mandel> sil2100, I just updated on of the mr in line 10
[14:41] <sil2100> mandel: as I said, silo 009 is from line 28 - so what is line 28 then?
[14:41] <t1mp> kalikiana: I think I overdid the negations in that sentence a bit. JS is so much clearer than English ;)
[14:42] <sil2100> mandel: line 28 was used to create silo 009
[14:42] <mandel> sil2100, ok, so line 10 is old and should be removed and I should update line 28
[14:42] <mandel> sil2100, god, I was really confused
[14:42] <sil2100> Oh my, me too
[14:42] <sil2100> Probably some leftover entry after some spreadsheet problems
[14:42] <sil2100> Ok, removing line 10 thn
[14:43] <sil2100> *then
[14:43] <mandel> sil2100, ok, and then, with one line less, can you recnfigure line 27 ;)
[14:44] <sil2100> On it ;)
[14:44] <mandel> awesome, thx
[14:47] <vila> oSoMoN: ack and yeah, elopio has the fix for that issue in ubuntu-ui-toolkit (merged on trunk), once that lands, it will unblock u-s-s-o-accounts and all will (crossing fingers) trickle down (or up ;)
[14:49] <oSoMoN> vila, cool, looking forward to that
[15:42] <jdstrand> sil2100 (or anyone else): hey, I am preparing my first package destined for stable-phone-overlay. what is supposed to be in the changelog for the distribution name?
[15:42] <jdstrand> not vivid but...
[15:43] <sil2100> jdstrand: it's vivid :)
[15:43] <jdstrand> oh, I thought you said something needed to be different to autoclose bugs or something
[15:43] <sil2100> jdstrand: basically the overlay PPA is vivid, we also give it the very same versioning there - at least for train packages
[15:43] <jdstrand> well, that is easy enough
[15:43] <sil2100> Well, that's only for bugs
[15:43] <sil2100> For bugs you need to have an Ubuntu-RTM task open
[15:44] <jdstrand> ah
[15:44] <jdstrand> yes, that all makes perfect sense
[15:44] <jdstrand> ok, thanks
[15:44] <sil2100> Since we agreed that we'll be auto-closing those when uploading to the overlay
[15:44] <sil2100> yw :)
[15:44] <jdstrand> gotcha
[15:45] <jdstrand> cwayne: fyi, as per email thread, preparing apparmor-easyprof-ubuntu 1.3.11 for the thumbnailer apparmor changes for stable-phone-overlay
[15:45] <jdstrand> cwayne: I'll ping you when in the ppa and when its tested
[15:48] <sil2100> davmor2: hey! Is jibel somewhere around?
[15:49] <cwayne> jdstrand, ack, thanks
[15:49] <davmor2> sil2100: 1 second
[15:50] <jibel> sil2100, pong
[15:51] <sil2100> jibel: hey! Just wanted to make sure you'll be around for the meeting, since I even wanted to poke you earlier re: closing the gates
[15:51] <sil2100> But I guess we can wait with discussion 9 minutes
[15:51] <sil2100> ;)
[15:52] <jibel> sil2100, I'll be there
[15:52] <davmor2> to love and cheerish yo-ou
[15:56] <ogra_> sil2100, i have another meeting now ... cant attend
[15:56] <sil2100> jdstrand: we don't have any free silos right now if anything
[15:57] <sil2100> jdstrand: so sadly, it'll take some time before we can handle your request :(
[15:58] <jdstrand> sil2100: ok... what does 'some time' mean? pmcgowan requested that this go in asap (it must be landed with the custom tarball before May 28th)
[15:58] <jdstrand> note, I'm not saying it should be prioritized above other things
[15:58] <jdstrand> just saying it is high priority
[15:58] <sil2100> Let's see, I suppose maybe QA will sign-off something soon and we'll have a silo free
[15:59] <jdstrand> ok, sometime today or even tomorrow is fine
[15:59] <sil2100> ...but there are issues with flashing right now I think
[15:59] <sil2100> I'll know more after the meeting
[15:59] <jdstrand> I just didn't want it to linger until tuesday cause then it would be tight
[15:59] <sil2100> Ok :)
[15:59] <jdstrand> ok, thanks
[15:59] <sil2100> We'll make sure it lands before the deadline
[15:59] <jdstrand> thanks! :)
[16:33] <dbarth_> hey trainguards; you can dismiss silo 17; we can re-add it later
[16:35] <robru> dbarth_: thanks
[16:35] <robru> jdstrand: got one freeing up for you
[16:36] <jdstrand> yay!
[16:36] <dbarth_> wait
[16:36] <robru> dbarth_: uh?
[16:36] <dbarth_> i will probably need one for a icon theme change
[16:36] <dbarth_> see https://bugs.launchpad.net/ubuntu-themes/+bug/1457424
[16:37] <dbarth_> though this one still needs to be blessed
[16:37] <dbarth_> if that takes too long, maybe pass jdstrand's in the meantime
[16:37] <robru> dbarth_: yeah i think jdstrand has the higher priority here
[16:37] <robru> jdstrand: ok you're in 17, please upload
[16:37] <jdstrand> thanks!
[16:38] <jdstrand> dbarth_: sorry if this jams you up (that wasn't my intent)
[16:38] <robru> lool: hey what's going on in silo 5? no movement since april 30
[16:38] <dbarth_> jdstrand: nw
[16:39] <ogra_> robru, he is french ... it is like good wine or cheese ... needs to ripen
[16:41] <sil2100> ;p
[16:45] <kalikiana> t1mp: as per ev above, screencasts were disabled and you're supposedly able to reproduce them following these instructions http://ubuntu-test-cases-touch.readthedocs.org/en/latest/#provisioning-and-executing-autopilot-tests-for-an-mp
[16:46] <kalikiana> though I'm neither convinced that to be true yet nor do I see how this makes up for the lost time of not narrowing down the issue faster
[16:47] <kalikiana> ^^ excuse my frank feedback, but that's what you get for killing workflows just like that :-}
[17:07] <sil2100> dbarth_: hey! About the icon change
[17:10] <sil2100> dbarth_: I think we'd like to land all icon changes at once, and do that after the 28th most probably
[17:16] <dbarth_> sil2100: right; i'll leave that up to pmcgowan and you to check; i was mostly helping design land their changes
[17:36] <robru> fgimenez: just double checking, is your silo 18 really meant to be an SRU back to vivid? or do you just want that in the overlay? (eg is it needed on desktop or just on phone?)
[17:36] <veebers> robru: heh, I just oked that (joint landing responsibilities in the team)
[17:37] <veebers> robru: That should be on the desktop and on phone, but perhaps I've screwed it up and it's to late?
[17:37] <robru> veebers: no not too late.
[17:37] <robru> veebers: just that we don't see many vivid SRUs in the train so I just wanted to double check that was the correct intention.
[17:37] <robru> veebers: it's currently configured to be an SRU, which takes longer, but will make it into vivid desktop
[17:38] <veebers> robru: ok thanks. We setup that silo a couple of weeks ago
[17:38] <robru> veebers: you familiar with the SRU process?
[17:39] <vrruiz> kenvandine: abeato: Why silo 35 has no merge proposals?
[17:42] <veebers> robru: not off the top of my head, no
[17:43] <robru> veebers: k, because that's a thing. https://wiki.ubuntu.com/StableReleaseUpdates
[17:44] <robru> veebers: you have to get the paperwork lined up and get the SRU team on the case otherwise that silo will just sit there in limbo for 2 months.
[17:44] <veebers> robru: ack, thanks
[17:44] <robru> veebers: you're welcome
[18:13] <veebers> robru: am I right in thinking the silo/train does some of the work for me (re: SRU)? i.e. Upload the fixed package to release-proposed? I've updated the bug linked in the silo details
[18:13] <robru> veebers: very little. your package is "uploaded" but it's caught in UNAPPROVED. you need somebody from SRU team to poke it through to actual vivid-proposed.
[18:14] <veebers> robru: ack, thanks
[18:23] <bfiller> robru: mind reconfiguring silo 29, I know it will conflict with silo 30 but we'll rebuild as necessary
[18:25] <robru> boiko: bfiller: ok, done. Also, silo 6 failed to publish because it has a new commit that hasn't been built. https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/95/console
[18:26] <boiko> robru: ouch, that was just a dummy commit to trigger a jenkins rebuild (we were testing the CI job), let me rebuild that on the silo
[18:27] <boiko> robru: the commit in question: http://bazaar.launchpad.net/~tiagosh/telephony-service/ringtone-thread/revision/1076 :)
[18:27] <robru> boiko: hm
[18:28] <robru> boiko: ok I gotta step out, will republish in a bit
[18:28] <boiko> robru: so, I rebuild that on the silo, right?
[18:28] <boiko> robru: (just to make sure I don't mess up with anything)
[18:29] <robru> boiko: yeah you'd have to, otherwise it won't merge right
[18:29] <boiko> robru: ok
[18:32] <pmcgowan> bfiller, looks like silo 6 passed but cant publish
[18:32] <boiko> pmcgowan: I am fixing that
[18:32] <bfiller> pmcgowan: yup, boiko fixing
[18:32] <pmcgowan> cool
[18:48] <vrruiz> alex-abreu: Hey
[18:48] <alex-abreu> vrruiz, hey
[18:49] <vrruiz> alex-abreu: I don't see test cases for the private mode, so I don't know how to test that
[18:49] <alex-abreu> vrruiz, for the webbrowser app?
[18:49] <vrruiz> alex-abreu: Yes
[18:51] <alex-abreu> vrruiz, well yeah, afaik, there is none atm ...
[18:52] <vrruiz> alex-abreu: I'm testing silo 15, which enables private browsing... can't see how to enable it, do you know how?
[18:53] <alex-abreu> vrruiz, yeah from the drawer in the top header
[18:53] <alex-abreu> vrruiz, one thing that you can have a look at is https://docs.google.com/presentation/d/1Qrd4Flfs3EH-fI79IfrYgLdAx2nce-L7ve8NKLCX324/edit#slide=id.g2b64bc8c2_557
[18:53] <alex-abreu> vrruiz, slide 56-57
[18:58] <vrruiz> alex-abreu: Hmm
[18:58] <vrruiz> alex-abreu: I don't see that on the phone
[18:58] <vrruiz> Checking
[18:58] <alex-abreu> vrruiz, maybe talk to artmello on #phablet
[19:01] <robru> kenvandine: mterry_: anybody around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-030-2-publish/lastSuccessfulBuild/artifact/telepathy-ofono_packaging_changes.diff/*view*/ looks like new binary package and new deps
[19:03] <mterry_> robru, sure
[19:14] <vrruiz> alex-abreu: Ok, problems installing the silo, private mode is there.
[19:14] <boiko> robru: done rebuilding (silo 006)
[19:16] <alex-abreu> vrruiz, ok
[19:17] <boiko> robru: once silo 6 and 30 are published, can I get one of those silos assigned for row 84? :)
[19:17] <robru> boiko: is it critical for ota4? :-P
[19:18] <boiko> robru: it is tagged as ota4 and ww22-2015, but the bug itself is high
[19:18] <robru> boiko: k, 6 should be free soonish
[19:19] <boiko> robru: nice! thanks :)
[19:31] <pmcgowan> boiko, no 30 cant land
[19:31] <pmcgowan> now
[19:32] <boiko> pmcgowan: mterry_ is looking at the packaging changes (we created a new package for the mission-control plugin)
[19:32] <mterry_> robru, my "sure" was meant to read as "looks ok to me"
[19:33] <robru> mterry_: oh heh, i thought "sure" meant "sure I'll start looking at it" ;-)
[19:33] <robru> mterry_: ok thanks
[19:33] <mterry_> robru, my fault  :)
[19:33] <awe> robru, pmcgowan, so my NM silo build failed because ci thinks there's a higher version available ( 4ubuntu15.2 )
[19:34] <robru> awe: what silo?
[19:34] <awe> 23
[19:34] <kyrofa> cihelp: I have a Go package which I'm about to ask to get added to the CI. I have the debian rules building and running tests, including generating a coverage.xml file. My question: assuming that coverage.xml is formatted correctly, will that "just work" with your coverage job? Or does the coverage job assume cmake -DCMAKE_BUILD_TYPE=coverage or similar?
[19:34] <awe> robru, looks like it's complaining about the version of nm that landed in -updates recently
[19:34] <awe> but we're supposed to be 'pinned'
[19:35] <josepht> kyrofa: let me find that out and I'll get back to you.
[19:35] <robru> awe: heh, no. that package version built in that same silo previously: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-023/+packages?field.name_filter=network&field.status_filter=&field.series_filter=
[19:36] <kyrofa> josepht, thank you!
[19:36] <robru> awe: launchpad ppas will never let you upload a lower version once a given version is uploaded, even if that upload is 'Deleted'
[19:36] <robru> awe: normally I'd say "we can fix this by putting you in a different silo" but there are no other silos
[19:36] <robru> awe: so you should probably think about bumping your version number to something that's higher ;-)
[19:36] <awe> ugh
[19:37] <pmcgowan> yuck
[19:37] <awe> are there any other free silos?  That's really unfortunate
[19:38] <robru> awe: oh a couple did just free. there weren't any a minute ago
[19:38] <robru> awe: I'm curious why you want it to be 4ubuntu1 anyway?
[19:38] <awe> well, we could free this one up
[19:38] <robru> awe: ok I'll move it, hang on
[19:38] <awe> my version is 15.1.1
[19:39] <awe> robru, but this means we'll never be able to build nm in this silo using the 15.1.1, .2., 3. scheme
[19:39] <awe> I guess I could change the version #, but we ( me and cypher ) were trying to come up with a reasonable version scheme between vivid-overly and vivid-updates
[19:40] <robru> awe: right, the current silo is totally burned for these versions you want to use
[19:40] <josepht> kyrofa: when you request the package be added make sure you indicate you want coverage results processed.  Other than that a properly formatted coverage.xml should work fine.
[19:40]  * awe wonders if we could get someone from lp team to do a one-time wipe of this silo
[19:40] <robru> awe: the job says it tried to upload "0.9.10.0-4ubuntu1"
[19:40] <awe> ?
[19:40] <awe> hmmm, lemme check again
[19:40] <robru> awe https://ci-train.ubuntu.com/job/ubuntu-landing-023-1-build/64/consoleFull
[19:41] <awe> Downloading network-manager 0.9.10.0-4ubuntu15.1.1
[19:42] <robru> awe: ugh I don't even
[19:42] <awe> robru, looks like some script somewhere doesn't like the extra dots
[19:42] <kyrofa> josepht, awesome, thanks!
[19:43] <boiko> kenvandine: hey, I have silo 28 assigned with some addressbook changes, would it be possible to get it released and assigned to row  84?
[19:43] <josepht> kyrofa: my pleasure
[19:43] <robru> awe: I blame sil2100, he tinkered with the sync code last
[19:44] <awe> robru, that said, I still think 15.2 is still > 15.1.1
[19:44] <awe> so we'd hit the same damn problem with the PPA
[19:44] <robru> awe: yeah
[19:44] <robru> awe: I'll reassign it in a sec, I'm poking at code right now
[19:44] <kenvandine> boiko, you mean you want to free silo 28 and reuse it?
[19:45] <boiko> kenvandine: yep, it seems we are low on silos, no?
[19:45] <robru> awe: oh wait, does it need to be a source sync? if we did a binary sync it wouldn't mangle the version
[19:45] <kenvandine> yeah
[19:45] <kenvandine> boiko, sure
[19:45] <boiko> kenvandine: so, row 84 is targetted for OTA4 and what is in silo 28 is not, so if it is possible to swap, that would be good :)
[19:46] <boiko> kenvandine: thanks
[19:46] <awe> robru, a binary sync, meaning you grab the source package + all the binary packages without rebuilding?
[19:46] <robru> awe: yeah
[19:46] <awe> if so, yes I think that's what we wanted in the first place.  Sorry if I should've mentioned that in my CI comments...
[19:47] <robru> awe: well it's your fault for not specifying that on the build job :-P
[19:47]  * awe sheepishly admits that he blindly hit the build button without thinking  ;(-
[19:47] <kenvandine> boiko, freed 28 and you ended up getting silo 6 :)
[19:48] <awe> robru, so next time we do this, I need to check "include_binaries_in_sync"?  anything else, or is that it?
[19:49] <robru> awe: that's it: https://ci-train.ubuntu.com/job/ubuntu-landing-028-1-build/parambuild/?delay=0sec&INCLUDE_BINARIES_IN_SYNC=true
[19:49] <awe> k
[19:49] <robru> awe: you're in 28 now, should be good to go
[19:49] <awe> merci beacoup
[19:49] <robru> awe: you're welcome
[19:50] <awe> would the version thing still have bitten us though?
[19:50] <awe> if so, I guess I could talk to lp folks and see if it's possible to wipe the memory of that nm package
[19:51] <awe> don't think we'll be silo building anymore -updates nm builds while using the overlay ppa
[19:51] <popey> cihelp is jenkins unwell. an hour after approval this merge hasn't been touched https://code.launchpad.net/~popey/reminders-app/update-icon/+merge/259752
[19:52] <robru> awe: not sure it's really worth it. just know not to use silo 23. there's 40 others ;-)
[19:52] <robru> what in the actual fuck
[19:53] <robru> awe: dont' click build yet, silo just shat itself
[19:54] <awe> k
[19:54] <josepht> popey: it looks like the apt upgrade caused the job to timeout due to a large number of packages needing upgrading
[19:54] <awe> the curse of nm
[19:55] <popey> josepht: oof. getting a fair number of timeouts on jenkins recently
[19:55] <popey> think it needs a few more lumps of coal under it
[19:56] <robru> awe: no what happened was whoever freed it didn't actually cancel a running build job, so the silo was freed, the running build job kept the silo in memory, the build job failed, saving it's state over the new nm state.
[19:56] <robru> awe: should be good now, go ahead with the build.
[19:56] <awe> whew...
[20:02] <boiko> kenvandine: thanks!
[20:02] <kenvandine> boiko, np
[20:07] <brendand_> robru, any new wily image coming?
[20:07] <kyrofa> josepht, just so I make sure I'm doing this right, can you walk me through the process jenkins uses to generate coverage for a cmake project with a "coverage" build type? I want to understand how this works
[20:07] <robru> brendand_: i don't know nuthin bout nuthin
[20:08] <brendand_> robru, honey badger don't care right?
[20:09] <robru> brendand_: I'm neck deep in other stuff. maybe ogra_ or rsalveti know about wily image builds?
[20:10] <josepht> kyrofa: I don't think you have to build it.  There's a hook that adds the needed cmake bits.  fginther correct me if I'm wrong please.
[20:11] <kyrofa> josepht, I think you're right, from what I've learned so far. I just want to make sure I understand what that hook is doing exactly so that I can inject my Go results into the process correctly
[20:11] <kyrofa> josepht, the job needs all the dependencies, right? So I'm assuming it uses debian/control to get those. But them does it run a custom command outside the .deb build process to get the coverage results?
[20:13] <robru>  ChrisTownsend: ok I hit publish on silo 21, that'll go into UNAPPROVED, please lean on SRU people to get it accepted into trusty-proposed ASAP.
[20:13] <kyrofa> josepht, it sounds like that's what the hook is doing (i.e. something completely external to the .deb build process)
[20:14] <ChrisTownsend> robru: Thanks!  I'll try to bribe them with beers.
[20:14] <josepht> kyrofa: I'm looking now.
[20:14] <robru> ChrisTownsend: excellent plan ;-)
[20:15] <kyrofa> josepht, thank you very much!
[20:24] <josepht> kyrofa: the hook is here: http://bazaar.launchpad.net/~private-ps-quality-team/pbuilderjenkins/trunk/view/head:/hooks/H10enable_coverage.in
[20:28] <kyrofa> josepht, thank you! Exactly what I was looking for :)
[20:28] <josepht> kyrofa: np
[20:30] <josepht> popey: I'm still looking for the coal skuttle now :)
[20:33] <josepht> popey: actually it seems to have passed on a subsequent build.
[20:35] <popey> josepht: yay, thanks
[20:35] <josepht> popey: np
[21:03] <kgunn> robru: just checkin' we were hoping to see mir landing sync'd to wily soon.....that sync needs to happen so we can land a unity8 silo 4
[21:03] <kgunn> do you know if that's gonna happen soon?
[21:03] <kgunn> (guess sil ran out of silos earlier)
[21:04] <robru> kgunn: first I've heard of it... Do you have a spread sheet row?
[21:05] <camako> robru, row 74 (and soon row 78)
[21:05] <robru> kgunn: there is one free silo if you want to nab it
[21:05] <kgunn> ...right, just need 74 really
[21:05] <robru> K, one sec
[21:07] <robru> kgunn: ok you're in silo 30, please build.
[21:08] <kgunn> ta
[21:08] <robru> yw
[21:12] <kgunn> robru: so...for a sync, do i just include qtmir-gles in the rebuild? or do i have to do the "ignore gles twins" dance ?
[21:12] <robru> kgunn: should be fine as is, both packages are already there so there's no dance to do
[21:12] <kgunn> cool
[21:13] <robru> kgunn: just consider if you want source or binary copy.
[21:13] <robru> Heh, to late
[21:14] <kgunn> robru: :) we were just wondering....
[21:15] <kgunn> could we sync binary like that ?
[21:15] <kgunn> from vivid+ to wily ?
[21:15] <kgunn> would think rebuild is safer
[21:16] <robru> kgunn: I'm not on the details. If the toolchaib had changed much then you need a rebuild. But the earlier in the cycle, the safer and easier binary copy is
[21:16] <kgunn> yeah
[21:34] <robru> kgunn: oh, uh, so silo 11 has mir in it and was only just approved. were you intending to have that synced to wily as well? because as it stands you missed it.
[21:35] <camako> robru,  that's my silo..
[21:35] <camako> robru, and yes it needs to be synced
[21:35] <robru> camako: k, because the sync that kgunn just started in silo 30 does not include it
[21:36] <camako> robru, why did it need to?
[21:36] <robru> camako: well that's what I'm asking.
[21:36] <camako> robru, Ah okay
[21:36] <robru> oh good
[21:38] <robru> camako: nm that error, just transient, it's copied now. silo will merge/clean soon
[21:38] <robru> kgunn: you'll need to resync if you want to include camako's landing ^
[21:40] <kgunn> robru: ack
[21:42] <kgunn> robru: matter of curiosity....so camako's is mir0.13.1 whereas the one i'm building is mir0.13....so
[21:42] <kgunn> when syncing
[21:42] <kgunn> is it proper to sync every landing ?
[21:42] <kgunn> or can you actually skip...
[21:42] <kgunn> e.g. could we just land mir0.13.1 ?
[21:42] <kgunn> and ignore the sync of mir0.13 ?
[21:46] <robru> kgunn: it's totally fine to skip when they're this close together, since 0.13.1 includes all of 0.13.0. You just can't skip them if there's a long delay between then as that results in them being out of sync for a long time.
[21:48] <kgunn> robru: ok...so it's just kind of sensible
[21:48] <kgunn> do whatever is right TM :)
[21:48] <camako> robru, and I don't need to build anything, correct? Or do I?
[21:48] <kgunn> camako: so maybe we swap that out
[21:48] <kgunn> and do a binary sync ?
[21:48] <kgunn> tool chain hadn't changed i think...
[21:48] <robru> camako: nope your silo will free automatically
[21:49] <robru> kgunn: yeah binary sync is probably fine, the only trick is that if the rebuilt source has a higher version number then the binary sync will fail.
[21:56] <cjwatson> awe: I'd be veeeery wary of wiping the history; if we had to do something heroic then my preferred option would be to pick some other silo in progress, binary-copy everything out of that to this silo, jedi-mind-trick the train into moving its records around of which silo is in use for what, and thereby free up another silo; mostly because that can be done entirely by the landing team and doesn't require crafting manual SQL
[21:56] <cjwatson> awe: (silos are total PPA abuse, fixing this properly requires "ephemeral PPAs" which hopefully will be practical soonish ...)
[21:57] <awe> cjwatson, ugh
[21:57] <awe> guess I'll just stay from silo 023 next time I do a nm fix
[21:57] <awe> ;)-
[21:57] <cjwatson> awe: your odds are good
[21:57] <awe> thanks
[21:57]  * awe likes good odds
[22:30] <jdstrand> cwayne, pmcgowan: fyi, apparmor -easyprof-ubuntu in silo 17 is tested and ready to publish
[22:30] <jdstrand> cwayne: should I wait for you to generate the custom tarball or just publish?
[22:30] <robru> cjwatson: yeah we moved it already. Can't wait for ephemeral ppas ;-)
[22:31] <jdstrand> I'm stepping away for a bit, but will read backscroll
[22:32] <robru> jdstrand: wait
[22:32] <robru> jdstrand: does it need qa?
[22:33] <robru> jdstrand: pmcgowan i mean presumably everything for vivid needs qa, not sure if this is excepted for some reason
[22:39] <jdstrand> robru: I excepted it cause there are no code changes and extremely low chance of regression-- it only adds accesses that currently nothing uses
[22:39] <jdstrand> and it would end up being QA'd via the custom tarball that is coming anyway
[22:39] <robru> jdstrand: OK thanks, will publish
[22:39] <jdstrand> if QA wants to do more qa on it, that's fine
[22:40] <jdstrand> ok, thanks
[22:43] <cwayne> jdstrand, custom tarball isn't ready *quite* yet, but it should be tomorrow i think.. in the meantime, no customers are running vivid, so longer boot times aren't as huge an issue I suppose?
[22:52] <robru> oooh two free silos, anybody want?
[22:58] <popey> jdstrand: got an apparmor question...
[22:59] <popey> 10:53 < popey> Anyone know much about ubuntu-html5-app-launcher? I have an html5 app which works with 14.10-html framework, but with 15.04-html framework I get an apparmor denial..
[22:59] <popey> 10:53 < popey> [M#f?[ 1209.474884] type=1400 audit(1432201895.125:70): apparmor="DENIED" operation="exec" profile="dontcrash.popey_dontcrash_0.7"  name="/usr/bin/ubuntu-html5-app-launcher" pid=23440 comm="exec-line-exec" requested_mask="x" denied_mask="x" fsuid=32011 ouid=0
[22:59] <popey> jdstrand: ^