severity 448843 minor thanks Luk Claes <[EMAIL PROTECTED]> writes:
> severity 448843 grave > thanks > > Camm Maguire wrote: > > severity 448843 minor > > thanks > > > > Greetings, and thanks for your report! There has been no accessible > > arm debugging environment in Debian for many many months. I can't > > justify an RC status for an unfixable bug. If you can provide me with > > an environment in which to fix this, I would be happy to do so. > > You mean that there is no official porter machine, which is a different > thing. Asking on debian-arm should give you either people willing to > test or people willing to give you an account to test yourself... Of Done that -- there simply are no resources at present. Accounts previously granted outside of Debian (smackdown for example) are no longer available and have not been for many many months. > course having a porter machine available should also be 'fixed'... It's Yep. > also not up to a maintainer to decide that an architecture should not be > supported release wise... and if it would be there is a procedure to Not doing that, just saying I'm not going to adjust my packages for an arch which cannot provide the basic facility to package maintainers to support it. Human time is much more valuable than machine time, and having to spend months of the former pursuing the latter is just wrong. In its current state, arm should mark difficult packages "not for us", like m68k does in some circumstances. None of my packages, if excluded from arm, would threaten its release candidacy. On the other hand, having my packages knocked out from Debian as a whole when any intermittent unaddressable arm-specific failure arises, without a constant toggling of ! [ arm] in the control followed by a forced rebuild on all the other platforms, just does not make sense human-time wise. Best for the port managers to trim the package list to work around toolchain instabilities if the build infrastructure is marginal. For example, atlas has never built on arm due to a weakness in its timer, but this does not affect its progress through testing, etc. There is a non-rc bug to this effect. One could counter that atlas has never built on arm, but if a marginal arch once manages to build a package, but then loses that ability, and provides no means to fix the situation, it is unjust for it to hold all other platforms hostage. One could make the case that it should be up to the port managers to supply arch specific patches/toolchain workarounds to the maintainer. I'm not even making that case -- but when there is not even a machine available, the whole project is threatened with terminal sclerosis to enforce such logjams. > follow which includes making sure the build fails on that architecture > (next to some other things)... which it does .... Please do not further adjust the severity of this bug without providing me a login or equivalent. Otherwise, I feel I will have to mark all of my packages to exclude problematic architectures to be able to adequately maintain them. This would likely be rather disruptive, as several are at the base of a rather long dependency chain. Take care, > > Cheers > > Luk > > > Niko Tyni <[EMAIL PROTECTED]> writes: > > > >> Package: hol88 > >> Version: 2.02.19940316-6 > >> Severity: grave > >> Justification: renders package unusable > >> > >> The package is missing the actual binaries under /usr/lib/ on arm. > >> Looking at the build log, loading compiled object files during the build > >> fails with 'Error: Unknown bfd format'. > >> > >> This is presumably a bug in the toolchain, but please make the build > >> fail on compiler errors so that this can be detected automatically. > >> > >> Cheers, > >> -- > >> Niko Tyni [EMAIL PROTECTED] > >> > >> > >> > >> > >> > > > > > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
