/srv/irclogs.ubuntu.com/2016/06/10/#ubuntu-ci-eng.txt

rvrbzoltan: 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/29639111:17
bzoltanrvr:  yes11:17
bzoltanrvr:  actually it is enabling to all others ... the yakketi disabling landed last time11:18
rvrbzoltan: Why is that? Unit tests must run everywhere.11:18
bzoltanrvr: and no, we donot want to stop landing OTA UITK because the Yakketi tests are failing11:18
rvrbzoltan: Why are Yakketi tests failing?11:19
bzoltanrvr:  i do not remember ... not because we are doing shity code :) the tests pass on Vivid and Xenial11:20
rvrbzoltan: Please, enable them and fix them.11:20
bzoltanrvr: 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
bzoltanzsombi:  I got to run now... would you help rvr please11:23
zsombirvr: 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 ones11:23
rvrzsombi: Which problems did you find and how much time would it take to solve it?11:28
zsombirvr: 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:32
rvrzsombi: So, why are you targetting yakketi at all?11:33
zsombirvr: because Mirv wanted to see how the tripple landing works, to be able to track the Qt validation on UITK too11:34
zsombirvr: Mirv suggested to patch out the tests until we can fix them all11:35
rvrzsombi: 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:39
bzoltanrvr: securing that uitk builds is the first step. Qt is newer in Yakketi, that explains the test failure.11:41
zsombirvr: 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:41
zsombirvr: 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:43
zsombirvr: so this would be a temporary solution11:44
rvrzsombi: You can do that in a separate silo11:44
rvrfor yakketi11:44
rvrCheck that it builds, fix the tests, etc11:44
zsombirvr: bzoltan^11:44
zsombirvr: all I know is Mirv wanted us to do it like this11:45
rvrAnd meanwhile, we land things that are known to pass tests11:45
bzoltanrvr: please check with Mirv when he is back why he decided to land uitk like this.11:45
rvrbzoltan: Ok11:46
bzoltanrvr: not havint unit tests ön Yakketi does not represent any risk. We do know the reason of the failure.11:46
rvrbzoltan: 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:49
rvrIf 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.11:52
bzoltanrvr: I guess you know that we never merge untested code. We do test for Trusty, Vivid and Xenial. All series what are official targets.12:29
jdstrandpmcgowan: 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
pmcgowanjdstrand, whats your symptom, and let me find the silo13:27
pmcgowanjdstrand, silo 77 has an NM update and fixes13:28
jdstrandpmcgowan: that the network isn't always there13:28
jdstrandI'm not sure how else to describe it13:29
pmcgowanok not sure whats exactly fixed there but thats the one13:29
jdstrandok, thanks! I'll read the changelog and see if that is what I'm seeing13:29
jdstrandpmcgowan: I think it is 157909813:32
jdstrandand/or 156571713:33
* ChrisTownsend *grumble* no more silos *grumble*14:49
dobeymterry, kenvandine: can one of you publish https://requests.ci-train.ubuntu.com/#/ticket/1461 and ack the packaging changes please?14:58
mterrylooking14:58
dobeythanks mterry15:07
robruChrisTownsend: try now.15:09
ChrisTownsendrobru: Got one now.  Thanks!15:15
robruChrisTownsend: you're welcome!15:15
mardytrainguards: can you please have a look why this is still in the proposed pocket? https://requests.ci-train.ubuntu.com/#/ticket/134415:49
robrumardy: did you look? http://people.canonical.com/~ubuntu-archive/proposed-migration/yakkety/update_excuses.html#account-plugins15:50
mardyhere it seems it's waiting for a dependency on ubuntu-system-settings-online-accounts, but that dep should be already there15:50
mardyrobru: ^15:50
mardyrobru: u-s-s-o-a is already in yakkety (it's been in Ubuntu for ages now)15:52
robrumardy: I dunno then, you should ask with #ubuntu-release15:52
mardyrobru: OK, thanks, let's try...15:53
oSoMoNrobru, 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 branch16:01
robruoSoMoN: 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
robruoSoMoN: or send a patch to lp ;-)16:02
oSoMoNokay16:03
robruoSoMoN: in the context of that comment, "Commit Message" means "the MP web interface field called 'Commit Message', not the bzr commit message"16:04
robrukenvandine: I'm eagerly awaiting content-hub's sister project: malcontent-hub. When is that going live?16:11
kenvandine:)16:11
robrukenvandine: to this day I see people talk about "foo and friends" and think they're talking about Friends16:11
kenvandinelol16:12
cjwatsonrobru,oSoMoN: It's not supported yet, but it's one of the things on our list for moving LP itself to git.16:18
cjwatsonrobru,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
robrucjwatson: oh, nice. you got an ETA? git support in the train is still ~months away16:19
cjwatsonrobru: 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 card16:19
cjwatsonWill hopefully beat you to it.16:20
cjwatsonHmm.16:20
cjwatsonI don't think the plan to link MPs to bugs will work for what you're doing, though.16:20
cjwatsonOh, maybe it will.16:20
robrucjwatson: well we use lp api to query linked bugs from branches, should be easy to query MPs instead.16:21
cjwatsonI guess each changelog entry is typically a different MP.16:21
robrucjwatson: yep, sometimes people write their own but if not, yeah, each bulet point is one mp16:21
cjwatsonRight, that should be fine then.16:21
robrucool cool cool16:21
kdubtrainguards, failure to assign silo: https://requests.ci-train.ubuntu.com/#/ticket/152816:23
kdubany ideas? says its low on silos from the logs16:24
robrukdub: yeah one sec I'll boot somebody else out16:24
kdubthanks robru16:24
robrukdub: ok, try now16:26
oSoMoNcjwatson, cool, looking forward to that feature16:28
kdubrobru, same message16:28
kdubrobru, ah, 2nd time worked16:28
kdubrobru, thanks for the help16:29
robrukdub: you're welcome16:29
robrugrumble empty error messages grumble16:35
dobeygrumble autopkgtests grumble17:42
robruhmmm I wonder why britney would approve momentarily and then switch back to running...17:49
robruoh, vivid always-failed, so it would approve based on vivid, then start other series and block on those17:49
robruI should really fix that to not report anything until all series have run17:49
dobeyrobru: eh, wish we could just make it faster18:01
robrudobey: did you miss the memo I sent out explaining how I reduced the run times from 80 minutes to 20 minutes18:02
dobeyrobru: that's great, but i meant more generally. like my silo was published 5 hours ago, and still stuck in proposed on y18:03
robrudobey: 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 silo18:04
robrudobey: "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
dobeyrobru: well it's autopkgtests, which is why i'm complaining about it. :)18:05
robrudobey: you should performance profile your autopkgtests then, that's not britney's fault :-P18:06
dobeyrobru: but yeah, since merges to trunk are blocked on the packages going to archives, it adds slowness18:06
dobeyrobru: it is when someone uploads php7 at the same time, and DoSes the hardware :)18:06
robrudobey: yeah, that was a design decision so people wouldn't just fire-and-forget garbage into -proposed.18:06
robru(blocking merges to trunk, not uploading php7)18:07
dobeyrobru: 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
dobeyor do we have plenty of cases of people just dumping stuff into proposed and having it stuck there?18:08
dobeyOverLimit: 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
dobeywhee, that's lovely18:40
dobeymaybe i should just force merge this18:41
=== kdub_ is now known as kdub
dobeyoh i don't have the job/build permission on jenkins it seems18:58
dobeywhatever that means18:58
dobey:(18:58
robrudobey: what?19:20
robrudobey: oh yeah, you can't force merge, only core dev & I can do that19:20
dobeyrobru: can you force merge https://requests.ci-train.ubuntu.com/#/ticket/1461 please?19:22
robrudobey: explain why you want that19:23
dobeyrobru: so i can rebuild my other silo, and because autopkgtests builders are apparently on overload and it's been waiting like 6 hours19:24
robrudobey: ok so  you have another silo that'll be ready to publish soon-ish?19:24
dobeyrobru: 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 state19:25
robrudobey: ok but having something stuck in yakkety-proposed while trunk leaves it behind will be a weird state for yakkety.19:26
dobeyrobru: how so? it's already in yakkety. it's just in -proposed rather than release.19:26
robrudobey: exactly. once i merge, trunk will have things that are not in release.19:27
robrudobey: anyway, it is done, but this is really a special case, not something you should do every time.19:28
dobeyrobru: it won't have anything which hasn't been uploaded to ubuntu.19:28
dobeywhich goes back to...19:28
dobey14: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
dobey14:04 < dobey> or do we have plenty of cases of people just dumping stuff into proposed and having it stuck there?19:28
robrudobey: 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:28
dobeyrobru: 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 policy19:30
robrudobey: 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:30
robrudobey: if yo resolve all the britney issues in-silo then you should have no trouble getting through yakkety-proposed.19:31
dobeyassuming the infrastructure hasn't exploded19:31
robrudobey: that's what force-merge is for then, when you're sure the issue is the infrastructure and not your package.19:32
robrudobey: not something we want to be the default case.19:32

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!