On Mon, 2012-01-02 at 11:28 +0100, A Mennucc wrote: > hi, related to the pygame problem [1] is another question: > > will kfreebsd-* be a release architecture in wheezy?
That's certainly the plan right now. > If yes -> > then portmidi has a release critical bug in it, it should > be removed from testing [2], No, and no. portmidi has never successfully built on kfreebsd-*. Its failure to do so now is therefore not a regression, and not release-critical. > and at the same time pygame should be built w/o it ; That's up to the maintainers. If it makes sense for pygame to exist without portmidi support, it may be worth considering doing that on kfreebsd-*. > if no-> > then pygame may transition to testing right now. Which it clearly can't. > The current situation is a mess, since 'portmidi' is in testing, but > there is no kfreebsd-* binary for it (as if "no") - whereas > python-pygame is not allowed in (as if "yes"). No, you've simply misunderstood. There's no requirement for every package to build on every architecture. Packages shouldn't fail for no good reason, and mustn't fail on architectures on which they previously built. If we required all packages to build on all release architectures from the beginning, many quite important packages would never get released. For instance, the "acpi" package only exists on amd64, i386 and ia64. That doesn't make the lack of s390 or armel binaries an RC bug, it just means the package doesn't build on those architectures. > [2] I posted bug 654187 against portmidi, level important, feel free to > severitize it to grave if kfreebsd-* is eligible for wheezy) Those two things are orthogonal. FTFBS which isn't a regression is "important" regardless of the status of the affected architecture. Regards, Adam -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
