On Tue, Mar 17, 2009 at 09:33:17AM +0100, Salvatore Bonaccorso wrote: > Hi > > On Sun, Mar 15, 2009 at 09:03:03PM +0000, Debian Bug Tracking System wrote: > > Processing commands for cont...@bugs.debian.org: > > > > > # It doesn't work. Binary for powerpc should probably get removed from > > > the archive. > > > severity 513891 serious > > Bug#513891: tuxcmd: Does not run at all > > Severity set to `serious' from `important' > > I agree with you that tuxcmd in it's current shape should not be > "released" for powerpc architecture (but works with i386 and amd64). So > serious bug will prevent whole tuxcmd to migrate to testing right > (future versions uploaded) What would be the best approach on your > point of view for that?
Since the same version is in testing, this bug will not prevent migration of new versions to testing. > My sponsor suggested to me, to not restrict Architecture in > debian/control, but at the moment there is no solution to have tuxcmd > also working on powerpc architecture. I'm currently not able to > solve this, and the Developer of tuxcmd sais that his effort to try > support also powerpc architecture failed in past [1]. The first step you should do is prevent the generation of binary packages on powerpc. There are a few ways to do that: - Restrict the arches list in the control file. This can make sense if upstream says it's not supported, and the source of the problem is this package. It does not make sense if this is a bug in fpc. - Run a test during the build process that tries to detect if it's working or not, and make it fail during the build process, if it doesn't work. - Have a list of arches that work in your rules file, and use that to decide if you continue buiding or not. You can close this bug in the package that prevents the generation of the binary package on powerpc. The next step is asking ftp-master to remove the binary package for powerpc from unstable. As long as the binary package stays it unstable, the scripts will assume something is wrong with the powerpc version and prevent migration to testing. When both those things have been done, the new version should migrate to testing. > Any hint, how I should procede? A new version of the fpc will be > released end of this week, and then tuxcmd should be retried to > build whit the new fpc, but then I need some people with powerpc > which could test that again [2]. You can either ask the buildd maintainers to schedule a binNMU to try with the new version of fpc, or upload a new version. Then you probably want to ask the submitter of this bug to try again. Kurt -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
