[00:41] robru, i don't think so [00:41] been there for quite a while [00:44] kenvandine: Hmmmmmmm, train only found them in the xenial package [00:44] ok, so maybe in the overlay ppa then and not vivid proper [00:45] kenvandine: did the format change at some point? Train looks for debian/tests/control [00:45] i thought they landed before vivid was released, but likely wrong [00:45] nope, we use debian/tests/control [00:45] kenvandine: but the package I'm testing i grabbed from overlay ;-) [00:45] that has to have them [00:46] there is no delta between overlay and xenial === _salem is now known as salem_ === salem_ is now known as _salem [02:35] kenvandine: 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.gz === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk === chihchun_afk is now known as chihchun [08:25] good morning [08:25] robru, you happen to be around? [08:25] robru, if so: what is our policy on landing to wily and xenial? [08:25] robru, do we have a combined target for both available? === alan_g is now known as alan_g|afk [09:32] davmor2, rvr: any news on silo 0? [09:32] Since jibel mentioned that was the last one needed to land [09:32] I don't see it even ready for QA.. [09:33] sil2100: you have as much info as I do, I just logged in ;) [09:59] davmor2: sil2100: Nope, I have no news [10:03] sil2100: ping [10:04] OTA-8 candidate bug #1514173 <- jibel, sil2100 [10:04] bug 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/1514173 [10:10] Mirv, k, do you have an example of this crash with an application? [10:16] jibel: I'm asking faenil to show up and tell about it [10:17] or zsombi can fill in if faenil doesn't appear [10:18] Mirv: here I am [10:18] Mirv: 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 crash [10:18] faenil: ^ do you have an answer to this? [10:18] faenil: Mirv: if the app changes are not in RC, then it's not OTA-8 [10:18] jibel: 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 crash [10:19] jibel: faenil: then it smells to me it's OTA-9 [10:19] if there's any app released in OTA8 that uses ListItemLayout with an tag in the text, it's going to crash [10:20] zsombi: let's hope no apps released for OTA8 trigger the bug then... [10:21] faenil, do you have an example of such app? [10:21] it'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 usecase [10:21] faenil: show an app from RC image that has this crash [10:22] zsombi: jibel I don't know. Telegram uses in its delegates, but Telegram is not using ListItemLayout yet [10:22] OTA9 then [10:23] faenil, 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 ota8 [10:23] morphis: pong [10:23] s/kand/land [10:23] sil2100: OTA8 is now in freeze, right? [10:23] jibel: we still waiting for silo 0 or should I do the snapshot and first rc candidate without that? [10:23] jibel: all AP tests are crashing here'n'there lately... no idea where the crash is so far... bzoltan_ suffers with this for days [10:23] morphis: yes, we don't accept anything else for ota8 [10:23] sil2100: just wanted to know when the doors are open for ota9 things [10:24] sil2100, wait, probably more fixes to land today [10:24] morphis: you want to land anything to the overlay? [10:24] jibel: I do... I really do [10:24] sil2100: nothing for ota8 [10:24] faenil: 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. === alan_g|afk is now known as alan_g [10:24] jibel: 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 snapshot [10:24] jibel: 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] sil2100, yes, we stay frozen [10:25] Mirv: 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 say === 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 [10:25] (I don't know if you cherrypick it) [10:25] faenil: yeah it would definitely need to be single cherry-pick fix if something. but those AP problems zsombi mentions complicate the issue. [10:25] Mirv: ok [10:26] faenil: we already have few bugs we cherrypicked, and those were OK with AP... but something got basted since then [10:27] zsombi: ok [10:29] zsombi: jibel: brendand knows about it and he knows how to reproduce the issue.. IMO it is a showstopper one. [10:29] I 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:30] jibel: just saw your tag. that bug is not a regression (fyi). [10:31] it is a new component (introduced in OTA7), the bug has always been there since the component was released [10:31] jibel: ^ [10:31] bzoltan_, btw i'm looking at that now, i reproduced the issue [10:32] faenil, ok, thanks for the clarification [10:32] jibel: np :) [10:32] brendand: thanks man! [10:33] bzoltan_, apart from the crash though what about all the failures? [10:34] brendand: I would be happy to jump on them and fix them.. but first is to bring back the AP tests to non crashing state [11:09] bzoltan_, i'm still not sure why the crash is happening but it is related to test failing, so no failures, no crashes :P [11:10] 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:11] bzoltan_, it happens when trying to write some error logs to the result [11:11] brendand: then it is an autopilot bug + a regression in Mir/Unity [11:11] bzoltan_, it's neither of those [11:12] bzoltan_, it's a testtools bug that's being exposed by lots of failures in uitk tests [11:12] 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 landed [11:13] 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 shell [11:13] bzoltan_, 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 autopilot [11:13] brendand: Okey, then it is an autopilot bug [11:13] brendand: failing test must not crash the whole system [11:14] bzoltan_, of course [11:14] 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:15] brendand: I am sure that something has landed in the last weeks what made this regression... because it is a serious regression. [11:27] bzoltan_, 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 change [11:29] 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] brendand: do we have a dashboard to see since what image the UITK tests crash? [11:30] bzoltan_, nope [11:30] brendand: we used to have such dashboard :( [11:31] bzoltan_, we did, but only a handful of people took any responsibility for it [11:31] bzoltan_, whereas everyone was supposed to [11:31] brendand: :( [11:31] bzoltan_, and some other changes meant the tests stopped being run a while back [11:32] bzoltan_, you could get a jenkins instance from ci and set up a regular run [11:40] brendand: so what should we do now? [11:41] brendand: what disturbs me a lot is that stuff can land and screw up UITK tests without much control === alan_g is now known as alan_g|afk === alan_g|afk is now known as alan_g [12:11] rvr: hi! Did you manage to test silo 1 with the new click? [12:12] mardy: Nope, needed to land a higher priority silo [12:12] rvr: ok === _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 [13:45] sil2100, ping [13:49] jibel: bfiller: not sure if there is still time, but: https://requests.ci-train.ubuntu.com/#/ticket/638 [13:58] boiko, yeah we want that one [13:59] mark it when ready [13:59] pmcgowan: ready already === awe is now known as awe|afk [13:59] davmor2, then ^^ [14:00] boiko, is it marked ready? [14:00] oh it is [14:01] pmcgowan: yep [14:02] pmcgowan: is that silo 0 [14:03] ah no 55 === barry` is now known as barry_ === barry_ is now known as barry [14:03] rvr: ^^ silo 55 is in jibel's list of bug fixes [14:04] pmcgowan, boiko: any news on silo0 [14:04] davmor2: salem_ is working on it, fixing a bug bfiller found [14:05] boiko: nice thanks [14:17] davmor2, which image has silo 2? its not working here for me [14:19] pmcgowan: 172 on krillin [14:19] davmor2, not working on mako or mx4 for me [14:19] with whatever I got this morning [14:20] davmor2, I understood it would be in the next image [14:21] pmcgowan: yes the one that landed last night 172, 171 was the last build yesterday [14:21] davmor2, I am saying the update I got an hour ago does not have it, is that expected? [14:22] or is it me [14:22] pmcgowan: opening here I get a location on the front road almost instantly [14:23] on MX4 image 162 location works fine again for me too [14:24] pmcgowan: http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/172.commitlog [14:25] something wrong here [14:25] about telss me I have 154 which I updated to 11/11 [14:25] wtf [14:28] I have the wrong channel [14:28] pmcgowan: indeed somehow [14:29] pmcgowan: that sounds most strange [14:29] davmor2, last time I reflashed I picked poorly [14:29] cockpit error [14:30] pmcgowan: https://www.youtube.com/watch?v=Ubw5N8iVDHI [14:32] davmor2, I just bricked my phone with a wrong flash [14:32] forgot to give it a channel so it installed v1 === alan_g|lunch is now known as alan_g [14:33] pmcgowan: ouch yeah that will do it, for mx4 power and volume down to get to bootloader, for mako power and volume+ & volume- [14:33] davmor2, its back [14:34] now to fix it [14:42] pmcgowan: you all sorted now? [14:42] davmor2, waiting to see, it keeps saying failed to enter recovery but then finishes [14:42] ubuntu spinny logo [14:44] pmcgowan: https://wiki.ubuntu.com/QATeam/ChannelsToFlash does your flash command resemble the ones on that page? [14:45] davmor2, I have 162 now [14:45] \o/ [14:45] pmcgowan: and does location work now? [14:45] davmor2, at some pint I used ubuntu instead of mezu.en === awe|afk is now known as awe [14:46] davmor2, yes, bam [14:46] pmcgowan: \o/ [14:53] 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:58] trainguards: hey guys, one question... I see silo 46 landed. Just would like to know if it landed for ota-8 or ota-9 [14:58] trainguards: please note that the silo adds some new strings that need to be translated === chihchun is now known as chihchun_afk [14:59] salem_: I'm on holidays right now but let me try taking a quick look [15:00] salem_: ok, seeing the vivid silo it seems dialer-app needs a rebuild [15:05] sil2100, 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 translated [15:06] 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] salem_: ah, yeah, that won't do... [15:07] salem_: you can just have a separate silo for just dialer-app if anything and dual land that there [15:07] If, of course, you don't need to build against the new libphonenumber explicitly [15:07] sil2100, yes, we don't. I think I will end up doing that. thanks! [15:08] salem_: this would make some things easier, and you can ask QA to for instance signoff both at once [15:08] sil2100, yeah, will do that. thanks for the help. enjoy your holidays :) [15:09] sil2100: sorry to bother, but we are concerned with xavigarcia about silo 46 being published [15:09] sil2100: 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:10] was it somehow published to OTA-8? [15:11] any other trainguard around? ^^^ [15:12] alecu: it was signed off so we landed it, it was rebuilt without the dep-changes right? [15:13] sil2100: yes, it was rebuilt without that, but it was bounced by cyphermox after that [15:13] sil2100: and since it was already late, we decided to postpone it to ota-9 [15:14] we added a note about that to the silo: https://requests.ci-train.ubuntu.com/#/ticket/528 [15:14] sil2100: the thing is that it adds a few strings that are very user-visible [15:14] those are shown whenever you change the volume [15:15] jibel: ^ should we revert it? [15:15] hm, well, that's bad in that case [15:15] fwiw 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] cyphermox: those all were fixed, there were no packaging changes [15:15] Since I was able to publish it with my powers [15:15] cyphermox: yes, I think you did right to bounce it at that point [15:16] I don't know; I still see these changes in the build job [15:16] cyphermox: if there were packaging changes I wouldn't be able to publish as it's a main package [15:16] and on the publish job [15:16] And I'm a MOTU [15:16] sil2100: it doesn't matter in this case, that wasn't the problem [15:17] my issue with it, and it looks unresolved, is that there are a dozen files added that aren't obviously mappable to adding OSD notifications [15:18] xavigarcia: cyphermox is right: the silo diff still seems to contain all of the testing harness [15:18] in 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 gmenuharness [15:18] Mirv, ping [15:19] I realize this is likely tests, but it's not so good to include changes that aren't listed in changelog [15:19] cyphermox: agreed. [15:19] so, should I ask to revert this? [15:20] alecu: I'm not sure I'd bother unless there is another reason to [15:20] cyphermox: the big reason is that this adds new strings, and that they are very user visible [15:20] alecu, cyphermox: the files are present but are no longer compiled [15:21] xavigarcia: it's irrelevant, we don't necessarily see what is compiled and what isn't from a quick look at the diffs [15:21] alecu: strings aren't an issue for xenial, at least [15:22] for vivid, you need an SRU bug in which case it may be arguable. [15:22] trainguards: could you please remove dialer-app from silos 0 and 20 PPAs? [15:23] cyphermox: I think we only want to land in the phone vivid overlay, not in vivid itself [15:24] boiko: done [15:24] cyphermox: and I worry if this has landed in the overlay, because ota-8 will have those strings untranslated. [15:25] alecu: that's up to you I suppose [15:25] sil2100: thanks [15:25] Mirv, could you get a silo for this? https://code.launchpad.net/~renatofilho/ubuntu/vivid/qtpim-opensource-src/fix-1514350/+merge/277264 [15:28] alecu: sil2100: shouldn't we be trying to land things for the overlay as SRUs as well though? [15:28] ie. not just in the overlay but also in vivid [15:30] sil2100: 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 rebuilding [15:51] cyphermox: 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 them [15:51] xavigarcia_: can you confirm that? ^ [15:55] alecu: yeah, the changes apply to the phone [15:56] alecu: the desktop is not showing those strings [15:56] xavigarcia_: great [16:05] another update just popped up [16:09] hi trainguards, may we ask to revert this landing? https://requests.ci-train.ubuntu.com/#/ticket/528 [16:10] trainguards: this should really go in for ota8: https://requests.ci-train.ubuntu.com/#/ticket/627 [16:10] I keep forgetting if I'm supposed to click "publish" or that's a guard's job [16:12] bfiller: ping === ev_ is now known as ev === Ursinha_ is now known as Ursinha [16:21] bzoltan_, can you return the favour and have someone look at https://code.launchpad.net/~brendan-donegan/ubuntu-ui-toolkit/swipe_into_view_keyboard/+merge/273805 [16:21] bzoltan_, it's been sitting around for a while [16:21] brendand: sure [16:22] bzoltan_, i just managed to do a full run without it crashing :/ [16:22] bzoltan_, not really a good thing, but interesting [16:22] greyback, yeah 44 can publish [16:22] brendand: how did you do that??? [16:22] brendand: must be black magic [16:23] bzoltan_, luck maybe [16:24] brendand: tomorrow I will eliminate 50% of the failures ... about that much fails because of the popover button introspection. [16:24] bzoltan_, yeah there were a lot of those [16:24] wtf [16:31] lousy luck, newer qtmir pushed to -proposed, but problem to fix on armhf xenial [16:41] jgdx: ping [17:12] greyback: that silo was already published when you published it [17:13] robru: yeah? Sorry, the train made it look like it wasn't [17:13] boiko: ping [17:13] greyback: look at the audit log on the ticket. sil2100 published it, it was migrating, you published it again [17:13] greyback: what did it look like when you clicked published? [17:13] robru: ok, then was my bad timing [17:13] as it definitely had the QA signoff as the last thing in the log when I clicked publish [17:14] greyback: 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:15] robru: sure, that I know. Perhaps I hadn't hit F5 soon enough [17:15] robru: anything broken? [17:15] greyback: doubtful: sil published it ~20 hours before you, and the page auto-refreshes every 3 minutes. ;-) [17:15] greyback: no nothing broken. but probably worth checking why it's in proposed for so long [17:16] robru: yeah I'm trying to figure that out, something weird with xenial [17:17] alecu: still want that reverted? I can do it if you're sure. [17:19] tvoss: 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] robru: yes, we'd like to revert that silo, please. [17:20] robru: thanks! [17:24] alecu: 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:30] hmm [17:31] rvr: pong [17:31] boiko: Hi [17:31] rvr: hello [17:31] boiko: I'm testing silos 49 and 0 [17:31] rvr: ok [17:32] boiko: I did a dial-number /ril_0 123456789#1 and worked [17:32] boiko: Do you need any specific test? [17:32] (also tried with the dialer app, manually) [17:33] rvr: nope, that's it, and also make sure you create a contact with a number including a #, and try to call from address-book-app [17:33] boiko: Nice, trying... [17:34] rvr: why is 55 blocked? [17:35] boiko: Cannot reproduce [17:35] rvr: 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 zero [17:36] robru: if that's the previous version, then yes. Where can I check all the versions? [17:37] alecu: 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] https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=indicator-sound&field.status_filter=&field.series_filter=vivid [17:40] rvr: you tried to reproduce in the latest rc-proposed? [17:40] alecu: once it's built I'll get you to review the diff to make sure it has sensible contents. [17:41] boiko: Yes [17:41] alecu: 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 again [17:41] rvr: let me try here [17:42] boiko: Address book and messaging app can dial to numbers with # [17:42] rvr: great! so the problem is fixed [17:43] boiko: I'm going to do some extra sanity checks, and will approve is everything is fine. [17:45] rvr: thanks [17:54] robru: sounds great, thanks [17:55] robru: when you say that the revert will be in vivid, do you mean the overlay? [17:55] alecu: yeah [17:56] alecu: https://ci-train.ubuntu.com/job/ubuntu-landing-057-1-build/lastSuccessfulBuild/artifact/indicator-sound_content.diff/*view*/ this looks a little weird to me [17:59] alecu: aside from the changelog being completely nuts, do the code changes make sense to you? [18:00] alecu: 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? === alan_g is now known as alan_g|EOD [18:05] xavigarcia, ^^ [18:07] pmcgowan: 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 guys === alexabreu is now known as alex-abreu [18:12] robru: what error do you get? [18:13] xavigarcia: 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] robru: ok... let me take a look [18:16] robru: sorry, was having a late lunch [18:21] boiko: Could you reproduce the label issue with latest rc-proposed? [18:22] robru: diff looks fine to me [18:23] robru: there were many new files in that silo [18:23] xavigarcia: ok, with your approval I'll release that to vivid overlay then. [18:23] rvr: nops, not happening, but still, the fix is correct, we cannot rely on the SDK selecting anything by default [18:26] pmcgowan: 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 ready [18:27] robru: yay! \o/ [18:27] robru: thanks a lot. [18:27] robru: thanks! [18:27] alecu: xavigarcia: you're welcome [18:39] boiko: I see [18:40] boiko: I think it first needs to set a default SIM [18:42] rvr: well, shouldn't make a difference, but who knows? :) [18:55] boiko: Approving silos 49 and 0 [18:56] rvr: great! thanks! [18:56] rvr: 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:57] pmcgowan: should I go ahead and merge those? [18:57] s/merge/publish/ [18:57] sure they are happroved [18:57] \o/ [19:24] boiko: davmor2: Approving silo 55. [19:25] rvr: nice [19:25] Err [19:38] trainguards: publishing silo 0 failed because it says it's dirty, that dialer-app needs rebuilding, but dialer-app is not on that silo anymore [19:39] rvr: davmor2: great! thanks, I will just have to rebuild that after silo 49 lands [19:41] robru: could you please check what is going on with silo 0? [19:57] boiko: one sec [19:59] robru: thanks [20:00] boiko: 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 finishes [20:00] there [20:01] brb [20:02] robru: thanks [20:08] robru: turns out I am not authorized to publish libphonenumber, could you please publish it? [20:08] boiko: if you're not authorized, neither am i. You need a core dev [20:09] robru: anyone here who could do that? [20:10] boiko: slangasek might be able to help [20:10] boiko: i usually poke kenvandine or mterry [20:10] it's a US holiday today [20:11] boiko: don't forget to land 20 too [20:11] but I happen to be around so I'll have a look [20:11] davmor2: that's my next question: do you guys need to validate it? [20:11] davmor2: it is the same changes as silo 0, but targetting xenial [20:11] slangasek: thanks [20:11] boiko: we don't touch xenial yet [20:12] davmor2: so it is just landing and that's it? [20:12] boiko: that can just land the important one was 49 which touches both [20:12] boiko: yeap [20:12] davmor2: ok, let me change the silo [20:13] slangasek: if that's not asking too much, could you please publish silo 20 too? (same changes as silo 0, but for xenial) [20:15] boiko: 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:16] slangasek: phone overlay [20:16] boiko: then it must not use this version number, which is reserved for SRUs [20:16] slangasek: ah, I think that's missing in the silo [20:17] slangasek: what version number would be fine? [20:17] boiko: the previous changelog entries show '6.0+r655-0ubuntu7vivid1', '6.0+r655-0ubuntu7vivid2' - something in that vein is probably ok [20:17] robru: ^^ is there a specific numbering convention boiko should use here? [20:18] I think kenvandine advised salem_ to use that version number [20:18] mm [20:18] not sure why [20:18] well, unless it's targeted for SRU, it's wrong and a problem [20:19] as it would lead to any later SRU of libphonenumber in vivid having the same number but different content [20:19] slangasek: boiko: train only enforces a certain version for MPs, so no preference on my end for manual sources [20:20] robru: sure, but what's the convention? maybe there's something we can use for consistency [20:20] I have no preference either (and no knowledge about the policies for that) [20:21] slangasek: well it would be upstream+15.04.YYYYMMDD-0ubuntu1 [20:21] right [20:21] so no help for this ;) [20:21] Maybe Ken thought it was an SRU [20:21] robru: 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:22] the package needs reuploaded and rebuilt [20:22] slangasek: 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 was [20:22] boiko: no way to change the version without a new upload [20:23] robru: ok, I will ask salem_ to provide a new package, which version you advise us to use? I have really no idea there :) [20:24] boiko: i guess 6.0+15.04.20151111-0ubuntu1 unless anybody has a good reason to keep the revno in there [20:24] salem_: ^ [20:25] salem_: can you provide a package with that versioning? [20:26] slangasek: what about the version in silo 20? is that one ok? [20:26] robru, boiko sure, but it doesn't match the previous versions in the overlay ppa, is that ok? [20:26] last one was 6.0+r655-0ubuntu7vivid2 [20:26] slangasek: 7.0.8-0ubuntu3 [20:26] slangasek: (for xenial) [20:28] boiko: salem_: wait, that version I said isn't actually higher than the one already there [20:29] boiko: salem_: I guess just use 6.0+r655-0ubuntu7vivid3 or something. I don't know where that scheme came from [20:30] boiko: 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 consistency [20:31] robru: 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 versioning [20:36] boiko: yes that version is ok for xenial [20:36] slangasek: would you mind publishing it then? === salem_ is now known as _salem [20:37] boiko: I haven't looked at the actual package yet - what's the ticket number? [20:38] slangasek: https://requests.ci-train.ubuntu.com/#/ticket/622 [20:43] boiko: ok, publishing [20:43] slangasek: thanks! [20:45] robru: 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 ppa [20:46] boiko: is your ppa devirt? If not we can just do a source copy now [20:47] robru: what is devirt? If I am supposed to know, then my PPA is not :D [20:47] robru: https://launchpad.net/~boiko/+archive/ubuntu/source-uploads/+packages [20:49] boiko: yeah train PPAs have special builders, so i can't binary copy, have to source copy and rebuild. [20:49] robru: that's fine [20:51] robru: thanks [20:52] boiko: UGH that version is lower than the version in the PPA [20:52] robru: yeah, I guess so [20:52] boiko: let's free the ppa and get you a new one [20:52] robru: ok [20:52] boiko: I'll do it [20:58] boiko: OK building in silo 6 now, when it finishes please give it a quick smoketest to make sure nothing exploded in the rebuild [20:58] robru: sure thing, thanks for the help [20:59] boiko: you're welcome [21:30] robru: all good with silo 6 [21:31] slangasek: 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/623 [21:35] pmcgowan: 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 already [21:37] boiko, wonder who is working [21:38] rsalveti, ?;) [21:39] maybe cyphermox is around [21:52]