=== doko_ is now known as doko [09:22] slangasek: now after the multiarch email, should it be safe for a rebuild test? === ogra is now known as Guest67326 === Guest67326 is now known as ogra_ === ogra_ is now known as ogra [12:43] cjwatson: Could you also sync kadu 0.9.0-1, please? bug #739335 [12:43] Launchpad bug 739335 in kadu (Ubuntu) "[FFe] Sync kadu 0.9.0-1 (universe) from Debian unstable (main) (affects: 1) (heat: 10)" [Wishlist,Confirmed] https://launchpad.net/bugs/739335 === chuck_ is now known as zul [13:23] iulian: done [14:10] cjwatson: Ta. === jjohansen is now known as jj-afk [14:59] rebuilding Ubuntu desktop following the overrides fix from earlier === chuck_ is now known as zul [16:12] cjwatson: hey, so what Neil propose is to roll a tarball over night on Wednesday (once the US guys integrated this work), then we all test the work on Thursday morning and do the upload right away, what do you think? [16:13] when have you done the upload to natty before? [16:13] cjwatson: you mean, last unity release? it was on Thursday [16:13] when on Thursday? [16:14] was at 4 UTC IIRC [16:14] 4am or 4pm? [16:14] 4pm, we aim at afternoon release for the weekly uploads [16:14] but not for this beta one [16:15] cjwatson, usual schedule is that njpatel rolls the tarball in the uk afternoon and that didrocks pick it up and upload before eod [16:15] we will aim for an upload at 9/10am UTC [16:15] yeah, I'll roll before you guys wake up in CET [16:16] it's not ideal, but it is an improvement [16:16] that would presumably mean we get some testing throughout the EU day [16:16] right [16:16] Yes [16:16] is there anything that can be done to increase the probability that if things go wrong we can move back by reverting changes rather than having to move forward and debug? [16:16] landing usually takes some 3 hours [16:16] i.e nux needs to be built and published than unity builds [16:18] cjwatson: we still can revert both libnux and unity (as unity is the only nux consumer) [16:19] but that's an all-or-nothing thing [16:19] and as compiz release will be today, hopefully, we won't depend on that ABI breakage [16:19] yeah [16:19] I agree that moving the compiz release forward significantly decreases the surface area of things that might go wrong on Thu [16:19] basically, libunity/dee/places are independent [16:20] let me check we don't have melt changes there [16:20] going one version backward doesn't seem the best way to move toward a solid natty release anyway so downgrading doesn't seem something we should plan for [16:21] we never had a weekly release broken enough that we had to rollback or that we couldn't have shipped a CD with it until now [16:22] seb128, we need a fall back, given the scope of changes coming in at the last minute, and the visibility of this beta [16:22] seb128: agreed on that, we had extra crashers, but they all have been fixed in due time when we saw it was a wide impact [16:22] skaet, we have weekly rollouts, that one doesn't seem to be especially disruptive to me? [16:23] it's never over a week work and tested by a complete team during the week [16:23] seb128, its the scrollbars landing so late, and we really don't have a full development week here, but rather just a couple of days. [16:23] skaet, we have some annoying crashers that collect duplicate in the current version though, I would really rather look to a way of moving forward and getting issues fixed than planning on staying backward [16:23] skaet: I would like to ask for a standing freeze exception, mostly for universe packages to fix ld-no-add-needed and gcc-4.5-ftbfs, introducing new upstream versions with syncs/merges if fixes are available in debian, as long as we don't introduce new library sonames. would that generally be ok with you? [16:23] skaet, scrollbars have nothing to do with unity though [16:24] skaet, they don't seem on track to land this week to me, if we speak about overlay scrollbars [16:24] those changing are totally independant to nux/unity [16:25] seb128: at least some previous weekly releases before milestones haven't worked well enough to make the milestone releasable until late Monday night, which really eats into validation time [16:25] a few bug fixes are one thing, that wouldn't be a big deal [16:25] being badly broken on Monday is a problem [16:25] well usually they did plan 2 released, one on thursday and one bug fix one on monday [16:25] cjwatson: we didn't push broken things in natty… [16:25] and that's because they were still landing features [16:26] that's not the case there [16:26] we are over feature freeze [16:26] err, multitouch! [16:26] what about it? [16:26] new feature not yet in natty, landing in this update, right? [16:26] cjwatson, that should makes any difference on normal desktop installs though [16:26] sure, but even so, it's a new feature being landed [16:26] I will have to look back through history to find out what happened, but I'm certain that we have had serious issues on the Monday of a milestone this cycle [16:27] cjwatson, well seems you guys are freaking out for some reasons I don't understand [16:27] I'm not freaking out, I'm trying to minimise risk [16:27] cjwatson, right as said those were weeks with 2 releases planned [16:27] bug fixes on the Monday of a milestone should be a last resort, not a plan [16:27] one to land features being short on time, one to fix issues [16:27] that's not the case this week [16:27] er, on the Monday of a beta, sorry [16:27] there is no hurry feature landing [16:28] so is what you're saying that the Unity release this Thursday will be small and much more risk-free than previous releases? [16:28] cjwatson: that was for alpha… [16:28] the alpha2 rollouts being done on monday were planned this way to give extra time to land features for the thursday [16:28] didrocks: yes; we're looking for assurance that this will not be like that [16:28] cjwatson: and only bug fixes. Otherwise, freezing on Monday morning has no meaning for alpha [16:28] cjwatson: and as I told you, it's not planned for beta as we have one week freeze [16:29] so what is the character of this Thursday release? [16:29] is it mainly new features or mainly bug fixes? [16:29] cjwatson, it's not a trivial update but it's focussed on bug fixing and stabilization where alpha were focussed on rushing to land features missing still [16:29] it's mainly bug fixing and stabilization [16:29] with some ui tweaks [16:29] if it's not something you're planning to *have* to fix up four days later, I am less worried about it [16:30] I'd still like it as early as possible to minimise risk [16:30] and a bit of new things (the ffe which got granted) [16:30] cjwatson, right, the alpha landings were scheduled this way, land thing half broken and do a round of fixing on monday [16:30] but can you see why the release team is taking a once-bitten-twice-shy approach? [16:30] that's not the case there [16:30] the release is planned to be stable [16:31] it's hard to distinguish planned-breakage from just-plain-breakage [16:31] from our point of view [16:31] we just see that it made us be hugely stressed for three days [16:31] but can you see why the release team is taking a once-bitten-twice-shy approach? [16:31] yes [16:32] though I didn't realize that people got really bitten before [16:32] so we're just trying to make sure that we're not going to be hugely stressed for this reason at least, this time round :) [16:32] seb128, didrocks Just to be clear, we've already agreed not to do a Monday release right? [16:32] I though that stabilizing alpha on mondays was a clearly communicated and agreed decision between teams [16:32] njpatel, yes, we need something stable tomorrow night [16:32] right [16:32] njpatel: right, as that for quite some time already… [16:33] njpatel, beta needs extra testing and stability [16:33] and there is no released planned on Monday: https://launchpad.net/unity/+series [16:33] contrary to the other time [16:33] Yeah, this all breaks for US/EU people but whatever [16:33] that's fine, I'll release before Thurs AM [16:33] OK [16:34] seb128, which specific FFes are you refering to for the new things? can you be specific on when each part will land? all on Thurs AM? or some before? [16:34] didrocks, do you have a list of the ffe pending? [16:34] and to be clear, we don't object if it turns out that you absolutely *need* to fix something on Monday - the distinction is whether you're planning for it, or whether it's something that comes up [16:34] njpatel, ^ [16:34] cjwatson, right, nobody planned to be late for this round [16:34] +1 on what cjwatson said. ^^ [16:35] alpha were rushs because we were behind [16:35] with the intention that we can do an initial validation pass on Monday [16:35] understood [16:35] skaet, we land them in trunk as the week goes on and roll on thurs morning normally (so they get testing through the week) [16:35] seb128: the latest one is the MT support: https://bugs.launchpad.net/unity/+bug/737601 [16:35] Launchpad bug 737601 in unity (Ubuntu) (and 1 other project) "Restore MT support in Unity (affects: 1) (heat: 879)" [Undecided,In progress] [16:35] skaet, ^ [16:35] skaet, so we've landed a big change already, one more from me today, and then minor bit stomorrow (and testing) until release tomorrow evening [16:36] njpatel, thanks, this is what I was looking to understand. [16:36] cjwatson, We're working on the idea that we're not allowed to upload past thursday morning, unless we've broken the world [16:36] and we're not planning to do that (april 1st is still some time away ;) [16:37] * skaet notes release is on March 31st... [16:37] skaet, you mentioned scrollbars, that's another story [16:37] *beta 1* release is on March 31st :-) [16:37] * njpatel makes sure that the launcher icons turning into pictures of Mark is still working [16:37] skaet, but that shouldn't have any impact on the default installation [16:37] (having gone "oh god it isn't is it?") [16:37] lol [16:38] skaet: I would like to ask for a standing freeze exception, mostly for universe packages to fix ld-no-add-needed and gcc-4.5-ftbfs, introducing new upstream versions with syncs/merges if fixes are available in debian, as long as we don't introduce new library sonames. would that generally be ok with you? [16:39] seb128, and there shouldn't be any impact or interaction from the new changes with 2-D ? [16:39] doko, sorry to not getting to your early post. trying to follow the thread here. [16:39] skaet, from what? scrollbars? or unity 3d? [16:40] seb128, either ;) [16:40] skaet, reply to doko, when we can continue on unity and scrollbar after that [16:40] skaet, what do you call 2d? unity 2d or GNOME classic? ;-) [16:40] but no, nothing should impact on either of those [16:40] no haste, if you are in a meeting ... [16:41] doko, just trying to settle issues with the release... and am thinking about the implications of what you're asking. [16:43] doko, I don't think we can take a broad FFE approach, uploadable at any time approach right now. However there where be windows of time, where getting the fixes in should be ok, as long as they are just fixing the ld-no-add-needed, and gcc-4.5 ftbfs. Its what else might be included in the packages with those fixes, compared to whats in the repository that concerns me. [16:44] skaet: sure, I know, but we'll probably release with a lot of ftbfs without such an approach [16:45] That being said, if the package is in universe a broader FFEs for those actual ones, is probably ok. If its not in universe - would like it explicitly FFe's and implications scrutinized a bit more. [16:47] doko, can we keep the uploads down until after the beta 1 is out, and then revisit on the friday meeting? [16:48] I'd like to get the ftbfs fixed as well, just they can't go in, in an ad hoc manner. [16:50] skaet: I didn't ask for ad-hoc [16:50] doko, I misunderstood broad FFE then. [16:51] doko, what is specific proposal for the changes to universe, ( when uploads ), and what is it for the others. (reacting to the word "mostly universe") in you original request). [16:52] * skaet looks at format of above line and hangs her head. [16:53] skaet: s/universe/not main/ [16:55] doko, so request is for blanket approval for FFEs in non main archives only? [16:55] skaet: yes [16:55] and without library transitions [16:56] * skaet thinking.... === jj-afk is now known as jjohansen [17:01] doko, if the changes are only to fix the ftbfs and not introducing new features from the current version, we should be fine then. If there is functionality change in together with the fixes, would prefer those get considered on a case by case basis or wait to Oneiric. If you avoid uploads during the beta freeze windows, esp. if we're having to do alot of rebuilds to get the images, that would be appreciated. [17:02] s/ftbfs/ ftbfs and ld-no-add-needed/ [17:02] skaet: ok, will file rc reports then, please feel free to re-assign these ;) [17:02] doko, fair enough, and thanks for pushing for this. getting these ftbfs cleaned up is a good thing. [17:06] seb128, if nothing thats coming should cause a regression on unity 2d or GNOME classic, am happy. :) [17:20] skaet, ok great ;-) [17:28] skaet, btw you were mentioning scrollbars before, did you have any specific concern about those? do they need to land in beta if they land in natty? [17:29] I had thought they'd be showing up this week. However if they're not stable/debugged enough, would like to very carefully work out when their landing. [17:29] seb128 ^^ [17:30] skaet, ok, I'm still waiting on an update patch to gtk to review and the bug will need a ffe approval once that's done [17:30] updated [17:30] then we need the new source to be uploaded to universe, reviewed, approved, etc [17:31] ok, lets over communicate a bit on this one, and judge the tactical window based on when things are ready and solid enough from your side. [17:33] ok [17:36] skaet, well I'm not happy that we have to ship a gtk hack in ubuntu but it doesn't seem it's going to be an issue for the distro stability so it's already something [17:37] i.e the patch is not likely to break things, it's just that it's not done the right way and hackish [17:38] I've no strong opinion about the lib itself yet but since that's an opt-in thing we can still evaluate how stable it is [17:41] seb 128, expectation set for the release notes is then that the implementation will improve in oneiric, and interface is provided as a prototype? will be on stand by for more data on the lib itself. [17:44] skaet, ok [17:45] thanks [17:45] I will keep you updated if I get new infos on that front [17:48] sournds good [17:49] sounds, even [17:49] thanks === smspillaz is now known as smspillaz|zzz [18:33] skaet, ScottK, Riddell: what's the state of kde on armel? [18:40] doko, I remember seeing that they fail to build in the daily reports, but am not sure of I've heard a root cause, yet. Went to go look up the recent reports, but I appear to have been a bit enthusiastic in cleaning my inbox this morning. :P [18:41] http://people.canonical.com/~ubuntu-archive/livefs-build-logs/ is your friend [18:41] cjwatson, awesome! :D [19:06] ScottK: postfix 2.8.2-1 uploaded to debian... did you want me to ask for a sync, or upload or ?? [19:19] doko: mostly good I believe except for packages which use opengl [19:22] Riddell: hmm, just saw a subversion build failure: [19:22] The following packages have unmet dependencies: [19:22] kdelibs5-dev : Depends: kdoctools (= 4:4.6.1-0ubuntu2) but it is not going to be installed [19:22] E: Broken packages === bjf is now known as bjf[afk] [19:41] I find that I am annoyed at the arm builders... quiescing the whole lot of them, then I'm going to make them happy , and put them all back in the pool together. [20:05] doko: indeed kde4libs failed and there's no logs so I don't know why [20:10] given that it's armel, perhaps it's related to lamont's above comment about builders being unhappy [20:11] I've requested a retry [20:12] (at least then we'll get a log, hopefully) [20:14] if it was building before I just stabbed them all, well, that'd be why there's no log === bjf[afk] is now known as bjf [20:26] is the pile of builds on i386 a translations update pile? [23:12] doko: As Riddell said, the issue right now is packages that use GL. I'm not sure where they are on getting fixed. I think slangasek had someone looking into that. [23:12] ScottK: well, lets hope that kde4libs gets built first ... [23:13] doko: Sure. It's built before so there's no reason to think it won't.