/srv/irclogs.ubuntu.com/2016/03/31/#ubuntu-ci-eng.txt

Saviqrobru, the test was invalid - it was trying to rebuild qtmir, which is not what autopkgtests are for and caused us trouble now that britney runs per trigger and not all of proposed00:15
robruah00:15
Saviqthanks, g'night!00:16
robruSaviq: night00:16
=== chihchun_afk is now known as chihchun
michitrainguards: I have a weird failure in a silo.02:04
michippc64el fails, but there is no build log: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/941961302:04
michiAnyone around who can help?02:04
robrumichi: no idea. I just hit retry in the hopes that it gives a log next time02:05
michiIt’s also failed in silo 59, same story there.02:05
robruWell that's troubling02:06
michiIt’s clearly an infrastructure thing. All the other arches built fine.02:06
michiTrying a rebuild...02:07
robrumichi: right but if it was a one off, it'd seem more likely to work on a retry. If there's consistent failures then we may need to escalate to Colin02:08
michiYeah02:08
michirobru: When does Colin normally come online?02:08
michiI don’t see him right now.02:08
michiAh, no, he’s around...02:09
robrumichi: UK time officially but he's known to keep irregular hours02:09
michiWell, that makes it around 1 am or so over there...02:09
robrumichi: anyway the retries have logs showing live, just a question of if it'll keep them after02:10
michiI’ll keep an eye on them, thanks.02:10
michirobru: This is not looking good: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-006/+build/941974102:13
michihttps://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-059/+build/941972402:14
robrumichi: huh beats me. Maybe try wgrant02:14
michiwgrant: ^02:15
michiCan you help?02:15
michicjwatson: In the unlikely case that you are still around, it looks like something is broken with the ppc64el builders for the train.02:16
wgrantrobru, michi: Looking.02:28
robruThanks02:28
=== chihchun is now known as chihchun_afk
=== chihchunl is now known as chihchun
bzoltanjibel: popey: I have fixed the 35 silo, so it is fully OK - https://requests.ci-train.ubuntu.com/#/ticket/1095 If you want it on OTA10 please put it on a quick line to QA and see if it is good for you.03:55
slangasekrobru: why do the silo descriptions link to swift objects that aren't readable? (e.g. https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-066, https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_39a8dbb93caf4ec889f8a1b7f69885db/bileto-1186/2016-03-30_07:49:08/xenial/qtmir/content.diff)04:42
robruslangasek: because the artifacts are deleted when the silo lands04:43
slangasekrobru: that silo isn't landed; it's stuck in -proposed04:43
slangasekrobru: relatedly: why is the qtmir from that silo reported to no longer have any autopkgtests?04:43
robruslangasek: the description says landed right there. Probably force merged04:43
slangasekok so who's force merging and why?04:44
slangasek(why do we even still allow force merges?)04:44
robruslangasek: Saviq asked me to force merge that one because it was stuck because of the same issue with dpkg breaking the packages to not run autopkgtests04:45
slangasekThis doesn't get to land.  Someone needs to take responsibility for the fact that the autopkgtests have gone missing from the source.  Saviq ? (the only one of the three landers currently online...) http://autopkgtest.ubuntu.com/packages/q/qtmir/xenial/amd64/04:45
slangasekrobru: what "same issue"?04:46
robruslangasek: it passed qa and just needed a small follow-up silo to fix the packaging to get it through proposed04:46
robruslangasek: the dpkg ftbfs in the backport ppa was meant to fix this04:46
slangasekhmm04:47
robruslangasek: instead Saviq started a new silo with packaging fixes that restore the autopkgtests04:47
slangasekI am unclear how it's dpkg's fault that the source package has no debian/tests directory04:48
robruslangasek: basically the autopkgtests were broken by my dpkg-buildpackage work because apparently vivid and newer automatically add the Testsuite: field but the trusty version doesn't04:48
slangasekor why it's acceptable to force-merge things that need source fixes in order to get into xenial04:48
slangasekrobru: I just downloaded the source package from the archive; it has Testsuite: in the .dsc file04:48
slangasekbut there are no actual debian/tests in the source package04:49
robruslangasek: Hmmmmmmm04:49
robruslangasek: i didn't actually look at it, I'm just going off what pitti told me04:49
slangasek$ pull-lp-source qtmir && grep Testsuite qtmir*.dsc04:49
slangasekTestsuite: autopkgtest04:49
slangasek$04:49
robruslangasek: pull-lp-source? That'll grab what's in xenial, not the broken one stuck in proposed04:50
slangaseknope04:50
slangasekpull-lp-source pulls the latest, == -proposed04:50
robruslangasek: so I'm just going off https://bugs.launchpad.net/bileto/+bug/156408404:53
ubot5`Launchpad bug 1564084 in Bileto "Does not automatically add "Testsuite:" header any more" [Undecided,New]04:53
robruslangasek: and this is the silo Saviq put together to fix it: https://requests.ci-train.ubuntu.com/#/ticket/120604:54
slangasekrobru: right, so that's unrelated to what has happened to qtmir04:55
slangasekthat bug reports a problem with a unity8 package, not with qtmir.  qtmir has the Testsuite header, autopkgtest tries to test it, and it fails because there are no tests in the source (and I can't see from the diff where they've gone)04:55
slangasekrobru: however, if this was the bug you had suggested "only affected unity8", then that should certainly not be the case04:56
robruslangasek: https://code.launchpad.net/~saviq/qtmir/drop-testsuite-header/+merge/29046804:56
slangasekrobru: where did the *tests* go?04:57
robruslangasek: Saviq said somewhere they were no good so he got rid of them.04:57
slangasekhmm04:57
robruslangasek: anyway ticket 1206 is supposed to fix everything and make everybody happy04:58
slangasekok, then dropping the testsuite header is correct in that case04:58
slangasekwell, it does not make me happy to have fewer tests ;)04:58
robruslangasek: it could have been rebuilt in the same old silo instead of force merging but he didn't want to re-qa the whole thing since it was already approved.04:58
robruslangasek: from what he said it sounded like the tests had no value, or negative value (eg flaky tests that didn't actually test anything meaningful)04:59
robruslangasek: I can't remember, I think it's in the scrollback in this channel if you look ~5 hours back04:59
slangasekrobru: ok; so I've found the packaging diff and I don't see how Saviq justifies the claim that the tests were no good05:02
slangasekcertainly not to where dropping them is better than keeping them05:02
slangasekand if we're force-merging because a one-line update to debian/control requires a complete QA re-test, then isn't that a bug in the QA workflow?05:03
robruslangasek: well if the silo is rebuilt for any reason it clears the qa approval05:04
slangaseki.e., either a rebuild with no changes to the upstream source requires a full QA retest, or it doesn't - regardless of it's done in this silo or another05:04
robruslangasek: bileto doesn't know that somethings' being rebuilt for a one line change or even for a no-line change05:04
slangaseksure05:04
slangasekbut the lander can tell QA, and QA and rubberstamp05:04
robruright05:04
robruslangasek: anyway, I think the force-merge is sort of a red herring here, sure it's suboptimal but the real issue is just that you don't approve of the tests being deleted. which I think you should take up with Saviq since I'm not really familiar with why they're being dropped05:06
robruslangasek: I can't seem to find the message, I thought it was IRC, maybe it was an MP comment or something somewhere05:06
slangasekrobru: no, I don't approve of the tests being deleted, *AND* I don't approve of things being force-merged and left in xenial-proposed05:06
robruslangasek: I was under the impression that it's ok to force merge when things are stuck as long as people promise to keep an eye on it, and in this case Saviq has a new silo to fix this already prepped, so it seemed ok to me05:08
slangasekrobru: hmm; I wasn't aware that was the accepted practice - at this point in the release cycle, it does mean e.g. release team members going on wild goose chases in update_excuses05:11
robruslangasek: how does force merge impact release team people? stuff sitting in proposed would look the same to them regardless of if the ticket is merged or not? I don't see the big deal with force merging really since it just means trunk is slightly ahead of distro for a short while. sometimes if there's two conflicting silos and one is being a little slow to05:13
robrumigrate I'll get asked for force merge so that the other silo can be rebuilt sooner, eg, to unblock people wanting to land conflicting silos.05:13
robruslangasek: it's not an every-day thing but it happens sometimes when people are rushing to get OTAs out the door.05:13
slangasekrobru: hmm, perhaps it's marginal and you should ignore my late-night rant :) but it took extra time to track down the landing because it was force-merged, so it was no longer listed on requests.ci-train.u.c05:23
robruslangasek: no i think your concerns are justified, there's definitely gaps in the discoverability of information in the system. just needs some iterations here and there05:28
=== tvoss|dinner is now known as tvoss
popeybzoltan: Thanks. i haven't tested a silo for a while, what's the easiest way for me to test that on a device?08:13
bzoltanpopey: I think that /usr/bin/citrain device-upgrade 35 [DEVICE-PASSWORD] is the easiest way08:15
popeythanks08:16
tvossMirv, for reference: https://code.launchpad.net/~thomas-voss/platform-api/build-modules-as-shared-libraries/+merge/29057108:27
Mirvtvoss: oh, ok!08:49
popeybzoltan: jibel silo 35 works for me.09:02
bzoltanpopey: Cool. The Automated Signoff is running, after that i think the packages can be released to xenial  too09:03
=== chihchun is now known as chihchun_afk
bzoltanjibel: popey: ready to land https://requests.ci-train.ubuntu.com/#/ticket/120210:10
popeysweet!, thanks bzoltan10:13
bzoltanpopey:  with pleasure .. nice to fix bugs quickly10:13
=== chihchun_afk is now known as chihchun
popeybzoltan: i see rvr has a problem with that landing11:20
popeybzoltan: https://trello.com/c/nGHexJw8/3001-1202-ubuntu-landing-035-ubuntu-ui-toolkit-bzoltan11:21
popeyrvr: any chance you can put videos on people.canonical.com rather that private share, as they're inaccessible to community people. ta11:21
rvrpopey: I have problems accessing people, bad ssh config or something11:29
rvrI'll try to fix11:29
bzoltanrvr: popey: is that indicator color issue somehow related to this silo35?11:58
ahayzenbzoltan, i think Tim's fix was just for MainView's .. that probably comes from Unity8 itself ? I think... and was there before silo03512:00
bzoltanahayzen:  indeed12:00
bzoltanahayzen: I can spend some time with checking how unity is using palette values, but not with this silo12:01
bzoltanahayzen: i would need a day to go thru all the color settings in unity12:01
ahayzenyeah sounds like a separate issue to this one, silo035 was trying to fix the colours on app launch not todo with the shell12:01
=== jgdx_ is now known as jgdx
=== alan_g is now known as alan_g|lunch
=== alan_g|lunch is now known as alan_g
jibeltvoss, did you publish 33?14:02
tvossjibel, nope, do I need to?14:03
* sil2100 is on it14:03
jibelthanks14:03
sil2100https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/28997914:03
sil2100Needs approval14:03
sil2100tvoss: ^14:03
tvosssil2100, ack14:03
tvossssweeny, mind top-approving: https://code.launchpad.net/~thomas-voss/location-service/fix-1447110/+merge/28997914:03
ssweenytvoss, done14:04
tvosssil2100, ^14:04
rvrbzoltan: Silo 35 approved14:08
sil2100\o/14:10
sil2100Publishing that as well14:11
sil2100bzoltan: ^14:25
ahayzen\o/14:25
sil2100bzoltan: please review https://code.launchpad.net/~tpeeters/ubuntu-ui-toolkit/fasterWindowColorTrunk/+merge/290458 and https://code.launchpad.net/~bzoltan/ubuntu-ui-toolkit/cherry_pick-gles/+merge/29046114:25
sil2100Eh14:49
sil2100Publishing forcing the unapproved branches14:49
sil2100We don't have time to spare14:50
tvossssweeny, would you mind if we take https://requests.ci-train.ubuntu.com/#/ticket/1104 prior to your ls landing?15:04
ssweenytvoss, go right ahead :)15:04
=== chihchun is now known as chihchun_afk
sil2100jibel, robru, rvr: I guess we cancel the LT meeting since we have the status meeting at the same time, right?15:59
sil2100Or maybe we do both at once!15:59
jibelsil2100, yeah, I didn't plan to attend the landing meeting15:59
jibelit's a bit redundant15:59
pmcgowansil2100, jibel should be quick16:00
=== alan_g is now known as alan_g|EOD
pmcgowansil2100, whats up with silo 68, its not publishing due excuses18:11
pmcgowantrainguards can you check silo 68? does someone just need to push it?18:17
robrupmcgowan: according to britney the android package has unsatisfiable depends but somehow QA approved it anyway.18:18
robrupmcgowan: but yeah this doesn't block publication, if somebody wants to publish it they can18:18
pmcgowanrobru, this happened with something the other day and we just published18:19
pmcgowanrobru, who can publish it?18:19
robrupmcgowan: any core dev can do it18:19
pmcgowanthat again :)18:19
pmcgowanI nominate you for core dev18:20
pmcgowanmterry, ?18:20
robrupmcgowan: yeah that's on my to-do list but it's been getting away on me, sorry18:20
robruken is mysteriously not here, he's my go-to core dev18:20
mterrypmcgowan: maybe...?  robru, what's the story with unsatisifable depends?18:21
robrumterry: https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-068/excuses.html but I dunno, i guess android package is special18:21
pmcgowanmterry, this same thing happened with a silo the other day and ken just pushed it in18:22
pmcgowanbut I dont know why18:22
mterrythe hidden assumption there being that that was the right thing to do?18:22
pmcgowanseemed to be, somehow ken knew it was bogus, but I really dont know18:22
robrumterry: I see it this way: this silo isn't actually introducing the unsatisfiable depends (if you look at the diff), so I guess it's a false positive in britney or eg I guess the image builder just pulls it in regardless of the depends or something18:23
* mterry is going throught that silo's packaging diffs and then if nothing crazy, is happy to publish18:24
robrumterry: yeah you should be reviewing diffs before publishing generally ;-)18:24
dobeyhrmm18:24
robrumterry: https://requests.ci-train.ubuntu.com/#/ticket/99518:24
dobeyrobru: i think it's because the autopkgtests environments don't have multi-arch on maybe? if i install "ubuntu-emulator-runtime" on my machine, it pulls in the :i386 one18:25
mterryrobru: uh.. android-tools-5.1.1r36+git20160322/debian/android-tools-adb.postinst does some crazy stuff, including modifying the current user's (whoever that might be when installing!) ~/.android/adb_usb.ini...18:25
robrumterry: isn't postinst just run by root?18:26
mterryrobru: if you're running sudo, I'm guessing $HOME is still your user18:26
dobeyeww18:27
dobeythat is nasty18:27
robruit's clearly just appending device IDs so that they work without clobbering the existing file18:27
mterryrobru: or creating the file18:27
mterryrobru: that's against policy though, to muck with user files.  I think we do it in very few cases.  But usually we have user-migration scripts to do that in a sane way18:28
dobeyand that obviously doesn't help other users on the system who aren't the one running the apt-get install/upgrade18:28
mterryrobru: er session-migration18:29
mterryrobru: This should use a session-migration script, not muck with files directly.  I can't ACK this18:29
robrumterry: hang on, something funny is going on. I can't find this postinst script in the input mp.18:30
dobeyandroid-tools isn't managed in launchpad18:30
dobeythe indicator mp obviously won't have it18:31
robruoh, manual packages. great18:31
dobeyyup18:31
dobeyi don't understand why that wasn't done in a patch though, instead of a hacky postinst18:32
robrumorphis: what's up with android tools? ^^18:32
dobeythe comment even claims the source has some list compiled into the default client; obviously we should be patching that list18:32
mterrydobey: agreed18:34
dobeyondra just left though i think18:34
pmcgowanI don't even think thats true18:35
dobeywhich part?18:35
pmcgowanthings work fine without those18:35
pmcgowanI thought they were added elsewhere18:35
dobeywithout the adb_usb.ini ?18:35
pmcgowanyeah18:35
pmcgowanBQ and Meizu is not exactly new to us18:36
dobeyoh they were18:36
dobey+++ android-tools-5.1.1r36+git20160322/debian/patches/add-bq-vendor-id.patch1970-01-01 00:00:00.000000000 +000018:36
dobeyso someone needs to regeenrate a source package without the postinst muck, and re-upload to the silo ppa for both xenial/vivid18:37
dobey(i don't have permissions to upload to the PPA)18:37
pmcgowanwho does?18:38
pmcgowanI can email ondrej as he said he would be back online later18:38
dobeyi presume robru does. mterry does as well i guess, being a core dev18:38
dobeymterry: ^^ can you strip that postinst muck out and tweak the version numbers, and re-upload to the PPA?18:39
robrupmcgowan: yes for silo PPA uploads, it's core devs + me18:39
robrubut best let mterry do it so he can get it just right I think ;-)18:40
mterrydobey: so...  looks like the old patch got dropped, but the new IDs are still in the merged debian-changes18:40
mterrydobey: so I agree I'm not sure why the postinst stuff was done...18:40
mterrypmcgowan: morphis is best to do this, is he not around?18:41
pmcgowanmterry, dont know we can wait if its best18:41
dobeyprobably best to know who did that change exactly, and why18:42
mterrypmcgowan, robru: this is why I hate this "packaging-ACK" system -- last minute NACKs suck18:42
pmcgowanindeed18:42
dobeymterry: agreed18:42
robrumterry: totally agree, but I can't think of a way to get the ACKs coming sooner. there's no way to stop people making mistakes until they try to publish18:43
mterrydobey: well....  worst case if we strip out the bogus postinst stuff is that there is some manual config needed on dev machines.  But we won't break anything.  And that can be fixed by future patch...18:43
mterryrobru: unity8 has a merge checklist, one of which is getting a packaging ACK if there are packaging changes.  Hard to FORCE that on other projects, but they should all be doing that18:43
robrumterry: agreed, should we talk to upper management and get this enforced on all projects? ;-)18:44
dobeymterry: well, the IDs seem like they are still added. the diff just looks a little weird because the patches all have the source dir with version in them as the reference18:44
dobeybut maybe i read the diff wrong too18:44
dobeywho knows18:44
mterrydobey: I agree they look like they are still added.  I'm just confused that the postinst stuff was added in first place.  So if our first blushes are correct, removing postinst bits is harmless.  If we're wrong, at worst some devs have to add some manual bits until someone can correct better...18:45
mterrySo I'm just going to do the quick change and hope it is enough18:45
* mterry patches18:46
dobeymterry: well if the ID patches are required for existing phones, and they are in fact removed, i guess it will break adb for all the current devices too18:46
mterrydobey: true...  not just dev machines but like all our test tooling  :)18:47
dobeymterry: but i guess it will be easier to tell if the patches are still there in an unpacked tree, too18:47
mterrydobey: I'll try it on my phones here at least18:47
dobeyok18:47
dobeyif krillin still works, i guess it should be good18:48
dobeyrobru: fwiw, i /hate/ the checklist thing on unity818:48
dobeywould be nice to automate most of that work though18:49
mterrydobey: oh why?18:51
mterrydobey: ok...  recompiled locally, installed new adb.  did adb kill-server, made sure I didn't have my own ~/.android/adb_usb.ini...  Was able to get into both krillin and arale18:56
mterrydobey: I guess that's good enough18:56
mterryrobru, pmcgowan: new android-tools for xenial & overlay are building in silo 6819:00
robrumterry: thanks19:01
mterryPackaging for everything else seemed fine enough19:01
robrumterry: right, android was the one blocked by unsatisfiable depends, so that one was ok after all19:01
dobeymterry: i find the whole concept of "copy and paste this big block of text into your MP and answer all the questions" a bit insulting really.19:04
mterrydobey: eh I like it as a simple way to avoid forgetting things19:04
mterrydobey: I'm a forgetful person  :)19:05
dobeymterry: i like "make check" as a simple way of not forgetting things :)19:05
pmcgowanmterry, awesome thanks19:06
dobeyi don't know if there are tools for covering all parts of the debian policy, but would be nice to automate some of the stuff that we require a packaging ACK for, when it is possible19:09
mterrydobey: heh, snapshot the system before, if there are any deltas in $HOME, complain.  Repeat for all possible contents of $HOME  :)19:10
mterrydobey: or I suppose just grep for ~ or $HOME in a clever way in debian/19:11
dobeymterry: grep HOME debian/*.postinst seems easier19:11
dobeyheh19:11
mterrydobey: but you won't catch malicious people assembling variable names out of H, O, M, and E, who just want to write code and hate your checker19:12
dobeymterry: or encode it into some lintian check if there isn't one already19:12
dobeywell, we should fire those people :P19:12
mterrydobey: yeah... but how to fire them automatically...?  :P19:13
dobeymterry: like this: https://www.youtube.com/watch?v=Km6bFBSVty419:14
* mterry dusts off his fax machine19:15
dobeyi guess we should also maybe have an apparmor rule that prevents dpkg scripts from screwing with $HOME19:17
dobeywhoot19:17
dobeyhuh19:18
dobeymterry: i still see the postinst block in the xenial packaging diff19:19
dobeyerr, no19:20
dobeyvivid19:20
dobeyno, both19:20
mterrydobey: do you see a new changelog entry by me?19:20
dobeyno19:20
mterrydobey: the packages aren't "published" in that PPA yet19:20
mterrydobey: I don't know what queuebot is on about19:20
dobeyoh19:21
dobeyhmm19:21
dobeyah ok19:21
* mterry regenerates silo diffs19:24
mterrypmcgowan, robru: so I'm guessing you need to re-acquire QA signoff on silo 68?  Probably a quick smoketest to make sure it's still working is enough?  Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK.19:26
=== blr_ is now known as blr
robruToyKeeper: jibel: ^19:34
mterrydobey: chagnes regenerated19:35
pmcgowanmterry, thanks19:35
dobeygreat19:36
pmcgowanmterry, is the whole silo rebuilding?19:37
mterrypmcgowan: shouldn't be?  I did a diff-regeneration-only build, but that said it finished19:37
pmcgowangreat19:38
robrumterry: ok I commented on the ticket & the trello board, hopefully qa notices that soon enough19:46
ToyKeeperD'oh.  New adb silo isn't done after all?20:20
ToyKeeper... and the suggested test will break some other things I have running.  I may want to wait a bit until the other tests finish.20:21
pmcgowanToyKeeper, its a "really simple change" but prefer to sanity check20:22
robruSaviq: if you get a sec pls review https://code.launchpad.net/~robru/qtmir/inline-gles-quilt/+merge/29064621:55
robruToyKeeper: "Tell QA folks to rm ~/.android/adb_usb.ini, run "adb kill-server" and then try to adb into their device to confirm the change is OK."21:59
=== salem_ is now known as _salem

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