Re: HAMM FREEZE IS ONE WEEK AWAY
Roman Hodek <Roman.Hodek@informatik.uni-erlangen.de> writes:
> But this reminds me of another problem with the freeze: Let's say,
> some maintainer uploads a new source version (plus i386 binary
> package(s)) quickly one day before the release. The distribution in
> the changelog will be "unstable". But this package has still to be
> recompiled for other architectures (I'll use m68k as an example),
> but this obviously isn't done in zero time... Assume that the
> package is recompiled for m68k some days later, when the freeze
> already has happened. Since a recompile never shall touch the
> changelog file, the distribution is still unstable, but this is
> wrong. The package should go to frozen, since it's the same version
> of a source already in frozen. How can we solve this?
By editing the .changes files before upload; basically I'm going to
point quinn diff at the frozen distribution, when it exists, and
Christian and I (and hopefully anyone else compiling for m68k) will
compile only packages which are out of date on m68k relative to that.
debbuild or some other wrapper will then edit the .changes file as
produced to by dpkg-buildpackage to ensure uploads go to frozen as
well as unstable.
If m68k is going to be released with hamm, we're going to need to be
able to do this. Even with true auto-compilation it would be nigh on
impossible to keep up with the flood of uploads at the moment as
everyone rushes to get packages into hamm before the freeze.
For the record, m68k's state of play as of this morning is:
87.08% (1354) of Debian packages are ported, and of those 1354, 85.82%
(1162) are up-to-date.
--
James
--
E-mail the word "unsubscribe" to debian-devel-request@lists.debian.org
TO UNSUBSCRIBE FROM THIS MAILING LIST. Trouble? E-mail to listmaster@debian.org .
Reply to: