Thanks, this is a problem indeed. Here are the steps in order to solve this problem once and for all:
* the release upgrader magic tarball moves from releases.u.c to
old-releases.u.c - we can deal with that easily via the
meta-release file on changelogs.ubuntu.com that we can
control/update anytime
* the upgrader does not know that old-releases.u.c is a
valid mirrors - fixed in bzr
* the upgrader must deal with the situation that a EOL release may
still point to archive.u.c but just gets 404 from it
* if the EOL release got pointed to old-releases.u.c it must rewrite
the sources.list to:
* archive.u.c if the upgrade goes to a supported release
* old-releases.u.c if the upgrades goes to a EOL release
(think edyy->feisty->gutsy where e->f will need this magic)
This means we need to sync the EOL process with copying the data to
old-releases.u.c - I will write a mail to the sysadmin team about it.
Thanks, this is a problem indeed. Here are the steps in order to solve this problem once and for all:
* the release upgrader magic tarball moves from releases.u.c to ubuntu. com that we can
old-releases.u.c - we can deal with that easily via the
meta-release file on changelogs.
control/update anytime
* the upgrader does not know that old-releases.u.c is a
valid mirrors - fixed in bzr
* the upgrader must deal with the situation that a EOL release may
still point to archive.u.c but just gets 404 from it
* if the EOL release got pointed to old-releases.u.c it must rewrite
the sources.list to:
* archive.u.c if the upgrade goes to a supported release
* old-releases.u.c if the upgrades goes to a EOL release
(think edyy->feisty->gutsy where e->f will need this magic)
This means we need to sync the EOL process with copying the data to
old-releases.u.c - I will write a mail to the sysadmin team about it.