fetch / checksum problems with distcache

[Ion-Mihai Tetcu]

On Sun, 01 Mar 2009 02:14:40 -0500
Joe Marcus Clarke <marcus at marcuscom.com> wrote:

> On Sun, 2009-03-01 at 09:09 +0200, Ion-Mihai Tetcu wrote:
> > On Sat, 28 Feb 2009 13:52:04 -0500
> > Joe Marcus Clarke <marcus at marcuscom.com> wrote:
> > 
> > > On Fri, 2009-02-27 at 21:02 +0200, Ion-Mihai Tetcu wrote:
> > > > Hi,
> > > > 
> > > > 
> > > > I wonder if:
> > > > - if checksum fails and file was fetched from distcache it
> > > > shouldn't be tried a second time w/o distcache
> > > > - if checksum fails and there is a MASTER_SITE_OVERRIDE
> > > > defined, a second fetch should be tried ignoring
> > > > MASTER_SITE_OVERRIDE
> > > > 
> > > > Unfortunately I don't see an easy way to do this in tindy's
> > > > code.

 [ .. ]
 
> > >  In the meantime, what about performing a cache removal in the
> > > case that state 1 of a portbuild fails?  This way, a port will be
> > > successfully rebuild on tinderbuild pass 2.
> 
> Well, you could schedule a rebuild of the ports that failed.  At least
> by purging the case, manual intervention is not required.

In portPortBuild, reset the entry to ENQUEUED if the fail reason is
fetch or checksum.

Speaking of (lib)fetch, is there a way to make it have a sane timeout
period? I see it hanged enough times (and not only on tindy).

> > It would do, but I'm trying to avoid the second pass on QAT, since
> > it would also try to rebuild all ports that fail for other reason,
> > thus increasing the response time drastically.
> > 
> > > This patch should handle that:
> > > 
> > > http://www.marcuscom.com/downloads/portbuild.diff
> 
> > I'm not sure about those 10 minutes, isn't it to much by far?
> 
> It's a worse-case scenario.  It means that if a lock cannot acquired
> after 10 minutes, then give up.  This is the same timeout applied to
> the cache insertion.

I guess you're right, and if it hasn't been able to acquire a lock in
10 mins my guess would be that build is stuck anyway.

-- 
IOnut - Un^d^dregistered ;) FreeBSD "user"
  "Intellectual Property" is   nowhere near as valuable   as "Intellect"
FreeBSD committer -> itetcu at FreeBSD.org, PGP Key ID 057E9F8B493A297B
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
URL: <http://marcuscom.com/pipermail/tinderbox-list/attachments/20090301/a5831d11/attachment.bin>