[00:25] <robru> Queuebot, nooooooooooooo
[01:18] <bfiller> robru: I need a silo for line 94 please
[01:21] <bzoltan1> rsalveti: I used to use the `gdbus call --session --dest com.canonical.UnityGreeter --object-path  --method com.canonical.UnityGreeter.HideGreeter|grep -v '\(\)'` to hide the greeter... it does not seem to do the job. Do you know what should I use instead?
[01:22] <rsalveti> bzoltan1: hm, no idea, mterry might know
[01:23] <bzoltan1> rsalveti: he is not around. ogra_ gave me this line... I need to unlock the screen and kill the greeter after resets between AP tests
[01:23] <rsalveti> robru: any idea ^?
[01:29] <bzoltan1> rsalveti:  the best kept secret of the CI :) is how the CI dash does things ... I am positive that nobody is unlocking the screen and typing passcodes manually there :) So there is a CI approved way to do. It would be cool to share those lines with the pubic.
[01:29] <rsalveti> bzoltan1: yeah, I know ogra_ was involved with that, maybe plars has any idea
[01:30] <bzoltan1> rsalveti:  for me that shell function used to work -> http://pastebin.ubuntu.com/8476271/ But not anymore.
[01:51] <plars> bzoltan1: rsalveti: you want to use /usr/share/unity8/unlock-device from unity8-autopilot
[01:52] <plars> it's made to be pulled onto the adb host and run from there
[01:53] <plars> otherwise, if you just want the dbus call, you should be able to run:
[01:53] <plars> adb shell "gdbus call --session --dest com.canonical.UnityGreeter --object-path / --method com.canonical.UnityGreeter.HideGreeter && echo Greeter unlocked"
[01:53] <bzoltan1> plars: Thanks I prefer the dbus call... I do my own reboots :)
[01:53] <plars> bzoltan1: actually, that looks the same as what you were running I think
[01:54] <plars> bzoltan1: we have seen it fail a few times if it's done too soon, what's it returning for you?
[01:54] <bzoltan1> plars:  it looks similar to my script, but it is not the same
[01:55] <bzoltan1> plars: I would not use the `adb reboot; sleep 5; adb wait-for-device`
[01:55] <bzoltan1> plars:  that is unreliable...
[01:56] <plars> bzoltan1: the sleep is more than enough to ensure that we don't return from wait-for-device before the reboot
[01:56] <plars> bzoltan1: or were you referring to something else?
[01:57] <bzoltan1> plars: sometomes... but 10 sec is safer
[01:57] <plars> bzoltan1: I've never seen that part of it fail so far, really we could probably even get away with less
[01:58] <plars> bzoltan1: the part we have problems with is that if it fires too soon after boot, sometimes it can't make the dbus call yet
[01:58] <bzoltan1> plars:  I run my reset like 100-200 times a day when I do... weekly.
[01:58] <plars> bzoltan1: mterry just landed a change that loops it a few times if it fails though
[01:58] <bzoltan1> plars: I think I stick to my script with the right dbus call :)
[01:59] <plars> bzoltan1: feel free to propose an improvement to it if you have something that works better :)
[02:00] <bzoltan1> plars:  according to my experience there is no sure way... I have to tune my script  every week.
[02:00] <bzoltan1> plars:  Things change all over without much notice and tools fail without any meaningful error... so it is a continuous fight :)
[02:06] <bzoltan1> plars:  so that dbus call takes away the Greeter. But does it take away the password lock too?
[02:07] <plars> bzoltan1: yes
[02:07] <bzoltan1> plars:  cool, thank you
[02:09] <imgbot> [02:22] <bzoltan1> plars:  I am still lobbying :) for releasing the CI validation tools via the CI train to the archive. Make it pass all the QA standard what other packages pass and offer a tool what developers can apt-get install and use
[02:31] <plars> bzoltan1: that script is part of unity8 - it already goes through the landing process same as everything else
[03:05] <robru> rsalveti: sorry nope, i just do train stuff, dunno about messy device stuff like greeters ;-)
[03:09] <robru> bfiller: utopic 2
[03:09] <imgbot> [03:14] <bzoltan1> robru: the clock app fails with the stock RTM image but all green on the CI dash.
[03:19] <bzoltan1> robru:  also the dialer_app tests are flaky
[03:28] <rsalveti> robru: just configured silo 8 and can't build: https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/82/console
[03:37] <robru> rsalveti: weird. click IGNORE_STEP for now
[03:37] <robru> bzoltan1: no idea
[03:42] <robru> rsalveti: hm that's odd... still digging
[03:44] <rsalveti> robru: hm, also failed
[03:44] <robru> rsalveti: the thing is I just refactored that code, and now it makes no sense to me. I need to review the old code to see how badly I broke it i guess.
[03:44] <rsalveti> but differently
[03:45] <robru> rsalveti: that one's a legitimate failure though, isn't it? ;-)
[03:45] <rsalveti> oh, need to put force rebuild
[03:46] <robru> rsalveti: well wait
[03:46] <robru> rsalveti: the trunk branch is really missing that revision from distro.
[03:46] <robru> rsalveti: make sure you check that before you just wantonly revert it
[03:46] <rsalveti> robru: yup, no worries, that is as expected
[03:46] <rsalveti> not landing this until my other landing migrates properly
[03:47] <robru> rsalveti: right http://launchpadlibrarian.net/186327488/ubuntu-touch-session_0.108%2B14.10.20140926.1-0ubuntu1_0.108%2B14.10.20140929-0ubuntu1.diff.gz you need to push this to trunk ;-)
[03:47] <rsalveti> robru: can't yet because it's waiting on another silo to be cleaned
[03:47] <rsalveti> guess I can actually
[03:47] <rsalveti> but the clean step from the other silo might fail
[03:48] <rsalveti> which is fine I guess
[03:48] <robru> rsalveti: why would the clean step fail? wouldn't it just merge the branch?
[03:48] <rsalveti> robru: migration is blocked as pulse still needs to be accepted
[03:49] <rsalveti> I just wanted to go ahead and start my other landing, but yeah, the changelog entry is still missing until the other silo gets merged
[03:49] <rsalveti> let me try something different
[03:49] <robru> ah
[03:59] <imgbot> [03:59] <imgbot> [04:09] <Mirv> morning
[04:11] <robru> Mirv: morning!
[04:12] <Ursinha> man, "morning" means I should go to bed :)
[04:13] <robru> Ursinha: haha. it sure means I shouldn't be working... not quite bedtime though
[04:13] <Mirv> rsalveti: if you're still there, you could possibly ack this addition of a single symbol to platform-api: https://ci-train.ubuntu.com/job/ubuntu-landing-007-2-publish/lastSuccessfulBuild/artifact/packaging_changes_platform-api_2.5.0+14.10.20141001.3-0ubuntu1.diff
[04:17] <bzoltan1> Wow, I got full OK from the gallery tests with the UITK silo.
[04:18] <Mirv> bzoltan1: it's been some time since I've seen full OK from gallery locally..
[04:18] <Mirv> nice
[04:19] <bzoltan1> Mirv:  yes, I am surprised too :D The UITK landing tests look good
[04:19] <imgbot> [04:19] <imgbot> [04:20] <bzoltan1> Mirv:  but the camera app hangs .. is there a special trick to make that run? Maybe robru knows...
[04:20] <robru> bzoltan1: i dunno nuthin bout nuthin
[04:21] <bzoltan1> robru: dude :) that is a perfect line before saying EOD
[04:21] <robru> EOD
[04:21] <robru> ;-)
[04:21] <robru> (EOD 3.5 hours ago)
[04:21] <bzoltan1> LOL
[04:22] <bzoltan1> I EOD'd 8 hours ago and woke up 3 hours ago...
[04:23] <rsalveti> Mirv: why the bump from 2 to 5?
[04:23] <rsalveti> I wonder if we shouldn't also bump the other files we have in there
[04:23] <rsalveti> ops, 3 to 5
[04:24] <Mirv> rsalveti: it looks like they forgot the bump the last time they bumped the version to 2.4.0..
[04:24] <rsalveti> right
[04:24] <rsalveti> seems fine from the MR
[04:24] <rsalveti> Mirv: +1
[04:25] <Mirv> thanks.
[04:26] <Mirv> bzoltan1: I know no special trick for camera, it used to run ok
[04:26] <robru> rsalveti:  my fix for that bug you saw just landed in production
[04:27] <Mirv> camako: (if you are around) are you planning Mir 0.8.0 landing soon or slightly later? mzanetti kgunn etc would probably like to know whether they can land their QtMir + QtUbuntu also to rtm now that it's landing to utopic
[04:27] <bzoltan1> Mirv: running like `/bin/sh -e /usr/bin/phablet-test-run -r 0000 -s JW024063 -p camera-app-autopilot camera_app` does nothing ... Failed to connect to Mir: connect not called
[04:27] <rsalveti> robru: nice, hot fix in production
[04:27] <rsalveti> that's how we roll :-)
[04:27] <kgunn> Mirv: i know camako said there was a stopper for mir0.8 promotion
[04:28] <Mirv> robru: any idea where queuebot went? it was active 45mins ago, no totally silent despite me doing things.
[04:28] <robru> rsalveti: oh no, this one went through code review! ;-)
[04:28] <Mirv> kgunn: ok. I can then at least assign silo for mzanetti.
[04:28] <rsalveti> robru: awesome
[04:28] <robru> Mirv: yeah stgraber says his server is kernel panicking every 10 minutes, so queuebot is more or less offline. before you woke up it was freaking out and spamming the channel a bit
[04:28] <Mirv> robru: oh, ok.
[04:29] <Mirv> oh yeah, scrolling a bit further, a suspiciously _lot_ of queuebot activity :)
[04:29] <robru> Mirv: but not like the spamming we saw before, it was behaving normally in the sense that it would start up, and then ping everything as if it was new, and then the server crashed, and then it would reboot, restart, ping everything, etc
[04:29] <robru> "behaving as well as could be expected from a server that crashes every 10 minutes"
[05:45] <ToyKeeper> cyphermox_: Any idea if the two critical indicator bugs for rtm-024 (indicator-network, urfkill) are still present?  (network indicator crashes and doesn't restart, wifi toggles disappear when wifi disabled)
[05:50] <ToyKeeper> The bug report doesn't indicate any fixes yet, and if the silo enables a new critical bug (even if it's in some other component), it can't land until the fix is included too.
[06:14] <bzoltan1> trainguards: is here a QA eng available to check and sign the UITK in the silo14?
[06:16] <ToyKeeper> bzoltan1: There might be soon.  The other two silos in queue are blocked.
[06:17] <ToyKeeper> kgunn, mzanetti: On that note, what test plan is relevant for silo rtm-011?  Nothing is linked.
[06:17] <bzoltan1> ToyKeeper:  all right, thanks. Then I carry on with the QtC work
[06:18] <ToyKeeper> kgunn, mzanetti: I'm heading to sleep soon, so could you add the test plan info to the spreadsheet for whoever picks it up next?
[06:20] <ToyKeeper> bzoltan1: I think a faster uitk testing method may have been worked out, but I don't recall if that matter ever came to a conclusion.  I hope it did, so we can get that tested and landed faster.
[06:21] <bzoltan1> ToyKeeper:  That would be awesome. My tests took only about ~24 hours this time... but the base is not really good. The stock image has too many failures
[06:25] <ToyKeeper> bzoltan1: I think the most bang for the buck with UITK is in manual exploratory testing, which would be both faster than re-running AP and more likely to catch visual glitches which don't affect the function.
[06:27] <bzoltan1> ToyKeeper:  that is exactly I was suggesting from the beginning. Simple re-running the AP tests on a most likely different base image (I tested on three images in 24 hours) does not make much sense in my view. But as you said, good eyes can catch things.
[06:27] <ToyKeeper> I just don't recall a final decision about it, and am at the end of my day.  I'll try to get it at least started though.
[06:27] <bzoltan1> ToyKeeper: So I am happy for the change
[06:29] <bzoltan1> Mirv:  I got a funny question... I am preparing the -gles package .. Now as the UITK is built in the RTM silo, I expect that the debian/watch file should contain different PPA URL. Is that correct?
[06:34] <bzoltan1> trainguards: I would like to ask for a reconfig of the rtm14 silo, i just added there the -gles package.
[06:36] <ToyKeeper> In that case, perhaps I shouldn't start on it.
[06:37] <ToyKeeper> If the contents of the silo changed just now, wouldn't that invalidate the previous test results?
[06:39] <bzoltan1> ToyKeeper: absolutely  not... I am adding the -gles package
[06:40] <bzoltan1> ToyKeeper:  that has nothing to do with the UITK package I tested. It is a package for the emulator... what is not tested by anybody for any landing
[06:40] <ToyKeeper> Oh, okay.
[06:41] <bzoltan1> ToyKeeper: actually it is something what is a real issue... at some point we should start testing the emulator images too
[06:41] <ToyKeeper> Haha, yeah.  As soon as the emulator itself is reasonably stable.  :)
[06:47] <Mirv> bzoltan1: you're correct, it should be of the style http://ppa.launchpad.net/ci-train-ppa-service/landing-020/ubuntu-rtm
[06:48] <bzoltan1> Mirv:  I used this "https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-014/+files/ubuntu-ui-toolkit_([^-]*)\.orig.tar.gz"
[06:49] <bzoltan1> Mirv:  I can still change
[06:50] <Mirv> bzoltan1: maybe that's correct... we'll see. reconfigured.
[06:50] <Mirv> or sorry, not yet
[06:50] <Mirv> changes in the prepare jobs
[06:50] <Mirv> "Please ask the trainguards to reconfigure this silo for you." I _am_ a trainguard :)
[06:51] <Mirv> oh, right, there it is
[06:51] <Mirv> bzoltan1: now reconfigured
[06:51] <bzoltan1> Mirv: :D
[06:59] <bzoltan1> Mirv: ehh https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-014-1-build/25/console
[07:02] <Mirv> bzoltan1: unsynced changelog vs https://launchpad.net/ubuntu-rtm/+source/ubuntu-ui-toolkit-gles
[07:05] <Mirv> psivaa: btw the clock app qmlscene was a duplicate bug #1376346
[07:05] <Mirv> but the mediascanner one was potentially a newly filed
[07:05] <Mirv> anyway, neither is upstream Qt crasher but apparently in our components
[07:16] <bzoltan1> Mirv:  does it mean that I need to change the previous entry in the changelog? So it will pull from the RTM distro...
[07:17] <Mirv> bzoltan1: probably yes
[07:17] <bzoltan1> Mirv:  all.. right. I try that
[07:20] <bzoltan1> Mirv:  it seems that the trick works.. thanks
[07:20] <Mirv> good!
[07:29] <brendand> sil2100, red alert, we got a true blocker yesterday
[07:29] <brendand> sil2100, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1376500
[07:34] <sil2100> brendand: ugh, that in ubuntu-rtm?
[07:35] <sil2100> Right, rtm
[07:44] <tsdgeos> who do i need to bribe to get some nodes for http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/ ?
[07:44] <tsdgeos> ' All nodes of label 'utopic&&amd64' are offline '
[07:46] <Mirv> sil2100: at least that wasn't "isolated bug fix" but went through QA
[07:47] <Mirv> tsdgeos: cihelp, probably
[07:47] <tsdgeos> Mirv: if there was someone called cihelp :D
[07:52] <sil2100> hah ;)
[07:53] <sil2100> tsdgeos: cihelp is a key-word that all CI team members get pinged on
[07:53] <tsdgeos> ic
[07:54] <vila> tsdgeos: O_o /me looks
[07:57] <brendand> Mirv, no i would have extra pissed off it is was an 'isolated bug fix'
[07:59] <davmor2> Morning all
[08:04] <sil2100> brendand: I just poked Satoris, not sure when he starts his day though
[08:08] <vila> tsdgeos: weird, the node appears to be up but jenkins fails to connect to it, I'll escalate
[08:09] <tsdgeos> vila: tx
[08:12] <Mirv> sil2100: what's your current damage report? I mean in terms of recovering from injuries..
[08:12] <Mirv> "hull intact" etc
[08:12] <sil2100> hah ;)
[08:13] <davmor2> sil2100: did I set the day thing right on those tags age still say N/A
[08:13] <sil2100> It's better, it's not swollen anymore
[08:14] <sil2100> But I still have problems moving it so I'm wearing a stabilizer
[08:14] <sil2100> davmor2: hm, I thought those were correct, let me re check
[08:15] <davmor2> sil2100: what this teach you about doing martial arts incorrectly ;)
[08:16] <sil2100> I think everyone took our previous exercises a little bit too seriously
[08:17] <sil2100> ;)
[08:17] <sil2100> davmor2: ok, fixed, we both filled in bad tags yesterday - it's suppsaosed to be lt-date- not lt-age-
[08:18] <davmor2> sil2100: hahaha
[08:20] <mzanetti> sil2100: hey ho :) could I have a silo for spreadsheet line 42 please?
[08:20] <sil2100> mzanetti: looking!
[08:21] <sil2100> mzanetti: it's a sync from utopic now, right? Only unity8?
[08:21] <mzanetti> sil2100: yeah
[08:21] <mzanetti> sil2100: wait, let me make sure which ones
[08:22] <mzanetti> sil2100: yep, only unity8
[08:22] <sil2100> mzanetti: hm, unity8 already seems to be configured for ubuntu-rtm in silo 11
[08:23] <sil2100> mzanetti: I'll assign a silo but make sure you land rtm/11 first
[08:24] <sil2100> mzanetti: as the packages in the new silo I'll assign will include the version from rtm/11 as well, so we first need to +1 the previous silo before proceeding
[08:26] <Mirv> sil2100: ok. hopefully getting better and better soon.
[08:26] <mzanetti> sil2100: ah... that's why
[08:26] <mzanetti> sil2100: ok... I can also wait... but rtm seems to start being 3 silo releases behind utopic
[08:27] <mzanetti> sil2100: but we have > 10 approved branches in unity8 again, so I'd need to get going with that too soon
[08:27] <sil2100> mzanetti: ok! Let's poke QA today to make sure it gets signed off as soon as possible
[08:27] <mzanetti> brendand: hey, could you prioritize silo rtm/11 a bit please?
[08:27] <sil2100> davmor2, brendand: can you (or anyone else) sign off rtm/11?
[08:32] <brendand> mzanetti, no test plan
[08:32] <brendand> mzanetti, otherwise it probably would have been signed off already
[08:37] <sil2100> psivaa: hey! You online today?
[08:39] <mzanetti> brendand: added the test plan link
[08:42] <brendand> mzanetti, you didn't think about running any of the indicator- test plans?
[08:43] <mzanetti> brendand: hmm... doesn't really change the indicators itself. only the ui for it.
[08:44] <mzanetti> brendand: unity8 test plan contains verification of the ui
[08:44] <mzanetti> but if you're worried, feel free to do some more checks
[08:44] <Mirv> sil2100: he e-mailed that he'll be later on
[08:44] <brendand> mzanetti, ok but keep in mind the testing is not only to verify the fixes work but also to check for regressions
[08:45] <mzanetti> brendand: yeah sure... but if that silo introduces regressions its the ui not connecting to them, or rendering some labels wrong in there... still covered by the unity8 test plan
[08:47] <brendand> mzanetti, ok just making sure - some people are not so careful
[08:54] <chihchun> question: how do I push a new package version to the image?
[08:56] <chihchun> https://wiki.ubuntu.com/citrain/RTMLandingApproaches # really confusing
[08:58]  * popey gives up
[08:58] <sil2100> chihchun: let me get back to you in a moment
[09:00] <chihchun> sil2100: #1351092 and #1334495 are fixed in fonts-android 1:4.3-3ubuntu2, but I see fonts-android 1:4.3-3ubuntu1 in current image
[09:02] <dbarth> hi trainguards; i've unblocked branches in silo 14 for landing
[09:04] <brendand> pstolowski, hey - you tested the last mediascanner landing right?
[09:05] <sil2100> chihchun: ok, so generally the RTMLandingApproaches is a document for people that already know the CI Train landing process and just want to know how to land the same stuff in ubuntu-rtm
[09:05] <sil2100> chihchun: did you use the CI Train before?
[09:05] <pstolowski> brendand, i tested last mediascanner-scope landing
[09:05] <Mirv> dbarth: ok!
[09:05] <Mirv> sil2100: robru: we'd btw need a feature to mark a silo "test silo" so that anything conflicting with only that is allowed to be prepared
[09:06] <pstolowski> brendand, (not the mediascanner)
[09:06] <Mirv> sil2100: robru: considering my Qt silo now conflicts with half the world
[09:06] <chihchun> sil2100: No, I did not. and the issue has been fixed in ubuntu package, I don't need to do a new MP
[09:07] <ogra_> ricmm, could you top approve https://code.launchpad.net/~ogra/phablet-tools/fix-phablet-shell-without-local-key/+merge/236696 ?
[09:10] <sil2100> chihchun: ok then, let me take a look at this
[09:10] <chihchun> sil2100: thanks
[09:11] <sil2100> chihchun: ok, so I see that the new utopic images already have the ubuntu2 in them - all we need to do is sync up this package to RTM
[09:12] <sil2100> chihchun: do you have an ubuntu-rtm enabled device?
[09:12] <chihchun> sil2100: right, I have a nexus4
[09:12] <sil2100> chihchun: does it have an image from the ubuntu-rtm channel installed?
[09:12] <sil2100> Or is it devel-proposed?
[09:13] <Mirv> pstolowski: MP not approved, can't publish https://code.launchpad.net/~unity-api-team/unity-scopes-shell/department-doesnt-go-away/+merge/231774
[09:13] <Mirv> (top-approved)
[09:14] <sil2100> chihchun: anyway, I'll fill in a sync landing for you - this will generate a PPA for ubuntu-rtm where the packages will be available for testing
[09:14] <chihchun> sil2100: yes, I have r67, 20141002 image on it. (ubuntu-touch/ubuntu-rtm/14.09-proposed)
[09:14] <sil2100> Excellent
[09:17] <pstolowski> Mirv, ah, it is now
[09:18] <ogra_> mvo, iirc that came from your meta upload ... https://lists.launchpad.net/ubuntu-phone/msg10035.html ... any idea about it ?
[09:18] <brendand> psivaa, but you know it had mediascanner and thumbnailer in that silo right?
[09:18] <brendand> psivaa, sorry
[09:18] <sil2100> chihchun: ok, so now https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu-rtm/landing-021 has the fonts-android version for your testing
[09:19] <brendand> pstolowski, ^
[09:19] <chihchun> sil2100: where should I report my test result?
[09:21] <sil2100> chihchun: once you test those packages, please go to the spreadsheet, find your landing (it's currently row number 68, but you can find it by your nickname), scroll the sheet to the right and switch 'Testing pass?' for this column to 'Yes (#image_no_you_tested_on device_name your_nickname)'
[09:21] <sil2100> chihchun: after that the rest belongs to us and QA, so you're free
[09:22] <Mirv> pstolowski: thanks, published.
[09:22] <psivaa> sil2100: sorry dint know you'd lead the meeting back today. so i emailed Mirv in the rush to go out
[09:23] <Mirv> psivaa: and I didn't notice sil2100 wasn't included :)
[09:23] <psivaa> :)
[09:24] <pstolowski> brendand, i know nothing about that, sorry
[09:25] <brendand> ok that's kind of a problem
[09:28] <chihchun> sil2100: all done, thanks
[09:29] <mvo> ogra_: I am just the uploader, its "bzr log -r 248" committer: Jamie Strandboge <jamie@ubuntu.com>
[09:29] <mvo>   merge from David Barth: Let apparmor protect access to the OA APIs
[09:29] <ogra_> oh, ok
[09:29] <sil2100> psivaa: ah ;) No worries!
[09:29] <ogra_> dbarth, ^^
[09:29] <ogra_> dbarth, see https://lists.launchpad.net/ubuntu-phone/msg10035.html for context
[09:30] <sil2100> chihchun: thanks! Now just we need to wait for QA to sign it off and it'll be in ubuntu-rtm
[09:33] <dbarth> reading
[09:34] <dbarth> ok, i noticed that yesterday with mardy
[09:34] <dbarth> mardy: ^^ that same permission error; so the fix is to explicitely specificy the applicationid when making calls. right?
[09:42] <mardy> dbarth, ogra_: I'll comment on the bug report, as well as to the ML
[09:42] <ogra_> mardy, merci :)
[09:51] <brendand> sil2100, i almost forgot there's something i needed to talk to you about
[09:52] <sil2100> Wazzup?
[09:53] <brendand> sil2100, silo 19 has qml pre-compilation fixes, we think it will be high impact so when it lands we want it to land alone
[09:53] <brendand> sil2100, you think you can arrange that?
[09:53] <sil2100> Oh, finally that big landing!
[09:54] <sil2100> brendand: sure thing, I also see that Mirv is set as one of the landers so I'm sure he'll additionally have a look at that
[09:58] <ogra_> lets make sure to have a standalone image for it
[10:02] <bzoltan1> brendand:  Do you think you can take the UITK release candidate?
[10:02] <mzanetti> sil2100: hey, when you have a minute, please assign me a utopic silo for row 69
[10:03] <brendand> bzoltan1, i'll put it next in the queue
[10:04] <ogra_> how would people think about a remote execution feature for phablet-shell ? like: http://paste.ubuntu.com/8478233/
[10:07] <bzoltan1> ogra_: I would use it
[10:07] <seb128> do you people know what happened to get glib updated in the rtm serie?
[10:07] <bzoltan1> brendand: thank you. The logs are at the same place. The link is in the sheet
[10:07] <ogra_> seb128, havent checked excuses yet
[10:07] <seb128> ogra_, excuses?
[10:08] <seb128> we wanted to get it updated but qa needed to approve it I think
[10:08] <ogra_> seb128, seems colin didnt move it over to rtm-proposed yet
[10:08] <brendand> ogra_, what benefits would it give over adb shell?
[10:08] <seb128> is that still blocked?
[10:08] <ogra_> seb128, oh, wait ... glib ? not glibc
[10:08] <seb128> ogra_, https://launchpad.net/ubuntu-rtm/+source/glib2.0
[10:08] <seb128> right
[10:08] <ogra_> heh, sorry ... (we're trying to land glibc too atm)
[10:08] <seb128> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=glib
[10:09] <seb128> that one ^
[10:09] <seb128> is it blocked? can we do anything to unblock it?
[10:09] <seb128> it's an important fix for wakeups issues
[10:10] <ogra_> seb128, spreadsheed line 19 ..
[10:10] <ogra_> hasnt been set to "testing done" yet
[10:10] <ogra_> QA qill only be notified about it if that has happened
[10:10] <ogra_> *wil
[10:11] <ogra_> l
[10:11] <seb128> Laney, ^ should we do that?
[10:11] <bzoltan1> brendand:  I explained to ToyKeeper that the silore configuration  is not relevant for the QA because it was needed to get the -gles package built too
[10:12] <ogra_> seb128, i assume the testplan: "test ALL the things" might be a bit time consuming though :P
[10:12] <seb128> ogra_, not sure how you want to test base libraries
[10:12] <ogra_> me neither
[10:13] <ogra_> but at least describing how to test the bugs you aim for to be fixed are gone might be helpful
[10:14] <Laney> testing done where?
[10:14] <ogra_> Laney, the K column on the spreadsheet
[10:15] <Laney> okay, I thought that was for QA to do
[10:15] <Laney> seb128 did some testing
[10:15] <Laney> I don't know how to check for the wakeup problem
[10:15] <seb128> I run my krillin with that version for a few days without issues
[10:16] <Mirv> sil2100: brendand: I'm just a lander helper there, but yes it's a high impact landing and requires super extra care. not sure about ETA though.
[10:17] <Laney> seb128: can you fill in image number please ;-)
[10:17] <davmor2> Laney: No the developers run their testplan and mark it tested, we then grant it in the needs QA sign off
[10:17] <seb128> Laney, urg, I don't remember, I think it was 71
[10:17] <Laney> heh
[10:17] <seb128> let me reinstall it on the current image
[10:17] <seb128> so we can put the current number there ;-)
[10:18]  * Laney wibbles at davmor2 
[10:19] <davmor2> Laney: take those pants off your head and pencils out of your nose, you don't fool anyone :P
[10:19] <ogra_> Laney, note that if you put in "test all the things" someone might take that literally and run all AP tests (which is a several hour process) :)
[10:19] <ogra_> i know that ToyKeeper does that in such cases
[10:19] <Laney> ogra_: I don't mind, it's not expected to break anything
[10:19]  * ogra_ usually points to the bugs and how to check they are gone in the test plan 
[10:20] <ogra_> Laney, no, but it takes QA time and will make the landing slow
[10:20] <Laney> well it's not an isolated upload just for that fix
[10:20]  * brendand grumbles check for regressions too...
[10:20] <Laney> we just took the upstream release which contains it
[10:24] <ogra_> sil2100, any idea on what vacation the bot is today ?
[10:25] <sil2100> hmmm
[10:25] <sil2100> ogra_: I think it's just slacking off, we should fire it!
[10:25] <ogra_> ++
[10:25] <davmor2> ogra_: tomorrow it is uniting with all the other bots
[10:25] <ogra_> lol
[10:26] <Laney> Tag der queuebotten einheit
[10:26] <sil2100> But yeah, I guess we need to poke stgraber about it
[10:33] <Mirv> sil2100: ogra_: the machine running it reportedly crashes every 10 minutes, so it's essentially gone for now
[10:33] <john-mcaleely> morning all
[10:34] <john-mcaleely> sil2100, ogra_ new device tarball available
[10:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141002-d5938d7.tar.xz
[10:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-20141002-d5938d7.changes
[10:34] <john-mcaleely> http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141002-d5938d7.ods
[10:34] <john-mcaleely> any chance of a davmor2 or brendand QA pass? ^
[10:35] <brendand> john-mcaleely, as long as we're going to have the results in spreadsheet form can we keep it in the google doc?
[10:35] <john-mcaleely> brendand, have a look at the google doc :-)
[10:36] <sil2100> \o/
[10:38] <bzoltan1> Mirv:  the QtC from the silo6 is well tested and good to go... it has a fix what could be important to important people :D
[10:40] <Mirv> bzoltan1: ok, I'll publish it as soon as the arm64/etc builds are fully ready
[10:41] <brendand> davmor2, are you busy with something else?
[10:42] <davmor2> brendand: bisecting the trust-store crash
[10:43] <ogra_> john-mcaleely, oh, i see two lovely fixes there :D
[10:43] <john-mcaleely> ogra_, only two :-)
[10:43] <brendand> davmor2, can we let the developers do that and you pick up the device tarball?
[10:43] <davmor2> brendand: location crashing is definitely just 76+ trying to find when truststore crash happened now
[10:43] <ogra_> well, the otherse are a nice icing :)
[10:43] <john-mcaleely> ha!
[10:46] <john-mcaleely> oh, the change in disk space will be latent unless you flash_tool install the release. I'll send mail on that topic once the release is up on s-i.u.c
[10:46] <lool> davmor2: could you check syslog for aa errors?
[10:46] <lool> davmor2: since the main difference seems to be apparmor
[10:46] <davmor2> lool: done it yesterday with jdstrand  no issues relating to location directly
[10:47] <lool> :-/
[10:47] <davmor2> lool: exactly
[10:47] <lool> davmor2: there was no simultaneous device tarball update, was there?
[10:47] <lool> davmor2: any satellite crashed in your backyard between #75 and #76?
[10:48] <davmor2> lool: no the device tarball is only available now, and the custom tarball did touch anything in here, but custom didn't land and ToyKeeper confirmed that location service crashed for her in 76 too
[10:49] <davmor2> s/tarball did/tarball did not
[10:50] <davmor2> brendand: I already have 73 flashing so I'll try that and then leave it with lool for the trust-store crash, and then test the device tarball on current
[10:54] <davmor2> lool so image RTM73 has trust-store crash
[10:55] <davmor2> lool: no I need to get on with some other stuff
[10:55] <davmor2> now even
[10:56] <davmor2> john-mcaleely: I get permission denied on the ods doc
[10:58] <john-mcaleely> davmor2, doh
[10:58] <john-mcaleely> davmor2, please retry
[11:00] <davmor2> john-mcaleely: yay
[11:13] <davmor2> lool just to confuse matter 77 with the device tarball I'm testing and location is working again but trust-store still crashes on it's initial run
[11:25] <sergiusens> sil2100: so today, there's no difference from doing a utopic or rtm first landing?
[11:25] <sil2100> sergiusens: what do you mean?
[11:26] <sergiusens> sil2100: well, robru was telling me you were working on something to make it just one atomic thing
[11:26] <sil2100> sergiusens: yeah, I didn't work on it yesterday because of a sick day so I'm one day late in the schedule
[11:27] <sil2100> So for now it's still the same as before
[11:32] <thostr_> sil2100: any idea what's wrong with silo 11? it seems to be building for days...?
[11:32] <sil2100> thostr_: looking
[11:33] <thostr_> sil2100: the log says it's building since 26.9.!
[11:34] <sil2100> thostr_: ouch, well... this is iterating into infinity, as urfkill started being unbuildable for 3 platforms with the introduced changes
[11:35] <sil2100> thostr_: I aborted the build, but this needs to be resolved anyway
[11:35] <bzoltan1> brendand:  any news about the UITK landing?
[11:35] <thostr_> sil2100: nice... just wondering why none of the landers noticed...
[11:35] <sil2100> cyphermox_: hey!
[11:35] <thostr_> and this is blocking others silos
[11:36] <sil2100> cyphermox_: what's up with silo 11? Is making urfkill unbuildable for those 3 architectures wanted?
[11:36] <sil2100> thostr_: yeah, I guess we, the LT, should have also noticed, but we can't keep track of all individual silo contents
[11:36] <sil2100> Though, this one we should have noticed
[11:36] <sil2100> thostr_: thanks for noticing!
[11:37] <thostr_> sil2100: well, I think it should have been noticed by landers... I mean, when I press the build button I really want ot have it build ASAP. anyway
[11:54] <cwayne> davmor2: ping
[11:56] <davmor2> cwayne: so the custom tarball sucks without location dude :(  I'm testing a device tarball now tough and the location seems to be working there so lets get that landed and I'll try the custom again after that and hopefully we will be rocking then
[11:58] <davmor2> cwayne: but it was looking pretty good except for the scopes that didn't load properly because of the lack of location :)
[12:00] <cwayne> davmor2: but that's not the custom tarball's fault :(
[12:01] <davmor2> cwayne: no but the broken scope become more obvious now they become front and center
[12:02] <cwayne> but it's really not a broken scope, its a scope that requires location but not getting it
[12:02] <cwayne> but anyway, im fine to get it in after device tarball :)
[12:13] <brendand> bzoltan1, someone is looking at it now
[12:14] <brendand> bzoltan1, remember the trello board :)
[12:15] <ogra_> brendand, i thought that was supposed to be linked from the spreadsheet
[12:15] <brendand> ogra_, i did to - look at sil2100
[12:15] <brendand> ogra_, it's in the topic though
[12:15]  * ogra_ loks at sil2100 
[12:15] <ogra_> *looks
[12:15] <sil2100> It was on the spreadsheet some time ago, ugh
[12:15] <ogra_> brendand, he looks like evry day ... just with that thing around his wrist
[12:16] <sil2100> brendand: re-added
[12:17] <sil2100> That thing on my wrist is irritating - looks cool but is uncomfortable as hell
[12:17] <ogra_> heh
[12:18] <davmor2> sil2100: then stop doing martial arts badly, lesson learnt ;)
[12:21] <davmor2> sil2100: this is the problem with martial arts when it goes wrong it hurts like hell, I broke me little finger cause it got caught up wrong doing a roll for gods sake :) You think your wrist support is annoying try a cast :D
[12:22] <sil2100> hah ;)
[12:23]  * sil2100 goes for lunch
[12:23] <sil2100> No way I'm cooking with this hand, we'll eat something outside
[12:23] <cwayne> davmor2: man im pretty sure i would break everything if i tried martial arts
[12:24] <davmor2> sil2100: wow that ambitious unless you have snails outside
[12:24] <davmor2> cwayne: man you'd be fine
[12:25] <cwayne> davmor2: nah, im pretty sure i'm like made of glass or something, I broke my pinky finger badly last year just playing catch with my brother
[12:25] <cwayne> lol
[12:25] <davmor2> hahaha
[12:27]  * ogra_ would recommend a ball instead
[12:28] <cwayne> lol
[12:28] <cwayne> but he's so fun to throw
[12:28] <ogra_> heh
[12:28] <bzoltan1> brendand:  ahh.. of course. I see victor opened it
[12:50] <cwayne> davmor2: btw, i've started this up if you think it could be helpful for tracking.. it's basically what you told me you test anyway + like 2 things :) https://docs.google.com/a/canonical.com/spreadsheets/d/1j9dQyiHLj5w6udh8Ixp3VfOF7C8ZGYaUYz65wx9TxyM/edit#gid=0
[13:01] <cwayne> davmor2: so installing with a --wipe, I am now able to reproduce not getting location
[13:01] <cwayne> and it does suck :/
[13:04]  * lool goes wiping his krillin then
[13:06] <davmor2> cwayne: told you so ;)
[13:06] <cwayne> davmor2: you were right :)
[13:06] <cwayne> although it isn't my fault at least :P but it does certainly ruin the scope experience
[13:07] <lool> davmor2: still we dont know exactly what caused the regression, there was no location-service related landing between 75 amd 76
[13:16] <davmor2> john-mcaleely: I have run everything on your spreadsheet and that is all good, including headset
[13:17] <davmor2> john-mcaleely: I'm just running a quick smoketest now and then I think it is good to go
[13:17] <john-mcaleely> davmor2, sounds good
[13:37] <sil2100> davmor2: I don't like eating snails
[13:44] <zsombi> brendand: ping
[13:46] <brendand> zsombi, hello
[13:48] <zsombi> brendand: zoltan is away, so in case you have sthing for the toolkit, I'll be here for an hour still
[13:52] <kenvandine> sil2100, can  you tell what's wrong with line 71 on the spreadsheet?  says circular dependency?  and there's a request ID, but it isn't in a silo
[13:53] <sil2100> kenvandine: hm, let me check
[13:54] <sil2100> kenvandine: ok, fixed - something broke and there was an invalid formula in column O
[13:54] <kenvandine> thx
[14:04] <davmor2> john-mcaleely, sil2100: device tarball is good
[14:04] <ogra_> yay
[14:04] <sil2100> yay!
[14:04] <sil2100> john-mcaleely: push it o/
[14:04] <ogra_> john-mcaleely, are we there yet ?
[14:04] <sil2100> davmor2: then the custom tarball, right?
[14:04] <john-mcaleely> sil2100, sure?
[14:04] <lool> davmor2, cwayne: How does one track landing of a custom or of a device tarball?
[14:05] <lool> cause I have some updates to land there too
[14:05] <davmor2> lool: you talk to cwayne and john-mcaleely
[14:05] <sil2100> john-mcaleely: I guess so - ogra_, brendand: any objections?
[14:05] <ogra_> lool, custom -> cwayne, device -> john-mcaleely
[14:05] <lool> and for utopic?
[14:05] <davmor2> lool: there isn't one
[14:05] <ogra_> the android package for device ...
[14:06] <lool> davmor2: there is!
[14:06] <lool> davmor2: or do you mean no process?
[14:06]  * john-mcaleely my hand is hovering above an 'enter' key...
[14:06] <ogra_> lool, cwayne again :)
[14:06] <ogra_> john-mcaleely, ohhhh, the suspense !
[14:06] <john-mcaleely> lool, one reads the tea laves
[14:06] <john-mcaleely> (for device tarball)
[14:06] <davmor2> lool: I meant tarball, it's in the package as ogra_ says :)
[14:06] <lool> ah right
[14:06] <sil2100> john-mcaleely: pressit!
[14:07] <john-mcaleely> pressed, sil2100 davmor2 ogra_ brendand  - new device tarball pushed
[14:07] <davmor2> john-mcaleely: Don't make me come down there and press it for you :P
[14:07] <john-mcaleely> lool, ^ there you go - live feedback on progress :-)
[14:08] <davmor2> cwayne: do you need to do anything to have it pull in the device tarball on your version?
[14:14] <lool> john-mcaleely: :-)
[14:15] <cwayne> davmor2: shouldn't
[14:41] <alecu> trainguards: ping. I'd like to ask about bug # 1376445, where a change in signon-apparmor-extension broke online accounts as used from the click scope and some other places
[14:42] <alecu> http://pad.lv/1376445
[14:42] <cwayne> if you're asking to revert it, +1 from me too
[14:43] <alecu> trainguards, cwayne: I'd like to find out how did it land (I suspect not thru a silo), and how we can prevent those kind of breakages in the future
[14:44] <alecu> at least, I'd like to make sure that landings for online accounts are triggering QA in dependent projects, like our scopes
[14:45] <alecu> mardy: dobey: I'd like your ideas on that too ^
[14:47] <dobey> alecu: require QA approval and ensure QA tests the appropriate things, when new packages are requested to be added to the ubuntu-touch seed, before the change is actually made, as i don't think ubuntu-meta lands through CI train
[14:48] <dobey> moving ubuntu-meta to CI train would probably be a major annoyance for everything other than ubuntu-touch though
[14:48]  * Ursinha watches the conversation and makes notes
[14:51] <alecu> Ursinha: feel free to throw ideas too, I'd like to understand how this is happening, and how to prevent it.
[14:51] <Ursinha> dobey: that's an interesting use case
[14:51] <Ursinha> alecu: I'm learning the process as well so I can suggest improvements :)
[14:51] <dobey> Ursinha: indeed
[14:52] <Ursinha> dobey: how does that work in that case? the package is pushed to archive directly and then you have to QA it?
[14:52] <Ursinha> as you say that doesn't land through citrain
[14:52] <Ursinha> *said
[14:54] <dobey> Ursinha: well, ubuntu-meta is just a meta package; the package that caused the breakage was already in the archive. what caused the breakage was it being added to the seed, and thus instaleld on the image.
[14:55] <dobey> Ursinha: so i think when there is a request to add a new package to the ubuntu-touch seed, QA should first install that package on a device, and then run through appropriate test plans to ensure things don't break; then they sign off and it can be added to the seed
[14:55] <cwayne> +1
[14:56] <dobey> and i'm guessing this problem happened, beacuse we aren't doing that (if we are doing that, then i guess the wrong tests were run, or at least, not enough tests were run)
[14:58] <Ursinha> dobey: oh, I see the problem package-wise..... do we have more of these, a significant number of metapackages that we care about on the phone side?
[14:59] <dobey> Ursinha: i don't think so. afaik ubuntu-touch is the only metapackage we really care about on the phone side
[14:59] <Ursinha> right
[14:59] <dobey> cjwatson would know better than me if there are others though
[15:00] <Ursinha> dobey: I'll think about it on the train/airline side, thanks for the info
[15:00] <sergiusens> sil2100: Mirv can I get a slo for 77?
[15:01] <sil2100> Ah, crap, right... no queuebot
[15:01] <sil2100> sergiusens: sure
[15:01] <Ursinha> sil2100: what happened with queuebot?
[15:01] <sil2100> Ursinha: stgraber's machine has problems right now, so queuebot has no where to work on - we've been already discussing moving it to somewhere public
[15:02] <Ursinha> sil2100: oh yeah, you know you have my +1 on that :)
[15:02] <dobey> Ursinha: sure. i'm not sure we want to stick ubuntu-meta in the ci train process completely though; as that would add a bunch of needless process for the rest of ubuntu when managing server/desktop images and such.
[15:03] <Ursinha> dobey: not completely, as you said it would be a lot of trouble and the goal is to facilitate, not the other way around
[15:03] <Ursinha> dobey: I was more considering the tracking part, having maybe a "partial" request where the building part is done outside the train but we still get to track and request QA input
[15:04] <Ursinha> something along these lines
[15:04] <robru> bfiller: your build failure is caused by a comma in the space-separated packages list, fixed it for you and building: https://ci-train.ubuntu.com/job/ubuntu-landing-002-1-build/76/console
[15:04] <cwayne> but so while fixing process in the future is great, we also need to fix the immediate problem :)  should we revert that addition? or wait for a fix?
[15:04] <cwayne> it breaks all my scopes that use OA..
[15:04] <bfiller> robru: oh thanks, I hadn't seen that yet
[15:04] <dobey> cwayne: i was hoping mardy would get the fix in which i suggested on the mailing list
[15:04] <Ursinha> bot being dead makes me sad
[15:05] <dobey> Ursinha: don't be sad. it's only the beginning in bot's new afterlife
[15:05] <Ursinha> LOL
[15:06] <cwayne> dobey: https://code.launchpad.net/~mardy/signon-apparmor-extension/lp1376445/+merge/236882
[15:06] <cwayne> not in a silo yet that i've seen
[15:07] <dobey> cwayne: well, jenkins doesn't like it :)
[15:07] <cwayne> noticed that :)
[15:08] <dobey> oh
[15:08] <dobey> that's because coverage isn't working in jenkins for some reason, but it's trying to build with coverage
[15:08] <dobey> the tests apparently passed
[15:14] <sergiusens> brendand: do critical bugs get QA signoff preference?
[15:15] <brendand> sergiusens, i would hope all silos are fixing critical bugs at this stage
[15:15] <sergiusens> brendand: well some of us only have high bugs in our lists ;-)
[15:16] <sergiusens> I would bet not thought
[15:16] <sergiusens> easily checked in the PPA changelog
[15:17] <dbarth> trainguards, can i have a silo for line 78 please; thank you
[15:21] <rsalveti> jezz
[15:21] <ogra_> lovely
[15:30] <sil2100> Let the poor guy talk all he wants
[15:30] <sil2100> queuebot: we're happy to see you too
[15:30] <sil2100> dbarth: ok! Let me check if anyone was faster than me
[15:34] <dbarth> eh
[15:34] <dbarth> so, who wins? ;)
[15:35] <sil2100> dbarth: I did ;) Silo should be yours
[15:44] <sil2100> elopio: hi! Do you know if there is any progres related to gallery and calculator utopic failures?
[15:44] <sil2100> elopio: the ones with $HOME issues
[15:45] <Ursinha> sil2100: where is the bot running now?
[15:45] <elopio> sil2100: we started a long discussion to find the right way to solve it
[15:45] <elopio> https://bugs.launchpad.net/ubuntu-app-launch/+bug/1376423
[15:45] <sil2100> Ursinha: I think it's still at Stephane's
[15:46] <elopio> for now, things point to create a new user, and that's something that will take time to implement properly.
[15:46] <elopio> so now we need to see if we add a new patch to fix it for the moment.
[15:47] <Ursinha> sil2100: got it
[15:49] <lool> trainguards, Mirv: FYI, I've repurposed the dbus-cpp + l-s rtm silo / landing request to include more packages and do a single bigger location related landing
[15:50] <lool> however I need to land translations first
[15:51] <lool> trainguards, Mirv: woudl you mind killing line 25 ?
[15:53] <lool> kgunn: hey, how's the utopic landing of trust-store going?
[15:53] <kgunn> lool: i am just now testing it
[15:53] <kgunn> hope to be done w/in 30 min
[15:53] <lool> kgunn: cool; mind pinging me when it's in?
[15:54] <kgunn> lool: will do
[15:54] <sil2100> lool: oh, ok, so completely freeing line 25, yes?
[15:54] <lool> sil2100: yes
[15:55] <lool> sil2100: I've merged into the first landing for l-s
[15:55] <lool> sil2100: if I read this correctly, there's no silo
[15:55] <sil2100> lool: just to make sure - you mean the rtm landing from tvoss, right?
[15:55] <lool> sil2100: yes
[15:59] <kgunn> lool: hey do you know much about trust-store ?
[16:01] <lool> kgunn: not much; the concepts and have poked a bit
[16:02] <lool> kgunn: I saw there was a comment on the top crasher that this could possibly be fixed by a random branch, but I kind of doubt it
[16:02] <kgunn> lool: so his official test plan filters down the testing, and it passes....but if i run the full suite i see a couple of failures....
[16:02] <kgunn> altho, those aren't called out in his test plan
[16:02] <kgunn> so...hmmmm
[16:02] <kgunn> reverting to virgin image to try
[16:11] <sil2100> geh
[16:12] <sil2100> Firefox died
[16:12] <sil2100> One final try
[16:12] <sil2100> Ok, that's no use, my connection to google services is too terrible
[16:12] <sil2100> ogra_: could you lead the meeting in my stead?
[16:12] <ogra_> sil2100, sure
[16:12] <sil2100> Since I can't even get hangouts to open now
[16:13] <sil2100> ...aaand I can't even close the tab, great
[16:19] <ogra_> sil2100, not sure you had anything you wanted to bring up specifically ... we shortly talked about the systemsettle issues ...
[16:19] <pstolowski> trainguards, what should I do with line 55 (see my comment in line 81)? i basically need the hotfix to land in utopic first, then 55 should have all the fixes listed previously in #54/#55, plus the hotfix
[16:21] <robru> pstolowski: i don't understand what you're trying to do
[16:23] <pstolowski> robru, a few MPs just laned in utopic, but we discovered an issue and need to land one more MP in utopic. then we want to copy utopic package into rtm (so, all the MPs from #55 + the hotfix)
[16:24] <robru> right, so just do that exactly how you described it, then? I don't understand what the problem is
[16:24] <pstolowski> robru, shall #55 still list all MPs, plus the new one? or just the new one?
[16:26] <robru> pstolowski: no, 54 already landed, it's done. 55 can't have any MPs because it's a sync. I gave you silo utopic 1 for line 81, build test & land that one, and then when you do the sync it'll pick up everything together
[16:27] <kgunn> lool: i want to check something but have to step away for an hour...sorry to be a hold up on trust -store but wanna be sure
[16:28] <pstolowski> robru, ack, thanks
[16:30] <lool> kgunn: ok
[16:30] <robru> pstolowski: you're welcome
[16:36] <dbarth> hey, i'm trying to see which rtm image oxide 1.2.4 will be in
[16:42] <bzoltan> brendand: I missed the last few hours. Is there any news about the UITK QA tests?
[16:53] <ogra_> dbarth, is it in the rtm archive already ?
[17:00] <imgbot> [17:00] <imgbot> [17:03] <davmor2> cwayne, sil2100, ogra: so let it roll I think, everything opens, everything seems to work, location works which was the big issue before I'm happy
[17:03] <cwayne> davmor2: did it add the extra favorites too?  (if you'd ever touched them it won't unless you do a fresh flash)
[17:05] <cwayne> neato
[17:05] <popey> my unity just crashed in 266
[17:05] <cwayne> so sil2100 am i good to push?
[17:05] <popey> died completely
[17:05] <sil2100> cwayne: yeah, I guess that's a +1!
[17:05] <sil2100> robru, slangasek: not sure if I'll be able to join todays hangout ;/ I seem to have issues with the internet, or at least with accessing google
[17:15] <robru> sil2100: try chromium? it seems to work better for hangouts
[17:16] <robru> sil2100: oh I need to coordinate with you: so I'm done hacking the build job (for now). are you still working on the publish job?
[17:16] <sil2100> Yeah, but I have problems with connectivity in overall, I'm dropping packets to google.com
[17:16] <robru> hm
[17:16] <sil2100> robru: not yet, but I'm almost done!
[17:17] <davmor2> popey: why did you kill it you are meant to cherish it and nurture it like it is a small child, not kill it ;)
[17:17] <sil2100> Still writing tests for the new bits
[17:17] <cwayne> sil2100: davmor2: pushed, thanks guys
[17:18] <cwayne> now there will probably be a new one on monday :P
[17:18] <robru> sil2100: cool, no worries. I do need to get on the publish job sooner or later, but it can wait ;-)
[17:24] <dbarth> ogra_: it's in ubuntu-rtm yes
[17:24] <dbarth> ogra_: https://launchpad.net/ubuntu-rtm/+source/oxide-qt
[17:28] <brendand> bzoltan, let me check
[17:29] <brendand> bzoltan, is it urgent to land today?
[17:31] <bzoltan> brendand: would be nice
[17:32] <bzoltan> brendand: so we can sync the trunk tomorrow and it could land on an rtm image
[17:34] <dobey> are the lines in the spreadsheet for syncs from one distro to the other supposed to include the MP lines now as well?
[17:38] <sil2100> dobey: no, no MPs needed there
[17:39] <dobey> that's what i thought. i saw a couple that had MPs listed there though
[17:39] <sergiusens> fginther: any reason http://s-jenkins.ubuntu-ci:8080/view/click/job/account-polld-ci/ is not running?
[17:41] <sil2100> dobey: yeah, we usually clean those up before assigning
[17:58] <sil2100> What the heck
[18:01] <fginther> sergiusens, We need to bounce s-jenkins. the trigger jobs were stopped a little while ago to stop incoming work
[18:01] <sil2100> slangasek, robru: I'm trying to connect right now
[18:03] <sil2100> Ffffff
[18:04] <sil2100> slangasek, robru: ok, quick modem reset
[18:04] <sil2100> brb
[18:04] <AlbertA2> trainguards: can I get a silo for line 84?
[18:06] <robru> slangasek: meeting?
[18:26] <fginther> sergiusens, s-jenkins is up again, that job should start soon
[18:26] <sergiusens> ralsina_: ^
[18:26] <sergiusens> fginther: thanks
[18:27] <ralsina_> fginther: thanks
[18:40] <kgunn> Ooo ooo ^ silo rtm11 ready to publish!
[18:45] <sil2100> !
[18:45] <sil2100> kgunn: publishing :)
[18:51] <kgunn> lool: ok...so sorry, so many interupts...but yeah, looks like those same tests are failling in the virgin image
[18:51] <kgunn> so i'm gonna say this tests ok
[18:51] <kgunn> no regression
[18:57] <sil2100> o/
[19:02] <kgunn> robru: line 59 on the sheet actually that one ^ silo003, can you set me up an rtm sync ?
[19:02] <kgunn> thanks
[19:09] <AlbertA2> trainguards: can I get a silo for line 84?
[19:10] <sergiusens> robru: can we setup a sync of http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=landing-022 to utopic?
[19:12] <robru> kgunn: you got rtm23
[19:13] <kgunn> thanks
[19:13] <robru> AlbertA2: utopic 12
[19:14] <robru> sergiusens: utopic 16, and congrats on being the 2500th silo assigned
[19:15] <robru> kgunn: you're welcome
[19:16] <thostr_> can I get a silo for line 81?
[19:17] <robru> thostr_: utopic 17
[19:19] <thostr_> robru: thanks. then another one for line 82? this is for fixing the blocker about the broken picture thumbnails
[19:21] <robru> thostr_: yeah build the utopic one first, the sync can come after
[19:21] <thostr_> robru: ok
[19:41] <cwayne> kgunn: any reason for line 67 to not have a silo yet? would love to test many of those branches..
[19:41] <kgunn> cwayne: it's up next in fact.... robru if you have a spare ^
[19:43] <kgunn> robru: also, in row 29 "small unity8 fixes" can get an rtm silo now that silo11 is cleared out
[19:43] <robru> kgunn: ok, row 67 got 19
[19:46] <robru> kgunn: line 28 you mean? 29 landed
[19:46] <kgunn> robru: which ever has the title "unity8 small fixes"
[19:46] <robru> right
[19:47] <robru> kgunn: i'll have to get back to you on that one, spreadsheet is imploding
[19:47] <kgunn> robru: np :)
[19:49] <robru> kgunn: ok utopic 11
[19:49] <bregma> is it imploding or exploding?
[19:50] <bregma> sideploding
[19:50] <robru> bregma: definitely an implosion, it's collapsing under its own weight. it may have enough mass to achieve a singularity
[19:50] <bregma> more likely just collapse into a neutronsheet, or maybe even a brown dwarf
[19:51] <kgunn> bregma: lol
[19:52]  * kgunn now has to imagine implosion vs http://www.youtube.com/watch?v=jdn8gQkHyHI
[20:00] <ted> rsalveti, Are you going to land the indicator-sound branch for the profiles?
[20:00] <ted> rsalveti, Want to rebase a couple branches on that, it would be easier if it was in trunk :-)
[20:01] <cwayne> fginther: so could I try to build clicks with click-buddy on s-jenkins? (i.e. will it be installed at all on those machines)
[20:02] <fginther> cwayne, I'll get back to you shortly
[20:02] <cwayne> ok thanks :)
[20:06] <ToyKeeper> Laney, seb128: So, the glib silo (rtm-015) needs some sort of test plan, and confirmation via testing that it actually fixes the bug it's supposed to fix.  Probably also a means of retesting the wakeups in the future to detect regressions.
[20:10] <alecu> that sounds wrong... line 84 is building on silo rtm-26
[20:10] <ToyKeeper> Laney, seb128: On the desktop it's usually okay to pull new revs from upstream without much testing, especially early in the release cycle, but the phone is much more strict (especially this close to release).
[20:11] <seb128> ToyKeeper, not sure what would be a test plan for that "run the phone, make sure it keeps working as before"
[20:11] <seb128> ToyKeeper, no need to give a speech on how the phone is stricter than the desktop
[20:11] <ToyKeeper> seb128: A good start would be "here's a way to measure wakeups before/after the change".
[20:12] <seb128> ToyKeeper, no idea how to do that, you would have to ask to the people who filed the bug
[20:12] <seb128> ToyKeeper, we got an update from upstream that fixes the issue, but no idea how to reproduce it
[20:14] <ToyKeeper> seb128: Do you have a link to the bug?
[20:16] <ToyKeeper> seb128: QA can't sign off until the changes are testable and documented in a test plan or AP test suite or unit test or performance test somewhere that it won't be forgotten.
[20:17] <seb128> ToyKeeper, ok, feel free to keep the phone eating power through wakeups then, your call
[20:17] <seb128> that update is coming from upstream and fixing things
[20:17] <seb128> even if we don't have specific steps to trigger the issue
[20:18] <alecu> seb128: ToyKeeper: I think we are all a bit exhausted with deadlines
[20:18] <ToyKeeper> seb128: You could ask jfunk for an exception.
[20:18] <alecu> seb128: but I understand that it's our job as landers to test the silos to make sure they fix the things that they are supposed to fix. That includes finding out how to test it, to try to make QA's life easier
[20:19] <seb128> alecu, well, I don't know how to make a testplan for a lib like glib
[20:19] <seb128> it's used by most processes on the phone
[20:19] <seb128> so it's basically "use the phone, run all the tests"
[20:19] <seb128> which is what we wrote on the landing ask
[20:19] <alecu> seb128: I wouldn't know how to do that too. But it sounds to me that there must be a way to test that specific thing that's being fixed
[20:19] <ToyKeeper> It is indeed difficult to test core libs.  It at least needs a way to test the specific issue it's fixing though.
[20:20] <seb128> well, I don't know how to reproduce/test it
[20:20] <seb128> I just can say the update includes an usptream fix
[20:20] <ToyKeeper> Can you find out how to test it?
[20:20] <kenvandine> ToyKeeper, i've improved the updates portion of the settings test plan
[20:20] <ToyKeeper> kenvandine: Sweet, thanks!
[20:20] <seb128> ToyKeeper, I guess, but I don't have the free slots for that
[20:20] <seb128> ToyKeeper, so either we take the fix or not, your call
[20:21] <kenvandine> ToyKeeper, it's still one scenario, but more thorough
[20:21] <kenvandine> i'll add more for install all/pause all along with landing fixes for  bugs in those :)
[20:22] <ToyKeeper> kenvandine: I should be ready to start on that as soon as I have my phone reflashed and the silo installed.
[20:22] <seb128> ToyKeeper, one corresponding bug is https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1308130
[20:22] <seb128> ToyKeeper, you can maybe ask cking to help since he reported the issue?
[20:26] <ToyKeeper> seb128: QA is a tiny team and doesn't have enough cycles to write the tests for everyone else's changes.  QA is mostly making sure the dev teams are doing proper testing.
[20:27] <robru> ok, spreadsheet statuses restored.
[20:27] <seb128> ToyKeeper, right, well other teams are also small and might not have the resources to write tests for every bugfix backported from other upstreams
[20:28] <seb128> ToyKeeper, so we have the choice to test for regressions and test the fix, knowing it likely fix the issue and doesn't create new one or just reject it because it has no proper testcase and keep a blocker bug in the rtm
[20:28] <seb128> ToyKeeper, I'm not the one who asked uploads to be gatekept by the qa team there, just trying to help getting issues resolved
[20:28] <ToyKeeper> seb128: I'll see if cking can help, but for now it's blocked pending tests (from cking, seb128, or Laney) or an override.  It's not actually my call.
[20:28] <seb128> ToyKeeper, nor mine
[20:29] <pmcgowan> ToyKeeper, do you know how the daily power test results are done
[20:29] <pmcgowan> thats the reference in the bug
[20:30] <ToyKeeper> pmcgowan: No, sorry, I'm not really involved in the performance testing.
[20:30] <pmcgowan> ToyKeeper, seems the test plan is to run that on the silo, who would know?
[20:34] <thomi> pmcgowan: are you referring to the battery discharge tests, as documented on the RTM readiness report? or something else?
[20:34] <thomi> pmcgowan: oh wait, I see now, sorry, ignore me :D
[20:34] <thomi> I'm pretty sure that's cking's baby
[20:37] <pmcgowan> robotfuel, we have a fix for https://bugs.launchpad.net/ubuntu/+source/indicator-messages/+bug/1308130 in a silo and want to run the daily power tests to validate it
[20:37] <pmcgowan> if that makes sense
[20:38] <pmcgowan> robotfuel, the fix is a new glib in silo rtm-15 and QA here was unsure how to test it
[20:39] <jfunk> pmcgowan: not to be pedantic, but it seems everyone is unsure how to test it
[20:39] <jfunk> not just QA ;)
[20:39] <robotfuel> pmcgowan: okay all the power tests take more than a day, due to lack of resources, but we should be able to tell from the screen off quiet and the screen on quiet tests.
[20:40] <pmcgowan> jfunk, fair enough :)
[20:41] <pmcgowan> robotfuel, would you validate that or can you tell us/ ToyKeeper how to do it
[20:41] <kgunn> ted: yo, you gonna land that silo that has unity8 in it very soon ?
[20:41] <kgunn> like tonight ?
[20:42] <robotfuel> pmcgowan: I can do that, I'll talk to toykeeper
[20:42] <pmcgowan> robotfuel, awesome thanks
[20:42] <ToyKeeper> kenvandine: Sorry, it's looking like your silo might be delayed a bit.  :(
[20:42] <ted> kgunn, 13?
[20:43] <kgunn> ted: yeppers
[20:43] <ted> kgunn, No, that's just an integration silo, mterry's branch isn't finished in there.
[20:43] <kgunn> ted: ah-ha...good, so i can proceed
[20:43] <kenvandine> ToyKeeper, problems? or did something else jump in front of me in line? :)
[20:43] <ted> kgunn, Yes
[20:43] <pmcgowan> ToyKeeper, kenvandine oh heck, I didnt mean to do that
[20:43] <mterry> ted, kgunn: sorry!  working on it, but i've got weird issues with it
[20:43] <kgunn> mterry: no prob, just trying to clear out some of our backlog
[20:43] <mterry> ted, also, you might want to reconfigure/rebuild that silo from latest chagnes
[20:44] <ted> kgunn, Sorry, it says "ignore this branch" in the spreadsheet, it just doesn't carry over well.
[20:44] <mterry> slightly smoother now
[20:44] <ToyKeeper> kenvandine: Depends on if we find a way to test glib soon.
[20:44] <kgunn> yeah i was on dashboard
[20:44] <ted> mterry, Cool, I'll rebuild.
[20:44] <robotfuel> pmcgowan: it might be good to send an email to cking to ask him to test the silo tomorrow morning, he has some special equipment to measure power consumption.
[20:44] <mterry> ted, only sticking point now is that it takes a bit for some of the menu content to regen
[20:45] <kenvandine> ToyKeeper, haha... pmcgowan was bugging me about when it would land... now he's bumping me down in the queue :)
[20:45] <pmcgowan> robotfuel, thats fine with me
[20:46] <pmcgowan> robotfuel, mind emailing him?
[20:47] <robotfuel> I'll send an email
[20:47] <robotfuel> pmcgowan: ^
[20:47] <pmcgowan> thanks robotfuel
[20:47] <ToyKeeper> I'd definitely prefer if cking could do it, since he has the tools and background for it and it seems no one else does.
[20:47] <pmcgowan> thats fine
[20:48] <pmcgowan> ToyKeeper, he can test if it fixes the issue but not if there are side effects I'd say
[20:48] <pmcgowan> but maybe also some of that
[20:49] <ToyKeeper> pmcgowan: Definitely.  I'm planning to do the daily image test on it as a system-wide sanity check.
[20:49] <pmcgowan> great
[21:06] <brendand> robru, can you make the spreadsheet behave please?
[21:07] <brendand> robru, we keep getting duplicate cards i suppose because it's flicking back and forth between the QA sign-off state
[21:08] <robru> brendand: http://38.media.tumblr.com/tumblr_lyjjr8cbwp1r34qiso1_500.gif waving my magic wand just for you buddy
[21:11] <brendand> robru, but seriously, this only started happening in the last couple of days
[21:14] <robru> brendand: oh did it? funny I must have been hallucinating for the last 6 months then because the spreadsheet is *CONSTANTLY* reverting state and generally throwing away critical information.
[21:14] <robru> brendand: you're a total nutjob for wanting to write code that integrates with this. just delete it.
[21:14] <robru> the spreadsheet is going away anyway so you'll need to write new code to read from the new thing anyway
[21:22] <asac> anyone knows if this glib landing can be backed out?
[21:23] <asac> Laney: is it an abi bump etc.?
[21:25] <robru> asac: the glib landing isn't even in RTM
[21:28] <fginther> cwayne, click-buddy is installed on the armhf boxes, but it's the trusty version
[21:28] <cwayne> fginther: ah, hm, any idea how different they are?
[21:29] <sergiusens> cwayne: only misses the --allow-untrusted for installing on target
[21:30] <asac> robru: i see a silo here: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=
[21:30] <fginther> sergiusens, thanks, I was getting ready to read through bzr logs
[21:30] <asac> robru: let me rephrase, i wondered if the landing intend is something that can be backed out in case we land it
[21:30] <asac> e.g. abi bump etdc.
[21:30] <sergiusens> fginther: much easier to grab the debs for each and compare the included click-buddy with a diff :-)
[21:30] <fginther> cwayne, installing to the target wouldn't be useful here, there are no devices attached :-)
[21:31] <robru> asac: oh I have no idea how easy that would be to revert. i thought you thought it was landed already and wanted to back it out
[21:32] <fginther> cwayne, sounds like it should work, if there are problems we can investigate
[21:36] <asac> robru: no, just want to figure what risk we can take to understand how we go about bootstrapping a formalized glib testplan
[21:36] <cwayne> fginther: sergiusens: excellent :) i'll try it out
[21:37] <robru> asac: ah, ok. not sure, better ask Laney then, sorry
[21:39] <cwayne> fginther: /tmp/hudson6281116677040042202.sh: 2: /tmp/hudson6281116677040042202.sh: click-buddy: not found
[21:39] <cwayne> oh the armhf boxes
[21:41] <cwayne> fginther: actually still seeing that on calxeda
[21:42] <cwayne> ah it works on calxeda-pbuilder, but doesnt have the right framework :/
[21:43] <Laney> What do you want to know?
[21:43] <Laney> There's no ABI break, that would be madness in the case of glib and you'd definitely know about it.
[21:48] <cwayne> sergiusens: where do the click frameworks actually come from?
[21:48] <cwayne> i.e. which package
[21:50] <asac> Laney: just to give you context (without implying anything at this time), the way we bootstrap landing gate testplans is that the landers start a pretty simplistic testplan that captures what they think is reasonable to protect us from majority of regressions we might encounter (after all the component owner knows best how his component is used in stack and what parts are a bit flaky and hence what hotspots in the stack we might
[21:50] <asac> Laney: then if we find regressions in image testing after landing, we improve the gate smartly (aka learning testplan rather than a blank "test all"); since glib never did landings before, our knowledge about how a smart testplan looks like is very constrained and since we cannot afford any big risk, we can only really do that in this way if we are sure we can get rid of a regression coming out of it through a backout.
[21:52] <asac> if we canot backout there are two choices: a) nothing changes for lander and we just frontload the QA image testing on the silo; b) land a cherry pick fix so we can back out
[21:52] <Laney> Can you show me one for a base library?
[21:54] <asac> Laney: depends how you define base libraries. good set of what you consider base libraries are in the same situation as glib because they were always direct uploaded by core-devs which means that we have no organically grown testplan (which is really unfortunate given the level of risk averseness we have at this point where customers constantly expect better deliveries)
[21:55] <asac> so i would like to use glib to maybe figure how we can do that as i expect there might be other libraries coming
[21:55] <asac> at even more unfortunate times
[21:55] <asac> anyway, there are components that are deep in the stack that have test plans grown organically
[21:55] <asac> let me find some
[21:57] <asac> Laney: given the nature that we grow as we go and start small, stuff that is stable usually doesnt need full testing. so https://wiki.ubuntu.com/Process/Merges/TestPlan/platform-api is pretty much something central is still reasonable
[21:58] <asac> Laney: other extreme is uitk which broke everything here and then over time, so we run basically all APs etc. on it
[21:58] <asac> Laney: https://wiki.ubuntu.com/Process/Merges/TestPlan/ui-toolkit
[21:58] <asac> I cannot remember glib breaking stuff here and then.
[21:58] <asac> so i think its pretty stable
[21:59] <asac> there were glitches that broke everything at once, but those would have been caught by just running a single AP test
[21:59] <asac> and boot system
[21:59] <asac> and do something like using systemsettings or so
[21:59] <asac> anyway, the whole thing is that we start with something the lander feels gives him some level of confidence in a formal manner so we can learn over time and tweak, improve etc.
[22:00] <asac> Laney: https://wiki.ubuntu.com/Process/Merges/TestPlans/
[22:00] <asac> there are loads of testplans under that
[22:00] <asac> imo you guys are most familiar with glib and know which areas are rock solid
[22:01] <asac> and which areas are causing grief
[22:01] <asac> (a few years back i would have suspected that the gio part is flaky so i would have probably checked if there is anything very basic i can do to exercise that that part works)
[22:01] <asac> otherwise, just think how glibt is used and which main submodules are used by which app in our touch stack
[22:02] <asac> so lets say gio is used by app X, just say: start app and see that X works
[22:03] <fginther> cwayne, I believe this error is caused by not having the necessary schroots (which makes sense as these machines have none)
[22:03] <asac> tell me what you think we could do that makes sense. as i said would really much would like to use this to understand what we would do in case another base library comes even later during our product crunch
[22:04] <cwayne> fginther: makes sense
[22:04] <asac> Laney: looking at the bug and that its marked low prio we can also continue talking about this on monday (tomorrow is pub holiday)
[22:06] <Laney> asac: Alright, well we can talk about this in the team tomorrow and see what we think.
[22:06] <asac> Laney: thanks. just repost the lines i wrote. as i said its something new. so far we only dealt with base libraries taht are under heavy development
[22:06] <asac> by ourself
[22:06] <asac> like uitk
[22:07] <asac> so folks automateically believe that all these base libraries need to have everything run at the gate automatically
[22:07] <asac> but i dont think thats the case for the parts in our stack that are super stalb
[22:07] <asac> but we have no data besides the incidential "all broken firedrills" due to big glitches that can happen on those
[22:08] <asac> imo we should just apply what we always do. you guys think what would be a good start and then se how this evolves over time
[22:08] <asac> and as long as we can backout the risk of not knowing things is bearable
[22:08] <Laney> There's a lot of random stuff in the stack that is actually pretty mature software
[22:08] <asac> just land early in day and if there is a regression, back it out, figure if there is a smart stitch to protect etc.
[22:09] <asac> Laney: exactly
[22:09] <Laney> I think that if you have this feeling about a change you want to make then a very heavyweight process is going to feel like quite a drag
[22:09] <asac> Laney: so i am sure if we start light, we will protect from the bit glitches and we wont have a big testplan
[22:09] <asac> Laney: what i describe above is very lightweight. its just writing up whatever you feel are reasonable test steps that help you feel confident that all will be good
[22:10] <asac> anyway, run that through team
[22:10] <asac> and lets chat monday
[22:10] <Laney> k, thanks for info
[22:12] <lool> kgunn: sorry, so what' the plan WRT trust-store? is this delayed to tomorrow?
[22:20] <lool> trainguards, would you mind assigning a silo for line 68 (roaming location-service fix); this one needs a separate PPA while it's being tested by HERE folks
[22:20] <lool> hopefully tomorrow morning if I can get a silo now  :-)
[22:27] <robru> lool: utopic 3
[22:28] <lool> robru: ty
[22:28] <robru> lool: you're welcome
[23:28] <kgunn> lool: i landed in utopic, and marked it ready for qa in rtm
[23:28] <lool> thanks
[23:29] <lool> trainguards, any free silo for utopic / line 74?
[23:30] <robru> lool: http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=location-service how many location-service silos does there need to be, exactly?
[23:31] <lool> robru: the ubuntu-rtm one should be gone...
[23:31] <robru> http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=location-service even also ubuntu ;-)
[23:31] <lool> robru: 17:54 < sil2100> lool: oh, ok, so completely freeing line 25, yes?
[23:31] <lool> 17:54 < lool> sil2100: yes
[23:31] <lool> 17:55 < lool> sil2100: I've merged into the first landing for l-s
[23:31] <lool> robru: not sure why it's still there
[23:32] <lool> robru: silo 3 is for HERE to test (roaming) and the other one I thought I could land, I've tested the branch successfully yesteryda, but the fix is insufficient
[23:32] <robru> lool: well those are rows 11 and 39, surely 25 is not location-service
[23:32] <lool> robru: speaking of the rtm one
[23:32] <lool> robru: it used to be line 25
[23:33] <robru> lool: well it's not clear to me whether you want to free row 11 or 39
[23:33] <lool> robru: none of these
[23:33] <robru> lool: which is the silo which should not be assigned?
[23:34] <lool> robru: sorry let me start afresh
[23:34] <lool> robru: there was one rtm landing WIP, we gave up on it and repurposed it; it's now the accunulated location related landings
[23:34] <lool> so just 1 in rtm, and that's ok
[23:34] <lool> but finishing some utopic landing firsts
[23:35] <robru> lool: except that there are two rtm silos assigned for location-service
[23:35] <lool> robru: hmm this silo 020 is completely new to me
[23:35] <lool> and I am not sure it will land happily in rtm
[23:36] <robru> lool: well you'll have to coordinate that with camako then
[23:37] <robru> lool: more to the point, the two utopic silos you have are not just 'small fix part of mir landing' or whatever. you have two silos for location-service already. are you sure you can't roll this new one into one of the existing ones?
[23:37] <lool> robru: I dont mind
[23:37] <lool> robru: we could I guess; just not sure either of them will be stuck
[23:38] <lool> robru: you see, the startup fix seemed to work but doesn't; am I supposed to take it back?
[23:38] <lool> or fix it?
[23:38] <lool> but that might take some time
[23:39] <lool> and the other one is ready to land too, it was just waiting for another landing to complete
[23:39] <robru> lool: the problem with having three simultaneous silos for a package like this is that a) there are only so many silos, so other people can't get theirs, and b) whichever one publishes first forces the other two to rebuild, which is time consuming and wasteful
[23:40] <robru> lool: so if there's any way you can merge the requests I'd appreciate that.
[23:40] <robru> brb
[23:40] <lool> oh actually I can do simpler
[23:42] <lool> snif, or so I thought
[23:45] <robru> lool: ok, I mean if you really insist on a third silo I can do it, but I'd prefer not to