Redport builds are all "finished" without logs

Bernhard Fröhlich decke at bluelife.at
Sun Feb 16 19:19:47 UTC 2014


Am 15.02.2014 21:07 schrieb "John W. O'Brien" <john at saltant.com>:
>
> On 2/15/14 12:53 PM, John W. O'Brien wrote:
> > On 2/10/14 9:52 AM, John W. O'Brien wrote:
> >> Could you help me understand what's going on with this build [0]? Did
an
> >> admin kill the job, and if so, why? Otherwise, what happened and is it
> >> because I'm doing something wrong?
> >>
> >> [0] https://redports.org/buildarchive/20140210032800-24135/
> >
> > Continuing to troubleshoot this. I've been adding ports to TEST_DEPENDS
> > one by one, and found an instance where the /before/ [1] works but the
> > /after/ [2] does not.
> >
> > The implicated port is math/py-statsmodels (maintainer CC'd).
> >
> > I'm still not clear on the circumstances under which Redports winds up
> > in the "finished" state, and consequently am unable to avoid it or work
> > around it. Any help or advice would be appreciated.
> >
> > [1] https://redports.org/buildarchive/20140215154500-1493/
> > [2] https://redports.org/buildarchive/20140215163200-621/
>
> I see the problem. math/py-statsmodels depends on math/py-pandas. So the
> bad news is that I cannot include the former in TEST_DEPENDS for the
> latter and expect much at all from Redports. The good news is that I can
> now fix my port to be more readily testable.
>
> For the benefit of those who come after, would it make sense to augment
> the description of the "finished" state [3] to mention the possibility
> of circular dependencies, which don't appear to be covered by the other
> detectable termination conditions?
>
> Regards,
> John
>
> [3] https://redports.org/wiki/Buildstatus

The finished state is not something the user should see at all. The truth
is that there are cases that redports is unable to detect because of bugs
inside tinderbox or in the redports scripts or because of extreme cases
like circular dependencies like in your cases. In the beginning circular
dependencies took the whole backend down but I worked around it by setting
the maximum size of the tinderbox environment directory to a very small
value so it fails after some minutes of excessive i/o and cpu usage. So
except from "when the tinderbox job fails in a strange way and the
environment directory is 100÷ full" I see no chance how to detect that case
and I don't want to build a feature based on a dirty workaround.

The right way to fix that is to add a circular dependency check to
tinderbox and then I can read out that error properly.


More information about the freebsd-ports mailing list