[09:26] <dbarth> hey trainguards
[09:27] <sil2100> Morning o/
[09:27] <dbarth> just for confirmation, do i need to publish https://requests.ci-train.ubuntu.com/#/ticket/856 or just merge
[09:27] <dbarth> hi sil2100
[09:27] <dbarth> i don't want to derail if we re in deep freeze
[09:28] <sil2100> dbarth: hmm, why do the automated tests fail?
[09:28] <sil2100> There's no freeze, anything can land now :)
[09:29] <sil2100> I mean, there's the OTA-9 freeze but rc-proposed is unblocked
[09:29] <dbarth> checking
[09:29] <dbarth> hmm ok
[09:30] <sil2100> It didn't appear on our publishable queue since the autopkgtests somehow seem to be failing
[09:31] <robru> sil2100: dbarth looks like the packages aren't installable in certain arches
[09:51] <dbarth> uh
[09:52] <dbarth> yet, the ppa has them all built
[09:53] <dbarth> robru: where do you see that?
[09:53] <robru> dbarth: it's not a build depend, just a depend. So it's built but not installable
[09:53] <robru> dbarth: click the excuses link on the ticket
[09:54] <dbarth> uh, because of oxide ?!
[09:54] <dbarth> ah sure, because oxide is not available on those arches
[09:55] <robru> dbarth: why does your package depend on oxide if oxide isn't available on those arches? is this a new dep?
[09:56] <dbarth> i wonder, cause that's the first time i see it blocked like this
[09:56] <dbarth> ussoa uses oxide for providing the webview needed to create accounts or renew credentials
[09:56] <robru> dbarth: well the automated testing stuff is pretty new in bileto. previously you would have published this and it would just get stuck in -proposed.
[09:56] <dbarth> mardy: is that a new dep?
[09:57] <dbarth> ah, that's why
[09:58] <dbarth> how can we move this forward? the oxide-on-certain-arches problem will come back every 6 weeks
[09:59] <robru> dbarth: well if this is a new dep you'll have to fix the packaging so that it no longer builds on those arches, and also get the existing packages deleted from those arches, so it isn't counted as a regression.
[09:59] <robru> dbarth: if it isn't a new dep, i dunno how this ever worked before
[09:59] <mardy> robru: it's not a new dep
[10:02] <mardy> but as far as I understood we are making an arm64 tablet, how can it be that we don't have oxide there?
[10:02] <sil2100> morphis: morning ping! You around?
[10:02] <robru> mardy: dbarth: well xenial apparently does not have v1.2 so it seems this silo depends on another silo to work? https://launchpad.net/ubuntu/+source/oxide-qt
[10:03] <morphis> sil2100: morning!
[10:03] <dbarth> oxide is at 1.12 now
[10:03] <robru> no wait
[10:03] <dbarth> i guess oxide related builds have been approved by cjwatson most of the time
[10:03] <robru> sorry i was reading 1.11 as 1.1
[10:04] <sil2100> morphis: hey! I was looking into the thing with importing device tarballs for mako and flo
[10:04] <sil2100> morphis: and if I understand everything correctly, all is good right now
[10:04] <cjwatson> dbarth: blink no
[10:04] <robru> dbarth: yeah I'm not sure what the deal is here. pitti is also a good person to contact re: unknown problems in excuses.html
[10:04] <dbarth> but he was recommending to keep all arches on
[10:04] <mardy> robru: I haven't been bumping the dependency version of oxide since a long time, oxide 1.2.0 should be quite old now
[10:05] <morphis> sil2100: sounds great, let me have a look in a bit
[10:05] <cjwatson> dbarth: so can this package work in principle without oxide?
[10:05] <dbarth> but ok, this is a new blocker because it is now enforced earlier in the process
[10:05] <mardy> robru: do you think that removing the "(>= 1.2.0)" could help here?
[10:05] <dbarth> mardy: ^^ ? i would assume no, because that view is an essential part, right
[10:06] <sil2100> morphis: so I see the latest android upload was on the 11th, so new device tarballs for mako and flo got generated on the 12th
[10:06] <robru> mardy: I doubt it, because the existing version is 1.11, and 1.11 > 1.2 so it's not like this is failing because the ">1.2" requirement is what's holding it back
[10:06] <cjwatson> oh, is this a dependency on liboxideqt-qmlplugin?  (my browser is still waking up)
[10:06] <mardy> cjwatson: no, it really needs oxide
[10:06] <morphis> sil2100: an imported into stable now?
[10:06] <robru> mardy: I wonder if -proposed has a broken version of oxide in it or something
[10:06] <robru> cjwatson: yes
[10:06] <cjwatson> ok, this is a weird special case
[10:06] <sil2100> morphis: not into stable, we only promote images to stable during OTA releases
[10:06] <cjwatson> not surprising you wouldn't know about it
[10:07] <sil2100> morphis: they're in rc-proposed
[10:07] <mardy> I guess that everything about oxide is very special :-)
[10:07] <cjwatson> to keep things vaguely moving and because there were some initial problems, there are a few hacks in the Ubuntu proposed-migration installation
[10:07] <sil2100> morphis: but yeah, well, depends on what exactly you want to happen and what's the original question
[10:07] <sil2100> :)
[10:07] <cjwatson> I'm guessing that robru didn't know about them and so didn't reflect them in the citrain one
[10:07] <robru> cjwatson: i dunno nuthin bout nuthin
[10:07] <sil2100> morphis: since I checked on things as per what was in the e-mail, but I might have misunderstood what you guys saw as the problem
[10:07] <cjwatson> the magic is in lp:~ubuntu-release/britney/britney1-ubuntu fauxpkg/FauxPackages and related scripts
[10:08] <cjwatson> it pretends that liboxideqt-qmlplugin exists at the version in xenial-proposed on arm64/powerpc/ppc64el/s390x
[10:08] <robru> cjwatson: train is using exclusively britney2
[10:08] <cjwatson> among other packages
[10:08] <dbarth> ah, there you go, we're a FauxPackage! :)
[10:08] <sil2100> morphis: I just checked that new device tarballs were generated for the new android upload, at least for mako and flo
[10:08] <morphis> sil2100: basically they should migrate to stable with ota9
[10:08] <robru> k, so this isn't something I'm going to fix at 2AM.
[10:08] <morphis> that was the expectation as we landed the android package in the overlay ppa for that
[10:09] <cjwatson> it would be good to figure out how to clean this up; but perhaps you could forcibly override publication or something, since it won't be a problem for xenial-proposed to xenial migration
[10:09] <sil2100> morphis: since only for those two (and emulator, of course) the device tarball is autogenerated
[10:09] <cjwatson> everything in FauxPackages ought to go away really
[10:09] <sil2100> morphis: yes, it'll be in OTA-9 :)
[10:09] <robru> dbarth: IIRC it should be possible to publish the silo in spite of the failure, if not just get somebody to copy the packages manually
[10:09] <dbarth> cjwatson: would it be better to create "faux packages" for oxide on those arches, as opposed to not building?
[10:09] <sil2100> morphis: when reading yesterday I actually thought you meant that you guys uploaded a new android recently and didn't see any new device tarball popping up
[10:10] <dbarth> i mean, have the oxide build process "proceeed" but create empty blobs
[10:10] <morphis> sil2100: yeah, that was around one two weakks ago
[10:10] <cjwatson> dbarth: I don't know if that's better, that would run the risk of people assuming it actually works :)
[10:10] <morphis> sil2100: but if it will be in ota9, everything is fine :-)
[10:10] <cjwatson> really oxide-qt ought to be ported (certainly to arm64)
[10:11] <cjwatson> I know that it's pretty touch-ish and so getting people to care about it on server-only arches is tricky, but it's so far down the dependency stack ...
[10:11] <dbarth> arm64 makes sense at least
[10:13] <dbarth> or is there a package tag/marker/construct that can stub the missing arches and still say this is a dummy to informed users / installers
[10:13] <cjwatson> not really
[10:14] <dbarth> hmm ok; well, that's not a new problem, so i guess if you resorted to adding scripts around it, there's not really a better way
[10:14] <dbarth> sorry robru ;)
[10:14] <dbarth> i can keep the silo around until next week once you have time to update the train
[10:15] <robru> dbarth: cjwatson: sounds like the correct fix is to just restrict what arches the package builds on and then delete those other arches from the archive.
[10:15] <robru> dbarth: just publish it
[10:15] <cjwatson> robru: that's problematic in some cases due to a dependency stack above it
[10:15] <cjwatson> robru: I think I vaguely remember this case and it was *very* problematic
[10:16] <robru> cjwatson: how is something depending on something that isn't installable on whatever arch?
[10:16] <cjwatson> robru: it was only one binary package out of several, IIRC
[10:16] <cjwatson> I don't remember the exact details
[10:16] <robru> hm
[10:16] <cjwatson> but it gave me conniptions trying to follow the stack up
[10:17] <dbarth> robru: ok
[12:56]  * sil2100 off to lunch
[13:36] <renatu> trainguards, could you assign this ticket for me? https://requests.ci-train.ubuntu.com/#/ticket/913
[13:37] <Mirv> renatu: done
[13:43] <renatu> Mirv, thanks
[15:38] <Saviq> trainguards, assign for https://requests.ci-train.ubuntu.com/#/ticket/914 please?
[15:38] <sil2100> Saviq: on it
[15:39] <Saviq> sil2100, thanks
[15:39] <sil2100> Saviq: done, yw!
[15:39] <Saviq> jibel, here's the request ↑, building now
[15:52] <dobey> hmm. no more edit history?
[16:01] <rvr> kenvandine: Hey. I created a bug for the missing bluetooth address in System Settings > About.
[16:02] <rvr> bfiller just triaged it
[16:05] <Saviq> jibel, so, the fix we have for apps (not) closing is currently built on top of 4k+ diff of test refactoring (already top-acked)... we're looking into isolating the fix, but it might take a while, think we could land the test refactoring with it after all?
[16:07] <jibel> Saviq, how much time it "a while" approximately?
[16:07] <Saviq> jibel, dednick's trying to work it out now
[16:08] <jibel> Saviq, I'd rathe rjust land the fix
[16:08] <Saviq> jibel, yeah, I know, just pre-empting
[16:26] <kenvandine> rvr, thx
[16:50] <Saviq> jibel, ok, looks like we've an isolated fix, building silo
[16:53] <jibel> Saviq, excellent, thanks
[16:54] <sil2100> Saviq: \o/
[16:54] <sil2100> Yeah, I was worried by the diff
[16:55] <Saviq> sil2100, robru, just realized train can't deal with private branches even if subscribed, we could use a fix for that
[16:55] <Saviq> OTOH the diff becomes public enough when it gets built (so maybe we need private silos ;))
[16:57] <sil2100> ;)
[17:32]  * sil2100 goes AFK for a while now
[17:32] <sil2100> I'll be back later once the silo is landed and a re-spin is required
[18:04] <pstolowski> hello trainguards, may i ask for help assigning a silo for https://requests.ci-train.ubuntu.com/#/ticket/915 ? it says we're low on silos, i freed one silo a moment ago but that didn't help
[18:11] <sil2100> pstolowski: yeah, there's a lot of those now
[18:11] <sil2100> Let me help you
[18:11] <pstolowski> sil2100, thanks
[18:14] <jibel> Saviq, we can start testing 14?
[18:18] <sil2100> pstolowski: done
[18:18] <pstolowski> thanks sil2100 !
[18:59] <Saviq> jibel, sorry, was otp, yeah, let's test in parallel
[19:00] <jibel> Saviq, rvr is on it and I just installed the silo
[19:00]  * Saviq does in devel-proposed then
[19:00] <jibel> we are testing on top of rc not rc-proposed
[19:00] <Saviq> ack
[19:11] <robru> Saviq: I don't think private silos makes any sense. it's gonna be public when you release it to ubuntu anyway
[19:14] <jibel> robru, there may be some code that you don't want to be public before it's released
[19:15] <Saviq> robru, yeah, but the thing is you want to keep it under wraps for as long as possible
[19:17] <robru> Saviq: jibel: k, well it's not something I'm going to be able to do anytime soon. the ppas just are public. i won't be able to implement this until we have ephemeral ppas which is probably 6 months away.
[19:17] <Saviq> robru, sure, just an idea
[19:25] <robru> dobey: charles: https://requests.ci-train.ubuntu.com/#/ticket/507 hasn't moved since the 13th, you guys still using that one?
[19:25] <dobey> robru: we're sprinting this week and i didn't get a chance to poke at the error from citrain
[19:26] <dobey> robru: but yes,, that still needs landing.
[19:26] <robru> dobey: ok no worries.
[19:30] <charles> robru, talking it over with dobey here, I think we should kill 507 after all. Marking as abandoned
[19:30] <charles> robru, thanks for the headsup
[19:30] <robru> charles: oh, thanks
[19:31] <robru> Trevinho: https://requests.ci-train.ubuntu.com/#/ticket/685 hasn't moved since the 13th, can you poke the SRU team to get that moving?
[19:32] <robru> jgdx: https://requests.ci-train.ubuntu.com/#/ticket/692 hasn't moved since the 13th, you still using that one?
[19:37] <robru> jgdx: lol https://requests.ci-train.ubuntu.com/#/ticket/692 this has needed a rebuild since november 30th
[19:40] <dobey> robru: can i force re-run of an autopkgtest on a specific arch for ci train?
[19:40] <robru> dobey: heh, we were just sprinting to enable that feature but it's not out yet. you'll have to ask pitti
[19:40] <Saviq> jibel, rvr, so one unfortunate result is that camera sometimes restarts when the content hub's done with it
[19:41] <dobey> robru: only pitti?
[19:41] <Saviq> because it's a race between being stopped, suspended, resumed, crashed, whatnot
[19:41] <rvr> Saviq: :(
[19:41] <robru> dobey: I'm not sure who else, but definitely pitti. just a handful of people have ssh into the autopkgtest system to do retries curently
[19:42] <Saviq> jibel, rvr, content hub really needs to start using prompts instead of just switching between apps, as we either break normal app behaviour or the content hub one
[19:42] <Saviq> IMO content hub should not be killing the app at all when it's done with it
[19:43] <dobey> ok
[19:43] <jibel> Saviq, I saw that on previous builds too
[19:44] <jibel> but it was pretty rare
[19:44] <Saviq> indeed
[20:17] <michi> trainguards: Could someone help with assigning a silo please?
[20:17] <michi> Need one for ticket 917
[20:17] <robru> michi: which one?
[20:18] <robru> michi: ok you got 46
[20:18] <michi> Beaut, thank you! :)
[20:18] <robru> michi: you're welcome
[20:22] <jibel> Saviq, did you find anything with the silo?
[20:22] <jibel> other than the app reopening
[20:22] <Saviq> jibel, nope, worked fine
[20:23] <jibel> Saviq, so I think it's good to publish.
[20:23] <Saviq> jibel, yeah, let me get someone to sanity-review
[20:24] <jibel> Saviq, can you approve it so propose migration can do its job
[20:24] <Saviq> jibel, right, doing
[20:24] <jibel> otherwise I cannot approve it
[20:25] <jibel> hm, actually I can. I'm pretty sure I couldn't last time I tried
[20:26] <robru> jibel: btw finally got queuebot fixed so it pings qa status properly again
[20:27] <robru> jibel: bileto will preserve an 'Approved' or 'Failed' value but if set to N/A, Required, or Ready it'll override the value with what it thinks is correct based on if the silo targets vivid overlay or not
[20:27] <jibel> robru, thank you very much
[20:28] <robru> jibel: you're welcome
[21:20] <jibel> robru, can we publish silo 14 before britney is done? it's running u8 tests which will fail
[21:20] <jibel> there is no point in waiting
[21:21] <jibel> Saviq, ^
[21:56] <robru> jibel: Saviq: it's also running qtmir which can pass. but generally yeah you can publish even if it says fail
[21:57] <robru> ... for now
[22:00] <sil2100> Ok, I'm publishing in that case
[22:01] <sil2100> Saviq: branches need approval!
[22:02] <sil2100> Saviq: all three branches please
[22:04] <sil2100> Eh, ok, I'll take this on me
[22:04] <sil2100> Saviq, jibel: approving the branches since we need this landed...
[22:11] <Saviq> sil2100, jibel, they're being reviewed now, we're worried the security fix isn't enough so we might need a follow up
[22:12] <Saviq> sorry guys, we're doing our best here, not enough hands
[22:15] <sil2100> Saviq: ok
[22:16] <sil2100> Saviq: I'll be doing the copies to snapshot and rc respins tomorrow
[22:16] <sil2100> Goodnight guys
[23:49] <robru> ugh, 'publish failed' cleared the lander signoff