[00:10] bfiller: please approve: https://code.launchpad.net/~michael-sheldon/ubuntu-keyboard/fix-1448019/+merge/257783 [00:52] robru: done [00:53] sorry about that [00:53] bfiller: thanks [02:05] === IMAGE 190 building (started: 20150505-02:05) === [03:40] === IMAGE 190 DONE (finished: 20150505-03:40) === [03:40] === changelog: http://people.canonical.com/~ogra/touch-image-stats/190.changes === [04:20] Mirv: it seems that the overlay PPA's QtC plugin is out of sync https://ci-train.ubuntu.com/job/ubuntu-landing-016-1-build/149/console [04:28] bzoltan: there is no q-p-u in overlay, but you need to sync that ubuntu2 from archives to your trunk [04:29] Mirv: Ahh... of course. So we had a release to the archive what was not merged to the trunk... I see [04:37] sergiusens: would you mind to give me the patch you applied on the qtcreator-plugin-ubuntu and pushed to the archive? It would make easier to fix the trunk. [04:42] sergiusens: I see that you habe added a distro patch to the archive packge. It now blocks the CI process for the lp:qtcreator-plugin-ubuntu [05:44] trainguards: good morning, can silo 3 be published, please? [05:50] oSoMoN: sure, I'll just make sure it's configured to go to the overlay [05:50] oh, this's the old silo, great :) [05:57] pedronis: hi! regarding line 27 in the spreadsheet, what should be done about it, removing? the two MP:s listed there are 404 like I wrote in there 2 weeks ago. [05:57] https://code.launchpad.net/~pedronis/account-polld/supp-sha384-512-certs/+merge/256477 + https://code.launchpad.net/~pedronis/ubuntu-push/automatic-into-vivid/+merge/256535 [06:09] Mirv, thanks! [06:17] good morning [06:25] good morning tvoss [06:26] Mirv, hey there :) [06:29] fixing your "MP" to be MP instead of branch [07:10] Mirv: yes, they can be removed [07:34] pedronis: thanks [08:41] sil2100, hey there. Do you know whom I have to ping to grant permissions for silo building/landing to someone? [08:43] mzanetti: hey, I can add that person if anything [08:44] Is that person trained in the train? ( ;) ) [08:44] sil2100, I gave him a walkthrough, not sure if there's a requirement to get a walkthrough from you guys [08:44] sil2100, talking about tsdgeos (aacid on launchpad) here [08:45] Ah, sure, let me add him [08:45] perfect, thanks [08:45] I'll assist his first few landings [08:46] mzanetti: he should be now train-enabled [08:46] nice. thanks :) [08:46] yw ;) [08:49] trainguards I'm working through the release process for Mir 0.13 and have reached the point of adding a line to the CI spreadsheet. But it seems to be read-only and I note the topic says there are problems. Am I blocked? Or can you help? === sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: low on vivid silos [08:52] alan_g: hey! So, to have access to the spreadsheet you need to be added as a lander [08:52] sil2100: ok, how does that happen? [08:52] alan_g: I can do that for you - have you been trained on the usage by someone? [08:53] The usage of the CI Train [08:53] I have document I'm fixing as I go [08:54] alan_g: you should be added now, remember about the https://wiki.ubuntu.com/citrain/LandingProcess documentation [08:55] I'll try browsing through it today and making sure it's 100% up to date [08:56] sil2100: thanks, have access and am adding that step (and reference) to the Mir doc [08:56] sil2100: can you join #ubuntu-app-devel? [09:00] Mirv: what's up? [09:01] sil2100: see there, a developer having a problem on desktop [09:01] (14.04) [09:20] ogra_: is "allow whoopsie to be permanently turned off" goind to land to rtm-14.09 or can the line be removed? [09:22] rsalveti: will "Upstream fixes and optimizations" (libhybris) land to rtm-14.09 or can the line be removed? [09:22] I'd guess not but checking before removing [09:22] Mirv, thjats waiting fro a fix to whoopsie ... seb128 kind of led that bug in the end ... not sure where we stand, but i suspect whoopsie wont be fixed before the hotfix OTA anymore [09:23] ogra_, yeah, not likely going to be fixed before the next ota update [09:24] Mirv, kick it :) [09:24] ogra_: thanks! [09:27] sil2100: somehow we seem to hit a cap at silo 037, ie claims that no silos left [09:27] huh [09:28] Let me check that [09:30] I just changed 30 -> 40 the number of production silos in metadata... === jamesh_ is now known as jamesh [09:30] it's probably not affecting anything as it was at just 30 [09:31] Ah, I think I know what's wrong [09:36] Uh oh, I think I see a bug in the train code [09:40] pstolowski: ping [09:44] wtf [09:54] rvr, pong [09:55] pstolowski: Hey [09:55] rvr, hi! what's up? [09:55] pstolowski: I cannot downgrade libunity-scopes3 [09:55] *** 0.6.9+15.04.20150429~rtm-0ubuntu1 0 [09:55] 500 http://ppa.launchpad.net/ci-train-ppa-service/landing-003/ubuntu-rtm/ 14.09/main armhf Packages [09:56] pstolowski: I guess the original package is only available in the image and not in the archives :-/ [09:56] rvr, sudo apt-get install libunity-scopes3=0.6.9+15.04.20150126~rtm-0ubuntu1 did this for me (on clean image + rtm silo 3; not dist-upgraded) [09:57] rvr, (I had to apt-get update) [09:57] rvr, ^ that's what you miss I think [09:57] Ahhh, that's it [09:57] Yeah [10:00] sil2100: hey, is train ready for landing to wiley yet? [10:00] if not, should I just wait? Or do we land to an overlay ppa of some kind? [10:05] also, if I select "vivid" in the spreadsheet now, this will go to the vivid phone image afaict. in which case, do we need QA signoff? [10:06] greyback_: it's not open for wily yet... but there are chances the phone will stay focused only on vivid [10:06] But I need more info to confim that [10:07] mzanetti: if you target vivid the it's targetted for the nearest vivid OTA release [10:07] sil2100: ok, thanks for clarifying [10:10] sil2100: vivid need QA signoff? [10:10] greyback_: yeah... [10:10] sil2100: ack [10:43] Mirv: this prepare_silo issue is absurd [10:44] Mirv: I checked the code, checked with cyphermox-test and every test I make shows that find_first_available should just properly return silo 38 [10:45] Mirv: I even ran a python snippet from find_first_available and it just worked [10:45] sil2100: hmm, is it possible 38/39/40 would be marked as allocated even though according to spreadsheet they're not? [10:46] sil2100: oh, but find_first_available returns 38.. [10:46] Mirv: no, I checked that too, the dirs are empty [10:46] weird [10:46] someone has decided 37 should be enough for everybody [10:46] Mirv: well, it *should* return 38 - the snippet I ran returns 38, all code shows it should but in prepare_silo it just seems to return None or '' [10:46] Still looking [10:49] trainguards: i'm going to need a silo for row 64 if possible to drive my first landing \o/ [10:51] tsdgeos: the train is misbehaving and doesn't want to assign moar silos ;) Debugging it now [10:51] sil2100: i see, thanks :) === MacSlow is now known as MacSlow|lunch [11:12] cihelp: hey! since yesterday ps-trusty-desktop-i386-1 is stopped, and I can't get it restarted, mind having a look? (it's a jenkins node used in s-jenkins) [11:29] Mirv: so, to get a better understanding of what is going on, I added some debug info to the train but now of course we need to wait for webops to redeploy it [11:29] Mirv: and they don't have time right now [11:29] * sil2100 loves how swift the debugging is with the current model [11:37] sil2100: ok... [11:38] * sil2100 needs to go for lunch [11:39] Mirv: in the meantime there's not much we can do [11:50] right [11:56] sil2100, davmor2 heya, just added a line to the spreadsheet for clicks/tarballs for the twitter trending scope to be updated in the store [11:56] should be really fast to test, all that was changed was some error checking [11:56] cwayne, thanks, I'll create a card [12:05] cihelp: I think I'd need a new exception for the licensecheck: https://code.launchpad.net/~mzanetti/unity8/inputinfo-plugin/+merge/258241 [12:24] cwayne, re twitter-trends LGTM, I get a completely blank scope for some hashtags but it's the same behaviour with 1.0.9 [12:24] cwayne, when do you plan to release a new custom tarball for RTM? [12:25] jibel, today :) just building and writing up what's changed [12:25] jibel, also thanks, I'll upload new twitter to the store [12:49] sil2100: yes, feel free to remove it (libhybris) [12:49] Mirv: ^ [13:11] rsalveti: thanks === MacSlow|lunch is now known as MacSlow === elopio_ is now known as elopio [13:34] sergiusens: ping [13:35] bzoltan: pong [13:37] sergiusens: I have merged your ninja upload of the qtc plugin :) to our trunk and we have pushed 6 important usability and security fixes. Would you be able to help us to SRU the latest release to 15.04? In a way or an other the app devs will get this change. [13:37] sergiusens: because if I do not SRU these fixes then I have to push itto the SDK PPA and direct the developers on Vivivd to use the PPA [13:39] bzoltan: I can't SRU, I'm not a core dev [13:39] you really have to fix that [13:39] err that's entirely orthogonal [13:39] that too :) [13:40] although ubuntu-ui-toolkit is in main, so in this specific case it does matter :) [13:40] cjwatson: oh, nice; I need to learn the process then; but that means bzoltan can also do that [13:40] ah, there [13:40] * sergiusens needs to read that wiki page again [13:41] cjwatson: it is the qtcreatot-plugin-ubuntu in this case... the austin sprinters have found couple of issues [13:41] * cjwatson tries to view /~sergiusens/+participation, gets annoyed enough to go and attack https://bugs.launchpad.net/launchpad/+bug/1409680 [13:41] Ubuntu bug 1409680 in Launchpad itself "Person:+participation is Forbidden if the person participates in a visible team via an invisible one" [Critical,Triaged] === jgdxx is now known as jgdx [13:50] cihelp, ping :) [13:51] mzanetti: please don't use contextless pings [13:51] don't ask to ask :) [13:52] ev, well, I asked before and didn't get a reply. [13:52] so I wanted to find out if someone is actually subscribed to this [13:53] ev, so my question was if I could get an exception added to the licensecheck in jenkins [13:53] https://jenkins.qa.ubuntu.com/job/unity8-vivid-amd64-ci/840/console [14:00] rsalveti, re: silo 30 for push. Does it strictly need to be tested on krillin or Arale is fine ? [14:02] mzanetti: is that legally compatible? [14:03] ev, it's upstream Qt [14:03] ev, basically I coped code from a merge proposal to Qt because we need it now already [14:03] copied [14:03] cihelp: 2nd try: since yesterday ps-trusty-desktop-i386-1 is stopped, and I can't get it restarted, mind having a look? (it's a jenkins node used in s-jenkins) [14:03] ev, here's the diff: https://code.launchpad.net/~mzanetti/unity8/inputinfo-plugin/+merge/258241 [14:04] om26er: arale is fine [14:04] ev, I *think* it's fine, as the Qt packages we use have the same things in them. That said, IANAL [14:15] * didrocks feels ignored… [14:16] /ignore didrocks [14:16] ogra_: see! :) [14:17] heh [14:18] trainguards: can I get a reconfigure on vivid silo 37 plz (spreadsheet row 12) [14:18] greyback_: on it [14:18] cheers [14:19] greyback_: did you guys abort the silo build? Just be sure not to abort the jenkins build jobs before the packages are uploaded to the PPA [14:19] The train is fragile in that regard ;) [14:20] sil2100: guilty as charged ;) [14:20] but no packages were generated, I aborte pretty quickly [14:21] greyback_: let's hope nothing got broken, since if it's cancelled during package preparation then it leaves stale files that can get in the way of building again ;) But a reconfigure should wipe things clean for us I guess [14:21] sil2100: hum, that's handled, isn't it? (aborting the jenkins build, the transaction is committed at the end and all uploads happen in the end) [14:21] and all states files are removed [14:22] sil2100: let's hope so. I'll let you know :) [14:23] didrocks: right now it's a bit fragile, the build job gets confused when the scripts are killed in the middle of preparing source packages, before their upload [14:23] sil2100: argh, it was done before to be transactional on that regard and generate stamped files at the end (while cleaning everything which didn't get stamped and cleaning), that changed, ok [14:25] rsalveti, also any other TestPlan you want to be run except for ubuntu-push ? The testing instructions are missing on the Spreadsheet [14:25] om26er: just ubuntu-push [14:29] mzanetti: cool, I've confirmed that it is a licence compatible change, and have created a task for it on our vanguard board [14:30] we're a bit shorthanded on that today, so it may be a little while, but rest assured the request is with us [14:30] didrocks, someone will have a look before too long and back to you [14:30] ev, awesome, thanks. [14:30] fginther: thanks! [14:31] Mirv: ...aaand it seems that it suddenly magically works, now it sees the other silos [14:31] Mirv: I didn't touch anything even [14:37] sil2100: FYI the network indicator RTM silo from earlier is tested now. just waiting on QA [14:37] pete-woods: \o/ excellent, thanks [14:37] john-mcaleely: hey! How's the device tarball going? [14:38] sil2100, still in progress [14:43] cwayne: I see the twitter trend scope passed QA - is that the only change that would land in the new custom tarball? [14:45] sil2100, nope, see the line below that in the spreadsheet :) [14:46] cwayne: ah! :) No question then! [14:46] sil2100, :) [14:54] pedronis, Hi! How long is it normally supposed to take for a Telegram push notification to appear ? [14:54] om26er: should be quick [14:54] ralsina_: ^ [14:55] om26er: seconds [14:56] ralsina_, hmm take ~10-15 seconds. That normal I guess ? [14:56] om26er: that's more or less what it takes, yes [14:56] om26er: some days it's a bit faster :-) [14:57] ralsina_, would love to see it faster :) [14:57] om26er: the bottleneck is usually between telegram server's and ours, IIRC [14:58] ralsina_, right, the notifications in the app are instant, so probably the problem is on our end [14:59] om26er: to get the push, telegram has a server that forwards the message to ours. That extra step takes a few seconds, karni knows best [15:02] rvr, what is the status of rtm/silo 0 [15:02] ? [15:04] pedronis, how can I verify bug 1446584 fix ? [15:05] bug 1446584 in ubuntu-push (Ubuntu) "[krillin] On airplane mode battery discharge more rapidly than with airplane mode off" [Undecided,In progress] https://launchpad.net/bugs/1446584 [15:05] om26er: I need to go afk, rsalveti can explain that as well [15:11] om26er: you can verify via syslog, if powerd got a lock or not (in a delta of 5 minutes) [15:11] I added that info to the bug [15:11] Easy way to check for the bug: [15:11] $ tail -f /var/log/syslog | grep powerd [15:11] Then look for acquire/release SysState. It shouldn't happen when flight mode is enabled. When either cellular data or wifi is enable, you should see that at every 5 minutes, as it's the default delta for push-client. [15:12] rsalveti, ok, thanks. [15:46] sil2100: hmmm.. [15:47] sil2100, is spreadsheet functional again or do we need to request manual landings ? [15:47] om26er: it's ok now... at least for now [15:47] ;) [15:47] Mirv: yeah, anyway the bug itself was completely crazy, looked like something not really code related === marcusto_ is now known as marcustomlinson [15:57] mandel: ping [16:01] cwayne: any news on the custom tarball? :) [16:02] davmor2, ^ [16:02] sil2100: yes it's custom and a tarball [16:03] Custom tarball for RTM? The queue only mentiones vivid [16:04] this ball of tar is quite custom indeed [16:04] yeah, it's RTM, i built the same for vivid as well though, so that we could do a 2-for-1 :) [16:04] sil2100: happy now [16:05] hm, ok, since I was confused since the spreadsheet said 'not ready yet' still ;) [16:05] oops sorry, ill edit [16:06] i swear i'd changed it already [16:06] guess not [16:14] Are their wily silos? It doesn't seem a selection in the spreadsheet. [16:15] Can I just write in ubuntu/wily ? [16:20] jibel: Approving silo 0 [16:20] * tedg just did it [16:21] rvr, thanks, only bit missing is a device tarball now [16:24] Damn [16:24] mandel: ping [16:25] mandel: we have a problem - silo 000 in RTM was built from https://code.launchpad.net/~mandel/location-service/back-port-1441619/+merge/258072 , which is Rejected [16:25] mandel: we would need the silo rebuilt with https://code.launchpad.net/~rsalveti/location-service/syncing-vivid/+merge/258127 instead ;/ [16:25] sil2100, does that mean we have to retest it? [16:25] We just probably wasted QA cycles damn it [16:26] jibel: I would have to do a comparison to see if they're source-identical [16:26] Let me check that [16:26] But I'm a bit irritated [16:26] sil2100, could this check be done *before* the silo can even be marked ready for QA? [16:27] sil2100, and if it is not fully approved, then it cannot be marked for QA. [16:27] jibel: I think it was in the past, but people protested since their workflow was to sometimes test stuff in the silo before top-approving branches [16:28] jibel: well, the perfect solution would be hard to do with the spreadsheet [16:28] sil2100, it wouldn't block dev workflow [16:28] What we could do is add a check for Rejected merges [16:28] Rejected or Superseeded [16:28] sil2100, it would just prevent people from marking a silo ready for QA while it isn"t [16:28] And inform during build-time about those [16:28] jibel: yeah, you can't easily do that with the spreadsheet [16:29] sil2100, I don't want to add an extra manual task for such a thing that is clearly what computer are good at. [16:29] plus a bunch of 's' in the sentence :) [16:30] sil2100: I did rebuitl with that [16:30] maybe the spreadsheet reverted something [16:30] rsalveti: you did? Did you reconfigure after changing in the spreadsheet? [16:31] Since the config still shows the old MR [16:31] weird [16:32] rsalveti: are the two branches code-identical? [16:32] sil2100: nops [16:32] https://code.launchpad.net/~rsalveti/location-service/syncing-vivid/+merge/258127 is the right one [16:33] Crap [16:33] and is the one that produced the package that is in that ppa [16:34] rsalveti: ah, indeed, the build log says so too [16:34] rsalveti: now this is a mystery [16:35] rsalveti: ok, so the silo is configured with the old branch but the build job indeed used the new branch [16:36] rsalveti: maybe someone reconfigured the silo after your build and at that time the spreadsheet reverted itself, so it reconfigured it to the old branch [16:37] rsalveti: could you make sure the spreadsheet row for this landing has the correct MPs and source pkgs? I'll reconfigure it then, watch-only and publish [16:37] sil2100, so it's all good and no retest, right? [16:41] sil2100: it's just this MR [16:41] so just use that [16:41] no more src package [16:42] ACK [16:42] jibel: yeah [16:42] sil2100, now we really need a device tarball [16:42] john-mcaleely, ^ any news? [16:42] john-mcaleely: ping ^ [16:43] rsalveti: thanks for clearing it up o/ [16:43] jibel, sil2100 fixed build running on capomastro now [16:43] \o/ [16:43] so, 45 mins away [16:43] john-mcaleely, good, thanks! [16:43] nice [16:43] john-mcaleely: you still need to test it then, right? [16:43] that's in the 45 min eta [16:44] takes around 30 mins to do the testplan :-) [16:44] sil2100, when there is a device tarball, davmor2 will be done with the validation of the custom, can you start a build and will do the validation device bits directly on the promotion candidate [16:44] (if this build fails, I have a tested, locally built, tarball ready to go [16:44] s/will/we will/ [16:45] jibel: yeah, I'll just build a new image once we have silo 000 in the archives [16:45] Actually... [16:45] hm [16:45] tedg: congrats on getting the first wily silo: http://people.canonical.com/~platform/citrain_dashboard/#?q=wily [16:45] (14) [16:45] slangasek, cjwatson: I published indicator-network to 14.09 a while ago and it didn't appear in -proposed [16:46] * tedg does a wily dance [16:46] robru, Thanks! [16:46] tedg: you're welcome [16:46] sil2100, well, wait until we have the 2 tarballs [16:46] jibel: those can land afterwards, they're not part of the rootfs anyway [16:46] sil2100, fine [16:46] indicator-network 0.5.1+15.04.20150505~rtm-0ubuntu1 in 14.09 (Cannot copy DDEBs to a primary archive) [16:47] huh? [16:47] that's odd, I thought we removed that check recently [16:48] oh, not entirely [16:48] cjwatson: strange, since we published packages today to rtm already, maybe infinity re-enabled something when he was working on wily? [16:48] no, that was re-enabled a while back [16:48] you probably published stuff that was built before we switched that back on [16:49] cjwatson: does that mean the silo will need to be rebuilt? [16:49] no [16:49] but it needs somebody to reconfigure the ubuntu-rtm archive [16:49] cjwatson: it's a new silo, it got built today actually [16:49] which would be, let's see [16:49] cjwatson: assigned and built today [16:50] oh look, techboard [16:50] slangasek: oh hai [16:50] :-) [16:50] point me at the button [16:50] slangasek: archive = lp.distributions['ubuntu-rtm'].main_archive; archive.build_debug_symbols = True; archive.lp_save() [16:50] in "lp-shell production devel" [16:51] devel rulz [16:51] Why is it still devel, I never had any issues with that right now, would love it to become the new stable version [16:51] sil2100: then I guess we might need to redo the publish step manually, or can you retrigger that from your end nowadays? [16:51] API guarantee, although basically the whole system is broken there [16:51] cjwatson: I think we can retrigger it from the train, since I think it would just re-publish then [16:51] cjwatson: http://pastebin.ubuntu.com/10990880/ [16:52] wut [16:52] you tell me ;) [16:52] slangasek: could you 'rm ~/.launchpadlib/api.launchpad.net/cache/*wadl*' and try again? possibly old cached wadl [16:53] old cached wadl, not the finest of whiskeys [16:53] cjwatson: same error [16:53] slangasek: you're definitely using devel? [16:53] I'm definitely typing 'lp-shell production devel' :) [16:54] $ lp-shell production devel [16:54] E: ipython not available. Using normal python shell. [16:54] Connected to LP service "https://api.launchpad.net/" with API version "devel": [16:54] Note: LP can be accessed through the "lp" object. [16:54] >>> [16:54] slangasek: ok, sod it, try https://launchpad.net/ubuntu-rtm/+archive/primary/+admin [16:54] check "Build debug symbols", save [16:54] Not allowed here [16:55] Uh oh [16:55] ah, I totally misread the security adapter [16:55] needs webops [16:55] ok :) [16:55] or wgrant when he wakes up, but that probably won't be for a few hours [16:56] so you can point them at either of those methods, but the web UI is probably less confusing [16:58] cjwatson, sil2100: 09:58 < seelaman> slangasek: done [16:59] \o/ [16:59] Thanks, let me try a re-publish [17:01] Mirv, re qtdeclarative silo, did you compare autopilot test results with previous version ? === alan_g is now known as alan_g|EOD [17:08] cjwatson, slangasek: could you check if the packages got published correctly this time? [17:08] sil2100, do you know ? ^ [17:09] om26er: hm, I have no info regarding that, I guess only Mirv would know [17:09] sil2100: seems to have been [17:09] sil2100, is he EOD ? [17:09] om26er: but usually he does that [17:09] om26er: yes, it's around 20-21 at his place now [17:11] wgrant: I have a branch in progress to fix the reason the above was a problem, but I'm about to EOD. Will submit it tomorrow [17:23] sil2100: I've committed the changes for daily phone builds, now fixing up the live crontab [17:24] sil2100, ogra: now, whose local change to the crontab is this?: [17:24] # do not build RTM on weekends, so we get two days of testing without forced reboots [17:25] #02 3 * * 1-5 DIST=ubuntu-rtm/14.09 for-project ubuntu-touch cron.daily-preinstalled --live [17:25] the crontab is in VCS, please make changes there [17:25] http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150505-db7b5bd.changes [17:25] http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150505-db7b5bd.tar.xz [17:25] http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150505-db7b5bd.ods [17:25] sil2100, jibel ^ [17:25] for your QA pleasure [17:25] (for everything except temporary disabling of jobs during milestone builds) [17:26] jibel: ^ [17:26] slangasek: ah, hm, it's an old change [17:27] i remember that being introduced [17:27] ages ago [17:27] ~August last year? [17:27] slangasek: but yeah, all the other changes I was always editing it directly on nusakan, had no knowledge of a VCS [17:27] yeah, improperly ;) if this is the policy, somebody should commit it to lp:ubuntu-cdimage [17:27] slangasek, please dont ! [17:28] ogra_: don't what? [17:28] the crontab ion VCS is only an example one [17:28] ogra_: that is false [17:28] dont merge them [17:28] no, that is how it was always handled [17:28] ogra_: no, it is *not* [17:29] and if this was the impression that you had, that explains why the live instance is so badly out of sync [17:29] sil2100, if you need the tarball pushing, ping me on telegram if I'm |away [17:29] slangasek, well ... ask infinity or cjwatson [17:29] john-mcaleely: uh oh I don't have a telegram account! Maybe davmor2 could do that though! [17:29] cronab is the one thing weher the live version supesedes the one in the branch [17:29] there's always an sms to the mobile in the corp. dir then :-) [17:30] because it might have ad-hoc changes for milestones etc [17:30] infinity, cjwatson: can you please either confirm my understanding of nusakan's crontab, or refute it? :) [17:30] infinity, cjwatson: since ogra_ and I seem to have a very different understanding of the intended crontab management [17:30] we used to sync it every now and then, but the production one is always been master [17:31] (oh, and no, i dont know who commented the line ) [17:33] ogra_: I commented it the line of RTM auto-builds some time ago [17:33] Once we stopped landing stuff there [17:33] sil2100, yeah, i surely commented it too at some point :) [17:33] slangasek: I think that in theory you're right, but years of practice going back several machines probably mirrors ogra's understanding better. [17:33] but i dont know if in this particular case since it was an on/off thing for the last weeks [17:33] slangasek: I certainly don't commit temp changes (like commenting during milestones), but adding/removing things should definitely be committed so they're not lost. [17:34] right [17:34] right [17:34] thats what i meant with "syncing every now and then" [17:34] and "it's been that way since August" is not a temp change [17:35] surely not :) [17:35] and it should have been synced [17:35] We have a lot more cooks dangling limbs in that pot than we used to, so a firmer policy wouldn't hurt at this point. [17:35] ogra_: ok, so I'm not sure what you were telling me to "don't" do [17:35] cihelp: can we get lp:unity-scope-click landing/MP configuration updated to land on wily now? [17:36] I never said I was overwriting the crontab, I said I was fixing it :P [17:36] slangasek, i thought you asked about the line being commented [17:36]