Ticket #940 (closed enhancement: fixed)

Opened 13 years ago

Last modified 11 years ago

Migrate zulu to not-Debian

Reported by: jdreed Owned by: jdreed
Priority: high Milestone: The Distant Future
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:

Description

Ops would very much prefer it if zulu were not-Debian. Since we can't make it RHEL unless we want to port all of Debian (what could possibly go wrong?), an Ubuntu LTS is the next best choice, in this case, Lucid.
Ops will give us a Lucid VM, but we'll need to move our build infrastructure over. We should take this opportunity to fix things and also ensure that the NOTES file is sufficient.

Change History

comment:1 Changed 12 years ago by jdreed

  • Milestone changed from Precise Alpha to The Distant Future

I think at this point we mean "Precise", not Lucid, but anyway, let's put this on hold pending the outcome of #1135.

comment:2 Changed 12 years ago by jdreed

  • Owner set to jdreed
  • Status changed from new to accepted

I think I'm going to get started on this (going to Precise), because of the schroot support for overlayfs. Quantal will get us a new-enough sbuild for #1135, but we can probably always backport something into precise, right? Or simply build our own sbuild? Or does sbuild upgrade frequently enough that building our own would be a bad idea? (Maybe Debathena should get a Launchpad PPA for this, just so everything's in the same place?)

I'm willing to entertain waiting another month for Quantal, but that will force us to do another build-server upgrade in early 2014, when the next LTS comes out, and that's smack in the middle of our release cycle.

comment:3 Changed 11 years ago by jdreed

Catching up on this, our new build server (magrathea) is now up. I'm in the process of stress-testing it with a quantal rebuild, although that's currently blocking on some changes to sbuild. I have a workaround, but am waiting for upstream to respond to a mail I sent confirming that there's no better way to re-enable old behavior. However, setting up overlayfs chroots worked, and I have tested a single build in the chroot, which works, so I'm optimistic we'll be able to fully transition before the end of the calendar year.

linerva's account on the build server still needs to be migrated. Part of the goal of this was also to sanity-check our instructions for staging a new build server, which I'm in the process of editing. I'd prefer, therefore, that nobody poke at magrathea just yet. Or, to put it another way, "The commercial council of Magrathea thanks you for your esteemed visit, but regrets that the entire planet is temporarily closed for business."

comment:4 Changed 11 years ago by jdreed

OK, I think we're mostly done with this. The autodebathenify failures appear to be non-deterministic, unreplicatable on manual builds, and only involve the debian-security repo, so I'm going to blame approx or something here. I still want to fix it, but I'm not convinced it's a blocker. I'll do one final pass over zulu and make sure we didn't miss anything, but I think we're mostly done with it. Anyone who believes otherwise should speak up soon -- I plan on asking Ops to power it off in early IAP.

comment:5 Changed 11 years ago by jdreed

  • Status changed from accepted to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.