[02:18] slangasek: Not that I particularly care in this case, but seeing that your gconf upload introduces two new binary packages, shouldn't there have been an FFe? [02:20] ScottK: hmm, yes, it probably ought to have - sorry [02:33] Consider yourself suitably chastized. [03:44] ScottK: could be worse, I could've managed to upload this completely broken patch to soprano I've been working on that my test methodology was broken for :) [03:45] slangasek: It depends. If that would stop Nepomuk eating my CPU it might be a net win. [03:45] heh [03:45] Actually that's gotten much better recently, but it's fun to complain about. [09:26] hey jibel [09:44] knome, morning [09:46] jibel, did you get my PM, or should i repost? :) [10:00] knome, I didn't get it [10:00] jibel, oki - just a sec, i'll PM you again === greyback is now known as greyback|lunch === chrisccoulson_ is now known as chrisccoulson === greyback|lunch is now known as greyback [13:10] Hi, I need somebody to consider this FFe please: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/947976 [13:10] Launchpad bug 947976 in unity-2d "[unity-2d] FF exception to add PointerBarrier to Unity2d" [Undecided,New] [14:57] good morning. I'd appreciate it if someone from the release team could look at bug 944849 and give a go/no-go. thanks! [14:57] Launchpad bug 944849 in isc-dhcp "[FFe] converting isc-dhcp from sysvinit to upstart" [Undecided,New] https://launchpad.net/bugs/944849 === chrisccoulson_ is now known as chrisccoulson [15:15] Daviey, could you weigh in on the implications of FFe 944849 ^, can we stabilize this change if it lands before 3/15? Any interactions with the other changes already planned that you're aware of? [15:16] stgraber, would the change be able to be landed before 3/15? [15:17] skaet: yes [15:17] skaet: I'd likely have it done and tested this week [15:18] it was initialy an ubuntu-server work item I stole from Daviey's team as they didn't have enough time to do it for 12.04 [15:18] thanks stgraber, that's what I was hoping to hear. :) [15:18] * skaet smiles at that... ;) [15:23] skaet: I'm not too concerned about that. stgraber knows what he is doing, and it's easy enough to rollback if we need to. [15:24] Daviey, it was more if there were implications with any of your other plans/fixes landing that I was wanting to make sure you had input. [15:25] but if you don't forsee any issues, with the other fixes landing, and it can be done this week, I'm ok with it. [15:25] skaet: Yep, thanks. I understand it, that for IPv4 it would be no-change.. and currently, none of our specific plans are dependant on ipv6 features. [15:26] So works for me :) [15:26] Daviey, coolio. [15:26] stgraber, I'll go put an approved comment in the FFe with the caveat that the work must land before 3/15 [15:26] skaet: ok, thanks [15:27] thanks stgraber for improving the IPv6 story. :) [15:28] \o/ [15:28] stgraber: If you kill my home ipv6 network, i will punish you. kkthnx [15:28] Hi, I need somebody to consider this FFe please: https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/947976 [15:28] Launchpad bug 947976 in unity-2d "[unity-2d] FF exception to add PointerBarrier to Unity2d" [High,New] [15:29] Daviey: are you using dhcpv6? otherwise you should be fine (or I broke it already) ;) [15:30] stgraber: Would you hate me if i said i was still using radvd? [15:31] Daviey: no, that's what I'm using here ;) [15:32] Daviey: and you'll always need radvd, even with stateful dhcpv6 as dhcpv6 won't announce the default gateway (and you need to set the "other-config" flag in radvd for your clients to start doing dhcpv6) [15:37] greyback, need to understand the timing of when your Feature would end up landing. didrocks, any concerns about 947976? [15:40] stgraber: ah, cool [15:40] bug #947976 [15:40] Launchpad bug 947976 in unity-2d "[unity-2d] FF exception to add PointerBarrier to Unity2d" [High,New] https://launchpad.net/bugs/947976 [15:40] skaet: the metacity patch I saw is pretty straightforward [15:41] skaet: and unity-2d team is good at writing tests [15:41] so I guess that if this is tested as usual with the freeze process [15:41] that's fine (and before beta2) [15:42] didrocks, ok, its just a question then of when it might be landing and visible, and how close up to Beta 2 it becomes. Any insight there? [15:44] skaet: next unity/unity2d release (we are still trying to land unity 3d 5.6) will be the 22 march (after freezing our own code the Monday before) [15:44] so tests between monday and thursday [15:44] and release on time for beta2 freeze [15:45] didrocks, landing it right on the freeze is a bit risky - what will the fall back be? [15:46] skaet: well, we do that now that we have a freeze period [15:46] skaet: as before we land, we have 4 full days of testing and only fixing the unity release critical [15:47] and it worked well so far [15:47] so it's not "we are cutting a release on thursday" [15:47] it's "we are prepping the release starting the monday before" [15:47] just so I'm clear, when does 5.6 actually land? and what will the number be of the one on 3/22 [15:48] During that test period we work closely with distro to ensure all concerns are dealt with [15:49] skaet: for unity 2d 5.6 has already landed, 5.8 will be the next one [15:50] didrocks, my definition of landed for a component is that its in the archive ;) I'm still seeing 5.4 as the version there.... when will 5.6 be showing up. [15:51] https://launchpad.net/ubuntu/+source/unity [15:51] skaet: we are speaking about unity-2d here [15:51] not unity [15:51] this FFe is about unity-2d [15:52] https://launchpad.net/ubuntu/+source/unity-2d [15:52] didrocks, gotcha [15:54] didrocks, how can we have a unity 5.4 and unity-2d 5.6 in the archive? I'm afraid I need a bit of education, and I had assumed that both needed to be at the same release number? [15:55] skaet: not at all [15:55] skaet: we just try to have rougly the same release versionning at the same time [15:55] skaet: but even last cycle, the versionning was totally separated [15:55] you can think them as two different applicatoins [15:56] which, they really are [15:56] some parts are in common, like libunity-core [15:56] when they preserve API/ABI stability, they are not really linked [15:56] (as it's not because a new gtk is out that all GNOME apps are released) [15:56] and older GNOME apps still work [15:58] Thanks for the explanation didrocks. :) [15:58] skaet: you're welcome :) [16:02] didrocks, https://wiki.ubuntu.com/Unity/ReleaseSchedule has unity-2d 5.8 listed for 3/8 (which I have to admit, am much more comfortable with for the FFE;) ) is unity-2d 5.8 3/8 or 3/22? [16:03] skaet: 3/22, not sure who put the date here [16:03] certainly not someone making the release :) [16:04] didrocks, dbarth is page author... [16:04] https://wiki.ubuntu.com/Unity/ReleaseSchedule?action=diff&rev2=15&rev1=14 [16:04] not sure he has the insight of the release timing then [16:05] as well, the LIM is almost 100% sured to be canceled [16:05] (in both 3d and 2d) [16:09] didrocks, can you work with dbarth to get that page updated please? we need to know accurately what's landing and when so we can prevent a pileup/system level breakage on beta freeze date. [16:10] skaet: speaking with the unity-2d guys right now, we can try having a micro release starting next week, just containing the barrier work to make everyone life easier [16:10] then, regular 5.8 release (bug fix only) for 3d and 2d on the 22 [16:10] wdyt? [16:11] didrocks, that would be great if we can manage it. :) [16:11] Yes I think it's a good solution to the problem [16:11] skaet: it's more work, but overworked to be overworked already… let's try this [16:17] thanks didrocks [16:17] yw :) [16:17] skaet: thanking you [16:38] skaet: Many thanks, your reservations are understood [16:39] thanks greyback. :) [17:09] quick question: ubuntuone-control-panel-qt has a wrong --help. Is that covered by UI freeze? It's not translated. [17:13] I don't think there's any need to regard --help as covered by UI freeze [17:29] Maybe we should call it GUI freeze. [17:30] ok, thanks! [18:11] smoser: I think that adding the apt config of "Acquire::Retries=3" should fix some of our EC2-archive pain [18:13] smoser: per the docs, it sets the "Number of retries to perform. If this is non-zero APT will retry failed files the given number of times." [18:28] ProgramSurfacesIncludedDirectlyInOfficialDocuemtationFreeze [19:18] hrm, I just uploaded inkscape to add recommends: libgnomevfs2-extra without noticing that it's in universe [19:18] the source is in main though [19:19] do you want me to revert that upload? [19:22] I don't think the desktop team wants to support gnomevfs anymore [19:22] indeed, don't think we should be supporting that [19:22] the feature that requires it should use gio now ideally [19:25] upstream says the next release will use gio but that won't happen in time for precise [19:26] might have to take that hit then [19:26] perhaps you could improve the error message to give users more of a clue [19:26] * Laney out [19:32] micahg: as I said gnome-vfs is in main anyway. it's just about the extra backends. [19:33] do we need inkscape in main? [19:35] isn't it on the DVD image? [19:35] yes [19:36] gnome-vfs still has a few build depends in main (firefox, thunderbird, shotwell) [19:41] chrisccoulson, ^ what are you doing! [19:41] micahg, shotwell seems a mistake, I though firefox,tb were using gio? [19:44] seb128: they should be using gio, it's only a build time depedency [19:46] seb128: all of those were build time only dependencies, here's the runtime dep list: http://paste.ubuntu.com/871965/ [20:30] micahg, seb128, the build-dependency is there as an artefact of the fact that we can't have per-release build-depends from the same branch [20:30] and older releases build with gnomevfs [20:30] although [20:31] i should change that. we're going to be purging all gnomevfs support from firefox anyway [20:32] chrisccoulson: you could do that with control.in, but as you said, it's a moot point now [20:34] micahg, that wouldn't work in any case. which is why i haven't done it ;) [20:36] chrisccoulson: well, if you regenerate control.in before uploading it would (the problem is changing control.in in the clean rule, nothing says you couldn't modify the bot to do it separately :)) [20:36] err..s/control.in/control/, but this is getting OT [21:05] Does "... but we will SRU key items ..." in http://www.markshuttleworth.com/archives/1027 imply that SRU policy is going to change for 12.04 to add new features post-release? [21:07] ScottK: I don't think it implies that, and that's certainly not something any of the release team is aware of being new policy (and we're the people who'd need to implement it, and the TB would need to approve it...) [21:08] ScottK: I'm choosing to read it as "Unity's not perfect, but we promise to keep fixing bugs, even post-release". [21:08] I'm good with that. [21:08] I hope you're right. [21:08] Meh, if it means something more, I'm happy to take it to the TB. [21:09] yeah, haven't heard of any change on the TB side either, so I assumed it was just usual SRUs (bugfixes only) [21:09] The same TB that Mark stepped down from, specifically to avoid these sort of conflicts of interest, I suspect. ;) [21:09] s/sort/sorts/ [21:10] hmm, that never prevented him sabdfl-ing changes though, just that now it can say that the TB was against it ;) [21:10] Policy changes are a bit different from sabdfling, say, new software during a development cycle, etc. [21:11] Not that I'm saying we won't consider sabdflication of SRU policies, but we (both -release and TB, I suspect) will stand up against it, I'm sure. [21:12] Anyhow, like I said, I'm choosing to read that blog post as "we'll fix bugs, honest". [21:12] Which is an important commitment to make when you're shipping something that you admit you know has bugs.