[01:31] <slangasek> I've updated checkrdepends to not spuriously report binary independencies when asked about a source package; hopefully this hasn't broken cron.NBS, but if it does you know where to look
[12:09] <cjwatson> pitti,SpamapS: so, there's a grub2 SRU currently in progress for lucid and maverick, which fixes multipath support.  Historically any grub2 upgrade has broken Wubi systems; I believe I've finally fixed that for good in natty now, and was planning to queue the relevant changes up for an SRU after the multipath one enters -updates - but that would mean that maverick Wubi users would have their systems broken in the meantime
[12:09] <cjwatson> pitti,SpamapS: I know we usually try to keep different bugs separate in the SRU queue, but in this case, do you think I'd be justified in attempting to SRU multipath support and Wubi fixes at the same time?
[12:10] <cjwatson> (the relevant Wubi bugs are bug 742967, bug 610898, and bug 695290; they require changes to grub2 and lupin)
[12:10] <ubot4`> Launchpad bug 742967 in grub2 (Ubuntu Natty) (and 4 other projects) "Wubi grub prompt on install (affects: 3) (dups: 1) (heat: 22)" [High,Fix released] https://launchpad.net/bugs/742967
[12:10] <ubot4`> Launchpad bug 610898 in lupin (Ubuntu Natty) (and 9 other projects) "grub-pc upgrade renders computer unbootable when Wubi is installed to partition other than Windows (affects: 15) (dups: 1) (heat: 126)" [High,Fix released] https://launchpad.net/bugs/610898
[12:10] <ubot4`> Launchpad bug 695290 in grub2 (Ubuntu Maverick) (and 2 other projects) "10_lupin case problem with ntfs UUIDs (affects: 1) (heat: 6)" [High,In progress] https://launchpad.net/bugs/695290
[12:22] <cjwatson> jibel: oh, which reminds me, if you want to run tests with Wubi installed to a different partition from Windows, the code is now ready for that as long as the upgrade target is natty
[14:39] <pitti> cjwatson: I think in this case it's actually preferable
[14:40] <pitti> as it'll also parallelize verification
[14:42] <seb128> hey guys
[14:42] <seb128> so I'm a bit unsure about timing for beta2 and hard freeze
[14:43] <seb128> when would be ok dates for a bug fix unity upload and until when can we cherry pick fixes for natty?
[14:44] <seb128> cjwatson, skaet_afk, pitti: ^
[14:46] <pitti> seb128: does it involve ABI breaks and several packages, etc.?
[14:46] <pitti> if it's just unity, I'd say we can cope with a Monday evening upload
[14:46] <pitti> but since this is "it" for beta2, it'll better be good :)
[14:47] <seb128> pitti, no abi break, just bug fixing
[14:47] <seb128> it could be compiz, nux, unity but they are not couplet
[14:47] <seb128> coupled
[14:47] <seb128> like it's just bug fixes
[14:48] <seb128> I can see compiz and nux landing early they will likely have less things
[14:48] <seb128> I was just talking to neil and didier to figure if we should doing cherry picking for every fix
[14:48] <seb128> or if they can roll a bug fix only tarball on monday
[14:49] <seb128> and also until when we will be able to get fixes in after that
[14:49] <seb128> like if there is an upload frame between freeze on monday and natty
[14:49] <seb128> or between beta2 and natty
[14:50] <pitti> seb128: I think Monday will be fine
[14:50] <seb128> ok great
[14:50] <pitti> we'll probably start announcing Tuesday's cron'ed builds for testing
[14:51] <pitti> beta-1 is just behind us, and since then we didn't have structural changes
[14:52] <seb128> well https://wiki.ubuntu.com/NattyReleaseSchedule is not really clear on the different between the beta freeze and the main freeze
[14:52] <seb128> nor on whether there is an upload target between beta2 and natty
[14:53] <seb128> since the release image builds are on the 21 but it's not clear if uploads will be accepted between the beta2 freeze and that
[14:53] <seb128> it's sort a tight run for unity
[14:54] <seb128> they got most of the issues fixes but they will keep fixing some
[16:31] <pitti> seb128: sorry, seems I missed that: beta-2 archive freeze is suposed to be 0900 UTC on Monday
[16:32] <seb128> pitti, which means no tarball possible on monday?
[16:33] <pitti> or very early :)
[16:33] <seb128> :-(
[16:33] <pitti> I'll ask in the release meeting when it's my turn
[16:33] <seb128> how likely unity would get an exception to get an update during the day?
[16:33] <seb128> ok
[16:33] <seb128> I was still waiting on a reply from skaet here
[16:33] <seb128> but not sure she read the scrollback or my question
[17:28] <skaet> seb128,  did read the backscroll prior to the meeting, but figured we'd get it sorted there.  :)
[17:29] <seb128> skaet, yes thanks ;-)
[17:56] <SpamapS> cjwatson: re your grub2/wubi/multipath .. it sounds to me like its worth holding the multipath fix back until we can do the update without breaking wubi systems, unless the multipath bug is eating peoples' data.
[18:00] <cjwatson> it's not, although it's already been partially validated.  ok, with your and pitti's comments, it sounds like we should do the two together.  I can't imagine how they could interact at all
[18:00] <cjwatson> (entirely different parts of the codebase)