[00:59] has silo 19 landed yet? [00:59] Wellark: no I'm still waiting on a core dev to ack the packaging. [01:00] Wellark: not sure who else is around to do that [01:00] the computer says.. no. [01:00] infinity: can you ack silo 19? https://ci-train.ubuntu.com/job/ubuntu-landing-019-2-publish/1/ [01:09] robru: Oh, right, let me look again. [01:09] Got distracted. [01:10] Wellark: What's with the removal of the copyright boilerplate from CMakeLists? [01:13] robru: Looks sane, assuming it all builds and installs right. [01:13] infinity: yeah Wellark tested it [01:13] infinity: also I installed it but didn't really test much. can confirm phone does not explode. [01:14] infinity: thanks [01:14] Saviq: kgunn: do not be afraid. I'm about to test a small change to citrain, and the bot will ping you with some phony info in a few minutes. it's all lies, I'm not touching anything in silo 16, there will be no interruption to the PPA, only the spreadsheet. Remember, the map is not the territory. [01:14] SHame about the really ugly newline mangling when creating changelogs. :/ [01:15] infinity: yeah that's been a sore point for citrain from the beginning. [01:15] infinity: i literally have no idea where is the code that is causing that, otherwise I'd rip it out [01:18] Saviq: kgunn I have completed the test and everything is back to normal. sorry for the noise [01:19] (must have been too fast for queuebot to notice the change...) [01:44] infinity: plain CMakeLists.txt files are not really copyrightable [01:44] generic cmake modules are a different story [01:45] I simply removed the few existing copyright notices from the couple of CMakeFiles.txt to be consistent inside the tree [01:46] it's really the same thing as we don't have copyright notices in debian/control and friends [01:47] they are just descriptions [01:47] hmm [01:47] robru: infinity: is there a freeze exception for the touch-only stuff or should I file a freeze exception bug? [01:48] I'm pretty sure we have a catch-all for touch [01:48] and if not we should [01:48] Wellark: the catch-all needs to catch all; not sure whether mtp was counted in, even if it really is touch only [01:49] cyphermox: anyone using it right now except though packages? [01:49] *touch [01:49] Wellark: please let me look into it [01:50] cyphermox: and even if it would have some non-touch users it's a core piece of the touch platform and clearly has to have the same blanket exception as the rest of the stuff [01:50] Wellark: I don't assume [01:50] what's the worst thing that could happen if you land without exception? [01:50] I agree, but I'd rather check that the bug does include mtp explicitly should it need to [01:51] Wellark: that's not the point, the processes are there for a reason :) [01:51] sure, I understand your point [01:51] just wondering :) [01:51] * Wellark imagines an angry mob armed with trouts [01:57] Wellark: a trout-whalloping is nothing to shake a stick at. [01:57] cyphermox: I'm not aware of any touch exception bug, just the one from last cycle. [02:02] cyphermox: To be fair, with RTM looming, we really should have a feature freeze (with review and acception criteria) for touch at this point too, not blanket wild west landing. [02:03] I agree [02:04] infinity: I'm not sure how you guys proceed to land stuff right now; and I'd like to land silo 007, it has MTP; but I also want to bring up the feature freeze thing. I'm sure others would be happy to just ignore that altogether and keep landing things [02:04] === trainguard: IMAGE 204 building (started: 20140822 02:05) === [02:05] cyphermox: utopic FF was only a few hours ago, if you already prepped a silo that breaks that, I'm happy to give you the verbal go-ahead with a release team hat on. [02:06] the silo was alredy in progress with some features, I didn't expect it would take so long to get ready [02:08] robru: so then I'll let you make the call when / whether to push the buttons on 007 [02:13] Wellark: this indicator-network landing; is that fixes for the wifi device disappearing? [02:15] cyphermox: will do [02:19] cyphermox: done [02:20] thx [02:20] cyphermox: you're welcome [02:21] now the only horrible horrible thing left is the bluetooth 2.0 pairing fubar. [02:21] cyphermox: nope. [02:22] which wifi dissapearence you are talking about? [02:22] I have not received any reports of that happening anymore [03:29] === trainguard: IMAGE 204 DONE (finished: 20140822 03:30) === [03:29] === changelog: http://people.canonical.com/~ogra/touch-image-stats/204.changes === [03:35] yay 204! [03:35] * alecu updates [03:39] Solo usage approaches an all time low... [04:30] * Mirv upgrades [04:31] robru: is the silo 010 delayed on purpose, would it need a small QA signoff or something? [04:31] I think I saw it tested already in the evening [04:52] Mirv: oh you can release it. I was just waiting for the image build, then forgot about it [04:53] robru: oh, ok [04:56] rsalveti approved the powerd branch, but https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/7/artifact/packaging_changes_indicator-datetime_13.10.0+14.10.20140819-0ubuntu1.diff would still need core-dev approval [04:56] * rsalveti looks [04:56] and he's awake! \o/ [04:57] the full branch in the silo together with the powerd was this https://code.launchpad.net/~charlesk/indicator-datetime/add-powerd-alarm-support/+merge/231303 [04:58] this diff is weird [04:58] oh, it's not [04:58] sorry, that's for the indicator, not powerd [04:58] Mirv: yeah, +1 [04:59] rsalveti: hehe. yes, since you already approved the powerd directly in there. [04:59] thanks. [04:59] yeah, thanks [05:01] wow, I thought KDE was big in the amount of packages, but Colin has now landed Perl... [05:01] it seems a popular language in the archive, that's for sure [05:03] Mirv: http://xkcd.com/224/ perl holds the universe together ;-) [05:09] ;) [06:24] good morning - could someone from QA please re-test line 31 (landing 006) ? I updated debsig-verify in the archive to deal with the readonly $HOME and it works for me now [06:25] what is this breanch? [06:25] https://code.launchpad.net/~ps-jenkins/indicator-network/ubuntu-utopic-proposed [06:25] jenkins just created that one [06:26] I didn't ask for it [06:40] Wellark: Jenkins makes those for all landings. You "asked for it" by publishing a silo. It's created in case there are merge conflicts meeting to trunk, eg, if somebody committed to trunk after the silo was built. [06:53] robru: how do I get rid of it? [06:54] Wellark: you don't? It's not owned by you, why do you want to delete it? [06:54] dunno :) [06:55] ok, I will just ignore it [06:57] Wellark: yeah, all ci train projects have them, https://code.launchpad.net/~ps-jenkins [07:00] :) [07:32] someone has pasted in a wrong place... (A1) [07:33] I moved it to line 34 because the spreadsheet was barely usable otherwise [07:33] oh, ok, it's just erronous copy from line 13, removing [07:36] sil2100, should i look at reminders_app? [07:37] brendand: yeah, now that the whole promotion run is over, please ;) [08:04] hmmmm [08:05] Is it only me, or dit someone for the first time implicitly call me a racist because I use the term 'whitelist'? o_O [08:05] no, you are right [08:06] * ogra_ has been shaking his head for the last 30min about that mail [08:07] there's always one guy [08:19] hmm, my mako isn't detecting the update [08:19] We already agreed yesterday that your mako is broken [08:19] ;) [08:19] sil2100, we? [08:19] sil2100, you and davmor2 ? [08:19] During the meeting! [08:20] sil2100, that's not *we*, that's you guys [08:20] sil2100, my mako is lovely and perfect thanks [08:20] * sil2100 is shocked [08:20] sil2100, you're a racist anyway :P [08:21] sil2100, so i don't have to listen to you [08:24] :| [08:25] I'm far from being racist dear brendand [08:25] oh, my brain didn't understand that e-mail at all. [08:25] And if I remember correctly, YOU used the term whitelist as well! [08:26] Now CONFESS [08:27] we're probably not in a business of studying etymology of colors, but I agree that black is cool, and especially black cats, so we should switch the blacklist being the cool list and whitelist being the annoying bug list [08:28] so not the right forum but I can see how the world is annoyingly full of faults [08:29] now if there'd be a bug tracker for World, we could forward this bug to upstream, but annoyingly I don't know who is controlling the World project [08:29] ;) [08:29] Who's upstream for World?! [08:29] maybe it's X.org though, they've had 'make world' [08:32] brendand, davmor2: is there a chance that someone from QA could retest my click update? in line #31, landing 006, I fixed a bug in debsig-verify (now 0.10ubuntu1) that fixes the verification when running in a RO rootfs [08:32] (please :) [09:27] sil2100, hey, looking at https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-016/+sourcepub/4365871/+listing-archive-extra [09:27] sil2100, is the take-changelog-until-newline working? [09:28] ogra_, be in the krillin channel [09:28] brendand, one moment ... once i moved devices ... [09:29] Saviq: it was supposed to, let me take a look if it didn't get broken somewhere with the RTM changes [09:30] Saviq: oh it seems it did get broken, let me try an fix that ;/ [09:31] sil2100, thanks [09:35] Ok, found the problem, fix in a few minutes [09:53] davmor2, you need any help reproducing the bug [09:53] ? [09:54] mvo_: I need to dig into a bug first. But can take a look after that [09:55] mvo_, oh just saw that - might get a chance later this morning [09:55] brendand: I'm going to reflash to 203 first and then see what happen if I ring the phone [09:55] davmor2, brendand: thanks a bunch, alternatively I could ask om26er as he did the test yesterday, not sure what your policy is here :) [09:56] mvo_: if om26er tested then it should be good unless you add new code [09:56] davmor2: well, he tested it and it failed :) [09:57] davmor2: and I added new code to make it stop doing this (sorry that I wasn't more clear in my original question) [09:57] mvo_: ah so a retest is required. If om26er has already tested and knows how to reproduce the failure then it might be easier for hime to continue testing it then [09:58] om26er: hi, sorry for being a nuisance - would it be possible to re-test the click update with the latest image (#204) ? that should have debsig-verify 0.10ubuntu1 which fixes the click signature verification bug ? [09:58] davmor2: thanks! [09:59] om26er: thanks dude handing off to you as you know where it breaks, what to look out for etc :) [10:03] curious, is there a new image that fixes the big unity/mir/whatever crashes that were in 202/203? [10:03] asac, no [10:03] asac, and it seems to be device specific anyway [10:03] kk [10:04] hope that gets fixed soon. kind of a miserable dog right now i am :) [10:05] asac, well, once we find the cause .... my suspicion is we get mixed up sensor info from the device level ... [10:06] i.e. you seem to be possible to crash it by moving the device at a point where only the proximity sensor should deliver data [10:06] s/possible/able/ [10:06] ogra_: I assume we land the device parts in cowboy style there still? [10:06] and the regression is from enablement level? [10:06] gerrit reviews [10:06] yeah, well. still :) [10:06] thats the entry level check ... [10:07] nothing beyond that though [10:07] sure, thats like MP review [10:07] but no silo testing properly [10:07] we dont use an android package right? [10:07] so just pure pump from gerrit into device tar [10:07] and since we have no properly working s-i server yet it isnt even sure you get the right device parts [10:07] asac: we're trying to bisect where it exactly started happening, but as it might be in the lower lever it's really hard to target [10:07] asac, right [10:07] sil2100: youc an try older device tarball with latest rootfs [10:07] if its gone then its that [10:08] i doubt we introduced incompatible changes there that require changing rootfs in parallel [10:08] right ... i just try the other way round ... [10:08] Saviq: deploying fix in a moment [10:08] my device build id seems to be from the 14th with 203 [10:08] while others seem to have builds from the 19th [10:08] ogra_: how can i install an individual combo of device and rootfs? is that easy? [10:08] asac, thats documented somewhere on the internal wiki [10:09] k [10:09] well, as long as QA and LT knows how that would be good [10:09] ogra_: so we didnt get a new device tarball update [10:09] sil2100, great, thanks [10:10] asac, *I* didnt ... i followed janis OTA instructions though ... seems davmor2 and brendand both had a newer tarball (we just checked in the meeting) [10:10] they both flashed using u-d-f [10:10] i'm just doing the same here [10:11] ogra_: man don't wake me up like that ;) [10:11] heh [10:11] i didnt know you go to sleep after the meeting :P [10:11] Saviq: could you retry to double check now? [10:11] ogra_: yeah best way to dream up new ways to break the phone ;) [10:12] asac, can we make it mandatory for davmor2 to not sleep anymore ... we have enough bugs already :P [10:12] sil2100, will do with a new silo soon [10:12] davmor2, sleep -> post-rtm [10:15] ogra_: it is post rtm that happened yesterday :P [10:15] no no, rtm *started* yesterday :) [10:15] It was just branching for RTM, that's different ;) [10:18] hahahaha [10:19] mvo_, yes, sure [10:41] sil2100, hmmm i can't reproduce the music app failure [10:41] sil2100, though it seems very straightforward [10:41] sil2100, can we get a rerun? [10:42] brendand: wait, on krillin? [10:42] brendand, 204 just ran it [10:42] failed the same way [10:42] brendand: what image are you running? [10:43] Yeah, it failed explicitly on my vanilla device [10:43] So maybe your device has something I didn't have [10:43] brendand: do you have music on your device? I don't remember if I had any mp3's when I was running myself [10:44] wow the publisher flies today [10:45] didnt take more than 15 for my dbus-property-service upload to send me the promoted to archive mail [10:45] sil2100, with the same error as in CI? [10:45] brendand: basically yes [10:46] ok strange [11:28] sil2100: I know pinging is evil :) and I risk a lot... but may I ask for a Silo? [11:29] you evil pinger you ! [11:37] :D [11:38] bzoltan: landing-009 [11:38] ;) [11:40] Mirv: thanks... I windor which half is joke... the "sophisticated algorithm" or the "do not ping us" [11:47] bzoltan: obviously "do not ping us", do not question our algorithm! [11:47] Mirv: :D [12:03] mvo_, Hey It fixes the issue I previously saw [12:03] i.e. I can install new apps now [12:04] om26er: \o/ [12:04] om26er: thanks for confirming the fix [12:04] mvo_, it took me a while, I was having problems with upgrade (internet issues). [12:09] np [12:17] my mako screen never seems to go off [12:26] sil2100, hmm, so i uplaoded dbus-property-service to utopic ... i assume i need to somehow push that into a silo now ? can the trainguards just sync that package from the archive or do i need a parallel upload ? [12:27] ogra_: how did you upload it to utopic? [12:27] dput ... [12:32] Can anyone else confirm that the screen never goes off with mako #204 ? [12:33] ogra_: and now you want the same in ubuntu-rtm, right? [12:33] yeah [12:35] ogra_: right, then you'll need to get this tested - fill in a landing with the dbus-property-service as source package and set target distribution to ubuntu-rtm/14.09 [12:35] k [12:35] ogra_: just remember to change the series and versioning ;) [12:35] sil2100, do there is no way to prevent me from the extra 2h of work then ? [12:36] ogra_: well, to tell the truth you're a core dev, sooo! If you wish, you can basically anyway push directly to ubuntu-rtm straight away with dput [12:36] As we have no power to stop you from doing so [12:36] hi, can i get help on landing silo15? [12:36] dbarth: what's up? [12:36] hi [12:37] i'v asked for qa signoff which i think i obtaind from om26er [12:37] ogra_: the thing is, we need to be double-sure that it doesn't regress anything, and a silo makes life for QA testers in case it's something risky [12:37] but now i see the silo has been touched by a build attempt or so [12:37] dbarth: let me check the silo [12:37] Oh? [12:38] sil2100, well, that still means two source packages [12:38] with different changelogs [12:38] (well, at least different version lines) [12:39] (beyond, well, i indeed want to be a good citizen) [12:39] ogra_: for now yes, but I think we'll need to maybe still discuss this a bit, too bad cjwatson is not here [12:39] sil2100, i think it would be really helpful if we could have one click imports when creating the silo or some such [12:39] Sure [12:39] I'll be working on that :) [12:40] so it would just pull the source package from the distro automatically into the ppa without requiring extra uploading or extra source packages [12:40] sil2100, ordering of prerequisites seems to have broken too https://ci-train.ubuntu.com/job/ubuntu-landing-017-1-build/21/console [12:41] popey: seems to be working for me (with #204) [12:41] sil2100, check those branches out and their prerequisites, the ordering is not good at all === renato is now known as Guest21428 [12:47] mvo_: ok, thanks [12:48] sil2100, if you can reproduce the music_app failure on krillin, can you paste me the error? [12:49] brendand: sure, let me just hook up my device [12:51] sil2100, hmmm ... another thing ... against what image do i test my rtm package now ? [12:51] i dont have any rtm install for the device i'm testing on yet [12:52] sil2100: FYI the UITK landing is blocked by this -> https://bugs.launchpad.net/ubuntu/+source/llvm-toolchain-3.5/+bug/1360241 [12:52] Ubuntu bug 1360241 in llvm-toolchain-3.5 (Ubuntu) "[Regression] LLVM error in executing Ubuntu UI Toolkit tests on x86" [Undecided,Confirmed] [12:53] sil2100: I wonder why the llvm was again updated once it was reverted exactly because it messed up the UITK releases. [12:54] bzoltan: ...great [12:54] bzoltan: I remember seeing some llvm discussion somewhere, but can't remember now what it was about [12:55] there is some complexity in that doko has been updating the llvm-toolchain itself, while mlankhorst has been updating Mesa to build either against LLVM 3.4 or 3.5 [12:56] so UITK hits the problem because mesa was now again put to use 3.5 https://launchpad.net/ubuntu/utopic/+source/mesa/+changelog [12:57] bzoltan: pitti and tvoss just also raised it on #ubuntu-devel [12:57] so apparently it affects others than UITK as well [12:59] or maybe it was just Thomas supporting us and Martin having seen it before too [13:05] sil2100, seems changelog generator is good again https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-017/+sourcepub/4368132/+listing-archive-extra [13:13] can I get a silo for line 36 please? [13:13] sil2100: Mirv: it seems I can not reconfigure the silo9 after I added the -gles branch [13:13] Saviq: yay \o/ [13:19] bzoltan: did you just add the branch now? [13:19] bzoltan: or you mean you can no longer reconfigure at all? [13:19] sil2100: yeps [13:19] Ok, we need to reconf then, it's a new project [13:20] sil2100: yes, it looks like it is UITK, but in fact it is not :) [13:20] One moment, spreadsheet is breakish for me ;) === Guest21428 is now known as renatu [13:22] bzoltan: done [13:22] sil2100: thanks [13:23] sil2100, cjwatson: hi. i'm a little confused about the ubuntu-rtm thing. are we not going to be doing straight syncs from ubuntu -> ubuntu-rtm like we do for deb -> ubuntu? [13:23] dobey, nope [13:23] :( [13:24] dobey: not really, as everything needs to be double-tested before it lands for ubuntu-rtm [13:24] sil2100, i think we can be lax wrt QA testing for landing in ubuntu though ... [13:24] i.e. i guess it is emough iif you only get signoff and testing for rtm [13:25] that might reduce the amount of extra work a bit [13:25] except that ubuntu is in feature freeze now [13:26] bfiller: ok, it seems that silo 004 cannot be published since someone released telepathy-ofono in the meantime, so a rebuild is required... [13:26] ogra_: right, true [13:26] sil2100: ok, I rebuilt it last night [13:26] you shoulld probably put that into a followup mail [13:27] will do it again [13:27] and several projects have devel branches that get changes first, then those get proposed for landing into ubuntu, and then they'll have to be landed to ubuntu-rtm [13:27] dobey, right === josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | CI Train support: trainguards | Vanguard (general help): josepht | CI Train Status: #203 promoted | CI Train Dashboard: http://bit.ly/1mDv1FS | Known issues: citrain struggles with source packages, don't WATCH_ONLY until *after* the source is built in PPA. http://youtu.be/-Rnw0D2AdYU. [13:27] dobey, ogra_: I might sound noobish here, but don't we have the standing FFe for touch apps again this cycle? [13:28] * sil2100 was so busy with the train that he might have missed it [13:28] sil2100, i dont think so, thats why i asked about FF and FFes yesterday [13:28] sil2100, i would suspect slangasek knows ... as a mmember of the release team [13:29] Let's wait for him to get rid of all (some) of our doubts [13:29] bfiller: strange situation, I wonder where that release came from... [13:29] and if landing to ubuntu and ubuntu-rtm get different version numbers generated, managing the MPs can be a bit annoying [13:30] sil2100: it was in silo 9 I think and we were told to rebuild once that landed.. guess I didn't wait long enough [13:30] trainguards, anything preventing silo 16 from publishing? [13:30] Saviq: no no, moving on to that one now ;) [13:31] sil2100, sorry, impatient ehre [13:31] Saviq: sorry for taking so long! [13:31] sil2100, so, is there a process for copying that to rtm yet? [13:32] since I think unity8 falls under the "rtm-only" category [13:32] Saviq: not yet, but I'll make the process much easier soon, and once cjwatson gets back I also have some even more 'rad' propositions [13:33] sil2100, so I should really get this into a rtm silo after it lands? I assume it's ok to squash the MPs then? [13:34] Saviq: yeah, so for now use new MPs, but just re-use the branches as they are [13:34] sil2100, can't re-use branches can I? I'd need to retarget to rtm-14.09? [13:35] sil2100, so file separate MPs for rtm [13:35] sil2100, which is a significant task when I have 10 branches on average per landing [13:35] Saviq: yes, new MPs, but I guess branches can stay the same? [13:35] sil2100, yeah, that's not good for us, too many MPs [13:35] with interdependencies and all, that will get fishy too soon [13:35] Saviq: I'll make this automated soon, I mean, I'll try ;p [13:36] sil2100, for now I'll go devel-style and use just one MP to land into rtm [13:36] sil2100, I've an idea to talk to you about devel/staging branches, too, when you have time === pete-woods is now known as pete-woods|lunch [13:48] sil2100: so for silo 4 once we land it, then we have to make new MR's against rtm-14.09 brances and resubmit another request? [13:49] bfiller: for now, yes, but this will be easier soon [13:49] om26er: if you don't mind I will update line #31 that QA test now passed with image #204, is that ok? [13:50] mvo_, I think we are not in traincon-0 anymore so my ack doesn;t really matter. But yes its good I think [13:51] om26er: aha, good to know, thanks [13:59] sil2100: eh, I guess I should know this, but what does "Migration: One package at least is not available at the destination. click (0.4.31.1) is in no known space (and time). (click)" mean exactly? [14:00] mvo_: it meanst that it's not in release or -proposed yet - that's usually the case right after publishing [14:00] mvo_: this means that the request has been copied to snakefruit and most probably copy2distro didn't yet run there to pick it up and push to the archive [14:01] But it will switch to -proposed soon [14:01] aha, ok. so nothing to worry about :) [14:01] thanks! [14:15] are images not being built from ubuntu-rtm yet? [14:16] They are [14:16] cjwatson said there's a cron job building once per day [14:17] sil2100: sorry, any update on silo 15? [14:17] sergiusens, you have system-settings in silo 8, i'd like to get a landing today, what's the status of that one? [14:18] let me kill it [14:18] thx [14:18] kenvandine_: was rejected [14:18] sil2100: hrmm. does one need to flash with a different channel now to get them? [14:18] also if a trainguard is available silo 2 can be freed; we won't land that this week [14:18] Mirv: can you kill silo 9? [14:18] ooop [14:18] Mirv: silo 8!!! [14:18] off by one finger [14:19] dobey: there's a ubuntu-touch/ubuntu-rtm/* channel set [14:19] also you can clear line 12 of the spreadsheet, this landing went into another silo; the request is obsolete [14:19] sergiusens: what do you need dead in that silo? The whole thing freed? [14:19] sil2100: yes [14:19] sil2100: cancel the landing [14:19] sergiusens, thx [14:19] haha [14:19] sigh :-/ [14:21] sil2100: can landers just request syncs from ubuntu to ubuntu-rtm for landings? [14:21] dobey, not yet [14:22] dobey: not yet - and besides, you anyway have to double test it in a silo [14:22] you need to do two landings currently [14:22] thostr_: ^^ :( [14:23] dobey, as cjwatson said in his mail ... such cases like syncing will need more testing ... which people simply didnt help with over the llast two weeks [14:24] it will come over time ... [14:24] I'll have something working soon, but this will have to be +1'ed by cjwatson best [14:24] ogra_: in my defense, I asked and was told to do the branch dance [14:25] so wasn't interested [14:25] sergiusens, well, you were one out of ... what ... five people ? [14:25] :) [14:25] ;) [14:25] 5... good joke ;) [14:25] if there had been 50 landings to test with instead of 5 ... [14:25] but I did present the use case ;-) [14:25] yeah [14:26] if only 30 oof the 50 testers had presented it too ... [14:26] ogra_: and I asked you what the process would be for only rtm too :) [14:26] oh, wait ... [14:26] there were only 5 [14:26] :P [14:26] ;p [14:26] anyways, I thought the rtm archive was supposed to protect us from new syncs from debian or a new Qt; not an extra extra process for us [14:27] which is what I think most people thought of after malta [14:28] I didn't invent the idea that things need to land in ubuntu first, but this makes sense in overall - and you need to remember that everything landing in ubuntu-rtm needs to be additionally tested by QA to make sure RTM is in best shape [14:29] The idea was that ubuntu can have flaws and can have some regressions, but only the most-probably-regression-free landings are migrated to RTM [14:30] Sync functionality will help out for sure, but even with it it will mean the sync will have to be restrictively tested before landing to ubuntu-rtm [14:31] sergiusens, but it does that [14:31] it protects us from QT landings and the like [14:33] the easiest way to solve these process issues is to have people making these process actually work with the process too [14:34] and that will happen [14:35] ogra_: so lxc-android-config going to be MPed and siloed? [14:35] android-tools you mean ? [14:35] oh [14:35] misread [14:36] ogra_: you rarely endure the pain ;-) [14:36] sergiusens, why ? [14:36] so you see how painful it is :-) [14:36] it will have to be siloed indeed [14:38] It's best if you contact QA about that, since as I said - core-devs can anyway do what they want and upload what they want - I just want it to be made sure QA approves the given upload [14:38] sil2100, btw, can i has rtm silo for line 35 ? [14:42] ogra_: sure, done [14:47] davmor2: hi, can i bother you with that silo15? [14:47] i'm pinging everyone involved to see if i can just land that now that it's been tested [14:47]