logfile_patterns adition

[Ion-Mihai Tetcu]

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,
extract,...).

-- 
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/fefe6761/attachment.bin>