On 2012-04-23 23:03, Guillem Jover wrote: > > Hi! > > While rebuilding packages for the new libbsd 0.4.0 upload, this package > fails to build consistently on at least my system, and it might seem > like on at least the mips buildd too, I've not investigated in detail > what exactly is triggering this only on these systems and not others, > but I think it's due to me having 3 network interfaces (lo, eth0, wlan0), > in any case there's a bogus fflush() on an input stream which is causing > wrong subsequent fseek()s. The behaviour of fflush() in input streams is > not usually well defined and in this case is not really needed, fseek() > should just do fine. > > Attached a patch fixing this. And here's the failure mode: > > [...] > > thanks, > guillem
Hi, Thanks for the report. I must admit I am a bit confused. The fflush code is in the src/Linux part and according to [1] fflush should be well defined on Linux. So I do not immediately see why the fflush should be removed from there. Also, libbsd is only used when building on (k)FreeBSD, in that case src/FreeBSD will be used as I understand the makefile[2] (and its network.c does not have the fflush call). So I do not see how removing the fflush call in src/Linux will help in this case either. Then there is the test error. "Cannot allocate memory" suggests a ENOMEM or so is returned, but I do not see a code path in sa_reset__netinterfaces() for Linux that could return ENOMEM. On the other hand sa_reset_net_interfaces on (k)FreeBSD has such a return (line 76). My primary concern here is that I will be unable to convince upstream why this patch is correct/needed. ~Niels [1] http://linux.die.net/man/3/fflush """ For input streams, fflush() discards any buffered data that has been fetched from the underlying file, but has not been consumed by the application. [...] The standards do not specify the behavior for input streams. Most other implementations behave the same as Linux. """ [2] src/CMakeLists.txt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org