On Tue, 2006-01-03 at 11:58 -0500, Mike Furr wrote: > Julien Cristau wrote: > > %i1 contains 0xa3f74, which is indeed not double-word aligned. > > The ocaml float allocation function doesn't take care of alignment, so > > we've reported this problem upstream. > Hmm... The new version of omake which I just uploaded failed to build > for exactly the same reason it seems. I wonder how many packages this > has affected for sparc. It looks like it will only surface when the > resulting code is run and I know a lot of packages don't have test > suites. :-(
I am curious to know Debian policy on testing. Felix does include a test suite -- but it takes quite some time to run. This will get worse as number of tests goes up, and number of combinations of options to test goes up. Furthermore, some new features require testing that begins to look nasty -- for example testing sockets requires opening sockets (we're using localhost .. but it isn't clear if even that is really permitted), and creation of pthreads (which in event of a bug could run away on some platforms .. and there is no point in tests that will never catch bugs, so one has to assume all tests can and will fail). Worse may be coming, for example testing killing of an application may require launching another process with sufficient authority which sends it a kill signal (and could kill autobuilder by mistake .. :) Yet the build scripts themselves are fairly arbitrary so there is already a risk of this. One technique might be a separate test package which build-requires the binary package being tested. However if the suite fails, the binary -- not the test suite -- should be flagged as bugged: it isn't clear the Debian autobuilder etc would handle all that properly. [Perhaps some new coding, such as: OnError: Packname which says to bug out Packname if this package fails to build .. rather than this package] Even trickier .. bootstrapped systems, which build depend on themselves .. :) Any advice on how far to go in original package would be of interest, and how to cope with 'extra testing' since the need for that will certainly arise: there have to be *some* limits on testing in original package, but there should also be a way to automate testing and bugging out of packages. Yes I know there are ways to do this manually.. but I hate to burden DD with a complex set of test instructions that have to be followed manually -- rather burden him with verifying scripts that automate this process are doing the right thing .. :) Perhaps this whole issue transcends Ocaml .. but at least considered responses may occur here. An Ocaml policy on this might leak into the rest of Debian, as well as any tools created to aid the process. If I were a DD I'd not be supporting packages WITHOUT tests -- even if the tests are inadequate they can be added to. Without a harness built-in this is much harder. Building the harness without a Policy is also difficult. Example: ocaml Policy could require some testing, then Bug raised in BTS on all packages without it, this is then fixed with at least a stub suitable for extension. However some packages can't be tested without risk and manual intervention, eg a GUI is hard as is any real time code or for example mod-caml plugin.. I just don't know. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
