[07:49] <bzoltan_> Mirv: robru: Do you guys know what is going on with the silo31 content?
[08:09] <Mirv> bzoltan_: I saw it was discussed by sil2100 yesterday, and he continued to say that address book app didn't fail to build (=run tests) in other silos
[08:10] <Mirv> bzoltan_: anyway, let me rebuild UITK for s390x now that it's possible, otherwise train complains about that too
[08:18] <Mirv> jibel: davmor2: when you're around, we'd need the click landing from silo 012 to unblock xenial
[08:27] <jibel> Mirv, ok, I'll ask someone to do the verification this morning
[08:38] <Mirv> thanks
[08:47] <Mirv> just retried again amd64 address-book-app, no luck https://launchpadlibrarian.net/229677326/buildlog_ubuntu-xenial-amd64.address-book-app_0.2%2B16.04.20151210-0ubuntu1_BUILDING.txt.gz
[08:49] <Mirv> sil2100: so bzoltan would be wishing to be able to land the approved OTA-9 landing to overlay despite xenial problem(s), and fix xenial issues after the UITK otherwise is safely in overlay, in the next landing.
[08:49] <Mirv> sil2100: it's actually not just one test failing in address-book-app, also a change in UITK exposes some sort of linking problem on the new s390x where the previous UITK just happened to build..
[08:50] <sil2100> Mirv: hmmm, not good
[08:59] <Mirv> sil2100: in other news, all the required xenial landings to fix what britney let through did not land in time - this is https://requests.ci-train.ubuntu.com/#/ticket/772 required for s390x so that UITK can be unblocked from proposed (for all archs) and ji_bel has promised to have someone looking at it soon
[08:59] <bzoltan_> sil2100:  comparing with the passing logs it looks to me like it already fails at "Fail to connect with syncfw" connecting to com.canonical.pim.AddressBook on DBus - I think it's safe to assume that is not a UITK problem
[09:08] <kalikiana> sil2100: could somebody from address book take a look at the failure? it looks like a flaky dbus connection issue to me. I don't think it's hitting uitk at that point
[09:10] <sil2100> kalikiana, bzoltan_: we don't have any evidence for flakyness as it hasn't failed anywhere else yet, where on the UITK silo it fails all the time
[09:10] <kalikiana> sil2100: well, it does seem to be fine on vivd, though
[09:10] <sil2100> Yeah, so some combination of xenial and the UITK is causing chaos
[09:11] <sil2100> Anyway, let me think
[09:11] <kalikiana> but it also fails to connect to com.canonical.pim.AddressBook - I'm not sure how UITK could cause that, that's at best Qt API
[09:12] <sil2100> kalikiana: I also have no idea, but as you can see it's somehow affecting the test as silo 44 built fine on first try 8 hours ago
[09:13] <sil2100> Anyway, you guys propose just releasing the vivid-overlay bits?
[09:16] <Mirv> sil2100: that's zoltan's wish, yes (although he's off today so he can scarcely join the discussion)
[09:17] <sil2100> Since for sure I wouldn't release something to xenial that doesn't build or affects builds
[09:18] <sil2100> kalikiana, bzoltan_: you guys would have to deal with this anyway with your next UITK landing, releasing the address-book-app changes to xenial too
[09:18] <dbarth> hey there, can i publish the sasl plugin now btw? seb128 ack'ed the package
[09:18] <sil2100> dbarth: I published it yesterday
[09:18] <dbarth> ah
[09:18] <dbarth> but i still see the ticket open here: https://requests.ci-train.ubuntu.com/#/ticket/695
[09:18] <sil2100> dbarth: it's in xenial NEW and vivid-overlay RELEASE
[09:18] <sil2100> NEW queue (signon-plugin-sasl/xenial).
[09:18] <sil2100> Release pocket (signon-plugin-sasl/vivid).
[09:18] <dbarth> do i need to press the merge button?
[09:18] <sil2100> (it's migrating)
[09:18] <seb128> dbarth, I NEWed it
[09:18] <sil2100> Not yet
[09:19] <dbarth> ok ok ;)
[09:19] <sil2100> It will merge automatically once it gets out of the NEW queue
[09:19] <sil2100> Which should be soon as per what seb128 said ;)
[09:19] <dbarth> ah perfect, ok so i'll stay on autopilot
[09:24] <kalikiana> sil2100: sure, and as soon as somebody from address book can take a look we can investigate more... otherwise we're blocked... these are the only options I see
[09:36] <sil2100> kalikiana, bzoltan_: ok, I'll grant you this one-time exception and only release the vivid bits but you need to make sure to contact bfiller with this, prepare a silo for testing and do a coordinated dual fix ASAP
[09:42] <kalikiana> sil2100: understood. thanks a lot!
[09:51] <sil2100> huh, ok, manual copy-package it is then
[09:55] <sil2100> kalikiana, bzoltan_: packages copied, force-merging silo
[10:07] <sil2100> Nothing like closing the wrong terminal
[10:31] <Saviq> sil2100, hey, do we have a way to tell what Qt/UITK version was in what framework? The phone today ships frameworks as old as 13.10 (not to mention all the -dev ones...)... I've  a weird feeling we're not backwards compatible that far back...
[10:32] <Saviq> sil2100, we'd like to prepare app devs to go device-pixel-ratio-aware (hidpi screens and such), but we'd need to tell them what's the minimal framework they need to declare for their app to work for sure on all apps it will get installed on
[10:33] <Saviq> s/apps/phones/
[11:14] <bzoltan_> sil2100:  lovely! thank you a big bunch :)
[12:07] <sil2100> Saviq: hmmm, I could try prepping such a list with the help of the SDK team
[12:07] <sil2100> Saviq: anyway, true on the fact that we need some cleanup of frameworks, we did none as none of the framework->deps pairs were documented anywhere
[12:18] <cjwatson> Mirv: would you mind publishing click for me if it passes QA?  I'm on holiday today and not at a computer where I could do it myself
[12:36] <Mirv> cjwatson: sure, thanks
[13:01] <Saviq> sil2100, yeah, it's not a good situation, as they are today... they're only remotely useful for API additions
[13:01] <Saviq> and not at all for deprecations
[13:04] <rvr> cjwatson: Silo 12 approved.
[13:07] <Saviq> rvr, brave soul! let me know anything you need about silo 22 ;)
[13:08] <rvr> Saviq: hehe
[13:40] <Mirv> sil2100: around? please click publish on https://requests.ci-train.ubuntu.com/#/ticket/772 ASAP. the packaging changes are removal of a patch (now included upstream) and small control file change
[13:42] <Mirv> kenvandine: or you ^
[13:54] <Mirv> cyphermox: ha, I see you're around. https://requests.ci-train.ubuntu.com/#/ticket/772 publish please? we need it to unblock xenial after britney did what it did yesterday.
[13:54] <cyphermox> ok
[13:54] <Mirv> thank you
[13:55] <Mirv> sil2100: kenvandine: unping therefore.
[13:59] <pmcgowan> sil2100, ping
[14:01] <cyphermox> Mirv: sil2100: btw I think there is a typo in code: 2015-12-11 14:00:59,670 DEBUG Beginning: phase: ackaging
[14:02] <cyphermox> (and cjwatson's silo is published, I reviewed it and didn't see anything wrong)
[14:02] <Mirv> cyphermox: thanks, and thanks for the publish run!
[14:03] <Mirv> this should unblock the last bits of xenial/s390x click -> ubuntu-app-lauch -> url-dispatcher -> ubuntu-ui-toolkit
[14:04] <cyphermox> I'm a little curious what bits would help s390x though?
[14:04] <Mirv> cyphermox: haha, it's not a typo, it's robru's great invention of the phase where ack:s are checked/done :D
[14:04] <cyphermox> Mirv: ok, that's what I wondered
[14:06] <Mirv> cyphermox: if you didn't follow, britney traded yesterday mass migration with some uninstallability which raised a few eyebrows and broke xenial image. UITK is stuck in proposed due to ubuntu-app-launch on s390x not being installable because click didn't build from source in xenial. http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-ui-toolkit
[14:06] <cyphermox> Mirv: yeah, I had seen the migration
[14:06] <Mirv> so this click landing should unlock it and xenial would be finally good
[14:06] <cyphermox> Mirv: so, the fact that it's building will unbreak s390x
[14:07] <Mirv> cyphermox: yes
[15:26] <Saviq> rvr, looking good, then? ;)
[15:26]  * Saviq can't wait
[15:38] <rvr> Saviq: So far, yes
[15:41] <Saviq> rvr, oh the suspense!
[15:45] <jhodapp> Mirv, just an FYI, just got another bgplaylist code PR merged with upstream
[15:45] <jhodapp> for qtmultimedia
[15:57] <Mirv> jhodapp: great work!
[15:58] <jhodapp> Mirv, thanks
[15:59] <Mirv> sil2100: hey! you might want to try to kick an image build when 'rmadison -s xenial ubuntu-ui-toolkit' says "ubuntu2"
[16:23] <sil2100> Mirv: ok, makes sense
[16:34] <Elleo> sil2100: am I right in thinking that ^ "Destination version <blah> is missing from changelog" isn't something to worry about?
[16:36] <sil2100> Elleo: hey! Depends on what that version is, but from what I see it's probably just some no-change rebuild
[16:36] <sil2100> Let me double check
[16:37] <Elleo> sil2100: thanks
[16:38] <sil2100> Elleo: ok, you shouldn't worry about it but just make sure that these changes are included in your ubuntu-download-manager:
[16:38] <sil2100> https://launchpadlibrarian.net/213247676/ubuntu-download-manager_1.0%2B15.10.20150724-0ubuntu1_1.0%2B15.10.20150724-0ubuntu2~ppa2.diff.gz
[16:38] <sil2100> I see there's some modification to debian/rules
[16:38] <sil2100> Elleo: normally someone doing changes like that should upstream them, but doko is bad at forwarding his changes
[16:39] <Elleo> sil2100: ah, how's that best handled at this point? should I include his changes in my branch?
[16:40] <Elleo> sil2100: it looks like his changes were made to ignore symbol checks on certain platforms, but we've moved away from using symbol files to using abi-compliance-checker now, so those changes should be irrelevant
[16:43] <sil2100> Elleo: in that case you can simply ignore this change ;)
[16:43] <Elleo> sil2100: okay, cool
[17:15] <rvr> Saviq: ping
[17:15] <Saviq> rvr, uh oh? :)
[17:15] <rvr> Saviq: What does the multiwindowed test do?
[17:16] <Saviq> rvr, on clicking "Click me!" it should say "Window 2" (and not crash and burn)
[17:16] <rvr> Saviq: Ah, cool
[17:16] <rvr> Then it works
[17:16] <Saviq> rvr, basically the QML opens a second window, which before would cause unity8 to die a painful death
[17:17] <Saviq> now it just pops up instead the original window
[17:18] <rvr> Yes, I see
[17:18] <rvr> Saviq: All the tests are ok
[17:18] <Saviq> rvr, great, thanks
[17:19] <rvr> Saviq: Approving the silo
[17:25] <Mirv> sil2100: any status on the xenial image build? just curious.
[17:27] <sil2100> Mirv: it's ounn, it's workin'
[17:27] <sil2100> I mean, buildin'
[17:30] <Mirv> ok
[19:22] <barry> sil2100: still around?
[19:31] <sil2100> barry: hey! Yeah, more or less :)
[19:31] <sil2100> What's up?
[19:32] <barry> sil2100: hi!  nothing urgent.  i just realize that i suck at getting to LP: #1463136.  i assigned it to you in the hopes you might have time to take a crack at it.  if not, feel free to reassign it back to me
[19:33] <sil2100> mmmmm, sure thing :) All things s-i I like
[19:33] <barry> sil2100: you are mr. server now :)
[19:33] <sil2100> barry: ok, I'll put it on my short-term TODO list for next week
[19:33] <barry> sil2100: i'm happy to review of course!
[19:34] <barry> sil2100: thanks
[19:34] <sil2100> np! Will throw a merge for review, there will be even more later next week too
[19:35] <barry> sil2100: sounds good!
[19:51] <tvoss> sil2100, if you are still around: do we have debug symbols for silos available?
[19:56] <robru> tvoss: yeah, should be
[19:56] <robru> tvoss: what silo?
[19:56] <tvoss> robru, 000
[20:01] <robru> tvoss: yep, -dbgsym packages appear to be in there
[20:05] <robru> bbl
[20:18] <bzoltan_> sil2100: robru: do you guys understand this? https://ci-train.ubuntu.com/job/ubuntu-landing-060-1-build/3/console
[20:21] <robru> bzoltan_: better file that bug like it says, looks like bzr itself is broken
[20:21] <robru> bzoltan_: i didn't change any Unicode handling recently...
[20:22] <bzoltan_> robru: thanks... should I just expect that it will magicly work when I retry?
[20:22] <robru> bzoltan_: as a workaround for now you could try removing the á from wherever that is
[20:23] <robru> bzoltan_: doesn't look transient to me, it's a Unicode error based on the inputs...
[20:23] <robru> bzoltan_: I'm at the doctor now, will be an hour or two before i can really dig into this
[20:24] <robru> bzoltan_: sadly i put a lot of effort into making the train work with Unicode in py3 but this is bzr itself which is still py2 and unmaintained, yuck
[20:24] <bzoltan_> robru:  ohh, get well dude and do not bother :) it is my name in the changelog... I do not mind being Zoltan and not Zoltán :)
[20:25] <robru> bzoltan_: thanks, it's just a checkup, I'll be home in no time
[20:27] <robru> bzoltan_: yeah $LANG is set correctly for utf8, not sure why bzr is puking like that
[20:32] <robru> bzoltan_: oh i guess your indentation is wrong. Add one more space and put the accent back in, i think it should work
[20:32] <robru> The [ should have two spaces in front i think
[20:32] <robru> OK gotta go, doctor is here ;-)
[20:40] <bzoltan_> robru:  how true :) thanks
[21:17] <dobey> kenvandine: err, does ubuntu-system-settings not get dual landed?
[21:18] <jgdx> kenvandine, it does
[21:18] <jgdx> dobey, ^
[21:18] <dobey> huh
[21:18] <dobey> why is the diff to debian/changelog so huge in my silo then?
[21:19] <dobey> for the vivid build
[21:21] <robru> dobey: what silo?
[21:22] <jgdx> dobey, seems something has gone sideways
[21:22] <dobey> robru: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-041/+sourcepub/5767446/+listing-archive-extra
[21:22] <dobey> something indeed has gone sideways
[21:22] <jgdx> dobey, this mp? https://code.launchpad.net/~dobey/ubuntu-system-settings/iap-trust-store/+merge/280356
[21:23] <jgdx> if so, that diff is crazy
[21:23] <robru> dobey: because that diff is against vivid, not the overlay. you want the diff generated by the train: https://ci-train.ubuntu.com/job/ubuntu-landing-041-1-build/lastBuild/artifact/ubuntu-system-settings_vivid_content.diff/*view*/
[21:24] <dobey> hmm, ok
[23:17] <robru> I've written a program that uses the same file for locking and logging. I call it... the "logck"