[04:29] <Mirv> mornings
[07:38] <oSoMoN> ubuntu-qa: good morning, is there an ETA for silo 23 validation?
[07:55] <mzanetti> trainguards, in bileto I can't find the link to the adt results if something is hanging in the proposed pocket, can you point me to it?
[07:57] <robru> mzanetti: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html
[07:57] <mzanetti> robru, good morning
[07:58] <mzanetti> robru, in the dashboard, the link would directly bring me to the packages I'm trying to land. can we have that back in bileto?
[07:58] <robru> mzanetti: yeah, please file a bug about this in lp:bileto
[07:59] <robru> (1am here, I'll get to it tomorrow)
[08:09] <Mirv> mzanetti: true, that would be useful
[08:10] <mzanetti> Mirv, hey, looking at unity8/qtmir adt logs but don't really understand what's going wrong. bootest has some issue. have you seen this before?
[08:11] <jibel> oSoMoN, likely today
[08:11] <oSoMoN> jibel, cool, thanks!
[08:15] <Mirv> mzanetti: I don't know what's the current status of boottests, they have had non landing related problems in the past. but seeing that the latest unity8 job was started by francis manually, at least they have been looking at it. let's ping ci_help if they can understand about the boottests more. all I see is that adt-run was Killed in the log.
[08:16] <mzanetti> ah ok... so you would agree that it rather looks like a system failure than some real regression in the branches we're trying to land?
[08:16] <Mirv> ogra_: it seems there was some action on wily image side this morning? (I see 20150910.changes, although empty)
[08:16] <Mirv> mzanetti: I'd say there's no reason to assume there's something wrong in the landing before we know more.
[08:16] <Mirv> mzanetti: and probably highly likely it's a system failure
[08:17] <mzanetti> ok :)
[08:17] <Mirv> oh, I didn't ping cihelp. now I did :) unity8/qtmir boottest failures.
[08:18] <psivaa> Mirv: now, you have :)
[08:24] <Laney> is it okay to upload livecd-rootfs and lxc-android-config to wily and then spin an image?
[08:25] <Laney> or is there some better way to QA changes to this?
[08:35] <Mirv> Laney: ogra_ knows a trick to test at least the latter, but not sure about livecd-rootfs. note that lxc-android-config just joined the train, so landing via MP preferable.
[08:36] <Mirv> and hmm the previous landing is stuck in proposed similar to unity8/qtmir
[08:36] <Laney> good old boottest
[09:17] <oSoMoN> ogra_, or anyone familiar with how touch images are built, it looks like oxide 1.8.4 from the overlay PPA takes precedence over oxide 1.9.1 that is in the -security and -updates pockets, how can we ensure that the images get the latest version? Does this require a seed update, or copying oxide to the overlay PPA?
[09:17] <oSoMoN> (note that we should wait for oxide 1.9.2 to be out in any case, as 1.9.1 has a critical issue that breaks all webapps)
[09:36] <Mirv> oSoMoN: you will need to land to overlay PPA. overlay PPA "always wins", so that a normal 15.04 update can't break touch image. only packages that are not in overlay PPA at all get automatic updates from 15.04.
[09:36] <Mirv> oSoMoN: so in this case for example webapps didn't get broken :)
[09:37] <Mirv> oSoMoN: QA will also want to verify it normally
[09:37] <oSoMoN> Mirv, ok, thanks
[09:46] <Mirv> heh, right, that needs fixing
[09:51] <Mirv> finally, done
[12:09] <mzanetti> Mirv, do you know whom to ping about the boottest issue?
[12:11] <mzanetti> oh... I just see you (accidentally) did already :)
[12:15] <Mirv> mzanetti: my best guess would be fginther since he was poking the jobs yesterday
[12:17] <Laney> do you mean lxc-android-config?
[12:21] <Mirv> I guess he means unity8/qtmir boottest failures
[12:53] <mzanetti> Laney, sorry, missed that, yes. I mean unity8/qtmir boottest
[12:59] <pstolowski> robru, hey, what's the issue with silo 10? is it just upload permission problem now?
[13:01] <jibel> fginther, do you know why http://d-jenkins.ubuntu-ci:8080/view/Wily/view/BootTest/job/wily-boottest-apport/19/ fails
[13:01] <jibel> cihelp ^
[13:33] <rvr> kenvandine: Approving silo 9
[13:33] <kenvandine> rvr, thx
[13:53] <fginther> jibel, looking
[14:21] <rvr> oSoMoN: bzoltan: In silo 23 (ui-toolkit), there is also a modification to webbrowser-app, anything special to check?
[14:29] <oSoMoN> rvr, only that context menus work as expected (they are dismissed when clicking an action), and that autopilot tests all pass
[14:29] <rvr> 1. The webbrowser-app failures were all caused by the the direct usage of AbstarctButton object type from the AP tests.
[14:29] <rvr> The https://code.launchpad.net/~bzoltan/webbrowser-app/UCAbstractButton/+merge/270369 patch fixed it and the browser.sh/browser.logs provides the extra tests.
[14:31] <rvr> Nice
[15:25] <jhodapp> davmor2, is there a delay between marking something as ready for QA in bileto until it shows up in the QA Trello board?
[15:26] <jibel> jhodapp, 10 minutes max
[15:26] <jibel> jhodapp, which ticket?
[15:26] <jhodapp> jibel, ok, I just marked silo 55 as ready for QA
[15:27] <jhodapp> jibel, I want to make sure whomever ends up testing it speaks with me first before testing it...there's some specifics they need to know about first
[15:27] <robru> jhodapp: that's what the Test Plan field is for ;-)
[15:28] <jhodapp> robru, yes indeed, but there's more to it than that for this one :)
[15:28] <jibel> jhodapp, you can add a comment in bileto, most of the time the person doing the verification reads it :)
[15:28] <jhodapp> yeah I did, but I insist, they really need to speak with me
[15:36] <pstolowski> robru, hello, have you seen my earlier query?
[15:36] <robru> pstolowski: no, what?
[15:38] <rvr> mzanetti: The "reboot" button in the power dialog is now grey instead of green. Do you know who can confirm that's intended and not a regression?
[15:39] <pstolowski> robru,  what's the issue with silo 10? is it just upload permission problem now? all good with packaging?
[15:39] <fginther> Mirv, robru, in case anybody asks, the devices used for boottest have gone into a bad state and need to be manually recovered. A handful of recent tests failed because if the device problems and will be retested once the devices are working again. Let us know if there are any packages that need priority.
[15:40] <robru> fginther: thanks
[15:40] <robru> pstolowski: it needs packaging ack
[15:40] <robru> kenvandine: if you're around can you ack & publish this one? https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/79/ thx
[15:41] <pstolowski> robru, k, thanks
[15:41] <robru> you're welcome
[15:42] <kenvandine> robru, looking
[15:43] <robru> thanks
[15:44] <kenvandine> -Package: libunity-scopes1.0
[15:44] <kenvandine> +Package: libunity-scopes3
[15:44] <kenvandine> with no replaces/conflicts for libunity-scopes1.0
[15:44] <kenvandine> which exists in wily
[15:44] <kenvandine> not sure about that
[15:45] <bzoltan> rvr: oSoMoN: the AP tests I have copied to the usual place .. all good
[15:45] <kenvandine> is that package in the overlay?
[15:45] <rvr> bzoltan: Great
[15:46] <rvr> kenvandine: Yesterday I approved a unity-scopes-api silo
[15:47] <kenvandine> so the libunity-scopes1.0 binary is in the overlay ppa?
[15:47] <kenvandine> ah, no it isn't
[15:48] <mzanetti> rvr, that's intended. there was a bug that the old one was looking like a "tricolor", so design took out some colors
[15:48] <rvr> mzanetti: Cool, thanks!
[15:49] <kenvandine> robru, it's a nack from me
[15:49] <kenvandine> robru, there needs to be a replaces/conflicts for the binaries that landed in wily that aren't built anymore
[15:49] <robru> kenvandine: ok, thanks
[15:50] <kenvandine> https://launchpad.net/ubuntu/+source/unity-scopes-api/1.0.1+15.10.20150826-0ubuntu1
[15:50] <kenvandine> there are a few binaries in wily that aren't in this package
[16:02] <rvr> oSoMoN: The font size of the context menu looks small in arale
[16:06] <pstolowski> kenvandine, hey, can you give an example? do you mean e.g. libunity-scopes-qt0.1 vs libunity-scopes-qt0.2_1.0.1 ?
[16:06] <rvr> bzoltan: oSoMoN: Approving silo 23
[16:06] <robru> bregma: uh? why doesn't 41 need QA? it's dual
[16:07] <bregma> it's also not used in any image
[16:07] <robru> hm
[16:07] <robru> ok
[16:08] <robru> kenvandine: here's a simpler one if you can please ;-) https://ci-train.ubuntu.com/job/ubuntu-landing-041-2-publish/12/
[16:10] <robru> kenvandine: and another one? ;-) https://ci-train.ubuntu.com/job/ubuntu-landing-023-2-publish/39/
[16:13] <bzoltan> wow robru is not authorized?
[16:14] <robru> bzoltan: new rules
[16:14] <robru> I am powerless
[16:14] <bzoltan> rvr:  cool, thank you
[16:14] <bzoltan> robru:  I told you to be nice and kind :)
[16:14] <robru> bzoltan: I can only upload if there's no packaging diff, "not authorized" is the new "packaging changes need manual ack"
[16:15] <bzoltan> robru: I see... we need a jedi for that
[16:16] <robru> bzoltan: yes. I pinged kenvandine but he's a bit swamped I'm sure
[16:18] <rvr> jgdx: Silo 15 has a merge proposal which needs review
[16:18] <jgdx> rvr, which one?
[16:19] <jgdx> on my list all of them are approved
[16:19] <rvr> jgdx: https://code.launchpad.net/~jonas-drange/ubuntu-system-settings/allow-insecure-hotspot/+merge/269671
[16:19] <rvr> jgdx: But I see it was already approved
[16:32] <fginther> Saviq, anpok, does the unity8 currently in proposed-migration require mir updates? The unity8 boottest is failing because the shell doesn't come up (but it is possible to adb shell in). It does work installing everything from the -proposed pocket
[16:35] <kenvandine> robru, sure, i'll look
[16:36] <bzoltan> kenvandine:  thank you!
[16:43] <kenvandine> robru, ^^ what's that exception?
[16:46] <robru> kenvandine: uh
[16:47] <robru> kenvandine: can you try it again? that shouldn't happen
[16:47] <kenvandine> exceptions should never happen :)
[16:48] <robru> kenvandine: I just did a rollout, maybe you caught something halfway
[16:48] <kenvandine> robru, boom
[16:48] <bzoltan> robru: kenvandine: thank you boys :) good job
[16:48] <robru> kenvandine: oh, well the test plan field is empty in bileto ;-)
[16:48] <robru> odd, that error should be printed nicer than that
[16:49] <kenvandine> bzoltan, np
[16:49] <robru> hang on a second guys, disk issue
[16:50] <kenvandine> robru, well i acked the packaging changes... let me know if you need me to publish it later
[16:52] <robru> kenvandine: yeah I will
[16:52] <kenvandine> thx
[16:54] <robru> kenvandine: ok can you publish now?
[16:56] <robru> bfiller: sorry, in the middle of a rollout, hold off for a sec and retry a bit later
[16:57] <bfiller> robru: ok
[16:58] <robru> bfiller: ok I retried it: https://ci-train.ubuntu.com/job/ubuntu-landing-046-1-build/71/consoleFull
[16:58] <robru> hopefully that one works
[16:59] <pmcgowan> jibel, is someone grabbing silo 55? very anxious for that one
[16:59] <kenvandine> robru, i can try
[17:00] <robru> kenvandine: it should work now
[17:03] <kenvandine> robru, seems to be working
[17:04] <robru> kenvandine: seems to be stalled, oh god what have i done
[17:05] <robru> kenvandine: it's stuck at "writing packagelist", which should be done in microseconds, it literaly just writes a short text file. the fact that it's been running for over 4 minutes is horrifying
[17:05] <robru> kenvandine: can you cancel it and try again
[17:06] <robru> hopefully that's just some kind of fluke, because I didn't really change that part of the code... also if there was a bug there it should just raise an exception, I can't imagine why it would block like that
[17:06] <robru> kenvandine: can you publish with DEBUG checked?
[17:07] <robru> kenvandine: or apparently it's fine
[17:08] <robru> kenvandine: nm about retrying, thanks for your patience
[17:10] <awe_> robru, when you get a chance could you take a peek at the latest build failure for ofono?
[17:10] <awe_> https://requests.ci-train.ubuntu.com/#/ticket/338
[17:11] <robru> awe_: bash: ./debian/rules: Permission denied
[17:11] <awe_> yea, trying to figure out how that happened
[17:12] <awe_> the permissions didn't get changed
[17:13] <awe_> they're the same in the trunk branch and mp
[17:13] <robru> awe_: I just branched your branch and the debian/rules file is not executable. I don't know how it happened but you're going to want to chmod 755 it
[17:13] <awe_> that said, the executable bit isn't set, so maybe an update on the builder side caused this to get caught?
[17:13] <awe_> ok, will update it
[17:14] <awe_> maybe it got changed in the last update
[17:14] <robru> awe_: I dunno, if it worked before without being set executable that's a fluke, debian/rules is expected to be executable
[17:14] <awe_> ack
[17:14] <awe_> thanks
[17:14] <robru> awe_: you're welcome
[18:06] <bzoltan> robru:  would you be so kind to assist thesilo35's landing?
[18:06] <robru> bzoltan: you're trying to merge it before it's landed?
[18:07] <bzoltan> robru: :D yes
[18:07] <robru> bzoltan: generally that's not recommended but if you want to do that you need to check FORCE to skip the version check
[18:08] <bzoltan> robru:  actually i would prefer to properly land it first
[18:08] <robru> bzoltan: so what's stopping you from landing properly?
[18:09] <bzoltan> robru: "bzoltan is missing the Job/Build permission"
[18:09] <robru> bzoltan: on what job?
[18:10] <bzoltan> robru: https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/build
[18:10] <robru> bzoltan: So what you're really trying to say is that you want me to publish the silo?
[18:11] <bzoltan> robru: Yes :) Sorry  for confusing
[18:11] <robru> bzoltan: ok, we'll see if I can
[18:19] <robru> bzoltan: ok, should be good to go then
[18:26] <awe_> robru, ofono failed again... this time it's a single unit test failing on wily for 5/6 arches;  I can't reproduce the failure using a wily sbuild.  Is there any way to get at other build artifacts in a PPA ( eg. the file test-suite.log )?
[18:27] <robru> awe_: uh, I don't have any special access to the PPA, but if there's a file generated in the source tree at source-package-build-time I might be able to fetch it from jenkins.
[18:27] <robru> awe_: what's the file called?
[18:27] <awe_> test-suite.log
[18:27] <robru> awe_: in the source root?
[18:28] <awe_> nah, it's generated during the binary build
[18:28] <awe_> this is gonna be a fun one ot find
[18:28] <awe_> s/ot/to/
[18:28] <robru> awe_: yeah you'd have to change your packaging to include that file in a deb to be able to get it from the PPA then. or maybe ping a launchpad person to poke at that
[18:28] <awe_> k, thanks
[18:28] <robru> awe_: you're welcome
[18:41] <bzoltan> robru:  thank you .. there were so many automatization recently :) that i almost thought that I can trigger a publishing process and then the trainguards just need to ack it :)
[18:41] <robru> bzoltan: that may happen one day soon... it's all coming together
[18:47] <robru> kenvandine: another packaging ack pls? ^ ;-)
[18:49] <kenvandine> robru, looking
[18:49] <robru> thanks
[18:51] <kenvandine> robru, done
[18:51] <robru> kenvandine: great, thanks
[18:52] <kgunn> trainguards unity8 seems stuck in proposed still from silo14, is that still being worked...see bootest retry but manually aborted
[18:52] <robru> fginther: ^^ boottest love?
[18:58] <fginther> kgunn, I posted a question about unity8 to Saviq and anpok earlier. Tested by itself, the UI does not come up when testing unity8. It does work when the rest of silo 14 is added.  Is that expected and will these all migrate together?
[18:59] <kgunn> fginther: yes, all of silo14 needed to go together
[19:00] <fginther> kgunn, thanks, I'll get them unblocked then
[19:02] <kgunn> fginther: thank you!
[19:02] <kgunn> oh and yeah Saviq is on vacation
[21:04] <jhodapp> robru, is it possible to have a silo depend on another for building - e.g. silo A has a package that silo B needs as a prereq to build, but it's not appropriate to put the MRs for B into A
[21:08] <robru> jhodapp: it may be possible with manual futzing but I'd have to check into that. Why aren't the MPs appropriate in the same silo? Sure sounds like it should all be in the same silo if it depends on the other to even build.
[21:09] <jhodapp> robru, well they only depend on each other because the version number got bumped because of an interface change
[21:09] <jhodapp> robru, but that's the only relationship they have, they definitely belong in separate landings
[21:10] <robru> jhodapp: what makes you think they are definitely separate? There isn't a limit on how big a silo can be.
[21:12] <robru> Hah
[21:12] <jhodapp> robru, because one silo has a scope of fixing MPRIS only which is what bumped the version number, and the other has nothing to do with MPRIS
[21:13] <jhodapp> could they technically land together, sure, but functionally it'd be inappropriate
[21:15] <robru> jhodapp: so the thing is, I can add PPA dependencies the way you describe, but it's quite a manual thing, it's not something you can define in the request.
[21:15] <robru> jhodapp: and then it becomes super important for me to remember to undo that change when you're done
[21:15] <jhodapp> robru, yeah not a huge deal and I know it's a niche circumstance, but was curious enough to ask :)
[21:15] <jhodapp> as soon as silo 55 lands this is a non-issue
[21:15] <robru> jhodapp: so generally it's gonna be a lot easier (for me, heh) if you just put them in the same silo, or land one and wait for it to complete before building the second
[21:16] <jhodapp> robru, I blame davmor2 ;p
[21:16] <jhodapp> he needs to hurry up and test silo 55
[21:16] <robru> ah, qa ;-)
[21:19] <robru> jhodapp: oh, I suppose an easier thing would be to just copy the necessary packages from the original silo into the new silo, and then delete them later before publishing
[21:19] <robru> then I don't have to remember to undo PPA changes.
[21:20] <robru> jhodapp: lemme know if you want me to do that, what packages from what silo to what silo