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

Re: kfree-* , portmidi, Re: pygame



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


Reply to: