=== _salem is now known as salem_
=== salem_ is now known as _salem
[03:51] <michi> robru: still around?
[03:59] <michi> trainguards: Anyone around who can help with publishing a silo?
[04:00] <robru> michi: i'm around but i can't publish anything. did you try it yourself?
[04:01] <michi> Yes. Tells me that the status is bad.
[04:01] <robru> michi: which one?
[04:01] <michi> Presumably because of the failed s390x build
[04:01] <michi> silo 26
[04:01] <michi> Problem is that I need to put another MR into a new silo.
[04:01] <michi> But to do that, I need the 26 to merge into trunk first.
[04:02] <robru> michi: ok, well if you publish this it's just going to get stuck in proposed because you're not allowed to regress on arches
[04:02] <michi> We are not regressing on arches.
[04:02] <robru> michi: why can't the mr that fixes s390x just go in here
[04:02] <michi> We have never published for IBM
[04:02] <robru> michi: the train would not report s390x failure unless it was a regression
[04:02] <michi> We can’t make it work on 390
[04:02] <michi> Because the gstreamer codecs are broken.
[04:02] <robru> michi: then you need to get an archive person to delete the existing s390x binary on that arch
[04:03] <michi> The train just builds for 390x whether we like it or not.
[04:03] <michi> There is no existing binary.
[04:03] <michi> There has never been a thumbnailer package for 390
[04:03] <robru> michi: yes it does: https://launchpad.net/ubuntu/+source/thumbnailer/2.3+16.04.20151102.2-0ubuntu1
[04:03] <robru> michi: https://launchpad.net/ubuntu/+source/thumbnailer/2.3+16.04.20151102.2-0ubuntu1/+build/8382530
[04:04] <robru> the train is detecting this binary and reporting the regression
[04:04] <michi> What a gooddam bloody screw-up :(
[04:04] <robru> michi: you need to either fix it or delete the binary
[04:04] <michi> Who can I delete the binary.
[04:04] <michi> We don’t want to support 390.
[04:04] <michi> It doesn’t make sense.
[04:04] <robru> michi: anybody in #ubuntu-release
[04:04] <michi> OK, thank you!
[04:04] <robru> you're welcome
[04:04] <michi> is there a special alert alias there I should use, such trainguards here?
[04:05] <robru> michi: no not really. just ask and if nobody responds try pinging colin or adam
[04:05] <michi> cool, thank you!
[04:05] <robru> michi: you're welcome
[04:05] <robru> michi: after the binary is gone, the status should update in ~15 minutes, then you should be able to publish
[04:05] <michi> That would be great, thanks!
[04:06] <michi> robru: Is that adam or adam_g?
[04:14] <robru> michi: infinit y
=== chihchun_afk is now known as chihchun
[05:31] <Mirv> michi: I can help with the 783
[05:31] <michi> Mirv: Thanks!
[05:31] <michi> I’m currently reflashing the phone to do a smoke test on silo 26
[05:32] <michi> Alternatively, if you could take a quick look, that would be awesome.
[05:32] <michi> No need to go through the whole test plan.
[05:32] <michi> All it needs is a quick test to see that you still get thumbnails.
[05:32] <michi> It’s just to make sure that the binaries that were just built aren’t broken in some weird way.
[05:32] <michi> There are no code changes.
[05:33] <Mirv> michi: oh was there a rebuild?
[05:33] <michi> I’ve changed debian/rules to lie about s390x test failures.
[05:33] <michi> Yes, because of the failing s390x tests.
[05:33] <michi> It’s a loong story.
[05:33] <michi> ^ That’s weird.
[05:33] <michi> I didn’t try to publish jus now.
[05:34] <Mirv> michi: I updated the packaging diff:s to be sure, with that
[05:34] <Mirv> michi: ah I see the diff now. well I'd need to flash too since my mako is on xenial so you'd be faster in smoke testing
[05:34] <michi> Not sure what’s happening.
[05:34] <michi> I flashed with —bootstrap
[05:34] <michi> It rebooted into recover.
[05:34] <michi> recovery
[05:35] <michi> Normally, while flashing, it has an orange rotating ubuntu log.
[05:35] <michi> logo.
[05:35] <michi> Now, I’m seeing a white non-rotating logo.
[05:35] <michi> Christ...
[05:35] <michi> I think the download of the image failed half-way through.
[05:36] <michi> And it rebooted with a partial image.
[05:36] <michi> I may not be able to get this to work at all.
[05:36] <michi> I’ve been having ongoing problems with flaky USB connection to teh phone.
[05:36] <michi> Mirv, if you could give it a quick sanity check, I’d be eternally in your debt.
[05:36] <michi> I’ve been trying to get this bloody silo out the door for ages now.
[05:37] <Mirv> michi: ok, will take a while but I assume I don't see thumbnails disappearing with the silo so I'll then publish it eventually
[05:37] <michi> That would be great.
[05:37] <michi> right now, my phone is briked.
[05:37] <michi> bricked.
[05:38] <michi> I need this to land in trunk because I have one more change that needs to go in for ota 9.
[05:38] <michi> And I can’t land that change without the current silo 26 ones.
[05:43] <Mirv> michi: flashing. meanwhile, can you check if https://code.launchpad.net/~thomas-voss/media-hub/enable-dual-landings/+merge/278270 looks ok to you? sil2100 is worried about the lack of symbol files, is the abi-compliance-check route supposed to be used manually by the developer basically? I see the shlibs magic is working correctly in the resulting binary files.
[05:43] <michi> Mirv: I’ll have a look.
[05:43] <michi> I don’t know what Thomas has done
[05:43] <michi> We are running the compliance check from the unit tests, so they run every time anything is tested in s-jenkins or a silo.
[05:45] <Mirv> michi: right, thanks
[05:46] <Mirv> I'll check that and then either for such tests to be added or not
[05:47] <michi> Mirv: I managed to unbrick my phone at least.
[05:52] <michi> Mirv: I looked through the changes and pulled the branch too.
[05:52] <michi> I don’t think there is any abi-compliance check in the tree.
[05:52] <michi> At least, a grep for it comes up empty.
[05:56] <Mirv> michi: same here
[05:56] <michi> Well, that’s pretty much all I can say.
[05:56] <Mirv> 026 smoke tested, publishing
[05:57] <michi> No shlibs or symbols file, no abi-compliance-check
[05:57] <michi> \o/
[05:57] <michi> I owe you one!!!
[05:59] <Mirv> michi: :)
[05:59] <michi> I mean it!
[06:00] <michi> Next sprint, it’ll be a beer on me!
[06:00] <Mirv> michi: I assume you'll want to start on the next landing immediately? I can merge the silo and we would just need to manually monitor that there is no surprises in xenial proposed -> release migration
[06:00] <michi> Give me a few minutes.
[06:00] <michi> I spent the last two hours or so in headless chicken mode.
[06:00] <michi> I have an MR that is currently building on s-jenkins.
[06:01] <michi> Will make a new silo for that as soon as 26 merges into trunk.
[06:01] <michi> How long should that take do you think?
[06:01] <Mirv> michi: I was asking "do you want your trunk to be up-to-date immediately?" :)
[06:01] <Mirv> so you can say "yes"
[06:01] <michi> Yes please!!!
[06:01] <michi> :)
[06:02] <michi> Pretty please… :)
[06:04] <Mirv> michi: trunk is up-to-date, you can start your next build at any point. we do these exceptions at the last minute OTA landings and we just need to occasionally check http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#thumbnailer (when it appears) and https://launchpad.net/ubuntu/+source/thumbnailer/2.3+16.04.20160107-0ubuntu1 that it finds itself to the release pocket
[06:04] <michi> Awesome, thank you!
[06:05] <Mirv> no problem
[06:07] <michi> Working on that now.
[06:33] <michi> Mirv: silo 26 again
[06:34] <michi> This time, it’s a really small change, and it’s not necessary to go through the full test plan.
[07:17] <Mirv> michi: nice. if you get it tested the QA will be up in ca 2 hours.
[07:17] <michi> Mirv: Will be tested in about five minutes, as soon as the armhf build is published.
[07:17] <michi> Testing will take only a few minutes.
[07:18] <michi> I’ve been building and testing with packages created on my Chromebook already.
[07:18] <michi> I don’t expect any problems.
[07:35] <michi> Mirv: Marked as ready for QA. Thanks again for your help!
[07:55] <Mirv> Mirv: you're welcome!
=== sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? Please switch to Jenkins as a service: http://bit.ly/jenkins-docs | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: -
[08:34] <Mirv> tvoss: please check my and sil2100's comments at https://code.launchpad.net/~thomas-voss/media-hub/enable-dual-landings/+merge/278270
[08:35] <Mirv> either symbols files or abi-compliance-check should be used
[08:35] <tvoss> Mirv, sure, they haven't been used before, though. The symbol file on common was pointless
[08:41] <sil2100> We had symbol files on media-hub previously, they got removed at one point but still...
[08:41] <tvoss> sil2100, we never had symbols on media hub
[08:41] <tvoss> sil2100, I'm pretty sure :)
[08:41] <tvoss> sil2100, we had symbols on the common library, which is a bit pointless as there is like 1 symbol in there
[08:42] <sil2100> tvoss: oh, you're right! It was just in the common part
[08:43] <tvoss> sil2100, yup
[08:43] <tvoss> sil2100, so I'm happy to add those symbols, but can we please have that in the next iteration?
[08:43] <tvoss> sil2100, file a bug, assign to me
[08:43] <sil2100> tvoss: could you guys set the ABI-compliance-checker+shlibs bits as priority for the nextish release?
[08:44] <sil2100> tvoss: sure
[08:44] <tvoss> sil2100, sure
[08:45] <sil2100> Excellent
[08:51] <sil2100> tvoss: oh, and one more thing - I won't block on it this time since we're short on time, but if you could be more verbose in the commit-message of big changes like that it would be awesome ;)
[08:52] <tvoss> sil2100, well, it's just a merge :)
[08:52] <tvoss> sil2100, but I can try to be a little more verbose
[08:52] <sil2100> Like, you know, I know what 'Enable dual landings' means in this context, but others would like to know more from the changelog, e.g. that the control file is auto-generated, etc.
[08:52] <sil2100> For the future of course ;)
[08:59] <sil2100> tvoss: could I get https://code.launchpad.net/~phablet-team/media-hub/sync-trunk/+merge/280738 approved? :)
[09:00] <sil2100> Just this one approval and we can land
[09:08] <sil2100> Ouch!
[09:12] <davmor2> sil2100: what did you break now ;)
[09:51] <tvoss> hmmm, poor little publisher could use some love: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-012/+packages
[09:51] <tvoss> cjwatson, ^ :)
[09:51] <tvoss> cjwatson, also: a late happy new year
[10:00] <jibel> robru, hi, the results of autopkgtest attached to silo 34 seems unrelated to the packages in the silo. https://requests.ci-train.ubuntu.com/#/ticket/840 any idea why?
[10:09] <morphis> sil2100, Mirv: time for an silo upload?
[10:10] <Mirv> morphis: sure
[10:11] <sil2100> Mirv was faster ;)
[10:27] <bzoltan_> Mirv: sil2100:  It seems that there is something fishy with the ubuntuone-credentials autopkgtest
[10:27] <bzoltan_> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/armhf/u/ubuntuone-credentials/20160107_000316@/log.gz
[10:27] <bzoltan_> QSYSTEM: TestToken::testGetServerTimestampMuchEarlier() Error fetching server timestamp: ""
[10:28] <bzoltan_> ony on armhf .. on amd64 it can fetch the timestamp and so the test passes on amd64
[11:11] <Mirv> bzoltan_: since it's probably not UITK thing, dobey would be your contact for ubuntuone-credentials regarding that TestToken::testGetServerTimestampMuchEarlier
[11:11] <bzoltan_> Mirv:  the question is if it blocks the UITK package or not
[11:14] <Mirv> bzoltan_: well yes it currently blocks it in xenial. but you see (and dobey) that it has occasionally failed similarly in the past too http://autopkgtest.ubuntu.com/packages/u/ubuntuone-credentials/xenial/armhf/ - so I think you should ask pitti to rerun it
[11:14] <Mirv> for example it failed for the runs on 2015-12-10 and 2015-12-09
[11:15] <Mirv> correction, only the 2015-12-10 is a similar failure
[11:15] <Mirv> anyway, a rerun could yield more information about whether it always happens currently or not
=== _salem is now known as salem_
[12:31] <pstolowski> hello trainguards, may i ask for a rebuild of unity-scopes-api in silo 54 for i386 only? got a random failure
[12:32] <sil2100> pstolowski: on it
[12:32] <pstolowski> thx
[12:33] <sil2100> Done
[12:34] <cjwatson> tvoss: you'll have to be more specific - what am I looking at there?
=== chihchun is now known as chihchun_afk
[12:35] <pstolowski> thanks sil2100
=== popey_ is now known as popey
[12:54] <tvoss> cjwatson, oh, no worries :) it was just the publisher taking a really long time for the mir armhf packages
[12:56] <cjwatson> tvoss: All seems to have been normal around that time.
[12:59] <cjwatson> tvoss: Looks like it published two minutes after you asked here; the build was just unlucky enough to finish two minutes after the start of the (in this case, and reasonably typically) 10-minute cycle, so it was near-worst-case.
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
[13:03] <tvoss> cjwatson, oh okay, so pure perception on my side :)
=== alan_g is now known as alan_g|lunch
=== timp is now known as t1mp
[13:23]  * sil2100 is off for lunch
=== alan_g|lunch is now known as alan_g
=== lool- is now known as lool
[16:08] <robru> jibel: probably wasn't set as ready for qa yet? Britney only runs if the status is ready
[17:02] <jhodapp> sil2100, seems this is stuck in the proposed pocket: https://requests.ci-train.ubuntu.com/#/ticket/793
[17:41] <cjwatson> jhodapp:     * armhf: account-plugin-ubuntuone, camera-app-autopilot, indicators-client, libonline-accounts-plugin-dev, liboxideqt-qmlplugin, liboxideqtcore0, liboxideqtquick0, libunity-webapps-dev, libunity-webapps0, oxideqt-chromedriver, oxideqt-dbg, qtcreator-plugin-ubuntu, qtcreator-plugin-ubuntu-autopilot, qtdeclarative5-ubuntu-ui-extras-browser-plugin, qtdeclarative5-ubuntu-web-plugin, ubuntu-html5-container, ...
[17:41] <cjwatson> ... ubuntu-pocket-desktop, ubuntu-push-autopilot, ubuntu-sdk, ubuntu-sdk-libs, ubuntu-sdk-libs-dev, ubuntu-system-settings-online-accounts, ubuntu-touch, unity-chromium-extension, unity-scope-click, unity-webapps-service, unity8, webapp-container, webbrowser-app
[17:41] <cjwatson> says http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt regarding that silo
[17:42] <cjwatson> jhodapp: looks like this is because liboxideqtcore0/armhf depends: libmedia-hub-client4 and that soname changed
[17:42] <jhodapp> tvoss, ^
[17:42] <jhodapp> thanks cjwatson
[17:44] <cjwatson> jhodapp: narrowed down as follows: "rmadison -s xenial,xenial-proposed -S qtubuntu-media media-hub", observe which package names changed, then "reverse-depends libmedia-hub-client4" and "reverse-depends libmedia-hub-common4"
[17:44] <cjwatson> some cases are more complex but when it's just a soname change then this approach is usually enough
[17:46] <jhodapp> alex_abreu, can we get an update to liboxideqtcore0 for silo 22 since the soname changed for media-hub
[17:49] <alex_abreu> jhodapp, you should check w/ chriscoulson
[17:49] <jhodapp> alex_abreu, alright
[17:52] <dobey> robru: hey, is there a documented REST API that i can make oauth-signed requests to for CI train, to create new landings, get status, etc…?
=== alan_g is now known as alan_g|EOD
[19:02] <tvoss> jhodapp, not sure what I'm expected to do now :)
[19:26] <robru> dobey: the rest api is read only, unless you authenticate with sso
[19:30] <robru> dobey: http://bazaar.launchpad.net/~cupstream2distro-maintainers/bileto/trunk/view/head:/README.API
[19:30] <dobey> robru: sure. does it support OAuth in the Authorization: header though? If I have an OAuth token from SSO, that is
[19:31] <robru> dobey: no, the authentication is based on having a session token in a cookie, which the server sets when you log in to sso
[19:32] <dobey> robru: i guess i can submit an MP to bileto to add support for authenticating with OAuth instead of a cookie?
[19:37] <robru> dobey: what are you trying to do?
=== Saviq_ is now known as Saviq
=== plars_ is now known as plars
[19:42] <dobey> robru: not sure exactly yet, but had a thought to write some nice client app to notify me when my landings need rebuilt/etc…
[19:55] <robru> dobey: that's called "irc" :-P
[19:56] <robru> dobey: also as i said the rest api is read only when you're not authenticated so you can poll statuses without authenticating
[19:57] <dobey> robru: well, sure. but i can't create new requests without authenticating though.
[19:57] <robru> Yeah
[19:58] <dobey> anyway, was curious thought. i'll figure out what i want exactly after looking at the API and thoughts settle more :)
=== josepht` is now known as josepht
=== bdmurray_ is now known as bdmurray
[21:12] <dobey> trainguards: does a package already in xenial that's being converted to land via ci train need a packaging ack?
[21:13] <robru> dobey: If you're publishing it and there's packaging changes it will require an ack, yes
[21:14] <robru> dobey: re: train api, the good news is that the rest api is the only api, so anything the web interface can do can also be done by any client app (eg there's no secret api that only the web interface can access)
[21:18] <dobey> robru: no real packaging changes, other than dropping all the patches that are in upstream, and such.
[21:19] <dobey> robru: also, i have upload privs for it…
[21:19] <robru> dobey: if you touch any files under debian/ other than changelog the train will require an ack no matter how good your intentions are.
[21:20] <robru> dobey: if you have upload rights then you should be able to ack it yourself
[21:20] <dobey> ah ok
[21:27] <dobey> robru: how do i do the ack?
[21:28] <robru> dobey: run the publish job again with "ACK_PACKAGING" checked
[21:28] <dobey> ah