Control: tag -1 pending On Wed, May 07, 2014 at 01:40:59PM +0200, Martin Pitt wrote: > 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;
Fair enough. > 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. There is not enough RAM, so for now I am setting dpkg unsafe-io as the default behavior. I committed a fix to the git repository that sets up new chroots with unsafe-io and without eatmydata, and already did the corresponding changes on ci.debian.net. -- Antonio Terceiro <terce...@debian.org>
signature.asc
Description: Digital signature
