On Thu, 13 May 2010 03:18:57 +0200 Goswin von Brederlow <goswin-v-b@web.de> wrote: > Neil Williams <codehelp@debian.org> writes: > > > * Source package: pilot-qof > > * Version: 0.2.1-1 > > * Architecture: alpha > > * State: failed > > * Suite: unstable > > * Builder: goetz.debian.org > > * Build log: > > https://buildd.debian.org/fetch.cgi?pkg=pilot-qof&arch=alpha&ver=0.2.1-1&stamp=1273661056&file=log > > > > > > tar: pilot-qof-0.2.1/m4: time stamp 2010-05-12 10:05:18 is > > 4472.963421 s in the future tar: pilot-qof-0.2.1/po/pilot-qof.pot: > > time stamp 2010-05-12 10:01:48 is 4262.962891 s in the future > > Is that really a wrong clock or just an timezone issue? If your > tarball is brand new and the buildd is living in a different timezone > then such a small time difference seems totaly believable. A timezone issue should not be allowed to cause a FTBFS! The buildd shouldn't care about timezones, it should operate in UTC. In this case, I think it IS working in UTC but the clock is wrong. > > * Architecture: alpha > > * State: failed !! Yes, the tarball is (or was) brand new but that wouldn't be unusual for a native package or an upstream package where the Debian maintainer is part of upstream. This cannot be dismissed as "just a timezone issue" because it causes the build to FAIL. Other buildd's don't have these timezone issues (or we'd hear a lot of complaints from DD's on the Pacific coast of USA etc.) Alpha cannot be treated differently in that regard. The buildd OS understands UTC and timezones, the buildd cannot be allowed to FAIL a build merely because the tarball originated in a different timezone! Is alpha now going to delay all builds by 24 hours merely so that all possible timezone issues can be avoided??? -- Neil Williams ============= http://www.data-freedom.org/ http://www.linux.codehelp.co.uk/ http://e-mail.is-not-s.ms/
Attachment:
pgpu1hpyuHE2g.pgp
Description: PGP signature