Hi Phil, > At a first glance this looks more like a TLS emulation kind of problem > than an instruction set discrepancy. But it'd take a bit more detective > work to figure out what's really going wrong, and I guess there is no > guarantee that this is the same problem the netwinders are seeing in any > case.
So where does that leave us for etch? Does a mono that doesn't run on netwinders and apparently not on smackdown either, but does run on other cats systems, make the grade for release? If no one has time to investigate the problem on netwinder, that at least suggests to me that netwinder isn't that important a use case for the porters and probably not the users either. Does the "TLS emulation" diagnosis imply a bug elsewhere in the kernel or glibc rather than in mono? Anyway, our three real choices here are: - mono support on netwinder is not RC in the porters' estimation, so the bug can be downgraded or etch-ignored - mono support on netwinder is RC in the porters' estimation, but no one has time to work on this problem, so the arm binaries should be removed from the archive for the release - mono support on netwinder is RC in the porters' estimation, and there is a porter with the know-how and time to fix this bug who is volunteering to have me nag them once every other day until it's fixed ;) If we are still missing information for the porters to decide whether this should be RC, what can I do to help get that information? -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/
