[09:09] <knome> is the release time set, or do we again have to wait until a randomly timed announcement? :)
[09:09] <cjwatson> knome: we don't set release times
[09:10] <knome> ok
[09:10] <knome> :)
[09:10] <cjwatson> there are too many variables late in the process to make it sensible to commit to a time at higher granularity than a day
[09:10] <knome> mm-hmm
[09:11] <cjwatson> and we're not going to foster nonsense journalist-has-nothing-better-to-write-about stories like "Ubuntu 12.04 LTS is one and a half hours late" either
[09:11] <knome> yeah
[09:11] <cjwatson> pitti: should we announce -proposed being open all the time now, do you think?
[09:12] <pitti> cjwatson: it certainly sounds like a good time for it
[09:12] <pitti> while we don't have an ideal workflow yet, we at least have enough tools to not cause too much pain
[09:12] <seb128> cjwatson, pitti: is it open as a staging or for stacking SRUs?
[09:12] <pitti> staging for now, I'd say
[09:13] <pitti> well, we can decide to leave any of the upload as an actual SRU, of course
[09:13] <pitti> uploads
[09:13] <pitti> but still a bit early for that IMHO
[09:13] <seb128> right
[09:13] <pitti> cjwatson: do you want to send the announcement, or want me to?
[09:14] <cjwatson> mm, my main concern is that if everyone starts using it for everything than our lack of tools for analysing whether a single source can be promoted will screw us horribly
[09:14] <cjwatson> pitti: I'd like to, since I wrote the LP patch :)
[09:14] <pitti> I wouldn't encourage using it for all uploads, at least not at this point
[09:15] <pitti> at this point, stuff like eglibc, the unity stack, LibO, and glib
[09:15] <pitti> qt 4.8.1 is a good candidate, too
[09:15] <cjwatson> At least two of those are also great examples of why it's problematic.
[09:16] <pitti> in a perfect setup, we'd have an arbitrary number of -proposed like pockets, each one for stacking one atomic set of updates
[09:16] <pitti> we could call them "bubbles"
[09:16] <cjwatson> FSVO perfect ... ;-)
[09:16] <pitti> i. e. one bubble for unity, one bubble for a new qt, etc.
[09:17] <pitti> they'd automatically migrate once everything is built and installable, and would avoid that problem with unintended building against newer libraries
[09:17] <pitti> but that's very far off still
[09:17] <cjwatson> I also think that's overengineering TBH
[09:17] <cjwatson> and would be impractically confusing to actually use
[09:17] <seb128> pitti, well, you can call those ppas
[09:18] <seb128> just need to be non virtual ones
[09:18] <cjwatson> PPAs would be workable if it weren't for the rule about non-virtual PPAs being confined to Canonical employees only
[09:18] <pitti> seb128: whatever the implementation is, just concept-wise
[09:18] <cjwatson> so in practice, we can't use them
[09:18] <pitti> but they are quite clumsy to use, too
[09:18] <infinity> pitti: There's no valid reason to send eglibc to -proposed, unless you think people will test it.
[09:18] <cjwatson> or we at least can't recommend that the whole project uses them
[09:18] <infinity> pitti: Staging in proposed is great to make sure arch skew doesn't break the world, but eglibc has no such issues.
[09:19] <pitti> infinity: true that; scratch that one from the list then
[09:20] <infinity> And, to be fair, arch skew issues are probably just one apt patch and one sbuild patch away from being mostly a non-issue.
[09:20] <infinity> Given that we already have the archive holding onto old arch:all binaries.
[09:20] <infinity> They just need to actually sanely get used in all cases.
[09:20] <pitti> infinity: sbuild for proper depwaiting instead of failing, you mean?
[09:20] <infinity> pitti: Yeah.
[09:21] <infinity> pitti: I have the code for sbuild lying around, just needs cleanup after 5 years of dust.
[09:21] <pitti> but an apt patch isn't sufficient there
[09:21] <pitti> it needs to be in Launchpad
[09:21] <infinity> pitti: And the apt patch is for end users actually having installable systems during a skew.
[09:21] <pitti> apt will just help upgrades
[09:21] <pitti> but not installs / ISO builds
[09:21] <cjwatson> I'd argue those are less of an issue anyway.
[09:21] <infinity> pitti: apt would fix ISO builds too.  Well, not alternates.
[09:21] <pitti> i. e. if glib FTBFS on i386 and succeeds on amd64, or vice versa, you immediately render thousands of packages uninstallable
[09:22] <pitti> actually, glib is fine
[09:22] <pitti> say, gtk
[09:22] <infinity> pitti: Yeah, apt dealing properly with that is fixable.
[09:22] <cjwatson> ISO build breakages don't cause hundreds of users to get confused and accidentally remove unity or something.
[09:22] <pitti> yes, but they are still annoying
[09:22] <pitti> same for LibO
[09:22] <cjwatson> Sure; but they can also often be dealt with by timing.
[09:22] <pitti> as the arm vs. x86 build times are so different
[09:23] <cjwatson> It's perfectly OK for us to fix a small number of things at a time. :-)
[09:23] <infinity> Anyhow.  It's all fixable, now that LP published arch:all packages that are still referenced.  (It's not perfect, in that it doesn't take the "i386 is the only thing that failed" case into account, but that's thankfully rare)
[09:24] <infinity> Maybe I'll spend some +1 cycles on at least fixing the sbuild dep-wait code.
[09:24] <infinity> But looking into apt doing some semblance of "the right thing" for the above would be nice too.
[09:24] <cjwatson> Right, as opposed to "I WANT THE NEWEST DAMNIT"
[09:24] <infinity> Perhaps as a switch that we can intentionally turn off on buildds, if we prefer skew causing dep-waits instead of installing old packages.
[09:24] <mvo> what would apt have to do? if there is a new :all with a strict arch spefific dependency that can not be satisfied, just ignore that package for now - would that be good enough?
[09:25]  * mvo hasn't really thought much about the problem yet
[09:25] <infinity> mvo: Basically, yeah.
[09:26] <infinity> mvo: Or, in the more general sense, if you have more than one version of an arch:all package, try to satisfy upgrades with the highest, and if that causes removals/failures, try downgrading and resolving again.
[09:26] <infinity> mvo: Your path might be shorter, though.
[09:27] <mvo> thanks
[09:27] <infinity> mvo: Oh and yeah, your path implies just ignoring entirely, when what we really need is "pick the right version".
[09:28] <infinity> mvo: So, if your "ignore" was changed instead to "try the next one down", etc.
[09:28] <infinity> (Think when someone uploads the same all/any split source package 5 times over 3 days, and it's always in skew for a week, we still want people to get the "latest", whatever that is on their arch)
[09:31] <cjwatson> pitti: http://paste.ubuntu.com/911251/ ?
[09:31] <cjwatson> (and others)
[09:31] <mvo> infinity: right
[09:31] <cjwatson> oh, I'm missing footnotes, those are to be pending-sru and precise-proposed_probs
[09:32] <infinity> I was just about to ask.
[09:33] <pitti> cjwatson: I suggest giving some example packages where this is encouraged, like the unity stack or LibO
[09:33] <infinity> I'm wary of declating the any/all thing as The Use Case for Proposed, cause if I fix dep-waits in sbuild, it could take years to untrain that behaviour. :P
[09:33] <cjwatson> http://paste.ubuntu.com/911253/
[09:34] <infinity> declaring, too.
[09:34] <cjwatson> I could trim that back to just "if bad things will happen if your builds are out of sync"
[09:34] <cjwatson> or something
[09:34] <infinity> Maybe if you mention that this is working around implementation shortcomings in lp-buildd and apt, and won't always be required.  I dunno.
[09:35] <infinity> I kinda liked the desktop team's "stage GNOME 3.4 in proposed" use case.
[09:35] <Laney> Probably mention how to get stuff migrated
[09:35] <infinity> Though that could have gotten painful in a hurry with other people also uploading.
[09:35] <cjwatson> That was specifically a freeze thing
[09:35] <infinity> With no britney to save us.
[09:35] <cjwatson> Laney: if developers have to ask we're doing it wrong
[09:36] <infinity> Laney: Migration will Just Happen when AAs scan pending.
[09:36] <Laney> Well, mention that.
[09:36] <infinity> Though, I'm still scared of this whole thing without a britney-alike to save us.
[09:36] <Laney> I don't think that's obvious
[09:36] <cjwatson> I will do
[09:36] <cjwatson> infinity: Ye
[09:36] <cjwatson> s
[09:37] <infinity> Of course, if there are never build failures in proposed, and we migrate 100% of the packages, we're fine. :P
[09:37] <cjwatson> I'm hoping to have a look at that over the next few weeks, but I have some other things to fix first
[09:37] <infinity> Maybe the general announcement is premature, then?
[09:37] <cjwatson> I think we can probably cope with the volume from here to release
[09:37] <infinity> Let people "in the know" test the waters, wait for general announcement until we're sure we can sanely migrate massive messes?
[09:37] <cjwatson> GNOME 3.4 - that was a freeze special case though
[09:38] <infinity> Sure, GNOME was freeze special, my concern is people starting to do large dep chains like that, though.
[09:38] <infinity> And all it takes is one 3rd-party dep in proposed to make that a nightmare.
[09:38] <cjwatson> infinity: we could, but I'm a bit worried that not saying anything will result in people making things up
[09:38] <pitti> infinity: it worked quite well for unity, too
[09:38] <pitti> especially during the freeze
[09:39] <cjwatson> which is worse than "this is an experimental process, please come and talk to us if you want to do anything weird"
[09:39] <pitti> uploading a new unity stack during the freeze directly to precise would have been a big No-go
[09:39] <infinity> cjwatson: True.  Okay, maybe it just needs more blink tags. :)
[09:45]  * cjwatson rearranges, and rewords to avoid mention of "pocket" jargon as well
[09:46] <cjwatson> How about http://paste.ubuntu.com/911266/ ?
[09:49] <infinity> cjwatson: +1
[09:49] <infinity> A++, would read again.
[09:51] <infinity> Now, I should get some sleep so I don't miss my flight.
[09:51] <infinity> pitti: If I don't manage to find time in the morning, I'll catch up with you tonight (ie: your tomorrow morning) instead.
[10:01] <pitti> cjwatson: sounds great to me, thanks!
[10:01] <cjwatson> excellent, sent
[10:06] <Laney> nice
[10:06] <Laney> perhaps we should teach ben about this
[12:19] <scott-work> i just subscribed ubuntu-release for bug #971159
[12:19] <ubot2> Launchpad bug 971159 in ubiquity "[UIFe] new wallpaper for ubiquity on ubuntu studio" [Undecided,New] https://launchpad.net/bugs/971159
[12:19] <scott-work> would it be possible to get an exception on it, por favor?
[12:20] <scott-work> since this is the background image for the isntallation i do not think translations or documentation needs to be addressed
[12:36] <didrocks> cjwatson: thanks for the email. FYI. I had commitment from the compiz guys to not have any more ABI break on compiz (so a huge part of the dep chain list off). However, Nux still have an ABI break, so I'll probably want to use -proposed for 5.10 (next week) for nux/unity/unity-2d
[12:36] <cjwatson> right, just an example :)
[12:38] <didrocks> cjwatson: well, I guess it's the one making most of the pain, especially when compiz is involved as well (last time, the time that everything build in time took 7 hours of instability, so clearly worth -proposed ;))
[12:38] <didrocks> even if I always pushed when having everything ready to not block on me
[13:26] <doko> cjwatson, currently writing an email to u-d-a, but maybe you want to point it out to the +1 team: http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120328-precise.html
[13:33] <cjwatson> doko: you can point it out directly, don't need to go through me :)
[13:33] <cjwatson> shudder, that's a lot of failures in main
[13:33] <doko> right ...
[13:42] <cjwatson> I wonder how much of this is http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659482
[13:42] <ubot2> Debian bug 659482 in automake "aclocal fails if /usr/share/aclocal does not exist" [Serious,Open]
[13:44] <cjwatson> possibly I was just unlucky that that was the first one I hit, but I'll go and fix that anyway
[13:46] <doko> cjwatson, let me know, then I'll give back the builds to clear the list
[13:50]  * cjwatson does a quick screenscrape to find out
[13:54] <cjwatson> PASS: aclocal9.test
[13:54] <cjwatson> PASS: acloca10.test
[13:54]  * cjwatson spots an alignment obsessive
[14:18] <cjwatson> doko: ok, the only victim of that automake change I could find was make-dfsg
[14:18] <cjwatson> I'll upload automake1.11 once the local test-build has finished
[14:22] <seb128> cjwatson, doko: the gnome-keyring build failure might go away on a retry, there is an issue with the testsuite, it does hang every n builds, the test rebuild seems to have ran into that bug, it did timeout on a test
[14:45] <skaet> scott-work,  UIFe is approved, but please send note to the docs & translators to let the know its coming down.   They shouldn't be affected, but letting them know is appropriate.
[14:49] <skaet> http://people.ubuntuwire.org/~wgrant/rebuild-ftbfs-test/test-rebuild-20120328-precise.html
[14:55] <stgraber> skaet, scott-work: I just pushed that change in ubiquity (revision 5349) so it'll be there in the next release.
[14:55] <skaet> thanks stgraber
[14:58] <scott-work> thank you both skaet and stgraber  :)
[15:03] <tsdgeos> hi, i have just created a UIFe for Unity-2d at https://bugs.launchpad.net/ubuntu/+source/unity-2d/+bug/971603
[15:03] <ubot2> Launchpad bug 971603 in unity-2d "[unity-2d] UI Freeze exception for HUD redesign to Unity2d" [Undecided,New]
[15:03] <tsdgeos> hope did it right, it's my very first time :-)
[15:04] <doko> seb128, given back
[15:10] <seb128> doko, thanks
[15:20] <jbicha> looks like we'll get a "new" 12.04 default wallpaper after all :) bug 968399
[15:20] <ubot2> Launchpad bug 968399 in ubuntu-wallpapers "Incremental tweaks to default wallpaper for Ubuntu 12.04 LTS" [Undecided,Confirmed] https://launchpad.net/bugs/968399
[15:32] <skaet> tsdgeos, can this land by April 5th?
[15:33] <skaet> (in Ubuntu archive as part of next drop)
[15:33] <tsdgeos> skaet: this can land now if you want
[15:33] <tsdgeos> ok
[15:33] <tsdgeos> let me rephrase
[15:33] <tsdgeos> the code is ready, design approves, and there is a new release plannned for friday i think, so yes it'll be there on the 5th
[15:34] <tsdgeos> just need to change the settings in the MR and it'll be all done
[15:34] <skaet> tsdgeos,  friday is the 6th.... hmm...
[15:35] <tsdgeos> maybe i'm wrong about the friday thing
[15:35] <skaet> didrocks,  when is the next version of unity-2d planned to be included?
[15:36] <tsdgeos> skaet: he's not here, is he?
[15:36] <skaet> tsdgeos,  you're right,  hadn't noticed that quit.  :/
[15:37] <skaet> tsdgeos,  anyhow,  its approved as long as we can get it with next drop.  which sounds likely.
[15:37] <tsdgeos> skaet: so what's the procedure, i confirm with didrocks, come back and you comment in the bug?
[15:37] <skaet> tsdgeos, I'll work the timings, etc. with didrocks.
[15:38] <tsdgeos> skaet: great :-)
[15:38] <skaet> just get it uploaded now.
[15:38] <skaet> :)
[16:24] <micahg> pitti: could you please copy 18.0.1025.142~r129054 from ubuntu-security-proposed to lucid and maverick proposed?
[18:46] <phillw> skaet: ping
[18:46] <skaet> hiya phillw,  ?
[18:47] <phillw> hi skaet, kanilot from lubuntu will eb covering for me at the QA meetings for lubuntu, is it in order for him to join this channel?
[18:47] <phillw> s/eb/be
[18:48] <skaet> phillw,  definitely,  he's most welcome.
[18:48] <skaet> he should also joing the #ubuntu-testing too.  :)
[18:49] <phillw> thanks, it's always more polite. Getting him on there is easy. But I'm still a n00b on this channel, so prefer to check :)
[18:49] <skaet> thanks for letting me know.   I'll look for kamilot now too, if I can't spot you and have a question.
[18:49] <skaet> :)
[18:57] <phillw> hi kanliot, welcome to -release. Do not worry if you do not understand some of the things they chat about - I don't :) They are a nice collection of people who push all the Daily and milestone releases out, including that mammoth session on Ubiquity bug solving prior to beta 2
[18:59] <kanliot> hi!
[19:19] <skaet> hi kanliot and welcome.  :)
[19:20] <kanliot> ty skaet
[19:26]  * skaet goes to finish off the moving of the beta2 milestoned bugs and finds them dealt with. 
[19:29] <stgraber> skaet: yeah pitti ran a script :)
[19:29] <skaet> thanks stgraber, pitti. :)
[19:29] <stgraber> skaet: move-milestoned-bugs.py in ~ubuntu-archive/ubuntu-archive-tools/trunk/
[21:15] <phillw> hi, is their a brain box around who could clear up a bit of confusion? Lubuntu and xubuntu have gone back to non-pae kernels, does this mean 12.04 will run on the likes of Pentium 3's or are they still only able to use 10.04 kernel release? Thanks
[21:16] <cjwatson> 12.04 will run on older CPUs provided that it's installed with Lubuntu or Xubuntu, or that the -generic kernel is otherwise installed / kept installed by hand somehow (e.g. on upgrades)
[21:16] <cjwatson> I don't happen to remember the full CPU list off the top of my head, but Pentium 3 sounds comfortably within range for -generic
[22:18] <ScottK> (that was me - it's not April 1 anymore)