Ticket #673 (closed task: fixed)
Rebuild for Squeeze
| Reported by: | geofft | Owned by: | jdreed |
|---|---|---|---|
| Priority: | low | Milestone: | The Distant Future |
| Component: | -- | Keywords: | |
| Cc: | Fixed in version: | ||
| Upstream bug: |
Description (last modified by geofft) (diff)
Debian 6.0 "Squeeze" was released. We should bump ~debian6.0~0.2 to just ~debian6.0 and rebuild all packages and make sure they work.
Change History
comment:2 Changed 14 years ago by jdreed
- Priority changed from normal to low
- Milestone changed from IAP 2011 to The Distant Future
comment:3 Changed 12 years ago by jdreed
- Status changed from new to accepted
- Owner set to jdreed
I have kicked off a squeeze rebuild using the new do-build and gen-build-deps.
comment:4 follow-up: ↓ 6 Changed 12 years ago by jdreed
Done. The new do-build and gen-build-deps work fine.
Squeeze is currently in squeeze-staging. Someone who actually runs squeeze should test it, particularly the "upgrade" path, or I can probably do so in a VM at some point.
Now that we have -staging, we should think about a workflow? Should it just get moved to -development upon a successful build? Or should it require testing in -staging, then -dev, then -proposed. Or -staging to production?
comment:5 Changed 12 years ago by jdreed
- Status changed from accepted to development
OK, I tested an upgrade from Squeeze in production to the one in -staging for -login, it worked fine.
I've moved Squeeze to -development. Other people who actually normally run Squeeze should test it, and then we can push it to production.
comment:6 in reply to: ↑ 4 Changed 12 years ago by kaduk
Replying to jdreed:
Now that we have -staging, we should think about a workflow? Should it just get moved to -development upon a successful build? Or should it require testing in -staging, then -dev, then -proposed. Or -staging to production?
I think it should just get moved to -development upon successful build, "most of the time".
Reasons not to move include if there's other stuff in -development we don't want to squash, or un-ack'd code or something like that.
