logfile_patterns adition

[Ion-Mihai Tetcu]

On Sun, 01 Mar 2009 16:10:31 -0500
Joe Marcus Clarke <marcus at marcuscom.com> wrote:

> On Sun, 2009-03-01 at 23:08 +0200, Ion-Mihai Tetcu wrote:
> > 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,...).
> 
> Not a bad idea.  Can you build a pattern -> stage mapping?

I can; if I'll have the time is an other question ;)
But I'll try to find some time after QAT is done with the current QA
run.


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