/srv/irclogs.ubuntu.com/2016/01/22/#ubuntu-ci-eng.txt

=== salem_ is now known as _salem
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
dbarthhey trainguards09:26
sil2100Morning o/09:27
dbarthjust for confirmation, do i need to publish https://requests.ci-train.ubuntu.com/#/ticket/856 or just merge09:27
dbarthhi sil210009:27
dbarthi don't want to derail if we re in deep freeze09:27
sil2100dbarth: hmm, why do the automated tests fail?09:28
sil2100There's no freeze, anything can land now :)09:28
sil2100I mean, there's the OTA-9 freeze but rc-proposed is unblocked09:29
dbarthchecking09:29
dbarthhmm ok09:29
sil2100It didn't appear on our publishable queue since the autopkgtests somehow seem to be failing09:30
robrusil2100: dbarth looks like the packages aren't installable in certain arches09:31
=== chihchun_afk is now known as chihchun
dbarthuh09:51
dbarthyet, the ppa has them all built09:52
dbarthrobru: where do you see that?09:53
robrudbarth: it's not a build depend, just a depend. So it's built but not installable09:53
robrudbarth: click the excuses link on the ticket09:53
dbarthuh, because of oxide ?!09:54
dbarthah sure, because oxide is not available on those arches09:54
robrudbarth: why does your package depend on oxide if oxide isn't available on those arches? is this a new dep?09:55
dbarthi wonder, cause that's the first time i see it blocked like this09:56
dbarthussoa uses oxide for providing the webview needed to create accounts or renew credentials09:56
robrudbarth: well the automated testing stuff is pretty new in bileto. previously you would have published this and it would just get stuck in -proposed.09:56
dbarthmardy: is that a new dep?09:56
dbarthah, that's why09:57
dbarthhow can we move this forward? the oxide-on-certain-arches problem will come back every 6 weeks09:58
robrudbarth: well if this is a new dep you'll have to fix the packaging so that it no longer builds on those arches, and also get the existing packages deleted from those arches, so it isn't counted as a regression.09:59
robrudbarth: if it isn't a new dep, i dunno how this ever worked before09:59
mardyrobru: it's not a new dep09:59
mardybut as far as I understood we are making an arm64 tablet, how can it be that we don't have oxide there?10:02
sil2100morphis: morning ping! You around?10:02
robrumardy: dbarth: well xenial apparently does not have v1.2 so it seems this silo depends on another silo to work? https://launchpad.net/ubuntu/+source/oxide-qt10:02
morphissil2100: morning!10:03
dbarthoxide is at 1.12 now10:03
robruno wait10:03
dbarthi guess oxide related builds have been approved by cjwatson most of the time10:03
robrusorry i was reading 1.11 as 1.110:03
sil2100morphis: hey! I was looking into the thing with importing device tarballs for mako and flo10:04
sil2100morphis: and if I understand everything correctly, all is good right now10:04
cjwatsondbarth: blink no10:04
robrudbarth: yeah I'm not sure what the deal is here. pitti is also a good person to contact re: unknown problems in excuses.html10:04
dbarthbut he was recommending to keep all arches on10:04
mardyrobru: I haven't been bumping the dependency version of oxide since a long time, oxide 1.2.0 should be quite old now10:04
morphissil2100: sounds great, let me have a look in a bit10:05
cjwatsondbarth: so can this package work in principle without oxide?10:05
dbarthbut ok, this is a new blocker because it is now enforced earlier in the process10:05
mardyrobru: do you think that removing the "(>= 1.2.0)" could help here?10:05
dbarthmardy: ^^ ? i would assume no, because that view is an essential part, right10:05
sil2100morphis: so I see the latest android upload was on the 11th, so new device tarballs for mako and flo got generated on the 12th10:06
robrumardy: I doubt it, because the existing version is 1.11, and 1.11 > 1.2 so it's not like this is failing because the ">1.2" requirement is what's holding it back10:06
cjwatsonoh, is this a dependency on liboxideqt-qmlplugin?  (my browser is still waking up)10:06
mardycjwatson: no, it really needs oxide10:06
morphissil2100: an imported into stable now?10:06
robrumardy: I wonder if -proposed has a broken version of oxide in it or something10:06
robrucjwatson: yes10:06
cjwatsonok, this is a weird special case10:06
sil2100morphis: not into stable, we only promote images to stable during OTA releases10:06
cjwatsonnot surprising you wouldn't know about it10:06
sil2100morphis: they're in rc-proposed10:07
mardyI guess that everything about oxide is very special :-)10:07
cjwatsonto keep things vaguely moving and because there were some initial problems, there are a few hacks in the Ubuntu proposed-migration installation10:07
sil2100morphis: but yeah, well, depends on what exactly you want to happen and what's the original question10:07
sil2100:)10:07
cjwatsonI'm guessing that robru didn't know about them and so didn't reflect them in the citrain one10:07
robrucjwatson: i dunno nuthin bout nuthin10:07
sil2100morphis: since I checked on things as per what was in the e-mail, but I might have misunderstood what you guys saw as the problem10:07
cjwatsonthe magic is in lp:~ubuntu-release/britney/britney1-ubuntu fauxpkg/FauxPackages and related scripts10:07
cjwatsonit pretends that liboxideqt-qmlplugin exists at the version in xenial-proposed on arm64/powerpc/ppc64el/s390x10:08
robrucjwatson: train is using exclusively britney210:08
cjwatsonamong other packages10:08
dbarthah, there you go, we're a FauxPackage! :)10:08
sil2100morphis: I just checked that new device tarballs were generated for the new android upload, at least for mako and flo10:08
morphissil2100: basically they should migrate to stable with ota910:08
robruk, so this isn't something I'm going to fix at 2AM.10:08
morphisthat was the expectation as we landed the android package in the overlay ppa for that10:08
cjwatsonit would be good to figure out how to clean this up; but perhaps you could forcibly override publication or something, since it won't be a problem for xenial-proposed to xenial migration10:09
sil2100morphis: since only for those two (and emulator, of course) the device tarball is autogenerated10:09
cjwatsoneverything in FauxPackages ought to go away really10:09
sil2100morphis: yes, it'll be in OTA-9 :)10:09
robrudbarth: IIRC it should be possible to publish the silo in spite of the failure, if not just get somebody to copy the packages manually10:09
dbarthcjwatson: would it be better to create "faux packages" for oxide on those arches, as opposed to not building?10:09
sil2100morphis: when reading yesterday I actually thought you meant that you guys uploaded a new android recently and didn't see any new device tarball popping up10:09
dbarthi mean, have the oxide build process "proceeed" but create empty blobs10:10
morphissil2100: yeah, that was around one two weakks ago10:10
cjwatsondbarth: I don't know if that's better, that would run the risk of people assuming it actually works :)10:10
morphissil2100: but if it will be in ota9, everything is fine :-)10:10
cjwatsonreally oxide-qt ought to be ported (certainly to arm64)10:10
cjwatsonI know that it's pretty touch-ish and so getting people to care about it on server-only arches is tricky, but it's so far down the dependency stack ...10:11
dbartharm64 makes sense at least10:11
dbarthor is there a package tag/marker/construct that can stub the missing arches and still say this is a dummy to informed users / installers10:13
cjwatsonnot really10:13
dbarthhmm ok; well, that's not a new problem, so i guess if you resorted to adding scripts around it, there's not really a better way10:14
dbarthsorry robru ;)10:14
dbarthi can keep the silo around until next week once you have time to update the train10:14
robrudbarth: cjwatson: sounds like the correct fix is to just restrict what arches the package builds on and then delete those other arches from the archive.10:15
robrudbarth: just publish it10:15
cjwatsonrobru: that's problematic in some cases due to a dependency stack above it10:15
cjwatsonrobru: I think I vaguely remember this case and it was *very* problematic10:15
robrucjwatson: how is something depending on something that isn't installable on whatever arch?10:16
cjwatsonrobru: it was only one binary package out of several, IIRC10:16
cjwatsonI don't remember the exact details10:16
robruhm10:16
cjwatsonbut it gave me conniptions trying to follow the stack up10:16
dbarthrobru: ok10:17
=== _salem is now known as salem_
* sil2100 off to lunch12:56
renatutrainguards, could you assign this ticket for me? https://requests.ci-train.ubuntu.com/#/ticket/91313:36
Mirvrenatu: done13:37
renatuMirv, thanks13:43
Saviqtrainguards, assign for https://requests.ci-train.ubuntu.com/#/ticket/914 please?15:38
sil2100Saviq: on it15:38
Saviqsil2100, thanks15:39
sil2100Saviq: done, yw!15:39
Saviqjibel, here's the request ↑, building now15:39
dobeyhmm. no more edit history?15:52
=== chihchun is now known as chihchun_afk
rvrkenvandine: Hey. I created a bug for the missing bluetooth address in System Settings > About.16:01
rvrbfiller just triaged it16:02
Saviqjibel, so, the fix we have for apps (not) closing is currently built on top of 4k+ diff of test refactoring (already top-acked)... we're looking into isolating the fix, but it might take a while, think we could land the test refactoring with it after all?16:05
jibelSaviq, how much time it "a while" approximately?16:07
Saviqjibel, dednick's trying to work it out now16:07
jibelSaviq, I'd rathe rjust land the fix16:08
Saviqjibel, yeah, I know, just pre-empting16:08
kenvandinervr, thx16:26
Saviqjibel, ok, looks like we've an isolated fix, building silo16:50
jibelSaviq, excellent, thanks16:53
sil2100Saviq: \o/16:54
sil2100Yeah, I was worried by the diff16:54
Saviqsil2100, robru, just realized train can't deal with private branches even if subscribed, we could use a fix for that16:55
=== chihchun_afk is now known as chihchun
SaviqOTOH the diff becomes public enough when it gets built (so maybe we need private silos ;))16:55
sil2100;)16:57
=== chihchun is now known as chihchun_afk
* sil2100 goes AFK for a while now17:32
sil2100I'll be back later once the silo is landed and a re-spin is required17:32
pstolowskihello trainguards, may i ask for help assigning a silo for https://requests.ci-train.ubuntu.com/#/ticket/915 ? it says we're low on silos, i freed one silo a moment ago but that didn't help18:04
sil2100pstolowski: yeah, there's a lot of those now18:11
sil2100Let me help you18:11
pstolowskisil2100, thanks18:11
jibelSaviq, we can start testing 14?18:14
sil2100pstolowski: done18:18
pstolowskithanks sil2100 !18:18
Saviqjibel, sorry, was otp, yeah, let's test in parallel18:59
jibelSaviq, rvr is on it and I just installed the silo19:00
* Saviq does in devel-proposed then19:00
jibelwe are testing on top of rc not rc-proposed19:00
Saviqack19:00
robruSaviq: I don't think private silos makes any sense. it's gonna be public when you release it to ubuntu anyway19:11
jibelrobru, there may be some code that you don't want to be public before it's released19:14
Saviqrobru, yeah, but the thing is you want to keep it under wraps for as long as possible19:15
robruSaviq: jibel: k, well it's not something I'm going to be able to do anytime soon. the ppas just are public. i won't be able to implement this until we have ephemeral ppas which is probably 6 months away.19:17
Saviqrobru, sure, just an idea19:17
robrudobey: charles: https://requests.ci-train.ubuntu.com/#/ticket/507 hasn't moved since the 13th, you guys still using that one?19:25
dobeyrobru: we're sprinting this week and i didn't get a chance to poke at the error from citrain19:25
dobeyrobru: but yes,, that still needs landing.19:26
robrudobey: ok no worries.19:26
charlesrobru, talking it over with dobey here, I think we should kill 507 after all. Marking as abandoned19:30
charlesrobru, thanks for the headsup19:30
robrucharles: oh, thanks19:30
robruTrevinho: https://requests.ci-train.ubuntu.com/#/ticket/685 hasn't moved since the 13th, can you poke the SRU team to get that moving?19:31
robrujgdx: https://requests.ci-train.ubuntu.com/#/ticket/692 hasn't moved since the 13th, you still using that one?19:32
robrujgdx: lol https://requests.ci-train.ubuntu.com/#/ticket/692 this has needed a rebuild since november 30th19:37
dobeyrobru: can i force re-run of an autopkgtest on a specific arch for ci train?19:40
robrudobey: heh, we were just sprinting to enable that feature but it's not out yet. you'll have to ask pitti19:40
Saviqjibel, rvr, so one unfortunate result is that camera sometimes restarts when the content hub's done with it19:40
dobeyrobru: only pitti?19:41
Saviqbecause it's a race between being stopped, suspended, resumed, crashed, whatnot19:41
rvrSaviq: :(19:41
robrudobey: I'm not sure who else, but definitely pitti. just a handful of people have ssh into the autopkgtest system to do retries curently19:41
Saviqjibel, rvr, content hub really needs to start using prompts instead of just switching between apps, as we either break normal app behaviour or the content hub one19:42
SaviqIMO content hub should not be killing the app at all when it's done with it19:42
dobeyok19:43
jibelSaviq, I saw that on previous builds too19:43
jibelbut it was pretty rare19:44
Saviqindeed19:44
michitrainguards: Could someone help with assigning a silo please?20:17
michiNeed one for ticket 91720:17
robrumichi: which one?20:17
robrumichi: ok you got 4620:18
michiBeaut, thank you! :)20:18
robrumichi: you're welcome20:18
jibelSaviq, did you find anything with the silo?20:22
jibelother than the app reopening20:22
Saviqjibel, nope, worked fine20:22
jibelSaviq, so I think it's good to publish.20:23
Saviqjibel, yeah, let me get someone to sanity-review20:23
jibelSaviq, can you approve it so propose migration can do its job20:24
Saviqjibel, right, doing20:24
jibelotherwise I cannot approve it20:24
jibelhm, actually I can. I'm pretty sure I couldn't last time I tried20:25
robrujibel: btw finally got queuebot fixed so it pings qa status properly again20:26
robrujibel: bileto will preserve an 'Approved' or 'Failed' value but if set to N/A, Required, or Ready it'll override the value with what it thinks is correct based on if the silo targets vivid overlay or not20:27
jibelrobru, thank you very much20:27
robrujibel: you're welcome20:28
jibelrobru, can we publish silo 14 before britney is done? it's running u8 tests which will fail21:20
jibelthere is no point in waiting21:20
jibelSaviq, ^21:21
robrujibel: Saviq: it's also running qtmir which can pass. but generally yeah you can publish even if it says fail21:56
robru... for now21:57
sil2100Ok, I'm publishing in that case22:00
=== salem_ is now known as _salem
sil2100Saviq: branches need approval!22:01
sil2100Saviq: all three branches please22:02
sil2100Eh, ok, I'll take this on me22:04
sil2100Saviq, jibel: approving the branches since we need this landed...22:04
Saviqsil2100, jibel, they're being reviewed now, we're worried the security fix isn't enough so we might need a follow up22:11
Saviqsorry guys, we're doing our best here, not enough hands22:12
sil2100Saviq: ok22:15
sil2100Saviq: I'll be doing the copies to snapshot and rc respins tomorrow22:16
sil2100Goodnight guys22:16
robruugh, 'publish failed' cleared the lander signoff23:49

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