retitle 747308 Using eatmydata breaks fsync in tests thanks Hello Antonio, Matthias,
Retitling the bug to be more specific, if you don't mind. Matthias Klose [2014-05-07 13:27 +0200]: > AssertionError: <built-in function fdatasync> didn't raise a OSError with a > bad > [...] > Chatting with Martin Pitt, he suggested that the eatmydata package > is installed in the test environment. I think this is wrong, and > here it likely introduces regressions in the testsuite for a real > package. Yes, I agree. This makes sense as eatmydata's libc preload turns the fsync/fdatasync functions into complete no-ops without error checking. I think it's wrong to let tests run with eatmydata; I'd suggest either of: * If the machine that runs the tests has enough RAM, I'd move to a tarball schroot and put the unpack directory on a tmpfs. (Note that aufs introduces its own set of bugs, so overlays are less reliable than a tarball unpack) * If there is not enough RAM, we could set the dpkg unsafe-io option to avoid the sync() hit on package install but otherwise keep sync() working for the actual tests. Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
