[02:05] <imgbot> [02:39] <bfiller> robru: still around?
[03:35] <imgbot> [03:35] <imgbot> [06:13] <bzoltan> Mirv:  would you assign a silo to the line84 please?
[06:19] <Mirv> bzoltan: sure
[06:22] <bzoltan> Mirv:  danke
[06:22] <Mirv> cihelp this seems a permanent problem https://jenkins.qa.ubuntu.com/job/kubuntu-packagers-kubuntu-packaging-qtdeclarative-opensource-src-vivid-amd64-autolanding/2/console can you help?
[06:42] <bzoltan> Mirv:  May I ask a reconf for the silo3?
[07:15] <vila> Mirv: I'm not here yet but AFAIK this smtp issue is worked on, will check the RT ticket after coffee&shower ;)
[07:18] <vila> Mirv: RT 77380 , acted on but still broken, so, known
[07:43] <Mirv> vila: thanks!
[07:44] <Mirv> bzoltan: done.
[07:45] <vila> Mirv: I lack some info though, are those job failures new ? I.e. I'm trying to understand if the mails were previously dropped on the floor instead of leading to job failure
[07:54] <Mirv> vila: I haven't tried that for some time, proposing against Qt branches since they have a bit special setup that assumes the upstream version is already in archives. in other words, for that package I couldn't do that before now.
[07:55] <Mirv> vila: worked in August :)
[07:55] <vila> Mirv: lol
[07:55] <vila> Mrlet's go back to August !
[07:55] <vila> bah
[07:55] <Mirv> then the whole 5.3.2 work was done, and this is the first update tried to be done via merging.
[07:56] <Mirv> or I tried also one qtbase branch and pinged ci_help about it and didn't get an answer. it looked like the qtbase stuff is broken since it tries to download the +dfsg orig tarball from a PPA
[07:57] <vila> Mirv: ci_help or cihelp ? Nobody track the former
[07:57] <Mirv> vila: cihelp but I thought you get additional pings everytime I use so I tried to avoid :) I can't find my own branch, but this is an example of that failure https://jenkins.qa.ubuntu.com/job/kubuntu-packagers-kubuntu-packaging-qtbase-opensource-src-vivid-amd64-ci/2/console
[07:58] <vila> Mirv: just checking as you said you got no answer, sorry I should know you know ;)
[07:58] <Mirv> at that point in time the tarball was already in archives even, but I had moved on from that particular ppa before I switched to Debian's +dfsg tarball
[07:59] <Mirv> vila: so these MP:s are not needed for me at all but QA requested I'd do those to get some code coverage numbers. that's about all I know about it.
[08:00] <vila> Mirv: ok, so, just to make sure we're on the same page. Is the issue related to smtp or is there another one I don't quite get about +dfsg tarball ?
[08:00] <Mirv> vila: there is another one about the +dfsg tarball
[08:00] <vila> Mirv: if it's smtp, may be we can just disable the email notification until it's fixed
[08:00] <Mirv> qtdeclarative doesn't have +dfsg tarball so it doesn't suffer from the same problem
[08:02] <vila> Mirv: and what can CI do for that ?
[08:04] <Mirv> vila: you're the author of that system I guess ;) or maybe it'd be on QA's turf.
[08:05] <Mirv> vila: so back in the days someone added to those jobs a logic that tries to find the tarball from a PPA for the case that the MP would be about unreleased Qt (new Qt version). this now fails since the PPA doesn't have those tarballs and it doesn't try to fetch the tarballs from the normal locations.
[08:05] <vila> Mirv: that was an honest question ;) I didn't author most of this stuff and I still have trouble deciphering ;)
[08:05] <vila> Mirv: so that's specific to your qt jobs ?
[08:05] <Mirv> vila: yes, the Qt jobs are somehow special
[08:06] <Mirv> vila: and I'd guess no-one has looke at those since spring or so
[08:07] <vila> Mirv: ok, I'll open a ticket to first check with fginther and whether that should go to Chris Gagnon instead
[08:07] <Mirv> vila: they're related to something I had bookmarked but that seems to be 404 now :) http://s-jenkins.ubuntu-ci:8080/job/aal+-coverity/search/?q=opensource-src-ci
[08:07] <vila> Mirv: but basically you're saying that the job has constraints that you can't respect about +dsfg ?
[08:08] <Mirv> vila: yes, I think those code coverages are something they'd still want
[08:08] <Mirv> vila: the job fails to find the tarball from archives, in short.
[08:08] <Mirv> so the logic should be "first try from archives, then a PPA" if anything
[08:08] <Mirv> vila: and thanks!
[08:09] <vila> Mirv: ack, this is way above my head, so I collect and dispatch ;)
[09:20] <zbenjamin> Mirv: ping, could you please assign line 85 if you have a second?`
[09:23] <zbenjamin> Mirv: that was fast :)
[09:23] <Mirv> zbenjamin: you're welcome :)
[09:32] <ogra_> popey, you around today ?
[09:32] <davmor2> popey: meeting
[09:33] <ogra_> psivaa_, do you know if anyone is fixing the krillin dashboard ?
[09:33] <ogra_> we still cant get past U1 Auth
[09:34] <jibel> cihelp ^^
[09:34] <psivaa_> ogra_: ohh, i was able to
[09:34] <psivaa_> let me check
[09:34] <ogra_> psivaa_, "canonical" isnt allowed ...
[09:35] <psivaa_> ogra_: vila was mentioning that he had to tweak the company wide VPN config to get pass that
[09:35] <psivaa_> https://pastebin.canonical.com/122154/
[09:35] <psivaa_> ogra_: the ci-lab vpn wont work anymore afaik
[09:36] <ogra_> well, we are blind since days, would be good to get access back today ... i'll check my vpn config ... such stuff should be sent to the ML
[09:36] <ogra_> (meeting atm, i'll test it afterwards)
[09:37] <psivaa_> ogra_: ack, thanks
[09:40] <mlankhorst> infinity: yeah it's just because of a change in mir I think
[09:40] <ev> ogra_: it was. See the "Status of CI Services" mail
[09:40] <ev> "Also, please be aware that the VPN to access the internal CI services has changed. For the new VPN go to https://wiki.canonical.com/InformationInfrastructure/IS/HowTo/CompanyOpenVPN for instructions."
[09:40] <ogra_> ev, oops, thanks ... i only read the last two of these it seems :P
[09:41] <ev> ogra_: :D
[09:41] <ev> ogra_: we're doing everything we can to keep you guys in the loop, but if you feel you're missing some critical details, do come to myself or fginther
[09:41] <ogra_> ev, will do
[09:42] <ev> cheers
[09:43] <bzoltan> ogra_:  is the vivid #58 somehow broken? Mine got in reboot cycle
[09:43] <ogra_> havent herad anything
[09:44] <ogra_> *heard
[09:44] <bzoltan> ogra_:  :) now you did
[09:46] <ogra_> bzoltan, do you get to the spinner ? if not i would blame the device tarball ...
[09:47] <bzoltan> ogra_: no spinner
[09:48] <ogra_> bzoltan, then let me introduce you to john-mcaleely :)
[09:48] <pstolowski> hey trainguards, i need to rebuilt silo 010 cause unity8 from another silo landed recently; but it says it's already built; what do i do?
[09:49] <Mirv> pstolowski: tick force_rebuild and list "unity8" in the packages to build
[09:51] <pstolowski> Mirv, thanks
[09:54] <bzoltan> ogra_:  hmm... now I see the spinner for few secs ... I have removed the cache and the user data from recovery
[09:56] <ogra_> bzoltan, http://people.canonical.com/~ogra/touch-image-stats/52.changes the only thing i could imagine to be at fault here is unity8 then ... what was the image you used before ?
[09:57] <ogra_> (57 ? )
[09:57] <bzoltan> ogra_: I do not remember maybe rtm #173
[09:57] <ogra_> there was a session manager change in 57 ...
[09:58] <ogra_> http://people.canonical.com/~ogra/touch-image-stats/51.changes
[09:58] <ogra_> (i doubt anyone actually tests vivid on krillin much btw)
[09:58] <bzoltan> ogra_:  is there a way to bootstrap that beauty?
[09:58] <ogra_> sure, boot into bootloader and usew u-d-f with --bootstrap
[09:59] <bzoltan> ogra_:  how to boot it to bootloader ... I pushed power+volume up .. it went to the recovery mode
[10:00] <ogra_> hmm, i forgot the key combo ... it is on the krillin wiki somehwere
[10:00] <ogra_> but in recovery you can "adb reboot bootloader" in any case
[10:01]  * ogra_ is afk for a bit
[10:06] <bzoltan> ogra_:  that made the trick
[10:52] <davmor2> ogra_: so what happens to the landing meetings next week if you and sil2100 are both off, is Mirv responsible for everything? :D
[10:52] <ogra_> davmor2, i dont think sil is off next week
[10:53] <ogra_> ev, so i dont get access to the rtm dashboard even after switching to the new vpn
[10:54]  * ogra_ tries a reboot
[10:55] <ogra_> probably some old stuff from the old vpn is still dangling around
[10:55] <ev> ogra_: yeah, maybe clear out your cookies as well?
[10:55] <ev> it's working here: http://rtm-dashboard.ci.ubuntu.com
[10:55] <oSoMoN> trainguards: can I have silos for lines 40 and 41, please?
[10:55] <ogra_> well, i did a complete logout/login process
[10:56] <jibel> ev, I cannot access it either, from FF or Chrome
[11:04] <ogra_> ev, no go, even after reboot my canonical Oauth membership isnt enough
[11:04] <ogra_> "Either you have not been granted access to this resource or your entitlement has timed out. Please try again."
[11:06] <ev> ah ha!
[11:06] <ev> if I uncheck the ci-engineering team box it won't let me through
[11:06] <ogra_> aha
[11:06] <ogra_> so just add "canonical" to ci-engineering :P
[11:08] <ev> lolz
[11:28] <ev> ogra_, jibel: #webops is looking into it. I'll keep you posted
[11:28] <ogra_> ev, thx
[11:29] <Mirv> oSoMoN: done.
[11:29] <jibel> ev, thanks
[11:30] <oSoMoN> Mirv, thanks!
[11:37] <Mirv> pstolowski: you'd need proper MP URL instead of lp:~ in the spreadsheet
[11:39] <pstolowski> Mirv, ah, sorry, i keep doing that mistake every so often..
[11:39] <pstolowski> Mirv, fixed
[11:42] <Mirv> pstolowski: thanks
[11:51] <bzoltan> ogra_:  either the #58 is busted in a way or yet again something  has changed what breaks the silo testing process
[12:14] <Saviq> trainguards, can we have silos for rows 43 and 44 please :)
[12:24] <Mirv> Saviq: done, although pstolowski will probably want to land vivid-010 first
[12:24] <Saviq> Mirv, yeah, I know he will
[12:24] <Saviq> Mirv, am preempting
[12:26] <Mirv> Saviq: note same pre-emption rtm-003 has unity-scopes-shell. I'll comment on the QA board that it'd need to be sign-off:d first if possible.
[12:26] <Saviq> Mirv, see my comment in the spreadshit ;)
[12:26] <Mirv> Saviq: oh :)
[12:27] <Mirv> pstolowski: did brendand contact you about https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1394155 not being targeted at the moment to rtm?
[12:27] <Saviq> Mirv, and yeah, rtm-003 is blocked atm, mine will be as well, need to harass the product team
[12:27] <Mirv> pstolowski: which apparently holds up them from starting QA sign-off on the silo
[12:27] <brendand> Mirv, i didn't. hopefully somebody did
[12:28] <pstolowski> Mirv, no he didnt' but Saviq did. I'll push for it to be accepted, it can manifest itself with any other scope
[12:28] <Mirv> Saviq: thanks, for the pusing.
[12:28] <Mirv> +h
[12:29] <john-mcaleely> bzoltan, ogra_ how can i help (I'm on spotty network coverage today)
[12:30] <bzoltan> john-mcaleely: my device gets into reboot cycle after I set it up for silo validation
[12:30] <ogra_> john-mcaleely, not sure you can, i guess it is something else ... vivid 57 doesnt seem to boot on krillin for bzoltan
[12:30] <bzoltan> john-mcaleely:  I am not sure if you can help with this
[12:30] <john-mcaleely> ogra_, that's very wierd, and I hope it's something else :-
[12:30] <john-mcaleely> .
[12:30] <john-mcaleely> :-/ even
[12:30] <ogra_> he said first he didnt reach the spinner ... which kind of pointed to device tarball ... but later the spinner was shortly visible
[12:30] <bzoltan> ogra_:  it is vivid #58
[12:31] <ogra_> ah, right 58
[12:31] <john-mcaleely> oh, ok. unless there's a hybris update that happened for other devices?
[12:31] <bzoltan> ogra_:  I am narrowing now down the issue
[12:31] <john-mcaleely> that can bork at this point, I think
[12:35] <cwayne_> davmor2, any chance of custom testing today?
[12:35] <davmor2> cwayne_: do it now
[12:35] <cwayne_> davmor2, you're my favorite.
[12:45] <davmor2> cwayne_: by the way thanks for the galileo update :)
[12:46] <cwayne_> davmor2, :) np
[12:46] <davmor2> cwayne_: works really nicely from your ppa so I assume I missed something from my install :)
[12:48] <cwayne_> davmor2, i remember pyusb was being a PITA, so could be that :)
[12:54] <Saviq> trainguards, can we have vivid silo 14 published and 9 reconfigured (added qtmir there)
[12:58] <bzoltan> ogra_:  here is what I suspect ->  before running silo validation one need to install a bunch of packages on the device -> http://pastebin.ubuntu.com/9488804/ If I skip that step then all looks good and the device is fine. If i install these packages from the archive on the the #58  then the next reboot will end up in a loop
[12:58]  * bzoltan said few zillion times that an R&D channel  with the core AP packages would be super cool
[12:58] <ogra_> bzoltan, oh, so 58 itself is ok ?
[12:58] <bzoltan> ogra_:  yes
[12:58] <ogra_> phew
[12:58] <bzoltan> ogra_: :D
[13:07] <Saviq> trainguards, also, reconfigure rtm silo 7 please, added mediascanner scope there
[13:24] <bzoltan> ogra_:  yeps... confirmed. installing those AP packages messes up the system
[13:31] <Mirv> Saviq: on those
[13:35] <Mirv> (done)
[13:36] <Saviq> Mirv, thanks!
[13:40] <jibel> ogra_, rvr finished testing silo 000.
[13:42] <ogra_> jibel, did it help ?
[13:42] <ogra_> (or rather: did it pass ?)
[13:42] <jibel> ogra_, yes, it fixes the problem. he already verified that it didn't break the original purpose of the fix.
[13:42] <jibel> s/already/also/
[13:43] <brendand> pmcgowan, https://bugs.launchpad.net/ubuntu/+source/indicator-network/+bug/1382033 has no c-s-i task for ww51
[13:43] <ogra_> jibel, great, tell me once it is signed off
[13:43] <jibel> rvr, ^
[13:43] <ogra_> i'll triggern an image then
[13:43] <brendand> pmcgowan, but it's tagged ota1 - is it alright?
[13:47] <pmcgowan> brendand, its not explictly approved no
[13:47] <pmcgowan> we could do
[13:49] <pmcgowan> brendand, I see that it got silod with another fix
[13:49] <pmcgowan> if its easiest we can land it
[13:50] <pmcgowan> its a small fix
[14:00] <jibel> ogra_, rvr signed it off, but we need an upstream to do the verification too?
[14:00] <ogra_> i thought we're good if two different people do it
[14:01] <ogra_> (thats why i asked in teh meeting if you have resources to do that in QA)
[14:05] <oSoMoN> trainguards: can silo 1 be published, please?
[14:05] <Mirv> oSoMoN: not approved https://code.launchpad.net/~osomon/webbrowser-app/remove-getUAString-API/+merge/244558
[14:05] <oSoMoN> ouch
[14:05] <Mirv> oSoMoN: :D related to that..
[14:05] <oSoMoN> now it is
[14:06] <Mirv> oSoMoN: done
[14:06] <oSoMoN> cheers!
[14:06] <Mirv> in the ideal world, teams could set a setting "do we require top-approves"
[14:06] <Mirv> lots of todo items for the team available for creating the ideal world
[14:09] <jibel> ogra_, I ran url-dispatcher test plan but it's really basic. but I guess that's what the devs do too
[14:09] <jibel> anyway. I'll mark it as pass
[14:09] <kenvandine> cihelp:  I no longer have a rebuild link in jenkins for MP jobs, did I get removed from some group?
[14:10] <Mirv> jibel: yes, the test plan should be what the upstream uses (and it should be enough if it's not lacking)
[14:10] <jibel> Mirv, well, no wonder there are regressions :/
[14:10] <ogra_> heh
[14:10] <Mirv> jibel: that's why I think QA has tried to push upstreams for better test plans..
[14:11] <Mirv> I agree with QA that a good test plan is uber important
[14:11]  * Mirv publishes
[14:11] <jibel> Mirv, some are very good, some are less good, it varies a lot.
[14:12] <kenvandine> oh... the ubuntu-system-settings-ci project is disabled
[14:12] <pmcgowan> brendand, that indicator bug is approved
[14:12] <pmcgowan> kenvandine, is that the issue with silo 2?
[14:13] <kenvandine> pmcgowan, ?
[14:13] <pmcgowan> kenvandine, MRs not approved
[14:13] <kenvandine> oh my... missing top-approval :/
[14:14] <kenvandine> pmcgowan, no reason, it's just hard to keep track of all the cherry pick branches
[14:14] <Mirv> ogra_: start your rmadison -s ubuntu-rtm/14.09 url-dispatcher loop :)
[14:15] <kenvandine> and that was a fix that was specific to fixing a regression found in this silo so we went straight to adding it to the silo
[14:15] <kenvandine> my mistake...
[14:15] <kenvandine> pmcgowan, i fixed and published :)
[14:15] <pmcgowan> great
[14:16] <kenvandine> i see the email about MP jobs, disabled again... so i guess that's why i can't rebuild
[14:16] <Mirv> uh oh, US came online of course :) we kind of discussed that we can postpone 002 until 000 is in and a new image is rolled, but we didn't write it to the spreadsheet...
[14:16] <pmcgowan> hmm I thought QA wanted an image with one fix in it
[14:16] <tedg> jibel, rvr, thanks for looking at the url-dispatcher silo!
[14:16] <Mirv> but ken's landing must be perfect
[14:16] <Mirv> tedg: not only looking, we created it :)
[14:16] <kenvandine> Mirv, it is :)
[14:17] <jibel> Mirv, please no more uploads otherwise, otherwise we won't be able to test the delta only
[14:18] <jibel> s/otherwise//
[14:19] <Mirv> jibel: yes, I won't publish anything, and ken is usually the only addition to the usual trainguards that does publishings.
[14:19] <kenvandine> sorry... i just did it because i saw someone else had tried to publish it
[14:20] <Mirv> yes it was obviously not marked as what we discussed, and it was just by the luck of non-approved MP that I didn't publish it in the morning before our meeting
[14:20] <Mirv> so it was quite destined to be landed anyhow
[14:22] <bzoltan> Mirv:  I am a bit worried about the vivid archive vs vivid image #58
[14:22] <Mirv> bzoltan: what's up?
[14:22] <bzoltan> Mirv:  if you flash the #58 and install few AP packages on it the device will go into boot loop
[14:22] <Mirv> bzoltan: hmm, I'll test
[14:22] <bzoltan> Mirv:  I am strugling with it all day...
[14:23] <Mirv> gah, red light of doom (empty battery)
[14:23] <bzoltan> Mirv: http://pastebin.ubuntu.com/9488804/ these packages pull in something what is not cool with #58 ... so I would predict that the next images might have some issues
[14:24] <boiko> trainguards: can I get vivid silo 8 republished? I removed the MRs that were causing the dependency problems
[14:24] <Mirv> bzoltan: rsalveti has at least done some manual upload of UITK regarding dependencies, you should pull that change into trunk regardless if you haven't yet
[14:25] <rsalveti> right, needs a merge
[14:25] <rsalveti> back in trunk
[14:25] <rsalveti> didn't do that as I'm not part of the sdk team, that's why I asked bzoltan earlier today :-)
[14:26] <bzoltan> Mirv: rsalveti's changes has little if anything to do with this problem
[14:27] <ogra_> rsalveti, hmm ... i cant really land the adbd change without bigger coordination with CI (they need to update u-d-f on the test machines etc) ...
[14:27] <ogra_> not sure thats such a good idea a day before i go on vacation
[14:27] <rsalveti> ogra_: right, guess we can create the silo and then sync with them
[14:27] <ogra_> right
[14:28]  * ogra_ checks rmadison for url-dispatcher
[14:29] <ogra_> pmcgowan, hmm, https://bugs.launchpad.net/ubuntu/+source/android-tools/+bug/1382559 isnt triaged at all for ota-1 yet ... can you mark it for next weeks milestone ?
[14:30] <pmcgowan> ogra_, jibel  I assume the plan is to reopen landings once url dispatchedr fix hits and build starts?
[14:30] <ogra_> (it has the ota-1 tag but wasnt added to csi)
[14:30] <pmcgowan> ogra_, sure
[14:30] <ogra_> pmcgowan, yeah
[14:30] <jibel> pmcgowan, yes
[14:33] <ogra_> Mirv, hmm, did you notice the mail for your vivid ubuntu-touch-session landing ? is my evo going mad or is that completely empty (no changelog entry at all)
[14:34] <ogra_> (not even a version string)
[14:34] <jibel> ogra_, it is not your evo, it's empty
[14:35] <ogra_> smells like a train bug
[14:35] <Mirv> ogra_: I don't get e-mails from my train landings, unless I'm also the MP lander
[14:35] <Mirv> ogra_: do you mean this? http://launchpadlibrarian.net/192263162/ubuntu-touch-session_0.108%2B15.04.20141209-0ubuntu1_0.108%2B15.04.20141210-0ubuntu1.diff.gz
[14:35] <ogra_> ah, i only see it on -changes
[14:36] <ogra_> haha
[14:36] <ogra_> didnt i say that would land :P
[14:36] <Mirv> ogra_: oh, that robru's triple landing thing..
[14:36] <ogra_> https://lists.ubuntu.com/archives/vivid-changes/2014-December/002762.html
[14:36] <rsalveti> hm, a bunch of uploads without change
[14:36] <ogra_> "Sorry, changesfile not available."
[14:36] <rsalveti> for quite a few
[14:36] <rsalveti> ubuntu-touch-session
[14:37] <rsalveti> telepathy-ofono
[14:37] <rsalveti> telephony-service
[14:37] <rsalveti> messaging-app
[14:37] <rsalveti> all without changesfile
[14:37] <ogra_> right
[14:37] <ogra_> and there are others that show the changelog entry but also have that error text in them
[14:37] <rsalveti> right
[14:38] <ogra_> like qtmir
[14:38] <ogra_> seems only train landings are affected though
[14:38] <Mirv> isn't that all silo 008... it looks like it has new branches added after the publishing and then republished
[14:40] <Mirv> so this time dialer-app was new, but the others from the same silo had been already published - but why not merge & cleaned?
[14:44] <Mirv> boiko: have you done anything special with vivid silo 008 that you know of? like adding new branches after publishing the old packages and reconfiguring?
[14:45] <Mirv> boiko: we're just trying to decipher how that silo has been published multiple times, this time dialer-app was new but the others had been already published.
[14:45] <Mirv> it's not a problem but it looks silly
[14:47] <ralsina_> Dear trainguard, can I get a silo for spreadsheet row 46?
[14:50] <greyback> trainguards: can I set a silo for line 48 please, want to land some qtubuntu bits in vivid
[14:51] <jibel> oSoMoN, for silo 5 in the test plan 'webapp-container/config options' what is the expected result for the UA with whichbrowser? unknown or a UA string?
[14:52] <Saviq> trainguards, and I'd like vivid silo 9 to be reconfigured, please - have added qtmir-gles
[14:52]  * Saviq needs to remember adding qtmir-gles into "additional packages to land" straight away
[14:52] <jibel> oSoMoN, the test says it's unknown but then that it is not functional
[14:55]  * Mirv notes there will be gap as soon as I stop working (should have already), until Robert is up
[14:56] <Mirv> Saviq: done
[14:57] <Mirv> ogra_: rmadison says url-dispatcher is in
[14:57] <ogra_> yeah!
[14:57] <ogra_> Mirv, thanks !
[14:57] <ogra_> triggering an image
[14:57] <Mirv> have a good one! :)
[14:58] <ogra_> you too !
[14:59] <boiko> Mirv: the only package that has changed is dialer-app: it first got one MR added, now that one is removed, and one more got removed
[14:59] <boiko> Mirv: but I have only rebuilt dialer-app itself, the other packages are still the same
[15:00] <imgbot> [15:01] <oSoMoN> jibel, yeah, basically this test is not valid until bug 1379497 is fixed
[15:01] <jibel> oSoMoN, so if it says "Chromium ...." that's fine, nothing to do with the change in silo5?
[15:01] <oSoMoN> jibel, so it should be skipped when testing on RTM
[15:01] <jibel> okay
[15:02] <oSoMoN> jibel, nope, indeed
[15:02] <Mirv> boiko: any idea why the packages already got published from that silo, before this dialer-app change?
[15:02] <boiko> Mirv: so, dialer-app got stuck in the proposed pocket because of a dependency change
[15:03] <boiko> Mirv: all the subsequent publications were tries to fix that, but at some point we just gave up (as we still want to cherry pick those for rtm)
[15:03] <dobey> cihelp: what's the currently recommended way to get a click package tested/approved by QA, and uploaded to the store, in the silo process?
[15:04] <dobey> or should i ask that to trainguards ?
[15:06] <boiko> Mirv: if you feel more comfortable with it, I can rebuild the whole silo
[15:08] <plars> dobey: I suspect that's probably a trainguard question
[15:09] <Mirv> boiko: ah, ok, thanks, that's what I wanted to just hear. no, don't rebuild anything more, the new dialer-app is now migrating to release pocket and it will automatically merge & clean! so let's not touch the silo anymore :)
[15:09] <Mirv> (this time it did migrate)
[15:10] <boiko> Mirv: nice! thanks a lot! :)
[15:11] <bzoltan> Mirv:  could you figure out which packages messes up the vivid image #58?
[15:12] <dobey> trainguards: what's the currently recommended way to get a click package tested/approved by QA, and uploaded to the store, in the silo process?
[15:13] <Saviq> Mirv, silo 9 doesn't seem to have noticed that it's reconfigured?
[15:15] <Mirv> Saviq: hmm. I thought I did. now running at https://ci-train.ubuntu.com/job/prepare-silo/3496/console
[15:15] <Mirv> bzoltan: I installed autopilot packages on #52 on mako and did not end up in reboot cycle
[15:15] <Saviq> Mirv, ugh, *just* missed it, I had to add unity-scopes-shell... sorry
[15:16] <Mirv> Saviq: so another one?
[15:16] <Saviq> Mirv, yes, please reconfigure
[15:16] <bzoltan> Mirv:  you installed _all_ packages I listed?
[15:16]  * Saviq thinks we should be able to reconfigure ourselves, it's dumb to have to drag you every time...
[15:17] <bzoltan> Mirv:  http://pastebin.ubuntu.com/9488804/
[15:21] <bzoltan> Mirv:  I am not sure yet, but the UITK is one candidate for the trouble. All other packages are landed via the train after sio validation...
[15:22] <bzoltan> Mirv:  If it is not big trouble I would like to revert that non tested UITK... the change is anyway in the silo what I want to test
[15:26] <oSoMoN> trainguards: can RTM silo 5 be published, please?
[15:28] <om26er> trainguards how can I see an old landing in the spreadsheet ?
[15:29] <Mirv> bzoltan: had not installed everything, now did, no reboot loop
[15:30] <Mirv> everyone: I'm really gone now, you need to wait 1.5h or so for robru
[15:30] <dobey> anyone? :(
[15:31] <om26er> Mirv, do you know ? ^
[15:31] <dobey> om26er: should be on the "Archive" page of the doc
[15:31] <Mirv> om26er: scroll to the bottom (line 1600 or so) in archive and search
[15:32] <dobey> but good luck with that. it's insanely huge, and google docs doesn't do terribly great with giant pages like that
[15:32] <ogra_> dobey, for your click package you should talk to QA ... not a landing team task
[15:33] <ogra_> i assume you need to hand them a test plan, plus the package to get it signed off
[15:33] <om26er> dobey, Mirv thanks found, i was searching the wrong term. Now I found that I was looking form
[15:33] <om26er> *for
[15:34] <dobey> ogra_: in DC there was a meeting where we discussed using the spreadsheet to document the process
[15:35] <dobey> ogra_: ie, we wouldn't get a silo, but we'd put a line in the spreadsheet with necessary info and have QA do the signoff similarly as for siloed packages, and then someone would do the store upload
[15:35] <ogra_> i dont think that has been formalized yet
[15:38] <oSoMoN> trainguards: can I have a silo for line 47 please?
[15:40] <dobey> ogra_: sure. that's why i'm asking for the not-yet-formalized info :)
[15:51] <bzoltan> ogra_:  MIrv is gone .. I can reproduce the reboot cycle easily ... flash the #58, make it writable, apt-get update and install  http://pastebin.ubuntu.com/9488804/ AP packages. That is a blocker for me to land the UITK in Vivid.
[15:51] <ogra_> bzoltan, well, did you do the trunk merge ?
[15:52] <bzoltan> ogra_: what trunk merge?
[15:52] <ogra_> bzoltan, see above ...
[15:52] <ogra_> Mirv answered you (and rsalveti too)
[15:52] <bzoltan> ogra_:  I am talking about a stock #58 image with AP packages ... not silo
[15:53] <bzoltan> ogra_:  1. flash 2. writable 3. install AP pacages 4. reboot .... goes to loop.
[15:54] <ogra_> i know what you are talking about
[15:55] <ogra_> bzoltan, https://launchpad.net/ubuntu/+source/ubuntu-ui-toolkit/1.1.1364+15.04.20141209-0ubuntu2
[15:56] <bzoltan> ogra_: I am very much aware of that ... but me merging it to the UITK trunk will not solve the problem... as it has nothing to do with the landing candidate
[15:56] <rsalveti> can you retrieve your syslog to see what might be causing the reboot loop?
[15:56] <rsalveti> could be a crash or just upstart-watchdog making it to reboot
[15:57] <rsalveti> in case a service is constantly crashing
[15:57] <ogra_> bzoltan, so you are saying you dont install ubuntu-ui-toolkit-autopilot ?
[15:57] <bzoltan> rsalveti:  no, I can not access the device during the reboot loop
[15:57] <rsalveti> you can always make it to boot in recovery and get it from there
[15:57] <bzoltan> ogra_: I do and I do install lots of other things
[15:57] <ogra_> rsalveti, more likely the wrong dep pulls in the -mesa packages
[15:57] <rsalveti> mount /system
[15:57] <rsalveti> could be as well
[15:57] <bzoltan> rsalveti: I would revert that package
[15:58] <rsalveti> bzoltan: when you get the reboot loop, force it to boot to recovery
[15:58] <rsalveti> then mount the fs, and check the logs from there
[15:58] <rsalveti> or just install one dependency a time, reboot and check what is causing the issue
[15:58] <bzoltan> rsalveti: can we revert and then validate your change from the silo?
[15:58] <ogra_> right
[15:59] <rsalveti> which change?
[15:59] <bzoltan> rsalveti:  one dep a time? One round takes half an hour :)
[15:59] <ogra_> do it one by one (though i'm rather sure it is the uitk--ap package)
[15:59] <rsalveti> my change didn't cause this
[15:59] <bzoltan> rsalveti:  your change
[15:59] <rsalveti> I added a | that only affects the emulator
[15:59] <ogra_> bzoltan, why does apt-get install ... and reboot take half an hour ?
[16:00] <bzoltan> ogra_:  because after that I have to reboot and then reflash the device
[16:00] <ogra_> huh ?
[16:00] <ogra_> you want to seee which akcage causes the loop ... no ?
[16:00] <bzoltan> ogra_:  there is no way out from the reboot cycle ...
[16:00] <ogra_> so install them one by one and reboot inbetween
[16:00] <bzoltan> ogra_:  no :) I want the non tested UITK upload reverted
[16:01] <ogra_> once it goes into the loop you found the issue
[16:01] <ogra_> not sure what we are talking about here ... seems to me like 5 things
[16:02] <rsalveti> bzoltan: that upload didn't cause anything
[16:02] <rsalveti> https://launchpadlibrarian.net/192391562/ubuntu-ui-toolkit_1.1.1364%2B15.04.20141209-0ubuntu1_1.1.1364%2B15.04.20141209-0ubuntu2.diff.gz
[16:02] <rsalveti> -         qtdeclarative5-ubuntu-ui-toolkit-plugin (>= ${source:Version}),
[16:02] <rsalveti> +         qtdeclarative5-ubuntu-ui-toolkit-plugin (>= ${source:Version}) | qtdeclarative5-ubuntu-ui-toolkit-plugin-gles,
[16:02] <rsalveti> this is the change
[16:02] <bzoltan> rsalveti: I know, but have you tested it?
[16:03] <rsalveti> bzoltan: of course
[16:03] <bzoltan> rsalveti: have you run the UITK test plan?
[16:03] <rsalveti> not the entire one, because it's a packaging change that only affects the emulator
[16:03] <rsalveti> tell me how that would break your stuff
[16:04] <rsalveti> if something is broken because of that it would only be related with external build dependencies and so on
[16:04] <om26er> jamesh, Hi!
[16:04] <rvr> ogra_: You confirmed this bug: #1394155. Can you tell me the steps to reproduce? I don't find the label "Tell me more"
[16:05] <om26er> jamesh, whats the status of bug 1379817 for rtm ?
[16:05] <ogra_> rvr, i'm pretty sure i only did what the description says
[16:06] <bzoltan> rsalveti: I am not quite happy that I do 10-12 hours validation before a single byte change in the UITK and now I have to post validate a change what went around the landing process. Nothing personal :) But I see a change what was not tested the way how the UITK shuld be tested.
[16:06] <rvr> ogra_: At the end of the Today scope there is twitter and "See more"
[16:06] <rvr> I'll ping Pete
[16:07] <ogra_> rvr, oh, but that was with the OOTB experience stuff in place which was reverted ...
[16:07] <bzoltan> rsalveti:  you could file an MR against the UITK staging just as anybody else and it could have landed with the CI train in no time.
[16:07] <rvr> ogra_: Aha!
[16:07] <ogra_> rvr, ask pmcgowan or victor where that is gone
[16:07] <rsalveti> bzoltan: dude, check the change
[16:07] <rsalveti> this was blocking the emulator testing
[16:07] <rsalveti> and you can prove that my change broken something, then I'm the one to blame
[16:07] <ogra_> (it was to broken so we ripped it out for GM ... but i dont know where you can get it to test against it)
[16:08] <rsalveti> *broke
[16:08] <pmcgowan> ogra_, hmmm?
[16:08] <bzoltan> rsalveti: usually we do this proving thingy before landing stuff :) not after
[16:08] <bzoltan> rsalveti:  but I am doing what ogra_ suggested right now ...
[16:08] <rsalveti> bzoltan: right, but I wanted to unblock this sooner than later, and as I'm a core-dev I just decided to push a simple package change
[16:08] <rvr> pmcgowan: "Crash of unity8-dash possible through Today scope" #1394155 This apparently fixed a bug raised with the OOTB, but that is gone now.
[16:09] <pmcgowan> ogra_, the scope training stuff? yeah that was pushed out
[16:09] <bzoltan> rsalveti:  please do not do that too often
[16:09] <pmcgowan> rvr, then not sure why thostr_ wanted to land it
[16:09] <rsalveti> bzoltan: only did that because it *only* affects the emulator
[16:09] <rsalveti> nothing else
[16:09] <rsalveti> otherwise I would use a silo
[16:10] <thostr_> pmcgowan: rvr: that crash can also happen in store scope
[16:10] <bzoltan> rsalveti: i understand
[16:10] <imgbot> [16:10] <imgbot> [16:10] <ogra_> pmcgowan, bug 1394155 was only visible with the OOTBE stuff in place
[16:10] <rvr> thostr_: Ok, I'm testing silo 3 and need a test to verify it.
[16:11] <thostr_> ogra_: no, it also crashed store scope sometimes
[16:11] <thostr_> ogra_: https://bugs.launchpad.net/ubuntu/+source/unity-scopes-shell/+bug/1381970
[16:12] <ogra_> thostr_, ah
[16:12] <ogra_> thostr_, do you have repro steps for rvr then ?
[16:12] <thostr_> ogra_: yeah, we also only figured afterwards, meaning when investigating the today scope that this is the same root cause
[16:13] <thostr_> pstolowski: ^ can you recall the exact steps for store crash?
[16:14] <ogra_> jibel,  in case you missed it :)
[16:15] <pstolowski> thostr_, no, seb128 reported it around washington sprint, afair he was just playing around with store. i couldn't reproduce
[16:16] <pstolowski> thostr_, but there was a definately a bug that could corrupt memory
[16:16] <pstolowski> thostr_, which was manifesting itself on Todays scope for some reason
[16:18] <oSoMoN> trainguards: hello? can RTM silo 5 be published, please?
[16:18] <thostr_> pstolowski: it was something triggerable when using departments IIRC, but I fail...
[16:20] <pstolowski> thostr_, seb128 is the only hope
[16:20] <seb128> pstolowski, for what?
[16:21] <thostr_> pstolowski: but the fix we did was cleaning up the state after it has been messed up with departments, no?
[16:22] <pstolowski> thostr_, no, the fix has nothing to do with departments, it just cleans up categories
[16:22] <pstolowski> thostr_, https://code.launchpad.net/~unity-api-team/unity-scopes-shell/today-scope-crash/+merge/242355
[16:23] <pstolowski> seb128, for steps to reproduce unity8 dash crash when using ubuntu store scope that you experienced ~2 months ago
[16:23] <seb128> pstolowski, not sure if that's still happening, I didn't try to trigger that for a while
[16:48] <rvr> thostr_: We are reviewing queued silos. Silo 1 is not tagged for week 51, can you get approval so we can test it? Thanks.
[16:56] <bzoltan> ogra_: it is the messaging-app-autopilot what causes the trouble
[16:58] <bzoltan> ogra_: http://pastebin.ubuntu.com/9491404/
[16:58] <ogra_> Setting up libgl1-mesa-glx:armhf (10.3.2-0ubuntu1) ...
[16:58] <ogra_> update-alternatives: using /usr/lib/arm-linux-gnueabihf/mesa/ld.so.conf to provide /etc/ld.so.conf.d/arm-linux-gnueabihf_GL.conf (arm-linux-gnueabihf_gl_conf) in auto mode
[16:58] <ogra_> Setting up libxmu6:armhf (2:1.1.2-1) ...
[16:59] <bzoltan> rsalveti:  your change is cleared :) Sorry, last week a simple and clear looking a|b dep screwed up the oxide package, that is why I was suspicious
[17:02] <ogra_> robru, LT meeting ?
[17:13] <thostr_> rvr: silo 1 approved now
[17:14] <rvr> thostr_: Ok!
[17:18] <rsalveti> bzoltan: no worries
[17:25] <bzoltan> robru:  would you please kick the silo6 again, now all the MRs are approved
[17:26] <robru> kenvandine: mterry: anybody around for a packaging ack? https://ci-train.ubuntu.com/job/ubuntu-landing-006-2-publish/lastSuccessfulBuild/artifact/packaging_changes_qtcreator-plugin-ubuntu_3.1.1+15.04.20141212.1-0ubuntu1.diff
[17:27] <mterry> robru, that's a lot of new packages  :)
[17:27] <robru> mterry: yeah ;-)
[17:27] <robru> mterry: ask bzoltan why those are necessary ;-)
[17:28] <mterry> robru, he links the bug in the changelog, looks fine, sure
[17:28] <robru> mterry: oh cool
[17:28] <mterry> all in universe, my MIR senses aren't tingling  :)
[17:28] <bzoltan> mterry: robru: the change is needed to pull the Qt examples, so devs can learn more :)
[17:29] <bzoltan> mterry: robru: before the last landing the qmake based examples were useless ... now they are good
[17:29] <robru> bzoltan: published
[18:22] <pmcgowan> jibel, any results on 177?
[18:31] <dobey> fginther: remember the meeting in DC we had, where it was discussed to have clicks linked in the spreadsheet to go through QA and then get uploaded to the store once approved? is there any sort of process documented or in placed to do that?
[18:35] <ogra_> pmcgowan, still ongoing, sanity was done, now the specific tests for the three landings are happening
[18:35] <ogra_> (gstreamer, url-dispatcher and ubuntu-system-settings got updated for 177)
[18:36] <pmcgowan> ogra_, thanks
[18:41] <cwayne_> davmor2, did the promition testing pre-empt the custom testing btw? (fine if it did, just trying to stay in the loop)
[18:42] <davmor2> cwayne_: custom is done we just want to land 177 and get it promoted before we tell you to press the button,  we just have a couple of delta tests left
[18:43] <cwayne_> davmor2, ah, perfect, thank you :)
[18:43] <pmcgowan> davmor2, not to be a pest but do you have an eta?
[18:43] <davmor2> pmcgowan: few minutes maybe depends how long the gstreamer test takes
[18:43] <pmcgowan> great
[18:43] <dobey> gallery-app is a click package, right?
[18:44] <pmcgowan> yes
[18:45] <ogra_> pmcgowan, why is that so important ? this is an out of line promotion anyway
[18:45] <dobey> hmm, i am slightly confused by like 28 in the spreadsheet then, having a silo
[18:52] <davmor2> ogra_: PPPPPPPPPIIIIIIIIIIIIINNNNNNNNNNNNNGGGGGGGGGGGGGGGGG    is that a big enough ping?   SO delta looks good regression is fixed I assume that means that 177 is blessed :)
[18:52] <davmor2> jibel: ^
[18:52] <ogra_> davmor2, hmm, still 12px high chars  only
[18:53] <davmor2> ogra_: I didn't want to flood the channel with and ascii art ping
[18:53] <ogra_> ogra@anubis:~/touchbot$ ./map-images.sh 177
[18:53] <ogra_> krillin version: 177 maps to mako version: 150
[18:53] <ogra_> krillin version: 177 maps to generic_x86 version: 144
[18:53] <ogra_> davmor2, are the other arches boot tested as well ?
[18:54] <davmor2> ogra_: mako is I can fire up emulator for you
[18:54] <ogra_> cool
[18:56] <davmor2> cwayne_: as soon as you here ogra_ woohoo \o/ !!!! I guess you can hit the button but confirm with ogra_ :)
[18:57] <cwayne_> cool, will wait for that then :)
[18:57] <cwayne_> thanks for testing today davmor2
[18:57]  * ogra_ looks for the pompoms 
[18:57] <davmor2> cwayne_: no worries dude told you ass soon as the promotion test was out of the way I would :)
[18:59] <davmor2> ogra_: 60% downloaded
[18:59] <ogra_> *twiddle*
[19:00] <davmor2> ogra_: 70%
[19:00] <ogra_> *twiddle*
[19:01] <davmor2> ogra_: 80%
[19:01] <ogra_> *twiddle*
[19:01] <davmor2> ogra_: 90%
[19:01] <ogra_> *twiddle*
[19:02] <davmor2> ogra_: setting up
[19:02] <ogra_> *boom*
[19:03] <davmor2> ogra_: now the long silence while it seeming does nothing
[19:03] <ogra_> *twiddle*
[19:05] <davmor2> ogra_: ubuntu-emulator run rtm hit no the picture of a blank phone while I wait for it to come up ;)
[19:07] <davmor2> welcome wizard
[19:09] <davmor2> edge demo complete and on to the apps scope \o/
[19:09] <davmor2> ogra_: ^
[19:09] <ogra_> woohoo \o/ !!!!
[19:09] <ogra_> cwayne_, ^^
[19:09] <cwayne_> ogra_, so im good to push the magic button?
[19:10] <cwayne_> davmor2, did you test es as well?
[19:10] <davmor2> cwayne_: no
[19:11] <cwayne_> if not that's fine, ill just setup both for testing on monday so it'll be a small delta
[19:11] <davmor2> cwayne_: but victor did bar the url change I think
[19:13] <cwayne_> davmor2, hm?
[19:14] <davmor2> cwayne_: just chasing on if he has looked at the latest
[19:16] <davmor2> cwayne_: I'll spin it up now
[19:16] <kenvandine> sigh!
[19:17] <kenvandine> alesage, your bluetooth-page-autopilot-helpers-minus-less-flaky  branch no longer merges cleanly
[19:19] <cwayne_> davmor2, agh, i just realized the deltas are going to be slightly different, so either way we should push both on monday with all the latest to get them back in sync
[19:20] <davmor2> cwayne_: D'oh
[19:20] <cwayne_> davmor2, i could've sworn the spanish build wasn't set to build automatically at midnight, but it seems it still was :(
[19:21] <kenvandine> alesage, you can probably just merge from trunk and clean up the conflict
[19:22] <davmor2> kenvandine: not sure alesage is 100% here, he wasn't feeling too good so if you get no reply it isn't cause he hates you ;)
[19:23] <kenvandine> haha
[19:23] <kenvandine> ok
[19:23] <kenvandine> or not 100% because he hates me :)
[19:23] <cwayne_> davmor2, so we'd have three options then: 1) build a new custom right now with a small delta (that'd be in sync with spanish); 2) push just english today then do both monday; 3) push both today, then do a new custom monday to get in sync
[19:24] <kenvandine> alesage, we just had another landing to trunk, so i needed to rebuild the silo
[19:24] <kenvandine> that probably caused the conflict
[19:27] <davmor2> cwayne_: do it Monday, Lock it down today so there are no more builds, I'll ask vrruiz to test spanish I'll hit the delta in the English and rellease them both then
[19:27] <cwayne_> davmor2, +1, so im good to push english now then?
[19:28] <ogra_> [19:28] <ogra_> (that is krillin 177, mako 140 and emulator 144)
[19:28] <ogra_> victorp, pmcgowan ^^^
[19:28] <kenvandine> WOOT
[19:28] <victorp> \o/
[19:29] <cwayne_> ok, so NOW i can push right ogra_ ? :)
[19:29]  * pmcgowan dances
[19:29] <ogra_> cwayne_, you could when i pinged you already :)
[19:29] <davmor2> cwayne_: yeap sounds good
[19:29] <cwayne_> k, done
[19:30] <cwayne_> davmor2, i'll write up an email about our plan for monday with changelogs
[19:30] <davmor2> cwayne_: cheers
[19:31] <alesage> kenvandine, ok will clean up
[19:32] <alesage> kenvandine, sorry for the delay
[19:32] <cwayne_> done
[19:32] <alesage> kenvandine, don't 100% hate you, for the record
[19:34] <kenvandine> haha
[19:47] <dobey> sigh i just want to get my click tested and shipped to the store :-/
[19:47] <alesage> kenvandine, this merge looks weird, possibly I'm adding some things back, maybe I should replay my changes on trunk https://code.launchpad.net/~ueqa-projects-team/ubuntu-system-settings/bluetooth-page-autopilot-helpers-minus-less-flaky/+merge/244248
[19:48] <kenvandine> alesage, that branch has a prereq on mine right?
[19:48] <alesage> kenvandine no, I made this to go around :( --explicitly "minus less flaky"
[19:49] <alesage> kenvandine, can whip up another one plus less_flaky if that's what we want
[19:49] <kenvandine> can you pastebin the diff?
[19:49] <kenvandine> your other branch depended on it, it's fine
[19:49] <alesage> kenvandine, I've already merged and pushed, it's in the MP
[19:49] <kenvandine> ok
[19:50] <kenvandine> alesage, that looked fine
[19:51] <alesage> kenvandine, ok--line 171 even?  didn't change that one
[19:51] <kenvandine> 171 of the MP diff?
[19:52] <alesage> kenvandine, yessir
[19:53] <kenvandine> that looks like it might be from my less_flaky branch?
[19:53] <kenvandine> are you sure you didn't merge my branch?
[19:53] <alesage> kenvandine, one sec
[19:55] <alesage> kenvandine not seeing it in the log, would you mind very much if I just replay my change on trunk?  don't want to break the world
[19:55] <kenvandine> maybe... hang on
[19:56] <kenvandine> alesage, that addition of _dialpad_sounds was in my less_flaky branch
[19:56] <kenvandine> you must have merged that in at some point
[19:56] <alesage> kenvandine, weird, my mistake
[19:57] <kenvandine> can you add the prereq?
[19:57] <alesage> kenvandine, ok
[19:57] <kenvandine> oh wait
[19:57] <kenvandine> you had merged my less_flaky in that yesterday :)
[19:57] <kenvandine> to fix a merge problem :)
[19:57] <kenvandine> but never added the prereq
[19:58] <alesage> kenvandine, resubmitted https://code.launchpad.net/~ueqa-projects-team/ubuntu-system-settings/bluetooth-page-autopilot-helpers-minus-less-flaky/+merge/244650
[19:59] <alesage> kenvandine, I need a weekend, evidently :)
[19:59] <kenvandine> me too!
[19:59] <kenvandine> thanks
[20:00] <alesage> kenvandine, I'm surprised if you got what you wanted by skipping that test?  (not saying this to throw a wrench into the works though ;) )  or is that unresolved?
[20:02] <kenvandine> unsure since CI got disabled again
[20:03] <kenvandine> alesage, but we know all the other tests pass in CI
[20:03] <kenvandine> it's the one single failure...
[20:03] <kenvandine> alesage, you think we'll start seeing a failure in another test with that one skipped?
[20:06] <alesage> kenvandine, ok well if that fixes it I'm convinced
[20:07] <kenvandine> alesage, hopefully we get CI again so we can see :/
[20:07] <kenvandine> soon i meant
[20:07] <alesage> kenvandine, indeedy
[20:09] <kenvandine> grr
[20:10] <kenvandine> alesage, can you merge my less_flaky branch again?
[20:11] <kenvandine> somehow it's still conflicting
[20:11] <alesage> egads, ok kenvandine
[20:14] <alesage> kenvandine, pushed
[20:15] <kenvandine> thx
[20:15] <alesage> kenvandine, that looks right now also
[20:15] <kenvandine> cool
[20:15] <om26er> rsalveti, Hi! can you confirm if silo12 only fixes bug 1376500 ?
[20:15] <alesage> kenvandine, informed of a criss-cross merge, something weird in the history there
[20:15] <alesage> kenvandine, almost certainly my fault :/
[20:17] <kenvandine> alesage, i added the commit message there
[20:17] <kenvandine> building again :)
[20:18] <alesage> kenvandine, all of this is to demonstrate how much I will have improved as a lander next time ;)
[20:18] <kenvandine> :)
[21:08] <alesage> hey hey
[21:11] <pmcgowan> why do I see a 178