[00:32] rsalveti, cyphermox, you around, need someone to publish https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AuDk72Lpx8U5dFlCc1VzeVZzWmdBZS11WERjdVc3dmc&usp=drive_web#gid=28 [00:32] * rsalveti checks [00:33] looks fine, didn't test, but you tested it :-) [00:33] rsalveti, I did as ogra_ [00:33] great [00:34] sergiusens: done [00:34] ty === fginther changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cihelp | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: - === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [03:05] === trainguard: IMAGE 263 building (started: 20140327-03:05) === [04:25] === trainguard: IMAGE 263 DONE (finished: 20140327-04:25) === [04:25] === changelog: http://people.canonical.com/~ogra/touch-image-stats/263.changes === [04:26] rsalveti, gave you silo 12 [04:26] robru: thanks [04:27] rsalveti, you're welcome [04:28] robru: hey would you have a moment to help me with a silo reconfig? [04:28] veebers, absolutely! [04:28] robru: awesome thanks :-) I have update the MPs on line 21 [04:29] (as well as updating the description as requested) [04:29] veebers, is it all just autopilot? any new projects there? [04:29] robru: no, just autopilot [04:30] veebers, ok, you should be able to take care of that yourself. have you been trained on the reconfig job? [04:30] robru: ah right. No I haven't been trained to use it [04:30] veebers, ok i'll give you a crash course [04:30] robru: do you mind stepping me through it now? [04:30] awesome cheers [04:31] veebers, so in the spreadsheet, you'll see you're in silo 3. if you go to the 'landing-003' tab at the bottom of the spreadsheet, there'll be a bunch of big yellow buttons [04:31] robru: right, I'll go to reconfigure [04:32] veebers, just remember you have to copy & paste the merge URLs into the reconfig job [04:32] robru: ah I see. I need to put the MRs there [04:32] veebers, yeah [04:32] robru: do I need anything in the sources param? [04:32] veebers, so that should work as long as you're not adding a new project that wasn't assigned to the silo before. if you need to add a new project, then it requires my help [04:33] veebers, not in this case. sources is only for things that aren't hosted on lp where you might want to do a manual upload (such as xorg or android) [04:33] robru: right makes sense. [04:33] robru: thanks for that, I have used the train before, just not the reconfig. I guess I could have figured it out myself, but didn't want to break anything :-) [04:34] veebers, just let me know if you have permission to do the config job. I don't have access to change the ACL so if it doesn't work for you, we need to ping didrocks and I'll just take care of the reconfig for right now [04:34] ugh, why doesn't it ask me for permissions _before_ I can see the jenkins job page :-\ [04:35] robru: seems I have perms ok (I'm just watching the console output now) [04:35] veebers, yeah, that bites me all the time. sorry :-/ [04:35] heh no worries :-) [04:36] robru: as soon as that config job is done I'm good to go and build etc. right? [04:37] veebers, yep. it might take a second to update the status in the spreadsheet, but that doesn't even matter. as long as the jenkins job says it's done, you can start the build job right after that (the script that updates the statuses in the spreadsheet has some lag, don't wait around for the spreadsheet if you care about efficiency) [04:38] robru: awesome, thanks again for the help [04:38] veebers, you're welcome! [05:00] morning [05:10] Mirv, ah, you're here! goodnight ;-) [05:11] :) [07:00] Mirv: hey, FYI, don't assign any silo right now, I'm pushing the ID transition [07:01] ok [07:03] backend done, moving frontend [07:22] good morning === tvoss|afk is now known as tvoss [07:40] frontend and sync available [07:55] didrocks: so, I could try assigning a silo now? [07:58] Mirv: I'm trying to assign some and see if there are any bugs before giving you the green light :) [07:59] ok :) [08:00] Are we migrated to the new way of silo assigment? ;) [08:02] sil2100: tests ongoing [08:02] \o/ [08:24] grrr, as there was a bug spawning with writes, it doesn't want to execute any other script now :( [08:29] didrocks, hey, wecanhassilo for row 56 please? [08:31] Saviq: not before didrocks gets less grrr [08:32] Saviq: let me attribute it to you, this part is working [08:32] Saviq: however, you won't get status feedback for now [08:32] uh oh [08:32] didrocks, thanks, will manage [08:35] Saviq: landing-013 [08:36] didrocks, thanks [08:39] frustrating, I introduced the bug when adding debugging :/ [08:49] * ToyKeeper hugs chrome's "tabs outliner" add-on... makes it so much easier to keep track of bugs which need re-testing! [08:50] Saviq: status refresh are back! [08:51] * didrocks just need to fix one bug (so 2 bugs for 500 lines rewrites, not bad) [08:52] auto assignement/removal works [08:53] \o/ [08:55] So, when can we give it a spin too :D ? [08:56] sil2100, icanhassilo for row 57? [09:01] didrocks: can I try it out? ^ [09:07] sil2100, I did an exploratory testing with silo 14, looks good [09:07] tvoss: I'm rebooting my phone now with those changes [09:07] sil2100, great :) [09:07] sil2100, once you are happy, I will set to testing -> yes [09:11] sil2100: sure, you can :) [09:12] * sil2100 assigns! [09:13] Woooo [09:14] working all fine? :) [09:16] Yes! Almost thought that something's wrong with assigning the silo in the spreadsheet, but it finally updated \o/ It's awesome! [09:16] Saviq: assigned, silo 10 [09:17] sil2100: well, there is the 2 minutes delay at most to get infos from the backend [09:17] sil2100, cools, what's new? [09:18] Saviq: basically, no need to copy and paste all MPs ans sources, only a request id (and no need to reassign manually on the frontend the selected silo by the backend) [09:18] didrocks, does that affect us (when reconfiguring), too? [09:18] Saviq: it's quite a big change in the whole spreadsheet logic for this [09:18] yup [09:18] Saviq: for now, you will need to get the request id [09:18] I'll change that after the landing meeting [09:18] so that it's automagic [09:19] okies cool [09:19] so basically, you will just have to press "build" [09:19] Saviq: FYI, siloMatrix is dead [09:19] the whole assignement is in the pending spreadsheet [09:20] * didrocks removed ~120 functions calls with this [09:20] :) [09:20] sil2100: Mirv (if you ask yourself why the siloMatrix isn't there anymore) ^ [09:21] ok :) [09:21] :D [09:23] Saviq: seb128: if you need a reconfigure for now, just ping us to give you your requestID [09:23] should be changes in < 1h hopefully [09:23] changed* [09:23] didrocks, ok, thanks [09:23] sil2100: Mirv: to get an existing ID, just select the line and choose in the menu "assign silo" [09:23] it will give you an existing ID if it's already assigned [09:24] generate a new one otherwise [09:26] Ok, awesome [09:29] tvoss: looking good seemingly, let's publish [09:30] sil2100, ack [09:30] sil2100, did you hit merge&clean, yet? [09:32] tvoss: no no, I need to get a +1 on the packaging diff [09:32] And then we need to wait for it to land in the archive [09:32] didrocks: looks good, needing ACK -> http://162.213.34.102/job/landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_process-cpp_1.0.0+14.04.20140326.2-0ubuntu1.diff [09:34] sil2100, okay, so you keep me posted, when I can hit the button? [09:34] Sure [09:39] didrocks: when you have time, I tried and apparently succeeded in getting a silo landing-016 for qtlocation http://162.213.34.102/job/prepare-silo/701/console but it's not showing in the spreadsheet [09:42] Mirv: it might show up in a moment, how long did you wait already? [09:43] sil2100: 15 min so far [09:43] and yes so I looked from the discussion that it might take some time [09:43] it's a special case with no MP:s and only manual upload package, so it might trigger something differently [09:46] Mirv: it might be a bug then! [09:49] didrocks: ff/gtalk/sound combo mess, did you see my msg about 263 being green ? [09:49] vila: yeah, all fine, don't worry, thanks! :) [09:49] and good luck for your issue [09:49] didrocks: ack, thanks ;) [09:52] * vila grabs the shotgun [09:57] where do we file bugs against individual scopes? [09:57] (the new ones) [09:59] sil2100, silo 13 can be published [10:03] Publishing [10:04] didrocks: do you have a moment for that packaging ACK ? :) (soname bump http://162.213.34.102/job/landing-014-2-publish/lastSuccessfulBuild/artifact/packaging_changes_process-cpp_1.0.0+14.04.20140326.2-0ubuntu1.diff) [10:04] sil2100: oh right, I was looking at that, yeah, +1 [10:04] (and then forgot) [10:04] didrocks: thank you! [10:04] sil2100: all the rdepends are going are rebuilt? [10:05] s/are going / [10:05] to pick up the new soname? [10:09] sil2100: ^ [10:09] tvoss: ^ [10:10] didrocks, it's only rdepends not reverse build depends [10:11] $ reverse-depends libprocess-cpp0 [10:11] Reverse-Depends [10:11] =============== [10:11] * libdbus-cpp2 [10:11] * libprocess-cpp-dev [10:11] * libunity-mir1 [amd64 armhf i386] [10:11] * libunity-scopes0 [10:11] tvoss: so, you did rebuild dbus-cpp, unity-mir and unity-scopes? [10:11] (I didn't watch the whole thing) [10:11] didrocks: yes [10:11] excellent :) [10:12] didrocks: they were in the silo ;) That was the thing I noticed yesterday and we rebuilt it [10:15] good work guys :) [10:47] sil2100: Mirv: Saviq: seb128: ok, now the self-reconfigure doesn't take any parameter anymore, just click "build", enjoy :) [10:47] didrocks, \o/ [10:52] Ouuu yeeea [11:03] sil2100: hi, i have a policy question: one of our dependencies can't build on powerpc/arm64/etc. so webbrwoser-app will timeout building on those (dep-wait i guess) [11:03] i've got a question about the trunk branch wrt ci train landing: does it have to be 'trunk'? does it have to be the focus of development on launchpad? something else? [11:03] so should we disable builds on the archs that won't work in the main package? [11:04] dbarth: so, was that dependency available on ppc arm64 before? [11:04] dbarth: tell me about the specifics and I'll investigate [11:04] v8 has no assembler for those, and v8 is in blink, which itself is in oxide [11:04] so oxide won't build on those arches [11:04] webbrowser-app was built on arm64/powerpc/ppc64el before [11:04] dbarth: oh, and that will make webbrowser-app unavailable for ppc again? [11:05] dbarth: fwiw if you actually need this overridden you need an archive admin, sil2100 isn't empowered to override it I'm afraid [11:05] cjwatson: but is now moving to oxide as a /build-dep/ though [11:05] dbarth: ok, so I guess cjwatson might help you here, he might be the best person to take a decision if we can remove it from the archive for those archs or not [11:05] jdstrand: did anyone consider the v8 portability story with oxide? [11:05] cjwatson: ah ok [11:05] * sil2100 sadly has no power at all [11:05] ;) [11:05] cjwatson: was discussed yesterday or so, i think doko asked [11:06] and what was the answer? [11:06] in the MIR for oxide (can't remember, i will just lookup the bug ;) [11:06] https://bugs.launchpad.net/bugs/1293681 [11:06] Ubuntu bug 1293681 in oxide-qt (Ubuntu) "[MIR] oxide" [High,Fix committed] [11:06] anyway, webbrowser-app has no rdeps on those architectures, so I can remove the binaries [11:06] Morning all [11:06] dbarth: is there a landing PPA I can look at for more details though? [11:06] see comment #4 [11:07] I see. It looks like a sad inevitability for now [11:07] cjwatson: in summary, google may do it on v8 for certain arches, but not all of them [11:07] right [11:08] Please try to avoid adding lots more dependencies on this to other existing packages though [11:08] The next case might not be easy to untangle [11:08] we'd need to rely on qtwebkit for those then [11:08] but that's just what we were trying to avoid to simplify the maintenance [11:08] I get that you might need it occasionally [11:08] I just don't want it leaking out all over the whole stack [11:09] I assume most of this is contained to the webapps/webbrowser elements [11:09] yes [11:09] but the dependncy chain may not be as simple [11:09] we need to ensure that unity7 isn't going to dep on webapps then [11:09] i can check how far it goes [11:09] (which would be wrong) [11:09] didrocks: that'd want to be no stronger than recommends anyway, right? [11:10] cjwatson: correct, but the first implementation 3 cycles ago was not optional, I think we need to check that's not coming back in another way [11:11] cjwatson: the landing ppa is https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/ if you need it [11:11] unity-webapps-service only depends on webapp-container on amd64 i386 armhf right now [11:11] so if we can carry on with that kind of bodge then we should be fine [11:12] unity-webapps-service already limits the supported architectures you mean? [11:12] yes [11:12] (looking up the branch) [11:12] ah ok [11:12] in its dependency on webapp-container [11:12] dbarth: ok, is this otherwise ready to land? I can remove the problematic binaries, but I don't want to do so until you're actually ready to land this because otherwise there's a risk I'll have to do the work twice [11:12] we're not ready yet, nope [11:13] the silo was for checking all bits work together [11:13] and we caught this one [11:13] dbarth: give me a shout when you are, then [11:13] and otherwise consider this will-be-fixed [11:13] but to make sure: should we modify the packaging of webbrowser-app? [11:13] I don't see why [11:13] ok, so we just let some builds fail, and the landing is a manual step [11:14] they aren't even really failing, they're dep-waiting [11:14] right [11:14] which is fine as long as it is made not to be a regression from trusty (which will happen by way of me removing the binaries) [11:14] ok thanks Colin [11:14] ah [11:14] in fact that's actually better than a hardcoded architecture list [11:15] ok [11:15] they suck, they take ages to unwind when we port things [11:16] ahem. Sorry for the bad timing in asking my question, above :) [11:16] i'll repeat: [11:16] i've got a question about the trunk branch wrt ci train landing: does it have to be 'trunk'? does it have to be the focus of development on launchpad? something else? [11:17] Chipaca: hey, that's what we do advise strongly during the bootcamp, yeah [11:18] Chipaca: you have UDS session on CI Train about the reasoning, but mostly, it's about focus, being able to pick any MP and get it in [11:18] didrocks: thing is, i'd like to have a different branch where dev branches land, so the server work isn't blocked on the ci train [11:18] Chipaca: for upstreams with a lot of branches, they are keeping up with it (even if the Airline is supposed to fix where you can end up with multiple MP conflicts) [11:18] and then have the ci train merge that [11:19] Chipaca: your client and server are in the same branch? [11:19] didrocks: the server depends on the client (because the client has the protocol, and acceptance tests, and the basic server, yes) [11:19] agreed, that for thing one, until we have the airline, it's more tricky [11:19] that is: the production server is a specialization of the demo/test server that's in with the client [11:19] just to be clear, what we do want is: [11:20] - in case of regression/failure, upstream being reactive to fix it (and not "I don't care because I continue to push to my own trunk") [11:20] - a fix should be easy to pick from the devel branch without to have pulling the whole trunk [11:20] s/pulling/to pull/ [11:21] (and if I mentionned both, it's because both happened and happens) [11:24] didrocks: as I see it, if the only difference between the pre-trunk branch and trunk is the manual process involved in landing things on trunk, both of those are just as satisfied as without it, and it unblocks people from waiting on the train [11:25] Chipaca: depends on people I guess, but if you commit to not land into that, for your case, I think this can make sense [11:27] didrocks: ok. And I understand how this could fail if we don't truly commit to the above, but if you're willing to give it a try I'll set it up [11:27] Chipaca: sure, you can do that :) [11:27] didrocks: thanks [11:27] yw, thanks for the head's up :) [11:28] didrocks: can you think of a name that communicates "this is where dev branches land before manual testing and ci train merging"? [11:29] otherwise it'll be some variation of "staging" or "canary" :) [11:29] or maybe just pre-trunk [11:30] Chipaca: we were discussing exactly the same for ubuntu-ui-toolkit [11:31] t1mp: their case is a little bit different as they need protocol to be available for the server side [11:31] t1mp: ubuntu-ui-toolkit also has a server that might need a quicker turnaround than the client for security or performance reasons? [11:31] Chipaca: no [11:31] t1mp: btw, just telling, still no SDK requests… so I don't understand why you are blocked on getting MP in [11:31] t1mp: ah :) [11:32] Chipaca: I'm not imaginative on names [11:32] didrocks: because we run all the tests before happroving and before doing landing requests [11:32] t1mp: yeah, and so, you are not passing tests and can't bundle them in one big requests? [11:33] t1mp: the external communication seems that you are locked by us, I'm clearly unsure why [11:35] didrocks: yes we are not passing tests for the individual MRs. I don't think the MRs are wrong (lets say an MR without changes will even fail) [11:35] didrocks: so it is more a matter of our policies than not being able to create a landing request [11:35] t1mp: they are passing on the dashboard though [11:35] ok, please be clear in the communication then, it seems what I'm hearing back from your team telling to other people don't really match that [11:36] didrocks: yes images 262 and 263 seem good. yesterday I spent time trying to get the ubuntu-test-cases scripts running locally for testing but I didn't finish [11:37] t1mp: as told multiple times, (and during the bootcamp to the lander), the metric should be "do we have the same failures than in the dashboard and not more?" [11:37] not "do we pass all tests" [11:37] otherwise, you will be blocked on other people having their tests failing [11:38] (of course, you need to check that the tests that are failing are exactly the same and due to the same cause) [11:38] didrocks: yes that was the problem. So either I misunderstood our policies, or we have impossible policies for uitk MRs [11:39] t1mp: TBH, you policy seems really impossible to me, let's see I do a wrong commit in unity8 AP tests [11:39] then, sdk shouldn't be blocked on that [11:39] sdk should just not "aggreviate" the issue [11:39] (if that makes sense) [11:39] didrocks: yes it makes sense [11:40] the lower you are in the stack, the more responsabilities you have [11:40] but don't punish yourself more than you have to ;) [11:41] bzoltan: you should have a read here as well (the last 10 minutes) ^ [11:41] well the idea of having 100% OK on all app AP tests is nice, but clearly not working well [11:41] yeah, clearly not reachable or you will release almost never [11:41] and then, you end up with that status [11:41] but for me, there was no ambiguity, I didn't know you have that policy [11:42] (of course, an AP failure can hide another one, but I think that's rare enough that we can afford the risk) [11:42] didrocks: still having a staging might make it possible. We don't require 100% for merging to staging, but before staging goes to landing/trunk we can wait for an image where we have 100% [11:42] t1mp: you will almost still never release in distro [11:42] t1mp: as from experience, we are not at 100% frequently [11:42] so I guess you are not going to fix your problem [11:43] just pushing it back on tree down the street [11:43] didrocks: we had images 250 and 262 now 100% on mako. I hope 100% will only become more frequent :) [11:44] but I cannot predict that of course [11:44] t1mp: well, better to deal with the reality for now and not having you blocking on that [11:44] and that's the policy that all other upstreams have btw [11:44] okay [11:44] or you won't be able to push code to distro and it won't be sustainable [11:45] bzoltan: ^ we can start to work with that now and see from there if we need/can improve the process? [11:45] t1mp: I guess the harder for you will be the first landing now that you have a lot of branches [11:46] but then, I think you will be in a similar situation than other trunks with a lot of commits [11:46] didrocks: we don't have to land all the branches at once, we can start with a few simple ones [11:46] t1mp: agreed, you can try multiple batches [11:46] t1mp: Would you join to Mumble? [11:46] ok [11:52] didrocks: I'm not a lander, so maybe I missed it, but what is the main argument against having a staging where the changes go first before landing them? [11:52] didrocks: sorry if you had to explain it several times before already [11:53] t1mp: bzoltan should have them, but you can see what I wrote 33 minutes ago on the same channel :) [11:53] didrocks: to Chipaca or me? (I'm reading through the backlog now) [11:54] to Chipaca [11:54] basically decolloration of concerns and release early, release often [11:59] didrocks: decolloration? [11:59] bzoltan: separation of concerns [12:00] didrocks: pronouncing it sounds ... hkhm... odd :D [12:00] yeah, I mistyped [12:00] decorrelation* [12:00] didrocks: OK :) dick coloration [12:00] :p [12:01] with a staging we still want release early & release often, but there will be a buffer (that we should keep small) === cjohnston changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: cjohnston | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone | Known issues: - [12:02] t1mp: the question is why? it seems you argument was the 100% tests passing [12:02] which won't get fixed by it [12:03] didrocks: true [12:04] well with the buffer we can wait for 100% before landing, but I'm not sure anymore if that's worth it [12:05] well [12:05] didrocks: it seems like we are too careful trying not to break anything [12:05] you won't be able to land the buffer often I think [12:05] as I told above :) [12:06] and when you land your buffer, there is a higher chance that you are going to have regressions (harder to decipher then) with things not catched up by automation [12:09] cjwatson: re v8 portability> I'm not sure of the context of the question. if you are asking re MIR> yes, there is a question in the MIR bug with a statement. if re why in the 1st place> ppc64el didn't exist when the decision was taken and arm64 is expected from upstream [12:09] just wondering about ongoing prospects. it looks like the MIR answers that (not really to my liking, but never mind) [12:10] as for the statement> as mentioned arm64 is expected. if we want ppc64el, we just have to work with upstream rather than distro patching [12:10] I have to believe upstream will want to support arm64 devices at some point [12:11] ppc64el I would think would be an easier port and more palatable to upstream than powerpc, but that is just a hunch [12:20] sil2100, hmm "Migration: One package at least is not available at the destination. thumbnailer (1.0+14.04.20140327-0ubuntu1) is in the UNAPPROVED queue." what's that about? [12:20] it's landing 013 [12:22] Saviq: beta freeze [12:23] Saviq: because of beta freeze it seems thumbnailer is locked in unapproved [12:23] sil2100, ah right [12:23] Saviq: you can try bribing the release team to push it forward or simply wait for it to move on ;) Do you have another landing of thumbnailer nearing by or something? [12:23] You should put that in the general status [12:23] sil2100, not that I know of, let me ask [12:24] another one about oxide [12:24] The freeze is intended to stay on until the release, btw [12:24] ah jdstrand maybe you can help [12:24] should chris find a sponsor for uploading a new version of oxide [12:24] or should we go via the silo/ppa now that it's going to main? [12:25] A silo can be used for this if it's related to the landing [12:25] and do we have /very fast/ arm builders? [12:25] Then it will be pushed to the archive along the merge branches [12:25] oxide is webkit/chrome and takes ages [12:25] dbarth: our silo PPA's have the same builders as the archive has ;) [12:25] dbarth: highbank is pretty good [12:25] so fast? [12:26] ie native [12:26] silos are native, yes [12:26] ok then [12:26] ah cool [12:26] jdstrand: that's the way to go right? i'm not sure if we're already in main or just about to [12:26] (that should be the first new upload i guess) [12:27] dbarth: that is an open question. we have to define how to do landings. in the meantime, we can do whatever is easiest. I can sponsor for chris, or we can go the silos route [12:27] dbarth: what I've done with apparmor is have them upload to our security-proposed ppa, then I pocket copy from there to a silo after review [12:28] dbarth: don't we have this same issue with webbrowser-app though? [12:28] ah [12:28] hmm, yes as we were discussing with cjwatson earlier [12:28] dbarth: it isn't in main afaik-- it needs to be seeded or something needs to Depends/Build-Depends on it [12:29] he proposed to take care of the webbrowser-app archive injection [12:29] to avoid speical casing a build that should be kept clean of arch specific controls [12:30] ah right [12:30] sil2100, so, if the freeze is on until release, does that mean we can't land anything? or is thumbnailer just not exempt like other touch-only components? [12:30] jdstrand: right now i need a newer build somewhere like in silo 009, universe or main to have the silo be landable [12:31] or it just crashes webbapps [12:31] Saviq: I think we need to discuss that with the release team, so that we can release that through the block [12:31] jdstrand: i guess i should take oxide in the silo as well [12:32] dbarth: how do you handle webbrowser-app? is it ppu or is oSoMoN core-dev? [12:32] (that is another option btw, chris pursuing core-dev) [12:33] webbrowser-app lands via a silo [12:33] I see [12:33] we aren't setup for autolanding yet [12:33] (via silo) [12:33] ok nw [12:34] Saviq: I need to rebuild landing-010 [12:34] sorry, my fault [12:34] have you started the testing on it already? [12:34] dbarth: so we need to do source package upload. do you want that via the archive or the silo? [12:34] didrocks, k, was about to test it, will wait then [12:35] jdstrand: via archive i guess; then we avoid the extra build [12:35] sorry, I meant to say the other option is chris pursuing ppu (he could do core-dev too, but ppu should be much faster) [12:35] yup [12:35] dbarth: I can avoid the build [12:35] * jdstrand can do a copy [12:36] ah [12:36] plars: any ideas what can be wrong here? [12:36] jdstrand: but maybe we can stay in universe still this week and chris can upload right now [12:36] but, it seems that via the archive is fine too [12:36] that would work too [12:36] then once the silo is ready we do the seed / depend dance [12:36] and talk about silo landings again [12:36] Saviq: building now :) [12:37] ftr, he can always upload to one of the security teams ppas. you then can ask me, an archive admin or a member of the citeam to copy the packages in [12:37] (in to the silo) [12:37] Saviq,sil2100: we'll be able to land thumbnailer after we're done with the beta [12:37] Saviq,sil2100: it's just on non-touch images so it would be disruptive to land it *right now* [12:38] dbarth: but, like I said in the email thread-- it is an open question how to do the landing since there will be multiple trees for dev, beta, stable, etc [12:38] cjwatson, ok, I misunderstood Laney, then [12:38] yup [12:38] dbarth: have you communicated with chris that we need an upload prepared? [12:38] cjwatson: oh, ok, since I misunderstood Laney that the beta freeze is till the release, ok [12:38] jdstrand: yes [12:38] Thanks [12:38]