[00:15] <bdmurray> if somebody could review ubuntu-release-upgrader in saucy-proposed that would be great
[00:21] <RAOF> bdmurray: Sure.
[00:58] <bluesabre> welcome Logan_ :)
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[01:17] <bdmurray> RAOF: thanks
[03:02] <med_> gaughen, are cloud-images painfully slow to load for everyone tonight?
[03:02] <med_> kirkland, ^
[03:29] <ScottK> Who knows phased updates well enough to know how it deals with a large set of packages released together?
[03:30] <infinity> ScottK: That's going to be mostly up to the package manager, but if they're all interdependent, the answer is probably "not very well".
[03:31] <infinity> ScottK: Since you might get half of them randomly wanting to upgrade, and half of them not, and then python-apt (or whatever backend your upgrader uses) will tell you where to go and how to get there, and you get no upgrades at all until they all phase in.
[03:31] <infinity> ScottK: Or, that's pretty much how I assume it would work out.
[03:31] <infinity> bdmurray: ^
[03:32] <infinity> Oh, though, it might be more clever than that, come to think of it.
[03:33] <infinity> Since apt (and python-apt) don't actually give a crap about phase, it's only the high-level manager that uses it to "show" the upgrades to you.
[03:33] <infinity> So, if you show half of them, then do dependency resolution, you'd get the other half...
[03:33] <infinity> So, maybe you'd just get everything phasing much more quickly than expected, rather than the inverse...
[03:33] <infinity> Definitely worth some closer investigation.
[03:38] <xnox> ScottK: the more packages depend on each other, the slower the phasing needs to be, since a phasing match on any higher level packages pulls in libcore, et.al. And i believe update-notifier / update-manager is the only one that looks at phasing.
[03:38] <xnox> apt-get dist-upgrade will just pull in everything.
[03:38] <xnox> ScottK: but bdmurray is the one you should probably talk to.
[03:39]  * ScottK is imagining the KDE point releases being unpleasant.
[03:40] <infinity> ScottK: It might be that the point release would be a special case where you'd just want to override the phasing to 100% for all of it, so it doesn't come in weird pieces.
[03:40] <infinity> Maybe.
[03:40] <ScottK> Since it's just bugfix stuff, it's mostly not driven by dependency and if you phase in a set of say 70 packages in over a few days, I think it'll be never ending updates for the lucky ones that draw the early update.
[03:40] <ScottK> Yeah.
[03:41] <infinity> Probably worth adding a --no-phase switch to sru-release.
[03:42] <infinity> Or --initial-phase, so it's more generically useful.
[03:42] <infinity> Just --phase, I guess.  We don't like typing.
[03:42] <ScottK> It doesn't affect Kubuntu now since muon-updater doesn't know about phasing, but I don't think that's the only place it's relevant.
[03:43] <infinity> So --phase=100 would just not set it at all (which is the same thing), no phase would default to 10, and you could alternately twiddle different initial options.
[03:43] <infinity> The other obvious interdependent mess is the kernel, but since I've never had a complaint, I assume xnox's analysis (and my second scenario) are correct.
[03:44] <infinity> So, once linux-meta phases in, you just get the whole mess at once.
[03:44] <infinity> And the phasing of the other packages would be meaningless.
[03:44] <ScottK> what about openstack point releases?
[03:45] <infinity> I really hope they version their depends correctly when they need to.
[03:45] <infinity> But they tend to do piecemeal updates of the components, not one massive dump.
[03:45] <ScottK> OK.
[03:45] <infinity> So, I'd assume deps are correct when they have to be, and otherwise things are backward compat.
[03:45] <xnox> ScottK: server has no support for installing phased updates, so also not quite so relevant.
[03:46] <infinity> Well, yes, that too.
[03:46] <ScottK> xnox: I meant installing it, not installing using it.
[03:47] <infinity> ScottK: Can't be too many people who run openstack on an Ubuntu desktop with update-manager.
[03:47] <infinity> (But yeah, it should probably be okay anyway)
[03:47] <ScottK> Does server still just use apt?
[03:47] <xnox> yes.
[03:47] <infinity> apt or unattended-upgrades, but nothing particularly more fancy.
[03:48] <ScottK> OK.
[03:48] <ScottK> My recent server install was on Hardy.
[03:49] <infinity> I suppose someone could try to jam phasing knowledge into landscape or some other mass admin thing, but I would pretty much consider it harmful at that point.
[03:49] <infinity> Or, at least, very confusing.
[03:49] <ScottK> Yeah.  I'm not proposing it.
[03:50] <ScottK> Just think it's worth considering that anything server/cloud 'ish won't do phase updates either.
[03:50]  * infinity scratches his head over one of his machines not running ntpdate on boot...
[03:52] <infinity> Oh, *sigh*.
[03:52] <infinity> It's outsmarting itself.
[03:53] <infinity> Internal bridge comes up, ntpdate runs, lockfiles, external if comes up via DHCP, ntpdate exits on the lockfile.
[03:53] <infinity> Derp.
[05:01] <xnox> !isitout
[05:01] <ubot2> Yes, it's out! Download at http://www.ubuntu.com/download | Release announcement at https://lists.ubuntu.com/archives/ubuntu-announce/2014-April/000182.html
[05:02]  * xnox ponders if we need a new command for "is next release named yet"
[05:17] <arrith> yes
[05:27] <ScottK> Not on IRC please.
=== xnox is now known as NoNameYet_xnox
=== Chipaca is now known as UtilitarianUvula
=== psivaa-afk is now known as psivaa
=== UtilitarianUvula is now known as Chipaca
[11:55] <saiarcot895> Hi all. Can someone nominate for #1308794 for Trusty? I have a fix ready for SRU.
[11:59] <NoNameYet_xnox> bug #1308794
[11:59] <ubot2> Launchpad bug 1308794 in checkstyle (Ubuntu) "Checkstyle unusable on Trusty" [Undecided,In progress] https://launchpad.net/bugs/1308794
[12:04] <saiarcot895> Thank you, NoNameYet_xnox
=== jhodapp|afk is now known as jhodapp
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
=== arges` is now known as arges
=== chorrell is now known as chorrell-away
[16:31] <bdmurray> Could I get a speedy release of the SRU for bug 1310851?
[16:31] <ubot2> Launchpad bug 1310851 in ubuntu-release-upgrader (Ubuntu Saucy) "Failed to fetch window does not appear" [High,Fix committed] https://launchpad.net/bugs/1310851
=== jamespag` is now known as jamespage
[16:38] <infinity> bdmurray: Yeah, that looks reasonable.
[16:39] <infinity> bdmurray: Done.
[16:47] <bdmurray> infinity: thanks
=== chorrell-away is now known as chorrell
=== ogasawara_ is now known as ogasawara
=== chorrell is now known as chorrell-away
=== chorrell-away is now known as chorrell
=== beidl_ is now known as beidl
=== jhodapp is now known as jhodapp|afk
[21:19] <bdmurray> infinity: when will Quantal be going EoL? I'm going on vacation later this week and was thinking about stopping the acceptance of crash reports for errors tomorrow.
[21:20] <infinity> bdmurray: I need to send out a warning announce, discussing with the security team has me sending out the warn nowish, and EOL would be in ~4w, then.
[21:21] <infinity> bdmurray: Though, given that we never switched the default upgrade path from 13.10 to 14.04, the arguments we originally had for the slight extention are gone.
[21:21] <bdmurray> infinity: ah, so not in april then
[21:21] <infinity> But no one told me that in enough time to warn for an earlier EOL. :P
[21:38] <ScottK> infinity: So what's the 12.10 upgrade path?
[21:41] <infinity> ScottK: 12.10->13.10->14.04
[21:41] <infinity> So, 12.10 needs to EOL before 13.10, but needed to EOL after 14.04 release.  Basically, anytime in the next month is fine for that.
[21:43] <ScottK> OK.