Ports marked as IGNORE - (cups-pdf) & (urlview) why - how long?

David Southwell david at vizion2000.net
Thu Dec 24 10:16:08 UTC 2009

> > > Looks like all the PR's were not in place before the test was run on
> > > pointyhat.
> >
> > pointyhat doesn't have anything to do with PRs.  It runs based on what
> > is checked into CVS when its runs start.  How would it be able to do
> > otherwise?  The ports PR count is currently 998.  How is a computer
> > program going to know which ones are relevant or correct?
> >
> > > I deduced from the information on my system that the error was more
> > > likely due to a false positive for failure by the testing procedure
> > > rather than due to an inherent failure in the code.
> >
> > build error != install error.  If you look at the two error logs, you'll
> > see that those are install errors (files required to be installed not
> > installed; files required to be deinstalled not being deinstalled).
> >
> > Ports that do not allow a clean install/deinstall cycle are broken,
> > whether they compile or not.
> >
> > mcl
> Yes I agree BUT it is suggested that the reason that there was not a clean
> install/deinstall cycle was because the pointyhat test may have been done
> without the benefit of PR ports 141375. Here is Mathew Seaman's take on it:
> "Looks like the problem would have been fixed in PR ports/141375, which
> modified
> the cups-base port to create the directory in question.  As that fix was
> applied
> on the 12th at 19:39 and the last pointyhat test on cups-pdf appears to
>  have been
> on the same day at 20:57 I reckon pointyhat just missed getting the fix for
>  at least one of its test cases by about >< that much."
> What we need now is another test on pointyhat to see whether his
>  speculation is accurate. It seems highly probable to me.
> Time will tell
> David
> _______________________________________________
Well that was it! Compiles and installs when the Makefile is amended. So the 
pointy hat run must have started before the fix was applied even though the 
test was done after.  I suppose the only thing that could prevent similar 
"false positives for failure" would be for the pointy hat test cycle to 
include a second check on failures after the run ends to pick up any fixes 
which had been applied between the start of the run and any individual test. 
However this is probably such a rare occurence that the effort to amend the 
procedure may not be justified. It is a useful reminder that pointyhat 
failures can, under such restricted circumstances, be misleading. Mind you I 
would prefer a few extra "false failures" than one "false passes"!!


More information about the freebsd-ports mailing list