[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: m68k not a release arch for etch; status in testing, future plans?



> > Well, we have offers for ftp-master roles out of Debian. Still, I think it
> > is better for everyone to have a (maybe) reduced set of packages being
> > released with etch.
>
> It's not the ftpmaster stuff that needs to be done, it's the RM and
> security stuff. Security stuff for *sarge* is already a problem, with
> the xfree86 update currently blocking the release of r4, due to lack of
> an m68k build, eg.

Well, xfree has been built some days ago but no attempt has been made to
get it uploaded yet.

This has been complicated by the fact that I've asked for access to
the security archive for hobbes but no response of any kind has been
forthcoming.

If you seriously think m68k is the main problem for the etch release
quality, I wish you all the luck you need indeed.

Regarding a solution for m68k beyond etch - I'd prefer to keep m68k
snapshots on a basis like you mentioned:

        * have m68k be in unstable, and have it have its own "testing-like"
          suite of some description
            + keeps the arch alive
            - some work to keep m68k-testing in sync with real testing needed
            - doesn't have real releases
            - may not have security support

Snapshots off that testing-like thing should then be kept somewhere off
.debian.org machines to avoid confusion with a real release, I guess.

Since I don't have a clue how the release management and archive scripts
work, I'd need to get help from those in the know to set it up. At the
current stage, with toolchain issues largely sorted, I'd expect the
backlog to clear up as soon as a few buildds have been restarted or DNS
problems fixed (cts going on vacation usually means his buildds crash the
next few days, no idea why that is).

The main reason not to shoot for the larger goal is security support. I
positively hate it to spend days on a security build (manually queued
because someone cannot be bothered to add yet another m68k security
account) and then see it headed for the drain. I'd rather cut that right
out.

So, if someone could give me a brief intro as to how testing migration of
packages works, and what would be needed to modify britney, I'd welcome
it.

	Michael



Reply to: