[06:25] <robru> Bloody hell
[08:55] <Saviq> jibel, sil2100, morning, we've got a fix for bug #1578665 - what's the process of getting it in as a blocker fix these days?
[08:59] <jibel> Saviq, it's already in the list
[08:59] <jibel> Saviq, now we need a silo with the fix
[09:00] <jibel> Saviq, blockers are tagged lt-blocker and targeted to OTA11
[09:03] <sil2100> Saviq: just prepare a normal silo, we still didn't snapshot or anything
[09:03] <sil2100> So trunk is OTA-11
[09:06] <Saviq> ack
[11:29] <Mirv> morphis: https://requests.ci-train.ubuntu.com/#/ticket/1351 claims there should be urfkilld in addition to urfkill, but only urfkill is there. is it ok to publish urfkill only?
[11:30] <morphis> Mirv: ah, package urfkill includes urfkilld binary, so yeah
[11:30] <morphis> sorry for the mis-wording :-)
[11:30] <Mirv> morphis: ok, I'll fix the train and publish
[11:34] <kdub> sil2100, seems ota didn't open yet, would it be possible to copy the packages in silo 31 into silo 69 to unblock mir building and testing?
[11:34] <sil2100> kdub: hey! Indeed, ok, let's maybe do it differently - just add a dependency to the PPA on the other silo PPA, this should just work (with a big warning not to forget removing that depenendency)
[11:36] <kdub> sil2100, alright, I will remind you to remove the dep, and then rebuild the packages before landing 69
[11:36] <kdub> thanks!
[11:43] <sil2100> kdub: done - you could try rebuilding I suppose
[11:44] <kdub> thanks sil2100
[14:44] <jdstrand> sil2100: hi! what is the status of the emulator with xenial overlay?
[14:45] <jdstrand> sil2100: actually, I'm curious about vivid too
[14:45] <sil2100> jdstrand: hey! We didn't check xenial recently, so not sure
[14:45] <sil2100> jdstrand: the vivid emualtor got promoted to stable, at least the one for OTA-10.1
[14:45] <sil2100> There should be an emulator for OTA-11 as well
[14:45] <jdstrand> sil2100: oh nice! :)
[14:46] <sil2100> jdstrand: look into the stable/ubuntu channel, you should find it there :)
[14:46] <jdstrand> I'll give the xenial one a go and report back
[14:50] <jdstrand> hmm, actually I don't know how to generate a xenial image
[14:50] <sil2100> jdstrand: use the staging channel
[14:50] <jdstrand> sil2100: what channel should I use for xenial emulator?
[14:50] <jdstrand> ok
[14:50] <jdstrand> thanks
[14:50] <sil2100> https://system-image.ubuntu.com/ubuntu-touch/staging/ubuntu/ for instance
[14:50]  * jdstrand uses ubuntu-touch/staging/ubuntu
[14:51] <jdstrand> perfect, thanks!
[14:51] <sil2100> Yeah ;)
[14:51] <sil2100> Thanks for looking into that!
[14:52] <jdstrand> well, that was fast
[14:52] <jdstrand> Device generic_x86 not found on server https://system-image.ubuntu.com channel ubuntu-touch/staging/ubuntu
[14:53] <jdstrand> I just used: ubuntu-emulator create touch.xenial --arch=i386 --channel=ubuntu-touch/staging/ubuntu --password=0000
[16:44] <rvr> sil2100: Payment screen is still un-translated
[16:45] <rvr> sil2100: So I guess my fears where right. Payment screen is not using pay-service as context.
[16:46] <rvr> The pay-service.mo files are in the image and contain the strings.
[16:56] <sil2100> rvr: really? We didn't have a new image with the new langpack yet
[16:56] <sil2100> rvr: I mean, we had the exports yesterday but I did a langpack run only today in the afternoon
[16:57] <sil2100> So in theory the latest image should not have pay-service.mo
[16:57] <sil2100> rvr: what image are you using?
[16:57] <sil2100> Maybe someone kicked a new one in the meantime..?
[16:57] <rvr> Oh wait
[16:58] <rvr> I was checking my phone with stable
[16:58] <rvr> ETOOMANYDEVICESINMYDESKTOP
[16:58] <sil2100> rvr: ;) If you have a free device for testing, you could try updating the -es langpack from the overlay and check real quick
[16:58] <sil2100> This would be faster I suppose than kicking a new image and waiting for it to build
[16:59] <rvr> sil2100: Ah, cool, I'll check
[16:59] <sil2100> rvr: thanks!
[17:04] <rvr> marcustomlinson: jibel: Silo 56 approved
[17:04] <marcustomlinson> rvr: awesome thanks!
[17:07] <dbarth> jibel: o/ silo 76 coming your way with oxide 1.14.8 with security fixes AND a nice DGU bug fix as well
[17:08] <dbarth> 1.14.8 is a stable release, same as 1.14.7 and previous which have been in use for a while
[19:29] <jdstrand> sil2100: ok, trying to test silo 15's xenial packages. I reflashed a mako with staging (xenial) but I can't set the passcode ('Could not set security display hint'), so I can't enable developer mode. I also can't enter a wifi password
[19:29] <jdstrand> sil2100: is this known?
[19:29] <jdstrand> jibel: ^
[19:29] <sil2100> jdstrand: possibly related to the policykit-unity8 landing that happened
[19:30] <sil2100> jdstrand: it's a known thing, we had the same regression in vivid but reverted, we're busy with OTA-11 so we didn't work on this in xenial yet
[19:30] <jdstrand> sil2100: that is what I was thinking. is there something I can do on the device to undo that? can a flash with a different rev?
[19:30] <sil2100> Yeah, let me quickly find you the rev that should be free of this change
[19:31] <jdstrand> sil2100: I'm asking cause pmcgowan ask that I try to get bug #1569582 in by friday
[19:31] <jdstrand> (for vivid overlay)
[19:31] <sil2100> jdstrand: https://system-image.ubuntu.com/ubuntu-touch/staging/ubuntu/mako/version-7.json <- try this version maybe
[19:31] <sil2100> The rootfs was built before the seed change happened, so I guess it should be okay
[19:32] <jdstrand> but we obviously need it for xenial, so I prepared those packages, but I can't claim I tested the silo if I haven't done xenial
[19:32] <jdstrand> ok, thanks
[19:32] <sil2100> jdstrand: thanks for looking into that!
[19:32] <sil2100> +1 on checking xenial, it's our big thing for the nearest days
[19:32] <jdstrand> hrmm, I can't flash cause I don't have adb
[19:34]  * jdstrand wonders if 'passwd' in a terminal will do what I need
[19:35]  * jdstrand is flashing
[20:24] <ToyKeeper> sil2100, robru: Do you see anything here which would keep it from showing up in the QA queue?  https://requests.ci-train.ubuntu.com/#/ticket/1396
[20:25] <sil2100> ToyKeeper: automated sign-off
[20:25] <sil2100> The autopkgtests are probably still running
[20:25] <ToyKeeper> awe seems to be EOD'd but he didn't get it quite far enough for QA before leaving.
[20:25]  * sil2100 goes EOD
[20:25] <ToyKeeper> :)
[20:26] <davmor2> ToyKeeper: he might of hit the trigger on the silos but then autopackage test not finished their run
[20:26] <robru> ToyKeeper: yeah you only approved it 20 minutes ago, takes usually an hour for automated signoff to happen, plus however long it takes for the autopkgtests if any
[20:27] <ToyKeeper> He did all his tests then started a rebuild to change the version number, and left.  :(
[20:27] <ToyKeeper> I assume those tests still apply, but it caused the ticket status to revert.
[20:28] <ToyKeeper> Anyway, thanks.  :)
[20:29] <pat_> ToyKeeper, from earlier...
[20:29] <pat_> once we finish testing and I kick off the silo rebuild ( to strip the ~testX suffix from the version ),
[20:29] <pat_> from awe
[20:30] <pat_> I forwarded email
[20:30] <ToyKeeper> pat_: That's why I kicked it manually.  :)
[20:31] <pat_> excellent
[20:31] <ToyKeeper> (wasn't sure what it was waiting on after that though)
[20:31] <ogra_> "kicked manually" ... sounds quite contradicting :)
[20:35] <pat_> heh
[20:39] <robru> ToyKeeper: strictly speaking the tes manual testing happens on the binary package and so a rebuild invalidates all the testing, however we don't usually require a complete retest on a simple version number change, just a smoke test to make sure nothing exploded during the build
[20:40] <robru> ToyKeeper: it's one of those things where, IN THEORY changing the version number can't break anything but in practice builds sometimes fail subtly, so it's best to double check
[20:40] <ToyKeeper> ogra_: ... kicked pedually?
[20:41] <ToyKeeper> robru: That's why I'm a little grumpy.  Usually it's build-then-test, not test-then-build.
[20:42] <robru> ToyKeeper: indeed
[20:42] <ToyKeeper> OTOH, it's also a blocker which needs to land ASAP.
[20:43] <ToyKeeper> ... and it looks like it worked.  Krillin standby went back down by 90%.  :)
[20:45] <ogra_> ToyKeeper, hah !
[21:00] <pat_> ToyKeeper, thats great, my arale has died every night this past week
[21:00] <ToyKeeper> pat_: Arale doesn't benefit as much.  Standby should at least double, but it won't go up by 10X like on krillin.
[21:01] <pat_> ToyKeeper, still goodness, why so much more on krillin?
[21:01] <ToyKeeper> (arale's standby w/ wifi has always been a bit power-hungry)
[21:01] <pat_> ah
[21:01] <pat_> but I usually got 3-4 days and now not 1 so will see
[21:01] <ToyKeeper> Seems to be an upstream kernel issue, I think.  Arale doesn't sleep well with wifi on.
[21:30] <robru> ToyKeeper: good news: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-077/excuses.html your autopkgtests have started
[21:30] <ToyKeeper> :)
[23:52] <ToyKeeper> Wow, it really does take a while for the automated parts to run.