bdmurray | if somebody could review ubuntu-release-upgrader in saucy-proposed that would be great | 00:15 |
---|---|---|
RAOF | bdmurray: Sure. | 00:21 |
bluesabre | welcome Logan_ :) | 00:58 |
=== Ursinha is now known as Ursinha-afk | ||
=== Ursinha-afk is now known as Ursinha | ||
bdmurray | RAOF: thanks | 01:17 |
med_ | gaughen, are cloud-images painfully slow to load for everyone tonight? | 03:02 |
med_ | kirkland, ^ | 03:02 |
ScottK | Who knows phased updates well enough to know how it deals with a large set of packages released together? | 03:29 |
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:30 |
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:31 |
infinity | Oh, though, it might be more clever than that, come to think of it. | 03:32 |
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:33 |
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:38 |
* ScottK is imagining the KDE point releases being unpleasant. | 03:39 | |
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:40 |
infinity | Probably worth adding a --no-phase switch to sru-release. | 03:41 |
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:42 |
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:43 |
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:44 |
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:45 |
infinity | Well, yes, that too. | 03:46 |
ScottK | xnox: I meant installing it, not installing using it. | 03:46 |
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:47 |
ScottK | OK. | 03:48 |
ScottK | My recent server install was on Hardy. | 03:48 |
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:49 |
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:50 | |
infinity | Oh, *sigh*. | 03:52 |
infinity | It's outsmarting itself. | 03:52 |
infinity | Internal bridge comes up, ntpdate runs, lockfiles, external if comes up via DHCP, ntpdate exits on the lockfile. | 03:53 |
infinity | Derp. | 03:53 |
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:01 |
* xnox ponders if we need a new command for "is next release named yet" | 05:02 | |
arrith | yes | 05:17 |
ScottK | Not on IRC please. | 05:27 |
=== 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 | ||
saiarcot895 | Hi all. Can someone nominate for #1308794 for Trusty? I have a fix ready for SRU. | 11:55 |
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 | 11:59 |
saiarcot895 | Thank you, NoNameYet_xnox | 12:04 |
=== 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 | ||
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 | 16:31 |
=== jamespag` is now known as jamespage | ||
infinity | bdmurray: Yeah, that looks reasonable. | 16:38 |
infinity | bdmurray: Done. | 16:39 |
bdmurray | infinity: thanks | 16:47 |
=== 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 | ||
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:19 |
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:20 |
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:21 |
ScottK | infinity: So what's the 12.10 upgrade path? | 21:38 |
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:41 |
ScottK | OK. | 21:43 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!