itetcu at FreeBSD.org
Sun Mar 1 16:08:32 EST 2009
On Sun, 01 Mar 2009 16:05:29 -0500
Joe Marcus Clarke <marcus at marcuscom.com> wrote:
> On Sun, 2009-03-01 at 21:58 +0100, Beat Gätzi wrote:
> > Ion-Mihai Tetcu wrote:
> > > On Sat, 28 Feb 2009 19:42:17 +0100
> > > Beat Gätzi <beat at chruetertee.ch> wrote:
> > >
> > >> Hi,
> > >>
> > >> Ion-Mihai Tetcu wrote:
> > >>> I think adding the pattern below to logfile_patters would give a
> > >>> link to the most useful place in the log in case of
> > >>> depend_object failures: /^===> .*-[0-9].* depends on .* - not
> > >>> found$/
> > >>>
> > >>> Now we're getting
> > >>> 'You may wish to ``make deinstall'' and install this port again'
> > >>> which is less useful since we need to know why that port was
> > >>> built (ie. what's wrong with the depends line) rather that is
> > >>> was built.
> > >> Thanks for this idea. Unfortunately this is not possible with the
> > >> current log file markup support. Only if a port build has been
> > >> successful the patterns from logfile_patterns were used. In cases
> > >> building a port fails the markup patterns are taken from
> > >> port_fail_patterns. I think it could be possible to highlight the
> > >> patterns from logfile_patterns as well but wouldn't this draw
> > >> off the attention from the port fail patterns?
> > >
> > > I thought it was a combination of the two. In this particular
> > > case, since we first install depends, then when this '===>... not
> > > found' appears it's obvious that a depend is specified wrong.
> > >
> > > Maybe add it to port_fail_patterns then? I think is unique enough
> > > and it would do the same this as the current 2000 pattern.
> > As far as I know the failure patterns are kept in sync with
> > pointyhat. Or are exception like this allowed?
> We have sort of gone off-script with the pointyhat sync. We try to
> stay in sync in terms of new additions, but our order is custom at
> this point.
Why don't we grep by stages? Some of the confused results seems to be
avoidable by taking in consideration in which stage we are (fetch,
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...
Size: 196 bytes
Desc: not available
More information about the tinderbox-list