On Wed, 24 Apr 2010 Bastian Blank wrote: > I just checked the change history, it looks random. How exactly do you > manage to build this on your own but make it fail on most other > machines?
This is a library that explains errors. The last few release have all been to fix false negatives in the test suite. Some errors move around depending on architecture (32-bit vs 64-bit, sparc vs x86 vs s390, etc) and test false negatives occur because of this. E.g. when testing EFAULT explanations. Some systems have different strerror implementations (the numbers vary, the texts vary, the existence varies, etc) although this doesn't happen on Linux too much... except when ABI compatibility was the goal, e.g. on sparc. This is a source of test false negatives. There are (at least) three inconsistent implementations of ioctl request macros, all incompatible, and all used on Linux for different architectures. This also appears to be for ABI compatibility reasons. This is also a source of test false negatives. Some tests are difficult because the testing environment can vary widely. Sometimes it's a chroot, sometimes it's a VM, sometimes it's fakeroot, sometimes it really is running as root. All these affect the ability of the library to probe the system looking for the proximal cause of the error, e.g. the error in question ENOSPC. This often results in 2 or 4 or 8 explanations of an error, depending on what the library finds, e.g. existence of useful information in the mount table, or not. > How exactly do you manage to build this on your own but make it fail > on most other machines? Because each Linux architecture, as seen from the perspective of this library, is actually different. I am not intentionally "making it fail". -- Peter Miller <pmil...@opensource.org.au> -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
