On Sun, Dec 31, 2000 at 12:14:01PM +0100, Raphael Hertzog wrote:
> 1. What arches are required (supposing the package is arch: any) so that
> the package can go in testing ? Is arm required ?
It's a little more dynamic than that, actually. Basically, all you need
to do is make sure that the package is in sync on all architecture's it's
built for. So if you have binaries from a package foo with versions like:
arm: -
alpha: 1.0-8
i386: 1.1-2
m68k: 1.1-2
powerpc: -
sparc: 1.1-1
then you need to either update sparc and alpha, or you need to bug the
ftpadmins to remove the binaries from those architectures if the package
no longer builds on them. Once you've done that, and ended up with something
like:
arm: -
alpha: -
i386: 1.1-2
m68k: 1.1-2
powerpc: -
sparc: 1.1-2
it'll go into testing as long as there aren't any, say, alpha packages
currently in testing that Depend: on foo. If you do, you either need to
rethink your support of alpha, or get those binaries removed too (since
they're no longer usable).
> 2. I've got a package libdbd-mysql-perl which has been uploaded a month
> ago and it is still not recompiled for sparc and m68k... could we get
> something like an automated system so that developers can tell to our
> autobuilder which package they should try to build ? Could we have the
> same online report for all arches as we have for arm
> (http://buildd.armlinux.org), I find it very useful to try to look why
> the package didn't build ... (and what about the build farm, we're
> talking about it for so long ...)
> 3. How does testing behave with package released every 3 days with low
> priority ? Suppose that the package is bug free, and that it could
> directly go to testing ... will there also be a new package in testing
> every 3 days ? Or will it never be included in testing since the
> latest package never get 14 days of testing ?
Well, even Joey Hess has slipped up in his religious debconf
uploads and had four or five delays longer than a fortnight between
updates. Basically, though, at some point the maintainer has to decide
"I'm happy with this" and leave well enough alone for a little while. At
worst, this could be done just before the freeze, although that seems like
it'd be a bit risky. Alternatively, the maintainer can just upload it with
a faked medium or high priority so that it'll go in earlier.
Note that packages tend not to be built for all architectures in less
than around seven days at the best of times.
> 4. How can I know precisely why my package has not been included in
> testing. I know update_excuse.html on ajt website ... but that's not
> enough. I want to know for example that my libdbd-pg-perl package is
> waiting on perl-5.6 (or on postgresql) to be integrated ...
You have to look at your dependency list, and investigate it yourself. :(
> 5. Is there a plan to use the testing dist to "force" release goals. eg
> consider the switch to perl-5.6. We make an official announce
> « perl-5.6 is the official perl for woody, developers you have 15 days to
> recompile everything with perl-5.6 ». After 15 days, we force the
> inclusion of perl-5.6 in testing (and the removal of perl-5.004 and
> perl-5.005) and let it remove packages that have not been updated.
> [ the same is possible for debian policy, remove all packages with old
> standard version, I know this has been discussed on another list, can
> someone give a short result of the discussion ? ]
"testing" doesn't try to take any action on its own: it'll only remove
packages if they've been removed from unstable first, and even then only
if nothing else depends on them.
With manual intervention though, the above is completely possible. I
plan on doing some manual intervention to remove packages with RC bugs
from testing (but not from unstable) once or twice before the freeze, just
to see what happens.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``Thanks to all avid pokers out there''
-- linux.conf.au, 17-20 January 2001
Attachment:
pgpmd9dxLFI58.pgp
Description: PGP signature