[11:17] <rvr> bzoltan: Hi. In silo 14 there is merge proposal to disable unit tests for yakketti?? https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/ifeq_is_better_than_ifneq/+merge/296391
[11:17] <bzoltan> rvr:  yes
[11:18] <bzoltan> rvr:  actually it is enabling to all others ... the yakketi disabling landed last time
[11:18] <rvr> bzoltan: Why is that? Unit tests must run everywhere.
[11:18] <bzoltan> rvr: and no, we donot want to stop landing OTA UITK because the Yakketi tests are failing
[11:19] <rvr> bzoltan: Why are Yakketi tests failing?
[11:20] <bzoltan> rvr:  i do not remember ... not because we are doing shity code :) the tests pass on Vivid and Xenial
[11:20] <rvr> bzoltan: Please, enable them and fix them.
[11:23] <bzoltan> rvr: We will, but not now. If you want you can block the OTA12 because of that... but i would not do that. yakketi is not a priority target.. it is not released yet, so no app developer should target yakketi with UITK apps.
[11:23] <bzoltan> zsombi:  I got to run now... would you help rvr please
[11:23] <zsombi> rvr: we know that Yakketi tests are failing, but we have no time/resources to focus on that target yet. All we managed to do is to make the toolkit to be built, but afaik Yakketi is not a top requirement just yet. So we had not spent time with it as long as OTA bugs are more important to fix than Yakketi ones
[11:28] <rvr> zsombi: Which problems did you find and how much time would it take to solve it?
[11:32] <zsombi> rvr: QtQuick internals on binding handling was changed. We saw some GLES stuff being also changed. Fixing those would require us 2-4 weeks. The Qt we have in Vivid is 5.4, Yakkety has yet 5.6.
[11:33] <rvr> zsombi: So, why are you targetting yakketi at all?
[11:34] <zsombi> rvr: because Mirv wanted to see how the tripple landing works, to be able to track the Qt validation on UITK too
[11:35] <zsombi> rvr: Mirv suggested to patch out the tests until we can fix them all
[11:39] <rvr> zsombi: How can the Qt validation be tracked if tests are disabled? If you already know how triple landing works, enable the tests and do not target yakketi until you can work on it. Disabling the tests is a bad practice.
[11:41] <bzoltan> rvr: securing that uitk builds is the first step. Qt is newer in Yakketi, that explains the test failure.
[11:41] <zsombi> rvr: well, Qt validation is not only about the tests. First we need to see modules building. Next come the tests. There were other modules around which were not building either, and first round is to get the built. Next comes the testing. Yes, we will get them working. We've been doing this earlier, when we swictedh to Qt 5.2, to 5.4, and we will do in the future as well.
[11:43] <zsombi> rvr: we never left a test disabled because we were not been able to run them. We re-enabled them as soon as we got driven to the new version, then we spent weeks to fix them, and we did it, re-enabled them, and ran them in full flavor.
[11:44] <zsombi> rvr: so this would be a temporary solution
[11:44] <rvr> zsombi: You can do that in a separate silo
[11:44] <rvr> for yakketi
[11:44] <rvr> Check that it builds, fix the tests, etc
[11:44] <zsombi> rvr: bzoltan^
[11:45] <zsombi> rvr: all I know is Mirv wanted us to do it like this
[11:45] <rvr> And meanwhile, we land things that are known to pass tests
[11:45] <bzoltan> rvr: please check with Mirv when he is back why he decided to land uitk like this.
[11:46] <rvr> bzoltan: Ok
[11:46] <bzoltan> rvr: not havint unit tests ön Yakketi does not represent any risk. We do know the reason of the failure.
[11:49] <rvr> bzoltan: As Donald Rumsfeld said once: we know the things that we know, and we know there are some things we do not know. And tests do exist for those.
[11:52] <rvr> If you begin to merge code that is not tested, then you do not know which problems you will find, and it is not assured that it will work. That usually ends with a big mess. We have seen this in the past.
[12:29] <bzoltan> rvr: I guess you know that we never merge untested code. We do test for Trusty, Vivid and Xenial. All series what are official targets.
[13:27] <jdstrand> pmcgowan: hi! I heard about a nm regression in ota11 and my phone seems affected. is there a silo for the fix? have you heard if it is safe? is it queued somewhere? (I'd like to install it)
[13:27] <pmcgowan> jdstrand, whats your symptom, and let me find the silo
[13:28] <pmcgowan> jdstrand, silo 77 has an NM update and fixes
[13:28] <jdstrand> pmcgowan: that the network isn't always there
[13:29] <jdstrand> I'm not sure how else to describe it
[13:29] <pmcgowan> ok not sure whats exactly fixed there but thats the one
[13:29] <jdstrand> ok, thanks! I'll read the changelog and see if that is what I'm seeing
[13:32] <jdstrand> pmcgowan: I think it is 1579098
[13:33] <jdstrand> and/or 1565717
[14:49]  * ChrisTownsend *grumble* no more silos *grumble*
[14:58] <dobey> mterry, kenvandine: can one of you publish https://requests.ci-train.ubuntu.com/#/ticket/1461 and ack the packaging changes please?
[14:58] <mterry> looking
[15:07] <dobey> thanks mterry
[15:09] <robru> ChrisTownsend: try now.
[15:15] <ChrisTownsend> robru: Got one now.  Thanks!
[15:15] <robru> ChrisTownsend: you're welcome!
[15:49] <mardy> trainguards: can you please have a look why this is still in the proposed pocket? https://requests.ci-train.ubuntu.com/#/ticket/1344
[15:50] <robru> mardy: did you look? http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#account-plugins
[15:50] <mardy> here it seems it's waiting for a dependency on ubuntu-system-settings-online-accounts, but that dep should be already there
[15:50] <mardy> robru: ^
[15:52] <mardy> robru: u-s-s-o-a is already in yakkety (it's been in Ubuntu for ages now)
[15:52] <robru> mardy: I dunno then, you should ask with #ubuntu-release
[15:53] <mardy> robru: OK, thanks, let's try...
[16:01] <oSoMoN> robru, just saw your comment on https://code.launchpad.net/~timo-jyrinki/ubuntu-keyboard/stop_depending_on_transitional_packages/+merge/295045/comments/763387 , out of curiosity how will that work for git-based merge requests? afaik there is currently no way to link a bug report to a git branch
[16:02] <robru> oSoMoN: well we'll cross that bridge when we come to it... if lp doesn't support linking bugs to git branches then you'll just have to type it into the commit message by hand.
[16:02] <robru> oSoMoN: or send a patch to lp ;-)
[16:03] <oSoMoN> okay
[16:04] <robru> oSoMoN: in the context of that comment, "Commit Message" means "the MP web interface field called 'Commit Message', not the bzr commit message"
[16:11] <robru> kenvandine: I'm eagerly awaiting content-hub's sister project: malcontent-hub. When is that going live?
[16:11] <kenvandine> :)
[16:11] <robru> kenvandine: to this day I see people talk about "foo and friends" and think they're talking about Friends
[16:12] <kenvandine> lol
[16:18] <cjwatson> robru,oSoMoN: It's not supported yet, but it's one of the things on our list for moving LP itself to git.
[16:19] <cjwatson> robru,oSoMoN: The plan is actually to support linking bugs to merge proposals rather than to git branches directly (since they're much more lightweight than bzr branches, and it would get pretty unmanageable to link bugs to git repositories).
[16:19] <robru> cjwatson: oh, nice. you got an ETA? git support in the train is still ~months away
[16:19] <cjwatson> robru: No very precise ETA but it's probably the next thing I intend to pick up when I get a chance to take a tech-debt card
[16:20] <cjwatson> Will hopefully beat you to it.
[16:20] <cjwatson> Hmm.
[16:20] <cjwatson> I don't think the plan to link MPs to bugs will work for what you're doing, though.
[16:20] <cjwatson> Oh, maybe it will.
[16:21] <robru> cjwatson: well we use lp api to query linked bugs from branches, should be easy to query MPs instead.
[16:21] <cjwatson> I guess each changelog entry is typically a different MP.
[16:21] <robru> cjwatson: yep, sometimes people write their own but if not, yeah, each bulet point is one mp
[16:21] <cjwatson> Right, that should be fine then.
[16:21] <robru> cool cool cool
[16:23] <kdub> trainguards, failure to assign silo: https://requests.ci-train.ubuntu.com/#/ticket/1528
[16:24] <kdub> any ideas? says its low on silos from the logs
[16:24] <robru> kdub: yeah one sec I'll boot somebody else out
[16:24] <kdub> thanks robru
[16:26] <robru> kdub: ok, try now
[16:28] <oSoMoN> cjwatson, cool, looking forward to that feature
[16:28] <kdub> robru, same message
[16:28] <kdub> robru, ah, 2nd time worked
[16:29] <kdub> robru, thanks for the help
[16:29] <robru> kdub: you're welcome
[16:35] <robru> grumble empty error messages grumble
[17:42] <dobey> grumble autopkgtests grumble
[17:49] <robru> hmmm I wonder why britney would approve momentarily and then switch back to running...
[17:49] <robru> oh, vivid always-failed, so it would approve based on vivid, then start other series and block on those
[17:49] <robru> I should really fix that to not report anything until all series have run
[18:01] <dobey> robru: eh, wish we could just make it faster
[18:02] <robru> dobey: did you miss the memo I sent out explaining how I reduced the run times from 80 minutes to 20 minutes
[18:03] <dobey> robru: that's great, but i meant more generally. like my silo was published 5 hours ago, and still stuck in proposed on y
[18:04] <robru> dobey: oh, publishing is different. my speedup only affects the lead time from when you lander-approve to when britney first notices and runs on your silo
[18:05] <robru> dobey: "stuck in proposed" can be a lot of different things, could be slow autopkgtests, could be tangled in some other complicated migration, etc.
[18:05] <dobey> robru: well it's autopkgtests, which is why i'm complaining about it. :)
[18:06] <robru> dobey: you should performance profile your autopkgtests then, that's not britney's fault :-P
[18:06] <dobey> robru: but yeah, since merges to trunk are blocked on the packages going to archives, it adds slowness
[18:06] <dobey> robru: it is when someone uploads php7 at the same time, and DoSes the hardware :)
[18:06] <robru> dobey: yeah, that was a design decision so people wouldn't just fire-and-forget garbage into -proposed.
[18:07] <robru> (blocking merges to trunk, not uploading php7)
[18:08] <dobey> robru: well, since we have britney running autopkgtests for silos now, maybe we could relax that so that when stuff is in -proposed it'll merge to trunk?
[18:08] <dobey> or do we have plenty of cases of people just dumping stuff into proposed and having it stuck there?
[18:40] <dobey> OverLimit: Quota exceeded for cores,ram: Requested 1, but already used 30 of 30 cores (HTTP 413) (Request-ID: req-9f63af4f-984f-4eb1-990a-e7f6e6f6fa65)
[18:40] <dobey> whee, that's lovely
[18:41] <dobey> maybe i should just force merge this
[18:58] <dobey> oh i don't have the job/build permission on jenkins it seems
[18:58] <dobey> whatever that means
[18:58] <dobey> :(
[19:20] <robru> dobey: what?
[19:20] <robru> dobey: oh yeah, you can't force merge, only core dev & I can do that
[19:22] <dobey> robru: can you force merge https://requests.ci-train.ubuntu.com/#/ticket/1461 please?
[19:23] <robru> dobey: explain why you want that
[19:24] <dobey> robru: so i can rebuild my other silo, and because autopkgtests builders are apparently on overload and it's been waiting like 6 hours
[19:24] <robru> dobey: ok so  you have another silo that'll be ready to publish soon-ish?
[19:25] <dobey> robru: no, but i need to rebuild it to test it, and since this silo has already 'landed' in overlay, i don't want to get things in a weird state
[19:26] <robru> dobey: ok but having something stuck in yakkety-proposed while trunk leaves it behind will be a weird state for yakkety.
[19:26] <dobey> robru: how so? it's already in yakkety. it's just in -proposed rather than release.
[19:27] <robru> dobey: exactly. once i merge, trunk will have things that are not in release.
[19:28] <robru> dobey: anyway, it is done, but this is really a special case, not something you should do every time.
[19:28] <dobey> robru: it won't have anything which hasn't been uploaded to ubuntu.
[19:28] <dobey> which goes back to...
[19:28] <dobey> 14:04 < dobey> robru: well, since we have britney running autopkgtests for silos now, maybe we could relax that so that when stuff is in -proposed it'll merge  to trunk?
[19:28] <dobey> 14:04 < dobey> or do we have plenty of cases of people just dumping stuff into proposed and having it stuck there?
[19:28] <robru> dobey: by force merging, you're essentially saying "I don't care that yakkety-proposed is broken, I'm ignoring that so I can work on something else"
[19:30] <dobey> robru: but at that point, the way to fix it is with a new upload with a new changelog entry, ie, a new silo; not to overwrite the existing upload with something completely different and lose the changelog, since that would be against ubuntu/debian policy
[19:30] <robru> dobey: no, we won't be relaxing it so that it can merge after it uploads to yakkety-proposed. the whole point of waiting for it to migrate is so that landers are made aware of when their uploads break devel series. If we allowed people to just fire-and-forget their devel uploads then devel would be chaos.
[19:31] <robru> dobey: if yo resolve all the britney issues in-silo then you should have no trouble getting through yakkety-proposed.
[19:31] <dobey> assuming the infrastructure hasn't exploded
[19:32] <robru> dobey: that's what force-merge is for then, when you're sure the issue is the infrastructure and not your package.
[19:32] <robru> dobey: not something we want to be the default case.