kenvandinerobru, i don't think so00:41
kenvandinebeen there for quite a while00:41
robrukenvandine: Hmmmmmmm, train only found them in the xenial package00:44
kenvandineok, so maybe in the overlay ppa then and not vivid proper00:44
robrukenvandine: did the format change at some point? Train looks for debian/tests/control00:45
kenvandinei thought they landed before vivid was released, but likely wrong00:45
kenvandinenope, we use debian/tests/control00:45
robrukenvandine: but the package I'm testing i grabbed from overlay ;-)00:45
kenvandinethat has to have them00:45
kenvandinethere is no delta between overlay and xenial00:46
=== _salem is now known as salem_
=== salem_ is now known as _salem
robrukenvandine: can you comment on this failure? Is this expected? https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-ci-train-ppa-service-landing-019/xenial/armhf/c/content-hub/20151110_225444@/log.gz02:35
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
=== chihchun_afk is now known as chihchun
tvossgood morning08:25
tvossrobru, you happen to be around?08:25
tvossrobru, if so: what is our policy on landing to wily and xenial?08:25
tvossrobru, do we have a combined target for both available?08:25
=== alan_g is now known as alan_g|afk
sil2100davmor2, rvr: any news on silo 0?09:32
sil2100Since jibel mentioned that was the last one needed to land09:32
sil2100I don't see it even ready for QA..09:32
davmor2sil2100: you have as much info as I do, I just logged in ;)09:33
rvrdavmor2: sil2100: Nope, I have no news09:59
morphissil2100: ping10:03
MirvOTA-8 candidate bug #1514173 <- jibel, sil210010:04
ubot5bug 1514173 in ubuntu-ui-toolkit (Ubuntu) "[listitemlayout] setting RichText format with html image tag leads to crash (segfault)" [Critical,In progress] https://launchpad.net/bugs/151417310:04
jibelMirv, k, do you have an example of this crash with an application?10:10
Mirvjibel: I'm asking faenil to show up and tell about it10:16
Mirvor zsombi can fill in if faenil doesn't appear10:17
faenilMirv: here I am10:18
zsombiMirv: I only know that there is a crash, not sure whether the app has been released with it or not. I assume if this is a blocker, it means the release or RC doesn't have the changes which would cause the crash10:18
zsombifaenil: ^ do you have an answer to this?10:18
zsombifaenil: Mirv: if the app changes are not in RC, then it's not OTA-810:18
faeniljibel: re the bug, it's a bug I found while playing with the component, apps are in the process of transitioning to ListItemLayout, so I can't say if any of them causes the crash10:18
zsombijibel: faenil: then it smells to me it's OTA-910:19
faenilif there's any app released in OTA8 that uses ListItemLayout with an <img> tag in the text, it's going to crash10:19
faenilzsombi: let's hope no apps released for OTA8 trigger the bug then...10:20
jibelfaenil, do you have an example of such app?10:21
faenilit's a risk...but if it's too much trouble to pull the fix in for OTA8, then yes, it's not a really common usecase10:21
zsombifaenil: show an app from RC image that has this crash10:21
faenilzsombi: jibel I don't know. Telegram uses <img> in its delegates, but Telegram is not using ListItemLayout yet10:22
zsombiOTA9 then10:22
jibelfaenil, zsombi well a crash in the sdk sounds critical to me, if the fix is safe and you can kand just this fix then it's worth preparing a silo and then we can decide to land or not in ota810:23
sil2100morphis: pong10:23
morphissil2100: OTA8 is now in freeze, right?10:23
sil2100jibel: we still waiting for silo 0 or should I do the snapshot and first rc candidate without that?10:23
zsombijibel: all AP tests are crashing here'n'there lately... no idea where the crash is so far... bzoltan_ suffers with this for days10:23
sil2100morphis: yes, we don't accept anything else for ota810:23
morphissil2100: just wanted to know when the doors are open for ota9 things10:23
jibelsil2100, wait, probably more fixes to land today10:24
sil2100morphis: you want to land anything to the overlay?10:24
bzoltan_jibel:  I do... I really do10:24
morphissil2100: nothing for ota810:24
Mirvfaenil: it's not that much about trouble but the risk involved in changing UITK at this point. so it depends on how risky the fix is.10:24
=== alan_g|afk is now known as alan_g
sil2100jibel: uh, so we stay frozen? Since we could let ota9 landings land to the overlay, but it would make things confusing for me as I would have to cherry pick to the snapshot10:24
zsombijibel: bzoltan_ so as doors are closed, nothing will go for ota8 anymore, ota9 will get the fix, but first we have to find what causes the random crashes on AP!10:24
jibelsil2100, yes, we stay frozen10:24
faenilMirv: I'd say the fix has quite low risk, but if pulling that fix will pull more stuff from recent uitk releases, then I can't say10:25
=== sil2100 changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: OTA-8 preparations in progress, overlay landings frozen temporarily
faenil(I don't know if you cherrypick it)10:25
Mirvfaenil: yeah it would definitely need to be single cherry-pick fix if something. but those AP problems zsombi mentions complicate the issue.10:25
faenilMirv: ok10:25
zsombifaenil: we already have few bugs we cherrypicked, and those were OK with AP... but something got basted since then10:26
faenilzsombi: ok10:27
bzoltan_zsombi: jibel: brendand knows about it and he knows how to reproduce the issue.. IMO it is a showstopper one.10:29
faenilI agree with jibel that a crash fix is a crash fix, it shouldn't be postponed. But given there are AP failures and the ListItemLayout bug requires a quite special usecase to be triggered, it could make sense...10:29
faeniljibel: just saw your tag. that bug is not a regression (fyi).10:30
faenilit is a new component (introduced in OTA7), the bug has always been there since the component was released10:31
faeniljibel: ^10:31
brendandbzoltan_, btw i'm looking at that now, i reproduced the issue10:31
jibelfaenil, ok, thanks for the clarification10:32
faeniljibel: np :)10:32
bzoltan_brendand: thanks man!10:32
brendandbzoltan_, apart from the crash though what about all the failures?10:33
bzoltan_brendand:  I would be happy to jump on them and fix them.. but first is to bring back the AP tests to non crashing state10:34
brendandbzoltan_, i'm still not sure why the crash is happening but it is related to test failing, so no failures, no crashes :P11:09
bzoltan_brendand: Nice try :) but no. The Unity/Mir should not crash after a failing AP test... AP tests to very simple user interaction stuff.. apps could do the same.11:10
brendandbzoltan_, it happens when trying to write some error logs to the result11:11
bzoltan_brendand:  then it is an autopilot bug + a regression in Mir/Unity11:11
brendandbzoltan_, it's neither of those11:11
brendandbzoltan_, it's a testtools bug that's being exposed by lots of failures in uitk tests11:12
bzoltan_brendand:  what else could it be? Can not be UITK because I do have logs from the very same UITK with a different image... image changed, UITK AP tests crash... so something has landed11:12
bzoltan_brendand: nice try again... but please do not try to blame the UITK for something what it is not responisble for. No AP should crash the shell11:13
brendandbzoltan_, every time a test fails it tries to write some extra logs and at some point (probably on a race condition) that is not working and it crashes autopilot11:13
bzoltan_brendand:  Okey, then it is an autopilot bug11:13
bzoltan_brendand:  failing test must not crash the whole system11:13
brendandbzoltan_, of course11:14
bzoltan_brendand:  and we are not seeking 100% test success here... we are trying to prevent regression.. so tests failed yesterday can fail today... but tests failed yesterday can not block other test runs.11:14
bzoltan_brendand:  I am sure that something has landed in the last weeks what made this regression... because it is a serious regression.11:15
brendandbzoltan_, it's pretty unlikely to have been either testtools or autopilot though as they are practically static. i'm sure it's an existing issue there that's been exposed by some change11:27
bzoltan_brendand:  Most probably ... not the first time that somebody just dumped an untested crap on the Overlay... untested I mean not running the UITK tests.11:29
bzoltan_brendand:   do we have a dashboard to see since what image the UITK tests crash?11:29
brendandbzoltan_, nope11:30
bzoltan_brendand:  we used to have such dashboard :(11:30
brendandbzoltan_, we did, but only a handful of people took any responsibility for it11:31
brendandbzoltan_, whereas everyone was supposed to11:31
bzoltan_brendand: :(11:31
brendandbzoltan_, and some other changes meant the tests stopped being run a while back11:31
brendandbzoltan_, you could get a jenkins instance from ci and set up a regular run11:32
bzoltan_brendand: so what should we do now?11:40
bzoltan_brendand:  what disturbs me a lot is that stuff can land and screw up UITK tests without much control11:41
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
mardyrvr: hi! Did you manage to test silo 1 with the new click?12:11
rvrmardy: Nope, needed to land a higher priority silo12:12
mardyrvr: ok12:12
=== _salem is now known as salem_
=== xavigarcia is now known as xavigarcia_lunch
=== alan_g is now known as alan_g|lunch
=== xavigarcia_lunch is now known as xavigarcia
tvosssil2100, ping13:45
boikojibel: bfiller: not sure if there is still time, but: https://requests.ci-train.ubuntu.com/#/ticket/63813:49
pmcgowanboiko, yeah we want that one13:58
pmcgowanmark it when ready13:59
boikopmcgowan: ready already13:59
=== awe is now known as awe|afk
pmcgowandavmor2, then ^^13:59
pmcgowanboiko, is it marked ready?14:00
pmcgowanoh it is14:00
boikopmcgowan: yep14:01
davmor2pmcgowan: is that silo 014:02
davmor2ah no 5514:03
=== barry` is now known as barry_
=== barry_ is now known as barry
davmor2rvr: ^^ silo 55 is in jibel's list of bug fixes14:03
davmor2pmcgowan, boiko: any news on silo014:04
boikodavmor2: salem_ is working on it, fixing a bug bfiller found14:04
davmor2boiko: nice thanks14:05
pmcgowandavmor2, which image has silo 2? its not working here for me14:17
davmor2pmcgowan: 172 on krillin14:19
pmcgowandavmor2, not working on mako or mx4 for me14:19
pmcgowanwith whatever I got this morning14:19
pmcgowandavmor2, I understood it would be in the next image14:20
davmor2pmcgowan: yes the one that landed last night 172, 171 was the last build yesterday14:21
pmcgowandavmor2, I am saying the update I got an hour ago does not have it, is that expected?14:21
pmcgowanor is it me14:22
davmor2pmcgowan: opening here I get a location on the front road almost instantly14:22
ogra_on MX4 image 162 location works fine again for me too14:23
davmor2pmcgowan: http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/172.commitlog14:24
pmcgowansomething wrong here14:25
pmcgowanabout telss me I have 154 which I updated to 11/1114:25
pmcgowanI have the wrong channel14:28
davmor2pmcgowan: indeed somehow14:28
davmor2pmcgowan: that sounds most strange14:29
pmcgowandavmor2, last time I reflashed I picked poorly14:29
pmcgowancockpit error14:29
davmor2pmcgowan: https://www.youtube.com/watch?v=Ubw5N8iVDHI14:30
pmcgowandavmor2, I just bricked my phone with a wrong flash14:32
pmcgowanforgot to give it a channel so it installed v114:32
=== alan_g|lunch is now known as alan_g
davmor2pmcgowan: ouch yeah that will do it, for mx4 power and volume down to get to bootloader, for mako power and volume+ & volume-14:33
pmcgowandavmor2, its back14:33
pmcgowannow to fix it14:34
davmor2pmcgowan: you all sorted now?14:42
pmcgowandavmor2, waiting to see, it keeps saying failed to enter recovery but then finishes14:42
pmcgowanubuntu spinny logo14:42
davmor2pmcgowan: https://wiki.ubuntu.com/QATeam/ChannelsToFlash  does your flash command resemble the ones on that page?14:44
pmcgowandavmor2, I have 162 now14:45
davmor2pmcgowan: and does location work now?14:45
pmcgowandavmor2, at some pint I used ubuntu instead of mezu.en14:45
=== awe|afk is now known as awe
pmcgowandavmor2, yes, bam14:46
davmor2pmcgowan: \o/14:46
salem_trainguards, hi, can you guys help me with silo 0 and 20? we created two silos because we can't dual land libphonenumber as it's a source package, but we have to land dialer-app along with the libphonenumber change. But the vivid silo now complains about versioning of dialer-app. how should I proceed?14:53
xavigarciatrainguards: hey guys, one question... I see silo 46 landed. Just would like to know if it landed for ota-8 or ota-914:58
xavigarciatrainguards: please note that the silo adds some new strings that need to be translated14:58
=== chihchun is now known as chihchun_afk
sil2100salem_: I'm on holidays right now but let me try taking a quick look14:59
sil2100salem_: ok, seeing the vivid silo it seems dialer-app needs a rebuild15:00
xavigarciasil2100, Hi there... sorry to bother you, I know you are off today... silo 46 landed and in case it landed in ota-8 I think we might have problems... the silo adds new strings that I'm not sure are translated15:05
salem_sil2100, I tried that, but I believe the problem here is that I am using the same MR on both silos. we usually do dual landing for dialer-app.15:06
sil2100salem_: ah, yeah, that won't do...15:06
sil2100salem_: you can just have a separate silo for just dialer-app if anything and dual land that there15:07
sil2100If, of course, you don't need to build against the new libphonenumber explicitly15:07
salem_sil2100, yes, we don't. I think I will end up doing that. thanks!15:07
sil2100salem_: this would make some things easier, and you can ask QA to for instance signoff both at once15:08
salem_sil2100, yeah, will do that. thanks for the help. enjoy your holidays :)15:08
alecusil2100: sorry to bother, but we are concerned with xavigarcia about silo 46 being published15:09
alecusil2100: we decided to delay it to OTA-9, but it seems that it was published yesterday: https://ci-train.ubuntu.com/job/ubuntu-landing-046-2-publish/27/15:09
alecuwas it somehow published to OTA-8?15:10
alecuany other trainguard around? ^^^15:11
sil2100alecu: it was signed off so we landed it, it was rebuilt without the dep-changes right?15:12
alecusil2100: yes, it was rebuilt without that, but it was bounced by cyphermox after that15:13
alecusil2100: and since it was already late, we decided to postpone it to ota-915:13
alecuwe added a note about that to the silo: https://requests.ci-train.ubuntu.com/#/ticket/52815:14
alecusil2100: the thing is that it adds a few strings that are very user-visible15:14
alecuthose are shown whenever you change the volume15:14
alecujibel: ^ should we revert it?15:15
sil2100hm, well, that's bad in that case15:15
cyphermoxfwiw it wasn't just the dependency issues that bothered me, but also the fact that there are changes that have no relation to the changelog entry.15:15
sil2100cyphermox: those all were fixed, there were no packaging changes15:15
sil2100Since I was able to publish it with my powers15:15
alecucyphermox: yes, I think you did right to bounce it at that point15:15
cyphermoxI don't know; I still see these changes in the build job15:16
sil2100cyphermox: if there were packaging changes I wouldn't be able to publish as it's a main package15:16
cyphermoxand on the publish job15:16
sil2100And I'm a MOTU15:16
cyphermoxsil2100: it doesn't matter in this case, that wasn't the problem15:16
cyphermoxmy issue with it, and it looks unresolved, is that there are a dozen files added that aren't obviously mappable to adding OSD notifications15:17
alecuxavigarcia: cyphermox is right: the silo diff still seems to contain all of the testing harness15:18
cyphermoxin other words, this is a new version, it probably should say that it's a new upstream version, or list the changes that introduce, for instance, the files in gmenuharness15:18
renatuMirv, ping15:18
cyphermoxI realize this is likely tests, but it's not so good to include changes that aren't listed in changelog15:19
alecucyphermox: agreed.15:19
alecuso, should I ask to revert this?15:19
cyphermoxalecu: I'm not sure I'd bother unless there is another reason to15:20
alecucyphermox: the big reason is that this adds new strings, and that they are very user visible15:20
xavigarciaalecu, cyphermox: the files are present but are no longer compiled15:20
cyphermoxxavigarcia: it's irrelevant, we don't necessarily see what is compiled and what isn't from a quick look at the diffs15:21
cyphermoxalecu: strings aren't an issue for xenial, at least15:21
cyphermoxfor vivid, you need an SRU bug in which case it may be arguable.15:22
boikotrainguards: could you please remove dialer-app from silos 0 and 20 PPAs?15:22
alecucyphermox: I think we only want to land in the phone vivid overlay, not in vivid itself15:23
sil2100boiko: done15:24
alecucyphermox: and I worry if this has landed in the overlay, because ota-8 will have those strings untranslated.15:24
cyphermoxalecu: that's up to you I suppose15:25
boikosil2100: thanks15:25
renatuMirv, could you get a silo for this? https://code.launchpad.net/~renatofilho/ubuntu/vivid/qtpim-opensource-src/fix-1514350/+merge/27726415:25
cyphermoxalecu: sil2100: shouldn't we be trying to land things for the overlay as SRUs as well though?15:28
cyphermoxie. not just in the overlay but also in vivid15:28
boikosil2100: so, on silo 0, I removed dialer-app from the source package names, but it stills shows the silo as dirty saying dialer-app needs rebuilding15:30
alecucyphermox: sorry, otp. I understand that the changes here apply to the phone, so we need the on the overlay, and I'm not sure about SRUing them15:51
alecuxavigarcia_: can you confirm that? ^15:51
xavigarcia_alecu: yeah, the changes apply to the phone15:55
xavigarcia_alecu: the desktop is not showing those strings15:56
alecuxavigarcia_: great15:56
pmcgowananother update just popped up16:05
alecuhi trainguards, may we ask to revert this landing? https://requests.ci-train.ubuntu.com/#/ticket/52816:09
greybacktrainguards: this should really go in for ota8: https://requests.ci-train.ubuntu.com/#/ticket/62716:10
greybackI keep forgetting if I'm supposed to click "publish" or that's a guard's job16:10
rvrbfiller: ping16:12
=== ev_ is now known as ev
=== Ursinha_ is now known as Ursinha
brendandbzoltan_, can you return the favour and have someone look at https://code.launchpad.net/~brendan-donegan/ubuntu-ui-toolkit/swipe_into_view_keyboard/+merge/27380516:21
brendandbzoltan_, it's been sitting around for a while16:21
bzoltan_brendand:  sure16:21
brendandbzoltan_, i just managed to do a full run without it crashing :/16:22
brendandbzoltan_, not really a good thing, but interesting16:22
pmcgowangreyback, yeah 44 can publish16:22
bzoltan_brendand:  how did you do that???16:22
bzoltan_brendand:  must be black magic16:22
brendandbzoltan_, luck maybe16:23
bzoltan_brendand:  tomorrow I will eliminate 50% of the failures ... about that much fails because of the popover button introspection.16:24
brendandbzoltan_, yeah there were a lot of those16:24
greybacklousy luck, newer qtmir pushed to -proposed, but problem to fix on armhf xenial16:31
rvrjgdx: ping16:41
robrugreyback: that silo was already published when you published it17:12
greybackrobru: yeah? Sorry, the train made it look like it wasn't17:13
rvrboiko: ping17:13
robrugreyback: look at the audit log on the ticket. sil2100 published it, it was migrating, you published it again17:13
robrugreyback: what did it look like when you clicked published?17:13
greybackrobru: ok, then was my bad timing17:13
greybackas it definitely had the QA signoff as the last thing in the log when I clicked publish17:13
robrugreyback: the full log is hidden by default. the status would have said "x is in the proposed pocket" which means "this is already published" when you published.17:14
greybackrobru: sure, that I know. Perhaps I hadn't hit F5 soon enough17:15
greybackrobru: anything broken?17:15
robrugreyback: doubtful: sil published it ~20 hours before you, and the page auto-refreshes every 3 minutes. ;-)17:15
robrugreyback: no nothing broken. but probably worth checking why it's in proposed for so long17:15
greybackrobru: yeah I'm trying to figure that out, something weird with xenial17:16
robrualecu: still want that reverted? I can do it if you're sure.17:17
robrutvoss: the train is technically capable of doing a xenial+wily silo but this isn't exposed in the UI because I'm not aware of a use case for it.17:19
alecurobru: yes, we'd like to revert that silo, please.17:19
alecurobru: thanks!17:20
robrualecu: just to confirm: you want to go back to 12.10.2+15.10.20151019-0ubuntu1 right? that's the one before the most recent upload.17:24
boikorvr: pong17:31
rvrboiko: Hi17:31
boikorvr: hello17:31
rvrboiko: I'm testing silos 49 and 017:31
boikorvr: ok17:31
rvrboiko: I did a dial-number /ril_0 123456789#1 and worked17:32
rvrboiko: Do you need any specific test?17:32
rvr(also tried with the dialer app, manually)17:32
boikorvr: nope, that's it, and also make sure you create a contact with a number including a #, and try to call from address-book-app17:33
rvrboiko: Nice, trying...17:33
boikorvr: why is 55 blocked?17:34
rvrboiko: Cannot reproduce17:35
boikorvr: ah ok, in any case, the fix is harmless, in dialer-app's live call view there will be only at most one header section, so we just set the selectedIndex to zero17:35
alecurobru: if that's the previous version, then yes. Where can I check all the versions?17:36
robrualecu: sorry, that didn't work, apparently reverts don't work on dual silos. switched to revert in vivid only and now it's reverting down to 20151014. but it looks like that is the second most recent version in the overlay:17:37
boikorvr: you tried to reproduce in the latest rc-proposed?17:40
robrualecu: once it's built I'll get you to review the diff to make sure it has sensible contents.17:40
rvrboiko: Yes17:41
robrualecu: also this revert will only be in vivid, it won't revert your trunk or anything, so you'll be able to keep developing on your same code until you're ready to release again17:41
boikorvr: let me try here17:41
rvrboiko: Address book and messaging app can dial to numbers with #17:42
boikorvr: great! so the problem is fixed17:42
rvrboiko: I'm going to do some extra sanity checks, and will approve is everything is fine.17:43
boikorvr: thanks17:45
alecurobru: sounds great, thanks17:54
alecurobru: when you say that the revert will be in vivid, do you mean the overlay?17:55
robrualecu: yeah17:55
robrualecu: https://ci-train.ubuntu.com/job/ubuntu-landing-057-1-build/lastSuccessfulBuild/artifact/indicator-sound_content.diff/*view*/ this looks a little weird to me17:56
robrualecu: aside from the changelog being completely nuts, do the code changes make sense to you?17:59
robrualecu: my reading of that diff is that there are 52 files just being totally removed. does that sound right? the most recent landing added 52 new files?18:00
=== alan_g is now known as alan_g|EOD
pmcgowanxavigarcia, ^^18:05
robrupmcgowan: xavigarcia alecu: if that diff is not correct, I'm not sure what went wrong or how to fix it. You'll have to prepare your own merge to revert the changes you don't want. Sorry guys18:07
=== alexabreu is now known as alex-abreu
xavigarciarobru: what error do you get?18:12
robruxavigarcia: what? I don't get an error. I built a package that is ostensibly a revert of the last release except the contents make no sense to me, i want you to review it: https://ci-train.ubuntu.com/job/ubuntu-landing-057-1-build/lastSuccessfulBuild/artifact/indicator-sound_content.diff/*view*/18:13
xavigarciarobru: ok... let me take a look18:13
alecurobru: sorry, was having a late lunch18:16
rvrboiko: Could you reproduce the label issue with latest rc-proposed?18:21
xavigarciarobru: diff looks fine to me18:22
xavigarciarobru: there were many new files in that silo18:23
robruxavigarcia: ok, with your approval I'll release that to vivid overlay then.18:23
boikorvr: nops, not happening, but still, the fix is correct, we cannot rely on the SDK selecting anything by default18:23
robrupmcgowan: alecu: xavigarcia: ok the package is now in vivid overlay, so ota8 won't contain the most recent landing. feel free to make a new landing when you're ready18:26
alecurobru: yay! \o/18:27
alecurobru: thanks a lot.18:27
xavigarciarobru: thanks!18:27
robrualecu: xavigarcia: you're welcome18:27
rvrboiko: I see18:39
rvrboiko: I think it first needs to set a default SIM18:40
boikorvr: well, shouldn't make a difference, but who knows? :)18:42
rvrboiko: Approving silos 49 and 018:55
boikorvr: great! thanks!18:56
boikorvr: with that in mind, I think it is a good idea to also approve silo 20 (which is the xenial silo for the libphonenumber changes)18:56
boikopmcgowan: should I go ahead and merge those?18:57
pmcgowansure they are happroved18:57
rvrboiko: davmor2: Approving silo 55.19:24
davmor2rvr: nice19:25
boikotrainguards: publishing silo 0 failed because it says it's dirty, that dialer-app needs rebuilding, but dialer-app is not on that silo anymore19:38
boikorvr: davmor2: great! thanks, I will just have to rebuild that after silo 49 lands19:39
boikorobru: could you please check what is going on with silo 0?19:41
robruboiko: one sec19:57
boikorobru: thanks19:59
robruboiko: ok, had to manually drop dialer-app from inside jenkins' local silo dir, just doing a WATCH_ONLY to clear up the status, should be ready to publish as soon as that finishes20:00
boikorobru: thanks20:02
boikorobru: turns out I am not authorized to publish libphonenumber, could you please publish it?20:08
robruboiko: if you're not authorized, neither am i. You need a core dev20:08
boikorobru: anyone here who could do that?20:09
davmor2boiko: slangasek might be able to help20:10
robruboiko: i usually poke kenvandine or mterry20:10
slangasekit's a US holiday today20:10
davmor2boiko: don't forget to land 20 too20:11
slangasekbut I happen to be around so I'll have a look20:11
boikodavmor2: that's my next question: do you guys need to validate it?20:11
boikodavmor2: it is the same changes as silo 0, but targetting xenial20:11
boikoslangasek: thanks20:11
davmor2boiko: we don't touch xenial yet20:11
boikodavmor2: so it is just landing and that's it?20:12
davmor2boiko: that can just land the important one was 49 which touches both20:12
davmor2boiko: yeap20:12
boikodavmor2: ok, let me change the silo20:12
boikoslangasek: if that's not asking too much, could you please publish silo 20 too? (same changes as silo 0, but for xenial)20:13
slangasekboiko: I'm surprised by the version number of the libphonenumber package for vivid; is this targeted as an SRU, or for the phone overlay ppa?20:15
boikoslangasek: phone overlay20:16
slangasekboiko: then it must not use this version number, which is reserved for SRUs20:16
boikoslangasek: ah, I think that's missing in the silo20:16
boikoslangasek: what version number would be fine?20:17
slangasekboiko: the previous changelog entries show '6.0+r655-0ubuntu7vivid1', '6.0+r655-0ubuntu7vivid2' - something in that vein is probably ok20:17
slangasekrobru: ^^ is there a specific numbering convention boiko should use here?20:17
boikoI think kenvandine advised salem_ to use that version number20:18
boikonot sure why20:18
slangasekwell, unless it's targeted for SRU, it's wrong and a problem20:18
slangasekas it would lead to any later SRU of libphonenumber in vivid having the same number but different content20:19
robruslangasek: boiko: train only enforces a certain version for MPs, so no preference on my end for manual sources20:19
slangasekrobru: sure, but what's the convention?  maybe there's something we can use for consistency20:20
boikoI have no preference either (and no knowledge about the policies for that)20:20
robruslangasek: well it would be upstream+15.04.YYYYMMDD-0ubuntu120:21
slangasekso no help for this ;)20:21
robruMaybe Ken thought it was an SRU20:21
boikorobru: would it be possible to tweak the versioning in the silo ppa, or do we have to go through all the uploading, building, etc again?20:21
slangasekthe package needs reuploaded and rebuilt20:22
robruslangasek: I'm not sure why the existing version has +rNNN in it, not familiar with that convention. I mean i get it's a revno but dunno who's idea that was20:22
robruboiko: no way to change the version without a new upload20:22
boikorobru: ok, I will ask salem_ to provide a new package, which version you advise us to use? I have really no idea there :)20:23
robruboiko: i guess 6.0+15.04.20151111-0ubuntu1 unless anybody has a good reason to keep the revno in there20:24
boikosalem_: ^20:24
boikosalem_: can you provide a package with that versioning?20:25
boikoslangasek: what about the version in silo 20? is that one ok?20:26
salem_robru, boiko sure, but it doesn't match the previous versions in the overlay ppa, is that ok?20:26
salem_last one was 6.0+r655-0ubuntu7vivid220:26
boikoslangasek: 7.0.8-0ubuntu320:26
boikoslangasek: (for xenial)20:26
robruboiko: salem_: wait, that version I said isn't actually higher than the one already there20:28
robruboiko: salem_: I guess just use 6.0+r655-0ubuntu7vivid3 or something. I don't know where that scheme came from20:29
robruboiko: salem_: if you guys ever do a 6.0.1 or a 6.1 it'd be nice to switch to the train style versions for consistency20:30
boikorobru: we are not upstreams for that, I think kenvandine wanted to change the packaging to be able to do dual landings, that might include fixing the versioning20:31
slangasekboiko: yes that version is ok for xenial20:36
boikoslangasek: would you mind publishing it then?20:36
=== salem_ is now known as _salem
slangasekboiko: I haven't looked at the actual package yet - what's the ticket number?20:37
boikoslangasek: https://requests.ci-train.ubuntu.com/#/ticket/62220:38
slangasekboiko: ok, publishing20:43
boikoslangasek: thanks!20:43
boikorobru: package with the right versioning (we used 6.0+r655-0ubuntu7vivid3) building in a ppa on my launchpad page, I'll let you know when it finishes so that you copy it to the silo 0 ppa20:45
robruboiko: is your ppa devirt? If not we can just do a source copy now20:46
boikorobru: what is devirt? If I am supposed to know, then my PPA is not :D20:47
boikorobru: https://launchpad.net/~boiko/+archive/ubuntu/source-uploads/+packages20:47
robruboiko: yeah train PPAs have special builders, so i can't binary copy, have to source copy and rebuild.20:49
boikorobru: that's fine20:49
boikorobru: thanks20:51
robruboiko: UGH that version is lower than the version in the PPA20:52
boikorobru: yeah, I guess so20:52
robruboiko: let's free the ppa and get you a new one20:52
boikorobru: ok20:52
robruboiko: I'll do it20:52
robruboiko: OK building in silo 6 now, when it finishes please give it a quick smoketest to make sure nothing exploded in the rebuild20:58
boikorobru: sure thing, thanks for the help20:58
robruboiko: you're welcome20:59
boikorobru: all good with silo 621:30
boikoslangasek: if you are still around, mind publishing it? we had to reassign the silo to fix the version: https://requests.ci-train.ubuntu.com/#/ticket/62321:31
boikopmcgowan: if slangasek is not around anymore, we just need a core dev to publish silo 6, all the other dialer-app related silos are publishing already21:35
pmcgowanboiko, wonder who is working21:37
pmcgowanrsalveti, ?;)21:38
pmcgowanmaybe cyphermox is around21:39
cyphermoxwhat's up?21:52
pmcgowancyphermox, hey, we want to publish silo 621:56
cyphermoxtiagosh, boiko: usually I'd expect to see comments in the patch following the DEP-3 patch tagging guidelines, but I'm not going to block that publishing on it21:59
cyphermoxnote that there's another issue with the package, the version number isn't sustainable, as soon we'll be at something that might not map as being bigger than z, so it would be better to use release numbers rather than release codenames in the version number.22:00
cyphermox(by that I mean the "vivid" in 6.0+r655-0ubuntu7vivid3)22:00
* cyphermox presses the buttons22:01
cyphermoxplease make sure this lands in xenial too; as well as an SRU in the appropriate releases as necessary.22:03
cyphermoxoh, I see it's already in xenial22:03
pmcgowancyphermox, thanks22:06
cyphermoxfwiw: # as a dialable char, useful ;)22:07
boikocyphermox: thanks22:11
robrucyphermox: yeah i mentioned already getting them on the train version scheme but unfortunately "15.04" isn't newer than "r655" so it won't work until they bump the upstream number.22:12
cyphermoxrobru: you could just replace "vivid3" ".15.04.3" or something to that effect22:13
robrucyphermox: i think that would interfere with the SRU versioning22:14
cyphermoxplus given that we just do snapshots all the time, the upstream version numbers are close to meaningless, except for here when we're doing sru22:14
cyphermoxrobru: not that much22:14
robrucyphermox: are we the upstream of this project? If so why is it not using MPs?22:14
cyphermoxit just needs some extra fudging, like adding a .$n more above whatever version is SRU'd to vivid22:15
robruboiko:  ^^22:15
cyphermoxrobru: there's always a way to make the version numbering work for what we need it to do, without using release codenames22:15
robrucyphermox: yeah i agree the codenames are bad in version numbers22:16
robrucyphermox: ironically this whole mess started because Steve rejected "0ubuntu7.1" as a version because it would conflict with SRU versioning22:17
cyphermoxI mean, it's true that it would22:17
cyphermoxwhat you want is probably always something higher than whatever might be in vivid-proposed until you merge between proposed and overlay22:17
cyphermoxso, 0ubuntu8~15.04.1 ?22:18
cyphermoxas opposed to the SRUs which will always grow from 0ubuntu722:19
cyphermoxbut all this quickly becomes quite ugly22:19
robrucyphermox: yeah tilde is probably better for wedging versions in between other versions22:19
cyphermoxIMHO the overlay needs to disappear and we need to find some way to be more agile at doing SRUs, which is a process we already are pretty good at I think22:20
cyphermoxeither that or getting back to the ubuntu-rtm derived distro?22:21
robrucyphermox: agree that overlay PPA is a gross hack, but disagree about SRUs. In my experience they take months of pain each. Better solution is just build phone images on dev series22:22
robrucyphermox: rtm was a bad idea, let's never mention it again22:22
cyphermoxrobru: I don't know that I'm sure of that.22:27
cyphermoxand let's not fool ourselves, the overlay PPA is SRUs, just with relaxed regression checking.22:28
cyphermoxbbl, I need to make a phone call :/22:28
robrucyphermox: yeah, "relaxed regression testing" meaning "not having to wait months for your SRU to get approved"22:28
cyphermoxyou don't have to wait months to get SRUs approved; if you do it right it can take just 7 days, just long enough to have a bit more assurance in proposed that things aren't breaking22:29
robrucyphermox: heh, "just 7 days", we fly by the seat of our pants in phone land.22:30
robrucyphermox: pat is currently freaking out because a 9 hour delay on an image build is too long.22:30
cyphermoxI'm not saying either option is perfect.22:30
=== _salem is now known as salem_

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