[00:25] Queuebot, nooooooooooooo [01:18] robru: I need a silo for line 94 please [01:21] 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] bzoltan1: hm, no idea, mterry might know [01:23] 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] robru: any idea ^? [01:29] 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] bzoltan1: yeah, I know ogra_ was involved with that, maybe plars has any idea [01:30] rsalveti: for me that shell function used to work -> http://pastebin.ubuntu.com/8476271/ But not anymore. [01:51] bzoltan1: rsalveti: you want to use /usr/share/unity8/unlock-device from unity8-autopilot [01:52] it's made to be pulled onto the adb host and run from there [01:53] otherwise, if you just want the dbus call, you should be able to run: [01:53] adb shell "gdbus call --session --dest com.canonical.UnityGreeter --object-path / --method com.canonical.UnityGreeter.HideGreeter && echo Greeter unlocked" [01:53] plars: Thanks I prefer the dbus call... I do my own reboots :) [01:53] bzoltan1: actually, that looks the same as what you were running I think [01:54] bzoltan1: we have seen it fail a few times if it's done too soon, what's it returning for you? [01:54] plars: it looks similar to my script, but it is not the same [01:55] plars: I would not use the `adb reboot; sleep 5; adb wait-for-device` [01:55] plars: that is unreliable... [01:56] bzoltan1: the sleep is more than enough to ensure that we don't return from wait-for-device before the reboot [01:56] bzoltan1: or were you referring to something else? [01:57] plars: sometomes... but 10 sec is safer [01:57] bzoltan1: I've never seen that part of it fail so far, really we could probably even get away with less [01:58] 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] plars: I run my reset like 100-200 times a day when I do... weekly. [01:58] bzoltan1: mterry just landed a change that loops it a few times if it fails though [01:58] plars: I think I stick to my script with the right dbus call :) [01:59] bzoltan1: feel free to propose an improvement to it if you have something that works better :) [02:00] plars: according to my experience there is no sure way... I have to tune my script every week. [02:00] plars: Things change all over without much notice and tools fail without any meaningful error... so it is a continuous fight :) [02:06] plars: so that dbus call takes away the Greeter. But does it take away the password lock too? [02:07] bzoltan1: yes [02:07] plars: cool, thank you [02:09] === trainguards: IMAGE 265 building (started: 20141002 02:10) === [02:22] 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] bzoltan1: that script is part of unity8 - it already goes through the landing process same as everything else [03:05] rsalveti: sorry nope, i just do train stuff, dunno about messy device stuff like greeters ;-) [03:09] bfiller: utopic 2 [03:09] === trainguards: RTM IMAGE 77 building (started: 20141002 03:10) === [03:14] robru: the clock app fails with the stock RTM image but all green on the CI dash. [03:19] robru: also the dialer_app tests are flaky [03:28] robru: just configured silo 8 and can't build: https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/82/console [03:37] rsalveti: weird. click IGNORE_STEP for now [03:37] bzoltan1: no idea [03:42] rsalveti: hm that's odd... still digging [03:44] robru: hm, also failed [03:44] 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] but differently [03:45] rsalveti: that one's a legitimate failure though, isn't it? ;-) [03:45] oh, need to put force rebuild [03:46] rsalveti: well wait [03:46] rsalveti: the trunk branch is really missing that revision from distro. [03:46] rsalveti: make sure you check that before you just wantonly revert it [03:46] robru: yup, no worries, that is as expected [03:46] not landing this until my other landing migrates properly [03:47] 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] robru: can't yet because it's waiting on another silo to be cleaned [03:47] guess I can actually [03:47] but the clean step from the other silo might fail [03:48] which is fine I guess [03:48] rsalveti: why would the clean step fail? wouldn't it just merge the branch? [03:48] robru: migration is blocked as pulse still needs to be accepted [03:49] 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] let me try something different [03:49] ah [03:59] === trainguards: IMAGE 265 DONE (finished: 20141002 04:00) === [03:59] === changelog: http://people.canonical.com/~ogra/touch-image-stats/265.changes === [04:09] morning [04:11] Mirv: morning! [04:12] man, "morning" means I should go to bed :) [04:13] Ursinha: haha. it sure means I shouldn't be working... not quite bedtime though [04:13] 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] Wow, I got full OK from the gallery tests with the UITK silo. [04:18] bzoltan1: it's been some time since I've seen full OK from gallery locally.. [04:18] nice [04:19] Mirv: yes, I am surprised too :D The UITK landing tests look good [04:19] === trainguards: RTM IMAGE 77 DONE (finished: 20141002 04:20) === [04:19] === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/77.changes === [04:20] Mirv: but the camera app hangs .. is there a special trick to make that run? Maybe robru knows... [04:20] bzoltan1: i dunno nuthin bout nuthin [04:21] robru: dude :) that is a perfect line before saying EOD [04:21] EOD [04:21] ;-) [04:21] (EOD 3.5 hours ago) [04:21] LOL [04:22] I EOD'd 8 hours ago and woke up 3 hours ago... [04:23] Mirv: why the bump from 2 to 5? [04:23] I wonder if we shouldn't also bump the other files we have in there [04:23] ops, 3 to 5 [04:24] rsalveti: it looks like they forgot the bump the last time they bumped the version to 2.4.0.. [04:24] right [04:24] seems fine from the MR [04:24] Mirv: +1 [04:25] thanks. [04:26] bzoltan1: I know no special trick for camera, it used to run ok [04:26] rsalveti: my fix for that bug you saw just landed in production [04:27] 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] 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] robru: nice, hot fix in production [04:27] that's how we roll :-) [04:27] Mirv: i know camako said there was a stopper for mir0.8 promotion [04:28] robru: any idea where queuebot went? it was active 45mins ago, no totally silent despite me doing things. [04:28] rsalveti: oh no, this one went through code review! ;-) [04:28] kgunn: ok. I can then at least assign silo for mzanetti. [04:28] robru: awesome [04:28] 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] robru: oh, ok. [04:29] oh yeah, scrolling a bit further, a suspiciously _lot_ of queuebot activity :) [04:29] 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] "behaving as well as could be expected from a server that crashes every 10 minutes" [05:45] 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] 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] trainguards: is here a QA eng available to check and sign the UITK in the silo14? [06:16] bzoltan1: There might be soon. The other two silos in queue are blocked. [06:17] kgunn, mzanetti: On that note, what test plan is relevant for silo rtm-011? Nothing is linked. [06:17] ToyKeeper: all right, thanks. Then I carry on with the QtC work [06:18] 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] 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] 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] 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] 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] 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] ToyKeeper: So I am happy for the change [06:29] 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] trainguards: I would like to ask for a reconfig of the rtm14 silo, i just added there the -gles package. [06:36] In that case, perhaps I shouldn't start on it. [06:37] If the contents of the silo changed just now, wouldn't that invalidate the previous test results? [06:39] ToyKeeper: absolutely not... I am adding the -gles package [06:40] 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] Oh, okay. [06:41] ToyKeeper: actually it is something what is a real issue... at some point we should start testing the emulator images too [06:41] Haha, yeah. As soon as the emulator itself is reasonably stable. :) [06:47] bzoltan1: you're correct, it should be of the style http://ppa.launchpad.net/ci-train-ppa-service/landing-020/ubuntu-rtm [06:48] 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] Mirv: I can still change [06:50] bzoltan1: maybe that's correct... we'll see. reconfigured. [06:50] or sorry, not yet [06:50] changes in the prepare jobs [06:50] "Please ask the trainguards to reconfigure this silo for you." I _am_ a trainguard :) [06:51] oh, right, there it is [06:51] bzoltan1: now reconfigured [06:51] Mirv: :D [06:59] Mirv: ehh https://ci-train.ubuntu.com/job/ubuntu-rtm-landing-014-1-build/25/console [07:02] bzoltan1: unsynced changelog vs https://launchpad.net/ubuntu-rtm/+source/ubuntu-ui-toolkit-gles [07:05] psivaa: btw the clock app qmlscene was a duplicate bug #1376346 [07:05] bug 1376256 in qtorganizer5-eds (Ubuntu) "duplicate for #1376346 libedataserver crashed with signal 5 in clock-app" [Medium,Confirmed] https://launchpad.net/bugs/1376256 [07:05] but the mediascanner one was potentially a newly filed [07:05] anyway, neither is upstream Qt crasher but apparently in our components [07:16] 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] bzoltan1: probably yes [07:17] Mirv: all.. right. I try that [07:20] Mirv: it seems that the trick works.. thanks [07:20] good! [07:29] sil2100, red alert, we got a true blocker yesterday [07:29] sil2100, https://bugs.launchpad.net/ubuntu-ui-toolkit/+bug/1376500 [07:29] Ubuntu bug 1376500 in thumbnailer (Ubuntu) "[regression] thumbnails and image previews displayed wrong" [Critical,Confirmed] [07:34] brendand: ugh, that in ubuntu-rtm? [07:35] Right, rtm [07:44] who do i need to bribe to get some nodes for http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-utopic/ ? [07:44] ' All nodes of label 'utopic&&amd64' are offline ' [07:46] sil2100: at least that wasn't "isolated bug fix" but went through QA [07:47] tsdgeos: cihelp, probably [07:47] Mirv: if there was someone called cihelp :D [07:52] hah ;) [07:53] tsdgeos: cihelp is a key-word that all CI team members get pinged on [07:53] ic [07:54] tsdgeos: O_o /me looks [07:57] Mirv, no i would have extra pissed off it is was an 'isolated bug fix' [07:59] Morning all [08:04] brendand: I just poked Satoris, not sure when he starts his day though [08:08] tsdgeos: weird, the node appears to be up but jenkins fails to connect to it, I'll escalate [08:09] vila: tx [08:12] sil2100: what's your current damage report? I mean in terms of recovering from injuries.. [08:12] "hull intact" etc [08:12] hah ;) [08:13] sil2100: did I set the day thing right on those tags age still say N/A [08:13] It's better, it's not swollen anymore [08:14] But I still have problems moving it so I'm wearing a stabilizer [08:14] davmor2: hm, I thought those were correct, let me re check [08:15] sil2100: what this teach you about doing martial arts incorrectly ;) [08:16] I think everyone took our previous exercises a little bit too seriously [08:17] ;) [08:17] davmor2: ok, fixed, we both filled in bad tags yesterday - it's suppsaosed to be lt-date- not lt-age- [08:18] sil2100: hahaha [08:20] sil2100: hey ho :) could I have a silo for spreadsheet line 42 please? [08:20] mzanetti: looking! [08:21] mzanetti: it's a sync from utopic now, right? Only unity8? [08:21] sil2100: yeah [08:21] sil2100: wait, let me make sure which ones [08:22] sil2100: yep, only unity8 [08:22] mzanetti: hm, unity8 already seems to be configured for ubuntu-rtm in silo 11 [08:23] mzanetti: I'll assign a silo but make sure you land rtm/11 first [08:24] 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] sil2100: ok. hopefully getting better and better soon. [08:26] sil2100: ah... that's why [08:26] sil2100: ok... I can also wait... but rtm seems to start being 3 silo releases behind utopic [08:27] sil2100: but we have > 10 approved branches in unity8 again, so I'd need to get going with that too soon [08:27] mzanetti: ok! Let's poke QA today to make sure it gets signed off as soon as possible [08:27] brendand: hey, could you prioritize silo rtm/11 a bit please? [08:27] davmor2, brendand: can you (or anyone else) sign off rtm/11? [08:32] mzanetti, no test plan [08:32] mzanetti, otherwise it probably would have been signed off already [08:37] psivaa: hey! You online today? [08:39] brendand: added the test plan link [08:42] mzanetti, you didn't think about running any of the indicator- test plans? [08:43] brendand: hmm... doesn't really change the indicators itself. only the ui for it. [08:44] brendand: unity8 test plan contains verification of the ui [08:44] but if you're worried, feel free to do some more checks [08:44] sil2100: he e-mailed that he'll be later on [08:44] mzanetti, ok but keep in mind the testing is not only to verify the fixes work but also to check for regressions [08:45] 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] mzanetti, ok just making sure - some people are not so careful [08:54] question: how do I push a new package version to the image? [08:56] https://wiki.ubuntu.com/citrain/RTMLandingApproaches # really confusing [08:58] * popey gives up [08:58] chihchun: let me get back to you in a moment [09:00] 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] hi trainguards; i've unblocked branches in silo 14 for landing [09:04] pstolowski, hey - you tested the last mediascanner landing right? [09:05] 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] chihchun: did you use the CI Train before? [09:05] brendand, i tested last mediascanner-scope landing [09:05] dbarth: ok! [09:05] 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] brendand, (not the mediascanner) [09:06] sil2100: robru: considering my Qt silo now conflicts with half the world [09:06] 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] ricmm, could you top approve https://code.launchpad.net/~ogra/phablet-tools/fix-phablet-shell-without-local-key/+merge/236696 ? [09:10] chihchun: ok then, let me take a look at this [09:10] sil2100: thanks [09:11] 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] chihchun: do you have an ubuntu-rtm enabled device? [09:12] sil2100: right, I have a nexus4 [09:12] chihchun: does it have an image from the ubuntu-rtm channel installed? [09:12] Or is it devel-proposed? [09:13] 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] (top-approved) [09:14] 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] sil2100: yes, I have r67, 20141002 image on it. (ubuntu-touch/ubuntu-rtm/14.09-proposed) [09:14] Excellent [09:17] Mirv, ah, it is now [09:18] mvo, iirc that came from your meta upload ... https://lists.launchpad.net/ubuntu-phone/msg10035.html ... any idea about it ? [09:18] psivaa, but you know it had mediascanner and thumbnailer in that silo right? [09:18] psivaa, sorry [09:18] 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] pstolowski, ^ [09:19] sil2100: where should I report my test result? [09:21] 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] chihchun: after that the rest belongs to us and QA, so you're free [09:22] pstolowski: thanks, published. [09:22] sil2100: sorry dint know you'd lead the meeting back today. so i emailed Mirv in the rush to go out [09:23] psivaa: and I didn't notice sil2100 wasn't included :) [09:23] :) [09:24] brendand, i know nothing about that, sorry [09:25] ok that's kind of a problem [09:28] sil2100: all done, thanks [09:29] ogra_: I am just the uploader, its "bzr log -r 248" committer: Jamie Strandboge [09:29] merge from David Barth: Let apparmor protect access to the OA APIs [09:29] oh, ok [09:29] psivaa: ah ;) No worries! [09:29] dbarth, ^^ [09:29] dbarth, see https://lists.launchpad.net/ubuntu-phone/msg10035.html for context [09:30] chihchun: thanks! Now just we need to wait for QA to sign it off and it'll be in ubuntu-rtm [09:33] reading [09:34] ok, i noticed that yesterday with mardy [09:34] mardy: ^^ that same permission error; so the fix is to explicitely specificy the applicationid when making calls. right? [09:42] dbarth, ogra_: I'll comment on the bug report, as well as to the ML [09:42] mardy, merci :) [09:51] sil2100, i almost forgot there's something i needed to talk to you about [09:52] Wazzup? [09:53] 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] sil2100, you think you can arrange that? [09:53] Oh, finally that big landing! [09:54] 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] lets make sure to have a standalone image for it [10:02] brendand: Do you think you can take the UITK release candidate? [10:02] sil2100: hey, when you have a minute, please assign me a utopic silo for row 69 [10:03] bzoltan1, i'll put it next in the queue [10:04] how would people think about a remote execution feature for phablet-shell ? like: http://paste.ubuntu.com/8478233/ [10:07] ogra_: I would use it [10:07] do you people know what happened to get glib updated in the rtm serie? [10:07] brendand: thank you. The logs are at the same place. The link is in the sheet [10:07] seb128, havent checked excuses yet [10:07] ogra_, excuses? [10:08] we wanted to get it updated but qa needed to approve it I think [10:08] seb128, seems colin didnt move it over to rtm-proposed yet [10:08] ogra_, what benefits would it give over adb shell? [10:08] is that still blocked? [10:08] seb128, oh, wait ... glib ? not glibc [10:08] ogra_, https://launchpad.net/ubuntu-rtm/+source/glib2.0 [10:08] right [10:08] heh, sorry ... (we're trying to land glibc too atm) [10:08] http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu-rtm&q=glib [10:09] that one ^ [10:09] is it blocked? can we do anything to unblock it? [10:09] it's an important fix for wakeups issues [10:10] seb128, spreadsheed line 19 .. [10:10] hasnt been set to "testing done" yet [10:10] QA qill only be notified about it if that has happened [10:10] *wil [10:11] l [10:11] Laney, ^ should we do that? [10:11] 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] seb128, i assume the testplan: "test ALL the things" might be a bit time consuming though :P [10:12] ogra_, not sure how you want to test base libraries [10:12] me neither [10:13] but at least describing how to test the bugs you aim for to be fixed are gone might be helpful [10:14] testing done where? [10:14] Laney, the K column on the spreadsheet [10:15] okay, I thought that was for QA to do [10:15] seb128 did some testing [10:15] I don't know how to check for the wakeup problem [10:15] I run my krillin with that version for a few days without issues [10:16] 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] seb128: can you fill in image number please ;-) [10:17] Laney: No the developers run their testplan and mark it tested, we then grant it in the needs QA sign off [10:17] Laney, urg, I don't remember, I think it was 71 [10:17] heh [10:17] let me reinstall it on the current image [10:17] so we can put the current number there ;-) [10:18] * Laney wibbles at davmor2 [10:19] Laney: take those pants off your head and pencils out of your nose, you don't fool anyone :P [10:19] 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] i know that ToyKeeper does that in such cases [10:19] 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] Laney, no, but it takes QA time and will make the landing slow [10:20] well it's not an isolated upload just for that fix [10:20] * brendand grumbles check for regressions too... [10:20] we just took the upstream release which contains it [10:24] sil2100, any idea on what vacation the bot is today ? [10:25] hmmm [10:25] ogra_: I think it's just slacking off, we should fire it! [10:25] ++ [10:25] ogra_: tomorrow it is uniting with all the other bots [10:25] lol [10:26] Tag der queuebotten einheit [10:26] But yeah, I guess we need to poke stgraber about it [10:33] sil2100: ogra_: the machine running it reportedly crashes every 10 minutes, so it's essentially gone for now [10:33] morning all [10:34] sil2100, ogra_ new device tarball available [10:34] http://people.canonical.com/~jhm/barajas/device_krillin-20141002-d5938d7.tar.xz [10:34] http://people.canonical.com/~jhm/barajas/device_krillin-20141002-d5938d7.changes [10:34] http://people.canonical.com/~jhm/barajas/device_krillin-testresults-20141002-d5938d7.ods [10:34] any chance of a davmor2 or brendand QA pass? ^ [10:35] 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] brendand, have a look at the google doc :-) [10:36] \o/ [10:38] 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] bzoltan1: ok, I'll publish it as soon as the arm64/etc builds are fully ready [10:41] davmor2, are you busy with something else? [10:42] brendand: bisecting the trust-store crash [10:43] john-mcaleely, oh, i see two lovely fixes there :D [10:43] ogra_, only two :-) [10:43] davmor2, can we let the developers do that and you pick up the device tarball? [10:43] brendand: location crashing is definitely just 76+ trying to find when truststore crash happened now [10:43] well, the otherse are a nice icing :) [10:43] ha! [10:46] 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] davmor2: could you check syslog for aa errors? [10:46] davmor2: since the main difference seems to be apparmor [10:46] lool: done it yesterday with jdstrand no issues relating to location directly [10:47] :-/ [10:47] lool: exactly [10:47] davmor2: there was no simultaneous device tarball update, was there? [10:47] davmor2: any satellite crashed in your backyard between #75 and #76? [10:48] 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] s/tarball did/tarball did not [10:50] 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] lool so image RTM73 has trust-store crash [10:55] lool: no I need to get on with some other stuff [10:55] now even [10:56] john-mcaleely: I get permission denied on the ods doc [10:58] davmor2, doh [10:58] davmor2, please retry [11:00] john-mcaleely: yay [11:13] 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] sil2100: so today, there's no difference from doing a utopic or rtm first landing? [11:25] sergiusens: what do you mean? [11:26] sil2100: well, robru was telling me you were working on something to make it just one atomic thing [11:26] 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] So for now it's still the same as before [11:32] sil2100: any idea what's wrong with silo 11? it seems to be building for days...? [11:32] thostr_: looking [11:33] sil2100: the log says it's building since 26.9.! [11:34] thostr_: ouch, well... this is iterating into infinity, as urfkill started being unbuildable for 3 platforms with the introduced changes [11:35] thostr_: I aborted the build, but this needs to be resolved anyway [11:35] brendand: any news about the UITK landing? [11:35] sil2100: nice... just wondering why none of the landers noticed... [11:35] cyphermox_: hey! [11:35] and this is blocking others silos [11:36] cyphermox_: what's up with silo 11? Is making urfkill unbuildable for those 3 architectures wanted? [11:36] thostr_: yeah, I guess we, the LT, should have also noticed, but we can't keep track of all individual silo contents [11:36] Though, this one we should have noticed [11:36] thostr_: thanks for noticing! [11:37] 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 === chihchun is now known as chihchun_afk [11:54] davmor2: ping [11:56] 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] cwayne: but it was looking pretty good except for the scopes that didn't load properly because of the lack of location :) [12:00] davmor2: but that's not the custom tarball's fault :( [12:01] cwayne: no but the broken scope become more obvious now they become front and center [12:02] but it's really not a broken scope, its a scope that requires location but not getting it [12:02] but anyway, im fine to get it in after device tarball :) [12:13]