[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: clock disparity on buildd?

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

Attachment: pgp_6P6aMjvdw.pgp
Description: PGP signature

Reply to: