Hi Paul, sorry for the delay in replying, I was quite busy and now I have some free time over the holidays to follow up.
>> I am puzzled. The recent upload only changed the watchfile and updated >> Standards-Version, compat level etc -- packaging things. Nothing touched >> the code or build rules. > > Well, but maybe your build dependencies have. Also, compat level isn't > totally safe either in general (although the issue here doesn't > obviously look like it). Yes, I agree it's likely not that. [...]>> I must admit that being unfamiliar with these architectures and not >> really having an idea of where to start, I am tempted to just remove >> armhf from the list of supported architectures and have the version with >> the broken autopkgtest removed from unstable. Do you probably know >> someone who might be more knowledgeable with such architecture-specific >> issues? > > We have porters for architecture specific support. However, I'm not > totally convinced yet it's architecture specific. Maybe. You noted that it seems to work fine on a machine with the same architecture but different specs. > Is there anything I can try out for you on our armhf host to help debug > the issue? Run the command with more debug options? Grab an output file > from somewhere? Hmmm. Since I am pretty unfamiliar with the source and/or any assumptions that are being made in the code, a good start would be to get an idea of where in the code the bus error is triggered. You could try the -v option but I am not sure it would help much. I think a real stack trace would help, by running the tests with valgrind or via gdb. Nothing one would do in a generic test suite :/ How much customization would be possible in the test run? > I could try to run the test in testing with a rebuild of > the package in testing, would that help? Maybe, if that does not cost much then please try. Cheers Sascha
