On Mon, Apr 11, 2016 at 9:15 AM, Andreas Beckmann <a...@debian.org> wrote: > [ this analysis is has been superseded by bug #820658 I filed against make ] Yeah, just read that. Do you think anything will happen on the side of make? Especially as below you can be right that filesystem timestamp resolution is the real problem.
> The (intersting part of the) diff between > > [GOOD] > https://buildd.debian.org/status/fetch.php?pkg=vice&arch=kfreebsd-i386&ver=2.4.dfsg%2B2.4.26-1&stamp=1458846545 > [BAD] > https://buildd.debian.org/status/fetch.php?pkg=vice&arch=kfreebsd-i386&ver=2.4.dfsg%2B2.4.26-1%2Bb1&stamp=1460088757 > > starts with > > @@ -2959,12 +2990,6 @@ > | sed -e '$s/\\$//') > POTFILES-t \ > && chmod a-w POTFILES-t \ > && mv POTFILES-t POTFILES ) > -cd .. \ > - && CONFIG_FILES=po/Makefile.in CONFIG_HEADERS= \ > - /bin/sh ./config.status > -config.status: creating po/Makefile.in > -config.status: executing depfiles commands > -config.status: executing default-1 commands > make[2]: 'intl2po' is up to date. > make[2]: Leaving directory '/«BUILDDIR»/vice-2.4.dfsg+2.4.26/po' > /usr/bin/make trans-update -C po/ > > So po/POTFILES has been updated, but po/Makefile has not been regenerated, > causing the future breakage due to an empty POTFILES variable. > For some reason make thinks that po/Makefile does not need to be regenerated. Then maybe an old timestamp on Makefile would help it? > Of course I could not reproduce that problem :-) Don't worry, me neither nor upstream could do it. :-/ > But I'd suggest the following for further debugging: > * drop try-to-fix-possible-race-condition.patch > * collect some timestamps: OK, but as you suspect this may build next time and so on, then it will just break again. Well, maybe the 'ls' calls will make it work, due to the extra time it needs to execute those. But then I can add 'sleep 1' between the 'make' calls. > I don't think we have here a "race condition" by some kind of parallelism. > I would more suspect a filesystem time resolution problem. Maybe even a bug > in make itself. > IIRC the file systems used by kfreebsd and hurd only have second resolution, > while (most) Linux filesystems have (up to) nanosecond resolution. That would explain why the breakage happens way too often on Hurd and kFreeBSD machines. Thanks, Laszlo/GCS
