[06:59] <Mirv> robru: funny ^ , see http://people.canonical.com/~ubuntu-archive/packagesets/xenial/ubuntu-qt-packages - is there some outdated permission data read from somewhere?
[07:00] <Mirv> I was able to ack webbrowser-app dual landing packaging changes earlier though
[07:01] <robru> Mirv: just calls checkUpload, should include PPU as far as i know
[07:01] <Mirv> robru: yes, and like I said I newly was able to ack + publish webbrowser-app which comes from the same PPU. maybe something "vivid only" specific?
[07:02] <Mirv> I'm not sure if the PPU means I don't have permission to upload those packages to earlier Ubuntus...
[07:02] <robru> Mirv: not as far as I'm aware, it treats stable overlay same as distro. Unless your PPU is only for xenial or something
[07:03] <Mirv> robru: well it's not specifically only for xenial but I was thinking that the packageset url has "xenial" in it
[07:03] <robru> Mirv: code was approved by Steve and Colin, so double check that your PPU is correct
[07:03] <Mirv> robru: sure the PPU is correct, it reads "oxide-qt" in there
[07:03] <Mirv> anyway, no big problem
[07:04] <Mirv> just interesting
[07:08] <robru> Mirv: yeah, dunno, sorry. maybe try running it with DEBUG and mail me the log, I'll look into it tomorrow.
[07:20] <Mirv> robru: thanks, no worries, I'll look if I spot something similar in the future too
[07:21] <robru> Mirv: oh try just copying the packages by hand. If your PPU is correct that should work, and train will notice and track it anyway
[07:22] <Mirv> robru: that's true too, train works well in that case as well. anyway, sil2100 can also publish it, there's no hurry.
[07:22] <Mirv> robru: but that's vivid only silo so that's why the copying would work anyway regardless of PPU.
[07:23] <robru> Mirv: oh OK i assumed it was dual without checking
[07:23] <robru> Mirv: in that case even i can copy it to overlay PPA ;-)
[09:53] <Mirv> davmor2: jibel: can either of you transform a normal JPG / photo taken with non-Ubuntu device to phone's Pictures/com.ubuntu.camera folder?  for me the photo is incorrectly rotated 90 degrees both in photo roll and gallery. I realized this when I started wondering why so many of my old photos transferred from elsewhere need rotating in gallery
[09:53] <Mirv> ...or is this a known bug there's a bug already for. OTA-9.
[09:54] <Mirv> Bq E4.5 in question
[09:55] <Mirv> I think this is because of some recent fix to camera, and not something that always was there
[09:59] <Mirv> ah, lpotter already filed bug #1541210
[09:59] <ubot5`> bug 1541210 in gallery-app (Ubuntu) "Photos are displayed as 90 degree rotated in photo roll" [Undecided,Confirmed] https://launchpad.net/bugs/1541210
[10:01] <davmor2> Mirv: not sure I follow, for me the top is always displayed at the top whether the top is landscape or portrait
[10:02] <Mirv> davmor2: if I transfer a portrait photo taken with my normal camera to Bq, it's showed rotated 90 degrees
[10:02] <Mirv> and not in portrait
[10:02] <Mirv> davmor2: and it seems it also affects photos taken on Turbo, behaving similarly to transferring photos from external source
[10:02] <davmor2> Mirv: oh okay let me try that then
[11:04] <Mirv> jibel: davmor2: sil2100: I would respectfully ask you to put https://requests.ci-train.ubuntu.com/#/ticket/944 manually in QA queue. The overrides are now implemented, and retries have been made fixing all other britney failures than kwin, which is caused by Train using all of proposed for testing and new libhybris breaking the tests. pitti allowed me to quote him on his blessing on this issue.
[11:05] <Mirv> we'd apparently need to not use all of proposed for our britney testing in order to not be caught in situations like this for silos
[11:05] <Mirv> there's another three bug fixes waiting for qtdeclarative after this landing
[11:16] <cjwatson> Mirv: PPUs are series-specific, yes.  You'll need to ask the DMB to extend that to vivid to make this work properly in the future
[11:16] <cjwatson> <cjwatson@niejwein ~>$ edit-acl -p timo-jyrinki -S xenial -s oxide-qt check
[11:16] <cjwatson> Timo Jyrinki (timo-jyrinki) can upload oxide-qt to Xenial/Release
[11:16] <cjwatson> <cjwatson@niejwein ~>$ edit-acl -p timo-jyrinki -S vivid -s oxide-qt check
[11:16] <cjwatson> Timo Jyrinki (timo-jyrinki) cannot upload oxide-qt to Vivid/Release
[11:19] <Mirv> cjwatson: thanks again for reading the backlog :) that's no big issue, I think I'll rather aim towards core dev rights next.
[11:25] <Mirv> bug #1541334 filed for the remaining britney issue
[11:25] <ubot5`> bug 1541334 in Bileto "Do not run britney on all of proposed" [Undecided,New] https://launchpad.net/bugs/1541334
[13:00] <davmor2> Mirv: silo 23 is this meant for ota9.5 there aren't any mp or bugs attached to it
[13:02] <davmor2> Mirv: nevermind found them
[13:17] <Mirv> davmor2: no, ota10
[13:17] <jibel> Mirv, is anything fixing kwin in xenial because even if these silos are approved they'll be blocked in xenial?
[13:17] <jibel> s/anything/any one/
[13:21] <Mirv> jibel: pitti can hint it so that it doesn't try to test it together with hybris. also, I believe morphis got a promise from Kubuntu folks they'd be fixing kwin too.
[13:22] <morphis> Mirv: I got
[13:22] <Mirv> right, hopefully that happens soon too
[13:22] <morphis> Mirv, jibel, pitti: yofel over in #kubuntu-devel said he will fix that
[13:27] <jibel> morphis, it's a regression, so an hint is not the solution.
[13:27] <jibel> morphis, okay
[13:27] <jibel> first reply was for Mirv
[13:29] <morphis> jibel: its not a regression, they are using APIs libhbris never exposed as stable
[13:29] <morphis> jibel: however they are dropping the build-dep on that
[13:30] <jibel> morphis, okay, it's a regression in the sense that a package that used to build will now fail. But I understand it's under control :)
[13:30] <morphis> yeah :-)
[13:30] <morphis> jibel: I am close to make those APIs really private
[13:30] <morphis> but that still needs some time ...
[13:35] <Mirv> jibel: it's a solution for letting others than libhybris in
[13:36] <Mirv> jibel: autopkgtests work so that they take a couple of involved packages and test them together. sometimes it's tricky because one of the proposed packages causes a failure but the other one doesn't.
[13:36] <Mirv> but yeah in any way it's in control
[14:10] <kgunn> trainguards do you have magic powers to target build vivid-arm64 only?
[14:10] <kgunn> it's the only failure i got on
[14:10] <kgunn> https://requests.ci-train.ubuntu.com/#/ticket/942
[14:17] <Mirv> kgunn: retried, check the logs as they proceed
[14:19] <Mirv> kgunn: note that your ticket also says "Needs rebuild due to new commits (mir/xenial)"
[14:19] <Mirv> probably duflu's typo fix 7h ago
[14:37] <kgunn> Mirv: dang it..duflu....always touching
[14:59] <dobey> trainguards: hi can i get retries for https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/8871609 and https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+build/8871611 please?
[15:08] <cjwatson> dobey: done
[15:11] <dobey> cjwatson: thanks
[16:44] <Saviq> robru, uh oh https://ci-train.ubuntu.com/job/ubuntu-landing-051-1-build/72/console ?
[16:45] <robru> Saviq: on it
[16:49] <robru> Saviq: ok try again
[16:49] <Saviq> robru, looks better, thanks
[16:50] <robru> Saviq: heh, sorry for breaking it ;-)
[16:50] <Saviq> nw
[16:56] <Saviq> robru, btw, filed bug #1540860 yesterday, I know not trivial, but maybe somewhere down the line
[16:56] <ubot5`> bug 1540860 in CI Train [cu2d] "Should error out if a branch's prerequisite isn't in the list of MPs" [Undecided,New] https://launchpad.net/bugs/1540860
[16:57] <robru> Saviq: yeah I have some questions about that, but a bit busy at the moment
[16:57] <Saviq> ack
[18:41] <alexabreu> robru, ping
[18:43] <robru> alexabreu: pong
[18:43] <alexabreu> robru, I'd need help for 2 silos ...
[18:43] <robru> What's up?
[18:43] <alexabreu> robru, silo 16 not sure what's failing ...
[18:44] <robru> alexabreu: what aren't you sure about?
[18:45] <alexabreu> robru,  the auto signoff failure ...
[18:45] <robru> alexabreu: did you look at the excuses page?
[18:48] <alexabreu> robru, yes ... https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-016/excuses.html ... unity8 is marked as regressing for i386 ...
[18:48] <robru> alexabreu: yeah. So you'd need somebody familiar with unity8 to dig into what failed there.
[18:49] <alexabreu> robru, yeah ... I was wondering if it was a red herring
[18:50] <robru> alexabreu: I'm not really familiar with unity8 so it's hard to say. In theory your silo broke unity8.
[18:50] <alexabreu> robru, also for silo 47 ... which fails building for https://ci-train.ubuntu.com/job/ubuntu-landing-047-1-build/lastBuild/console
[18:51] <alexabreu> robru, ok I'll investigate
[18:51] <dobey> hmm, where was that mail about the autopkgtest retry stuff
[18:51] <alexabreu> it shouldn't have ... broken unity8)
[18:51] <alexabreu> but ok
[18:52] <robru> dobey: it's not implemented for silos yet. In -proposed there's just a link to click in excuses.html
[18:52] <dobey> oh
[18:54] <dobey> robru: so i have ping pitti i guess? have trainguards still not been given enough permissions to retry tests?
[18:54] <robru> alexabreu: for silo 47 there's a manual upload of that package in Ubuntu that wasn't landed on trunk. You need to find that version in launchpad, and check the diff. If the diff is just a no-change rebuild then you can ignore it and force the build. If the diff has any substance whatsoever, you need to commit it to trunk, otherwise your silo will regress it
[18:55] <alexabreu> robru, mmmh weird, ack thx
[18:55] <robru> dobey: there are no plans to give trainguards retry permissions for autopkgtests. The retries are based on upload rights
[18:55] <kenvandine> anyone know the magic words to run autopkgtests locally for armhf?
[18:55] <alexabreu> robru, is there a way to retrigger britney for silo 16?
[18:55] <dobey> kenvandine: you don't have enough goats
[18:55] <kenvandine> adt-buildvm-ubuntu-cloud downloads the image but never boots it in qemu
[18:55] <alexabreu> just to make sure
[18:56] <kenvandine> dobey, i guess... it's driving me nuts :)
[18:56]  * kenvandine looks for more goats
[18:56] <robru> alexabreu: you can ask pitti to rerun the autopkgtest
[18:57]  * dobey wonders how to get this test rerun, without depending on one single person in germany
[19:02] <robru> dobey: well pitti is online right now because he's sprinting with me. Maybe ask him who else has access, i don't know
[19:26] <kgunn> trainguards i'm having a problem b/c of a mistake i made, so my u-s-c branch in
[19:26] <kgunn> https://requests.ci-train.ubuntu.com/#/ticket/942
[19:27] <kgunn> is 0.4 but the packages showing up in the ppa are 0.5
[19:27] <kgunn> b/c i had "accidently" used an incorrect branch there
[19:27] <kgunn> not sure, but can the u-s-c pkgs just be deleted and then can i rebuild to get 0.4 ?
[19:27] <kgunn> or should i abandon and just start over?
[19:27] <kgunn> happy to abandon
[19:28] <robru> kgunn: yeah you can never go backwards with version numbers in a PPA, you need to abandon and reassign the same ticket (don't make a new ticket)
[19:29] <kgunn> robru: uh, how do i "reassign" the same ticket?
[19:29] <robru> kgunn: you abandon it... and then assign it again
[19:30]  * kgunn tries, with raised eyebrow
[19:33] <robru> kgunn: each assign assigns a random ppa so you should get a different ppa. if not just abandon again and assign again
[19:33] <robru> there are only 3 available so chances of getting the same one again are high
[19:42] <kgunn> ok, that seemed to work
[19:57] <charles> bah
[20:47] <alesage> robru, if you have a minute I'm stymied by this dependency-resolution snafu, wonder if you have a second to look at http://paste.ubuntu.com/14871365/
[20:48] <alesage> robru, (all the way at the bottom)
[20:49] <robru> alesage: one sec
[20:53] <robru> alesage: I'm not sure what's going on there but the key clue seems to be "E: Packages need to be removed but remove is disabled."
[20:53] <robru> alesage: where are you even seeing that?
[20:53] <robru> like that's not a train message
[20:54] <alesage> robru, I've tricked you into diagnosing one of our internal Jenkins logs :/
[20:54] <robru> alesage: oh is this jenkaas stuff?
[20:54] <alesage> robru, well adt-run stuff which fiddles with the overlay, was wondering if a new packaging kink got in somehow
[20:55] <alesage> robru, here are our instructions FWIW http://paste.ubuntu.com/14871427/
[20:55] <robru> alesage: not really sure, sorry. I'd look into "enabling remove" and also that other message about updating the testbed.
[20:55] <alesage> robru, ack thanks for your time
[20:56] <robru> alesage: you're welcome
[21:11] <dobey> robru: hmm, does silo britney not update status if tests are manrually re-run?
[21:12] <dobey> hmm, seems the re-run tests is hung
[21:13] <dobey> especially since typical duration is ~30 min
[21:13] <dobey> and it's been running for 1.5 hrs
[21:24] <dobey> lol, one has "Running for" that keeps increasing, because it's hanged. another has "Running for" that somehow keeps decreasing
[21:25] <dobey> and appears to be hanged, but not entirely sure
[21:25] <dobey> ah no, the ever decreasing one is gone now after another page refresh
[21:26] <dobey> http://autopkgtest.ubuntu.com/running.shtml#pkg-unity-scope-click <- seems to be hanged and not going anywhere though :(
[21:54] <robru> dobey: britney runs every ~35 minutes and should pick up whatever tests are running
[21:54] <robru> dobey: any problems you see in running.shtml should be sent to pity, that's not my are
[21:55] <dobey> ok
[21:55] <dobey> robru: well that test has been running for over 2 hours now, i'd expect britney to have changed status to "running" and show "in progress" on excuses page by now, no?
[21:56] <robru> dobey: what ticket?
[21:57] <dobey> https://requests.ci-train.ubuntu.com/#/ticket/780
[21:57] <dobey> excuses still says regression and points to the old failed build
[22:12] <robru> dobey: of course it's unity8
[22:12] <robru> dobey: I dunno dude, pitti and I are neck-deep in britney issues, unity8 is causing a lot of problems for a lot of people
[22:12] <dobey> robru: unity8?
[22:13] <robru> dobey: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-041/excuses.html
[22:13] <dobey> robru: unity8 isn't the test or the trigger for this one.
[22:13] <dobey> robru: oh i didn't even notice unity8 there yet
[22:14] <dobey> robru: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-041/excuses.html
[22:14] <robru> oh the othe one's different
[22:14] <dobey> robru: i'm looking at unity-scope-click
[22:15] <dobey> i think the real issue is in autopkgtest though or something; it's where all the python traces are coming from :-/
[22:15] <dobey> or at least, it's timing out waiting for adt-virt-lxc-fnquxu
[22:16] <robru> dobey: yeah you should file some bugs against britney and/or autopkgtest
[22:16] <dobey> ok
[22:21] <dobey> robru: i'll leave you alone for now. i gotta go anyway :)
[22:21] <robru> dobey: yeah sorry, drowning in britney issues right now, not sure what yours is about. i'm hoping one fix fixes everything
[22:24] <dobey> robru: no worries. just have lots of urgent things and trying to get the big stuff off to QA so I can stop worrying about it and having to rebuild it all the time,
[22:24] <robru> dobey: oh, you can probably get a qa person to override the failure and get it in the qa queue anyway
[22:26] <dobey> robru: yeah, but i'm getting tired of having to do that too :)
[22:26] <dobey> i guess i'll ask jibel in the morning
[23:17] <kgunn> trainguards ok, one more time, can someone kick just arm64-xenial build for https://requests.ci-train.ubuntu.com/#/ticket/942
[23:17] <kgunn> seems to have timed out on both
[23:17] <robru> kgunn: on it
[23:18] <robru> kgunn: ok done
[23:20] <kgunn> ta