[05:02] Mirv: I have no idea why, but the AP tests on krillin are run in windowed mode http://people.canonical.com/~bzoltan/ap-2015_07_06-DUAL-SILO03-KRILLIN/ [05:22] bzoltan_: pretty weird [05:22] bzoltan_: there's an option for that, of course, for running all apps in windowed mode, but how would be triggered and why [05:24] Mirv: I forced the phablet-test-run to set com.canonical.Unity8 usage-mode Staged before and after executing th eautopilot tests... that way looks better now [05:29] bzoltan_: ok, so another hack to put in the test script.. unity team might know a reason for the behavior change [05:44] Mirv: yes, that is the solution for now. It is shame because it messed up my nightly tests and so the silo3 landing is now delayed by at least a day. [05:45] bzoltan_: oh, silos, I remember those. [05:45] (opens up dashboard for the first time in two weeks) [05:46] Mirv: yes, and I am Zoltán, your mate in the SDK... and the OS you work on is the Ubuntu [05:47] * Mirv does the 2nd qtbase 5.5.0 PPA upload already === chihchun_afk is now known as chihchun [07:46] this new device tarball gets me pretty good battery life on arale \o/ [07:46] and it doesnt get as hot anymore either [07:46] nice [07:47] it still gets hot, but doesnt burn your fingers ... [07:47] and i had ~24h between the charges on the weekend even when using the device a lot [07:48] (i think my average befor was about 6h) === chihchun is now known as chihchun_afk [08:25] Good morning trainguards! Can I have a silo for line 84, please? [08:25] oSoMoN: on it! [08:28] oSoMoN: I'd have assigned it with pleasure, but sil2100 has gone into superfast mode while I was away :) [08:28] Done :) [08:29] Mirv: ah ha! [08:29] thanks guys! [08:29] and welcome back Mirv! === chihchun_afk is now known as chihchun [10:22] davmor2: how would I decipher currently that silo 21 is destined for OTA5? [10:23] there are not really bug reports attached to the landing so it's not on the ota5 bug list either [10:31] Mirv: https://docs.google.com/document/d/1F36EeZbS3Gzqq_tivKZHyoLDCOxT1TPh0vubhvWJafI/edit [10:31] Mirv: it's in the list of things to land :) [10:34] davmor2: yay for yet another google doc. this time not a spreadsheet, I guess that's a change :D [10:35] davmor2: do you know if the people responsible for the doc are aware of this thing called Launchpad, pretty good tool for triaging milestones? ;) [10:46] who can give me permissions in the CI Train landing sheet? [10:48] morphis, sil2100 ^^^ [10:48] ogra_: thanks [11:07] sil2100: can you help me with that? [11:17] o/ [11:17] morphis: sure [11:19] morphis: done [11:29] oSoMoN: Merge proposals of silo 22 need review. [11:33] rvr, right, I overlooked that, they are now approved [11:35] oSoMoN: Self-review... not good ;P [11:37] trainguards: row 34 in the spreadsheet is not marked as landed, even though it is. Anything I can do? [11:39] jgdx: let me look [11:40] jgdx: it's landed, just the spreadsheet has issues marking it as released [11:40] It's a known bug [11:40] Will only be fixed by the replacement sadly ;p === chihchun is now known as chihchun_afk [11:53] sil2100, thanks :) Do I delete the line? [11:53] No, it's cool [11:53] We need to have history [11:53] So nothing gets deleted, only archived [11:53] k === psivaa is now known as psivaa-afk [12:08] sil2100, hey, I've noticed that one of the packages in silo 6 has been in "Migration" since Friday [12:09] sil2100, it is lxc-android-config, was wondering if something needs to be done manually [12:09] sil2100: thank a lot! [12:15] abeato: let me take a look [12:16] sil2100, ok [12:20] cihelp: hm, I see a strange error in the boottest results for lxc-android-config [12:20] cihelp: could anyone help? === _salem is now known as salem_ [12:46] Damn, too hot here... [12:53] sil2100: is a free silo I can get assigned for row 67 in the sheet? [13:07] jibel, hello, do i need qa signoff if i'm only landing gfx asset change (music/video scope)? [13:07] morphis: on it! [13:07] sil2100: thanks [13:07] Sorry, was preempted to something else for a moment [13:07] pstolowski: in vivid? yes [13:07] dobey, yeah, dual.. ok [13:08] morphis: I'm thinking if I can use a dual silo here... you would need to ask for an upload for 2 packages [13:09] morphis: a vivid one and a wily one [13:09] sil2100: it can't be just synced back to vivid from wily? === marcusto_ is now known as marcustomlinson [13:15] sil2100: can you give me a link to those results please? [13:18] rvr: a bit same question than for davmor2 earlier - how I can check silo 43 with bug #1470331 is targeted to OTA5? the bug itself has no milestone, and I don't see the bug mentioned in the document davmor2 linked earlier [13:18] bug 1470331 in mediaplayer-app (Ubuntu) "the progress bar not start from very begining place when play form 0:00:00" [Undecided,In progress] https://launchpad.net/bugs/1470331 [13:18] Mirv: I approved the silo [13:19] Mirv: So my understanding is that it will be included in OTA5 [13:19] rvr: but how do you come to that understanding? :) or maybe sil2100 can fill in that we're also allowed to fix non-targetted bugs. [13:19] I was under impression that https://launchpad.net/canonical-devices-system-image/+milestone/ww28-2015 + approved certain features are allowed [13:20] Mirv: Those are priorities, AFAIK [13:20] rvr: sorry, I'm just back to work, I might not know all the today's landing rules so that's why I'm double checking [13:21] Mirv: We have been testing silos that are not critical [13:21] josepht: the boottest ones? Here: https://jenkins.qa.ubuntu.com/job/wily-boottest-lxc-android-config/lastBuild/ [13:21] rvr: right, and in addition to priorities others are allowed too. thanks. I'll just wait for sil2100's word on it (so that I'm back on track understanding what's allowed to go in) [13:21] Mirv, rvr: we let in anything, but prioritize those on the milestone list [13:21] sil2100: double thanks [13:22] Since there are currently no freeze rules, besides the translations [13:22] morphis: hm, syncs only work for CI Train generated packages [13:22] * Mirv publishes [13:23] sil2100: so only way would be to create a wily silo first, me uploading the src package and then creating another silo for vivid and syncing the package from wily? [13:23] sil2100: thanks, we'll take a look [13:24] sil2100, josepht taking a look at the log you pointed at the error is when installing lxc-android-config and it is the same it happens if you try to install it directly in a "live" system [13:24] morphis: we can do it like that, or you can simply get a dual-landing silo, upload from the same source both the vivid and wily version (you know, only changing the version number and target series in the changelog) [13:24] sil2100, josepht note that lxc-android-config is special for installation: https://wiki.ubuntu.com/Touch/Testing/lxc-android-config [13:24] sil2100: it's the first time for me doing so lets see :) [13:24] abeato: yes, and that's a bug I think, it should be skipped in this case or a special case should be made in the boottests [13:25] morphis: I'll assign a silo now :) It's a bit different when not using merges [13:26] sil2100: :) [13:27] morphis: ah, ok, looks like I can't give you a dual silo because of recently added safety checks... I'll assign a wily silo for now, we can get it to vivid after this lands there first [13:27] sil2100: I do have the rights then to do dput on that silo? [13:28] morphis: sadly no, only core-devs and train operators have that, you can poke any of the two with a source package and they'll upload for you [13:28] As I said, it's a bit less convinient without MPs ;/ [13:29] ok [13:31] rsalveti: looks like you still have to do that :) [13:31] sil2100, abeato: we'll discuss in our standup how to deal with lxc-android-config. [13:31] morphis: put your src package somewhere public, like people.canonical.com [13:31] morphis: then I can upload, or any other member from the landing team [13:32] josepht, ok, but how was this managed before? was it landed directly to the archive? [13:33] abeato: do you mean before boottesting was enabled? [13:33] josepht, ah, it this boottesting a new thing? [13:33] basically I am curious... [13:33] abeato: yes, within the past several months [13:36] josepht, interesting, pretty sure there have been landings for lxc-android-config in the last 2 months, ogra_ did you have this issues with boottesting last time you landed lxc-android-config? ^^ [13:37] issues ? [13:37] ogra_: did it fail boottesting? [13:38] josepht, what kind of boottesting ? [13:38] ogra_, https://jenkins.qa.ubuntu.com/job/wily-boottest-lxc-android-config/lastBuild/ [13:38] ogra_: during proposed migration [13:39] josepht, no, obviously it has never been uploaded since that test is in place ... and the test cant work [13:39] (you cant upgrade packages that span into the writable space on touch installs ... (there are a bunch more of them where this cant work)) [13:40] ogra_: is there a list some place? we'll need to figure out a way to whitelist those [13:40] powerd is another one [13:41] well, essentially every package in touch that ships writable bits ... you will only be able to "dpkg -i" them from recovery [13:41] this is a dpkg limitation ... it uses hardlinks when replacing files ... hardlinks do not work across partition boundaries [13:42] and i dont think there is a list ... for lxc-android-config it is explicitly described in the test plan how to install it [13:42] potentially all touch packages could get this issue ... [13:43] i would suggest finding a better way to do boottests ... [13:43] this is a conceptual flaw here [13:43] ogra_: that's good information to know, thanks a lot. I'll discuss with our team and we'll see what we can come up with. [13:43] +1 [13:45] josepht, meanwhile, how could we land lxc-android-config? we'd like to have it for ota-5 :) [13:45] abeato: I'll get it skipped [13:46] trainguards: I just tried to help mattheu getting this branch landed: https://code.launchpad.net/~tiheum/ubuntu-themes/suru-app-icons-v2/+merge/260863 [13:46] but the train says: ERROR https://code.launchpad.net/~tiheum/ubuntu-themes/suru-app-icons-v2 is not a valid merge [13:46] josepht, nice, thanks... note that the sync with vivid is in silo 35 so I'll ping you again when that gets QA approval [13:46] can we land this with the train or needs to be uploaded manually? [13:47] mzanetti, you can landing it with the CI [13:47] E_PARSE_ERROR [13:48] mzanetti, did you top-approve it yet ? [13:49] not me, but yes, it is top approved [13:49] *facepalm* [13:49] * mzanetti tries again [13:51] mzanetti, you can land it through CI train [13:51] if the "eparse" was for me [13:51] seb128, yes :) [13:51] have it working now [13:51] seb128, but the train throws an error [13:51] copy/paste mistake [13:52] :) [13:52] hence the *facepalm* :/ [13:52] heh, right, the rrors even tells you :) [13:52] :-) [13:52] *error [13:52] yeah... [13:52] mzanetti, btw speaking of landing, could you maybe handle https://code.launchpad.net/~lukas-kde/gsettings-qt/queued-processing/+merge/259883 ? [13:53] seb128, ok [13:53] thanks [14:01] pmcgowan: hey [14:01] hey [14:01] pmcgowan: so looking at https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1462489, is this wily only or for stable-phone-overlay? [14:01] Launchpad bug 1462489 in qtsystems-opensource-src (Ubuntu) "Allow apps to keep the screen on" [High,In progress] [14:01] jdstrand, for vivid too [14:01] would like to include in the ota [14:02] pmcgowan: this will cause all app and webapp (but not scope) policy to be regenerated [14:03] pmcgowan: which I'm fine to do if you give the ok. by vivid, you mean stable-phone-overlay or an actual vivid sru? [14:03] jdstrand, overlay [14:03] jdstrand, what can we do if anything to avoid total regenerate, sounds like nothing [14:03] nothing [14:04] well, there is one thing [14:04] jdstrand, wasnt there a thread on this [14:04] a policy group could be added [14:04] and apps could start using that. this wouldn't require regenerating policy because no apps would use it [14:05] but, this policy group would end up being undocumented [14:05] I mean, we can fix that of course [14:05] trainguards: could I have a silo for row 68? [14:05] jdstrand, what group would you add it to otherwise [14:06] trainguards hello, may i ask for reconfig of silo 42 (unity-scopes-shell project added) ? [14:06] but this isn't something we would normally break out-- we want apps to be able to do it by default if they so choose to [14:06] jgdx: dual landing, right? [14:06] pmcgowan: I was going to add it to the template policy (ie, ubuntu-sdk and ubuntu-webapp) [14:06] sil2100, yes [14:06] pmcgowan: it doesn't fit into an existing policy group [14:08] jdstrand, seems a new group makes some sense then [14:10] pmcgowan: well, I don't know. I mean, I appreciate the problem with not wanting to regenerate policy, but adding a policy group should not be taken lightly-- we have to update all docs, train users and carry it forward. my inclination was to not add a new policy group, but maybe I am being overly cautious. let me ask the security team [14:13] jdstrand, ok I will defer to you all [14:15] mdeslaur, tyhicks: in thinking about the policy for bug #1462489, we have two choices: update the appropriate templates or add a new policy for screen inhibiting [14:15] bug 1462489 in qtsystems-opensource-src (Ubuntu) "Allow apps to keep the screen on" [High,In progress] https://launchpad.net/bugs/1462489 [14:17] personally, I'd add a new policy as that would allow blacklisting certain combinations [14:17] mdeslaur, tyhicks: I was initially thinking that this should be added to the templates because apps should just be able to do this, but then a screen inhibit policy group is perhaps meaningful [14:17] mdeslaur: what is an example combination that you were thinking about? [14:17] mdeslaur: yeah-- we were already thinking of that with scopes [14:18] design might decide to pop up a trust store question ... would that work with just template upgrade ? [14:18] in which case, I just wouldn't add it to the scopes template [14:18] (or s/design/someone/ ... ) [14:18] tyhicks: I don't have an example...but adding more and more stuff to the base policy seems like it will limit us in the future [14:18] oh, I agree [14:18] ogra_: this was discussed with tvoss-- no trust prompt for now cause only apps (ie, not scopes, push helpers, etc) would be able to use it [14:19] for now ... right [14:19] and it will be obvious that they are inhibiting the screen [14:19] (i didnt expect us to have one now ... ) [14:19] if this changes, then trust prompting should be rediscussed [14:19] once we add it to the base policy, it becomes much more painful to split out into its own policy group down the road [14:19] but someone might want to add one in the future ... so having the lower level able to handle that is probably a good idea [14:19] tyhicks: that assumes we want to split it out :) [14:19] it does [14:20] there is a little more background on this [14:20] adding it to the template means that developers can just start using it [14:20] but it means all app policy has to be regenerated [14:21] which we avoid for non-Ubuntu version upgrades (ie, normally we would only make this change in wily) [14:21] if we add a policy group instead, then there is no app policy regeneration-- no one uses the policy group [14:22] sil2100: So, I've implemented the translations redirection for PPAs, and I have an approved MP for it, but it shouldn't be landed/deployed until a 15.04 series exists in ubuntu-rtm [14:22] but, that means we have to update the review tools and documentation for this policy group [14:22] Mirv, sil2100: I'm about to pass silo 35 any chance of spinning up an image once it lands as there is an lxc-android-config change in it that will likely cause issues with the landing of silos, thanks [14:22] cjwatson: oh, excellent! [14:22] I wanted to poke about that soonish [14:22] sil2100: Is that something we should go ahead and sort out? [14:22] cjwatson: give me a moment, finishing an e-mail to Pat - I'll poke you afterwards [14:23] jdstrand: how much effort is the review tool and documentation updates? [14:23] mdeslaur, tyhicks: it sounds like you guys like the idea of a new policy group. I'm ok with that. what should it be named, screen? [14:23] I think we could create it as Future or some such to avoid disturbing Soyuz [14:23] davmor2: ok, I guess that might make sense, we can kick a new image then [14:23] tyhicks: it is a lot more effort for me but a lot less 'global time' when considering users' time [14:23] that shouldn't be a factor [14:23] imo [14:23] sil2100: it hasn't passed yet I'm just setting that up ahead of time :) [14:23] cihelp: any idea why ubuntu-touch-meta is failing the boottest? http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#ubuntu-touch-meta [14:24] well, that's what I was thinking about [14:24] we should consider the user and the developer experiences [14:24] less time for for the user [14:24] more time for us [14:24] right [14:24] trainguards hello, may i ask for reconfig of silo 42 (unity-scopes-shell project added) ? [14:24] I also don't want to set a precedent that we should just add policy groups willy nilly [14:24] jdstrand: perhaps "screenblank" or something a little more descriptive than "screen" [14:25] AlbertA, looks like someone added a dependency on ubuntu-application-api3-examples ... [14:25] to avoid stuff like this, cause that makes the developer experience muddled (which policy group should I add?!?) [14:25] but, if this is a reasonable thing to add, that's fine (hence the discussion :) [14:25] I do prefer the policy group [14:25] ok, I'll add a policy [14:25] pmcgowan: ^ [14:25] AlbertA, blame Laney [14:25] policy group [14:26] it's 3 to 'on the fence' so you guys win [14:26] :) [14:26] is 'blanking' the right term here? [14:27] we're stopping screen blanking from happening [14:27] screen-inhibit? [14:27] screensaver? [14:27] screenlock-inhibit? [14:27] AlbertA, ubuntu-touch-meta appears to no longer be compatible with the installation method that boottest is using, we're taking a closer look at the problem [14:27] if it helps, the qml is: [14:27] maybe screenlock should be screen-lock [14:27] import QtSystemInfo 5.0 [14:27] ScreenSaver { screenSaverEnabled: false } [14:28] fginther: ogra_: ack thanks [14:28] screensaver sounds so old though :) [14:28] heh [14:28] ogra_: what? [14:28] mdeslaur: screen-inhibit, screensaver screen-lock-inhibit-- thoughts? [14:29] Laney, your switch to the api3 stuff makes touch-meta uninstallable it seems [14:29] I think I don't like screen-inhibit [14:29] AlbertA, oh, looks like ogra_ has a better answer [14:29] Laney, [14:29] https://jenkins.qa.ubuntu.com/job/wily-boottest-ubuntu-touch-meta/lastBuild/artifact/results/log/*view*/ [14:29] fginther, yeah, i gave it above already :) [14:29] jdstrand, mdeslaur: one more - disable-screen-lock [14:29] I also prefer screenlock-inhibit to screen-lock-inhibit [14:29] does anyone understand what's the issue there [14:29] https://ci-train.ubuntu.com/job/ubuntu-landing-052-1-build/1/console [14:29] ? [14:30] jdstrand, tyhicks: is it just lock, or perhaps blank too [14:30] it is blank too [14:30] hrm [14:30] at least I sure hope it is or what are we doing this for [14:30] ogra_: lies [14:30] I guess that project is not set up for ci landing [14:30] I don't really care honestly...as long as it's not just called "screen" [14:30] heh [14:31] ogra_: laney@snakefruit:~$ /srv/ubuntu-archive/bin/chdist apt-get wily-proposed-amd64 --dry-run install ubuntu-touch/wily-proposed >/dev/null 2>/dev/null && echo yes [14:31] yes [14:31] ok, so mdeslaur is out of the conversation [14:31] mdeslaur: well-layed [14:31] played* [14:31] :) [14:31] jdstrand, keep-screen-on ? [14:31] Laney, well, it isnt installable in the above log for whatever reason [14:31] ogra_: something might be busted in boottest [14:31] josepht was trying to help me with a similar one on friday [14:32] yeah, might be [14:32] I didn't understand why (forgot) wasn't installable [14:32] pmcgowan: the api is keepDisplayOn, so maybe keep-display-on if we went that route [14:32] same one? [14:32] Laney: it's the same one [14:32] jdstrand, +1 [14:32] does the boottest use the overlay PPA ? [14:32] it's wily [14:32] jdstrand, pmcgowan: I like keep-screen-on or keep-display-on the best out of all others so far [14:32] ah [14:32] wily ... who cares :P [14:32] * mdeslaur signs over bikeshed deed to jdstrand and tyhicks [14:33] ok, let's go with keep-display-on (that is the dbus api call and exposed via c++ api) [14:33] jdstrand: sounds good [14:33] it is clear and conceivably mappable from a denial to the policy group [14:33] yeah, that is nice [14:35] josepht, Laney, I'm debugging that package install locally, see if I can tease any more info out on my mako [14:36] josepht: maybe it needs to be >>...stderr? [14:36] or >${package}.stderr [14:36] fginther: ^ - good luck, but it looks installable to me locally [14:37] mdeslaur, tyhicks, pmcgowan: thanks for the discussion-- I've got it from here [14:37] jdstrand: thanks! [14:38] jdstrand, thank you [14:38] I look forward to turn by turn [14:39] pmcgowan, turn by turn works fine :) [14:39] * ogra_ used it yesterday ... [14:39] just set your screen to 10min and tap every once in a while :P [14:58] sil2100, abeato: lxc-android-config has been passed [14:58] josepht: thanks! [14:59] josepht, thanks :) [15:23] trainguards any thots on why this might be stuck ? [15:23] http://people.canonical.com/~platform/citrain_dashboard/#?q=ubuntu%2Flanding-013 [15:23] or at least...it seems stuck [15:23] 4 days in pocket [15:25] kgunn: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_output.txt says http://paste.ubuntu.com/11831300/ [15:25] which means that the listed packages on each listed architecture are made uninstallable by this change [15:25] lander needs to investigate why [15:27] AlbertA: ^ just fyi, cause you're name was on it....altho really i think this is racarr's mess [15:27] kgunn: no I'm landing it [15:28] kgunn: fginther is looking at it [15:28] AlbertA: ta [15:43] Mirv, tested on vivid, #54, mako. Works fine for unconfined apps [15:43] (as expected, that is) [15:44] Laney, I found the problem with ubuntu-touch-meta. Its dependency, ubuntu-application-api3-examples, doesn't cleanly replace ubuntu-application-api2-examples [15:44] dpkg: error processing archive /var/cache/apt/archives/ubuntu-application-api3-examples_3.0.0+15.10.20150624.1-0ubuntu1_armhf.deb (--unpack): [15:44] trying to overwrite '/usr/bin/test_ubuntu_app_api_location_service', which is also in package ubuntu-application-api2-examples 2.9.0+15.04.20150326-0ubuntu1 [15:44] fginther: aha [15:44] fginther: that's a bug then, which platform-api needs to fix [15:45] fginther: Laney: ok so I need to add a replaces? [15:45] fginther: can you get boottest to give us that output? [15:46] Laney, yes, I'm looking into that logging discrepancy [15:46] fginther: It might just be an >> vs > in the stderr redirection [15:48] AlbertA, Laney, This problem shouldn't prevent the promotion of ubuntu-touch-meta, correct? It's a problem upgrading a dependency which is completely avoided when the image is built from scratch. [15:48] AlbertA: You probably want Conflicts+Replaces (<< 3.0.0+15.10.20150624.1-0ubuntu1) to hint that the old package should be removed [15:48] fginther: right [15:48] fginther: If you let it migrate, then anyone using apt will get errors [15:49] It's good that we've caught it, normally proposed-migration wouldn't [15:50] Laney, ah ok. We'll just have to retry that manually once platform-api fix is ready [15:50] fginther: AlbertA: BTW this still can't migrate until telephony-service is uploaded - that needs to move to the new ABI [15:50] boiko said he would get it done today [15:51] Laney: yep, soon [15:51] no worries [15:51] need another fix in platform-api now anyway ;) [15:51] Laney: is there a reason why telephony-service doesn't show up in the rdeps of platform-api? [15:51] does for me [15:52] Laney: Breaks+Replaces surely, to make the upgrade more graceful [15:52] Or drop the version [15:52] it's armhf only, probably you did the query on amd64 [15:52] AlbertA: only on armhf IIRC [15:52] I guess either works though [15:52] Laney: I see [15:53] AlbertA: Try reverse-depends from ubuntu-dev-tools next time - e.g. reverse-depends src:platform-api [15:54] cjwatson: Should be removed, but both would work [15:55] Laney: ack [15:56] boiko, are you doing a no change rebuild? [15:56] boiko, because I want to land https://code.launchpad.net/~seb128/telephony-service/dialpad-nosound-silentmode/+merge/260731 [15:58] seb128: so, telephony-service will fail to build on wily until silo 39 lands [15:59] seb128: I will land that still today, but need to take care of silo 44 before that [16:01] boiko, so it means you don't have dual landing for those? [16:02] like if I want that fix ^ in the vivid overlay I should do a vivid only landing? [16:02] seb128: no, I think silo 34 needs to be re-targetted to wily or vivid [16:02] seb128: yeah, the latest telepathy-qt landing on wily changed the plans a bit, we are trying to accomodate all the changes in the less painful possible way [16:03] seb128: we will certainly sync wily and vivid overlay after OTA5, but as that involves updating telepathy-qt5 on vivid, we better do it calmly and with deep testing [16:04] boiko, right [16:04] seb128: the easiest for now would be to land the fixes on wily, unless you want/need them on OTA5 [16:04] boiko, I want them on OTA5 [16:05] it's ridiculous that those obvious fixes are waiting since early june and still didn't land [16:05] I'm closing from just dputing things in different locations out of frustration [16:06] seb128: I know you are upset about it, but we are short on staff to do everything we need, there is always something higher priority to look at and we end up forgetting about those small fixes [16:06] boiko, those are like 1 liners, it shouldn't be that difficult to land them :-/ [16:07] seb128: we were not idle slacking around, you know [16:07] I know [16:08] but it's taking like 5 minutes to look to a 1 liner change, we should have our schedule accomodation for regular review of easy fixes [16:08] accomodating* [16:08] seb128: let me deal with the re-submitting of MRs and reconfigure the silo, as I am already working on landing silo 44 on vivid, I can deal with that one too [16:08] boiko, thanks [16:11] boiko: so does that mean I need to wait for silo 44 to land, then I can do a no-change rebuild and land my platform-api silo? [16:11] boiko: sounds like it. [16:12] AlbertA: silo 44 is for vivid, is your also vivid? [16:12] boiko: it's dual landing [16:12] AlbertA: ouch, that complicates it a bit [16:13] AlbertA: so, we would need one telephony-service fix MR for vivid and another one for wily [16:13] boiko: ok so can I do a no-change rebuild before then? [16:14] boiko: we removed the ua_ui apis...which are not used by telephony-service...so just needs to link to the *.so.3 version now... [16:14] AlbertA: ok, what would happen if you land that without telephony-service? just curious [16:15] boiko: the binaries would look for *.so.2 [16:15] which won't exist anymore [16:15] ok, so we need to land it in both places [16:16] AlbertA: the problem is: starting today until OTA5 is released, we have different codebases for telephony-service in vivid and wily [16:16] AlbertA: using different series (trunk for wily and rtm-15.04 for OTA5) [16:16] boiko: I see...so lp:telephony-service is wily currently? [16:16] AlbertA: yep [16:16] boiko: I see [16:16] AlbertA: and lp:telephony-service/rtm-15.04 is vivid [16:17] which one is vivid+overlay? [16:17] rtm-15.04? [16:17] AlbertA: yep [16:17] boiko: ok so I'll need to do separate landings then [16:17] AlbertA: I guess so, sorry for that :/ [16:18] boiko: no prob... [16:34] trainguards: can I have silo 013 reconfigured? [16:51]