I produced this bug on an armv7a board (Raspberry Pi 2), so it may not happen on x86 or amd64. Basically this chunk of the configure script repeats forever: checking dpkg architecture name... armel checking that generated files are newer than configure... done configure: creating ./config.status config.status: creating Makefile config.status: creating dpkg-deb/Makefile config.status: creating dpkg-split/Makefile config.status: creating dselect/Makefile config.status: creating dselect/methods/Makefile config.status: creating dselect/po/Makefile.in config.status: creating lib/Makefile config.status: creating lib/compat/Makefile Potentially it's trying to wait until the file's modification times aren't in the future anymore (which, if your board thinks it's 1970 is going to take a while. Reproducible: Always
Created attachment 398550 [details] dpkg.build.log.xz
This happens with tons of packages in the configure phase, that's why you set your clock properly.
What I set my system clock to should have no bearing on my ability to compile a package. The configure script of any package that checks system time in this way is badly broken. I specifically had my clock set in the past to work around a bug in the icedtea ebuild that failed to build if the time was later than midnight, Jan 1st, 2015. (this was fixed in icedtea-7.2.5.4) This is absolutely a bug because taking no action can (and has) result(ed) in a user or system administrator allowing portage to spin in an infinite loop for multiple days. If it's valid for packages to check the system time and break in unexpected ways when the system time is not set properly, then it's INVALID for portage to allow an emerge to continue if the system time is set improperly. Either: Add some kind of check to the dpkg ebuild (and every other ebuild that can exhibit this broken behavior) that warns that the distfile archive has a timestamp from the future and that an infinite loop is probable OR Patch the configure script of dpkg (et. al.) to remove this broken check. I'm happy to provide either patch, if I can be assured that it won't be rejected out of hand (obviously patch quality and any number of other considerations would need to be satisfied before actually merging such a patch, but I'm only looking for assurance that I'm not going to be completely wasting my time to write a patch for this).
bug #22378 bug #163282 bug #185656 I really think this is going to be remarked invalid, I didn't mean to upset you or anything, just going based off the countless similar bugs I've seen marked invalid. You're free to write patches for all these configure scripts so they build in 1970, but I think it'd be easier to set your clock properly.
You didn't upset me, and I hope that my reply didn't read as if I was, and apologize if it did read in such a way. Status quo of "Lots of packages do this, therefore it's not a bug" isn't a valid reason in the same vein of "If all your friends decided to jump off a bridge...", and I seriously hope that other folks on this bugzilla don't think that way. There are numerous deployment scenarios where setting the system clock is difficult to do. I have a few hundred small ARM boards (none of which have a hardware clock, or CMOS battery) deployed on a private, air-gapped network for manufacturing purposes. Power outages happen, and setting the clock manually on each would take days. We did have a time server with a GPS based tier-2 network time source that we sync'ed with, but after the gps time source bit the bucket, we discovered that having invalid clocks didn't effect what we were doing at all. I obviously can't sway anyone other than myself to fix this issue, but I'd at least like the problem to be recognized as the problem that it actually is, even if it languishes forever as an open bug.
emerge & configure aren't the only things that may go bonkers if you have future-modified files... maybe you should look into a solution like chrony which can save/restore time in a file on disk, to restore a reasonable clock setting w/o network. There are a million ways you can shoot yourself in the foot and break emerge, it certainly can't check for all of them... but I suppose some kind of basic detection of clock skew (independent of the specific package's own build system) may be a useful addition to portage. I think if you try to solve this by patching a thousand different configure scripts, that's a battle you probably can't win. IMHO, FWIW, etc =)
Right. I fully support the notion of there being too many packages in the tree to fix them all. My main concern is that portage happily let the configure script chug for 3 days even though (as evidenced by the 3 other bugs you provided links to) it's known that this can happen when there's clock skew. Checking some (or all?) of the timestamps on the unpacked tarball and emitting a warning seems like a cheap and effective way to warn the administrator that bad things might be about to happen. Doing date --set "10 MAR 2015 00:00:00" takes less than a minute, and I would have moved along happily, if portage had warned me that a known failure scenario was likely to happen. I'll be adding to my todo list to create a patch or eclass or something that'll check for this scenario. If this bug stays open, I'll submit it here. Else I'll create a new one.
Yeah there should be no problem with converting this to a portage feature request bug
dpkg's ebuild or build system doesn't do any of this. It's all generic autotools stuff. Seriously, everyone in the world should help you set your system clock to newer than the newest timestamp on any file or directory, just in case that might prove that your system clock is wrong? Or warn you about it? There is no plausible bug or feature request here. And certainly no bug in dpkg.
