interpret tinderbox results

[Florent Thoumie]

On Fri, 2006-08-11 at 11:37 -0400, Joe Marcus Clarke wrote:
> On Fri, 2006-08-11 at 13:26 +0400, Boris Samorodov wrote:
> > On Thu, 10 Aug 2006 11:51:32 -0400 Joe Marcus Clarke wrote:
> > > Boris Samorodov wrote:
> > 
> > > > The port lang/gnat-gcc34 is marked as broken (doesn't extract at
> > > > 4.x). I've got a patch and asked the man who has a 4.x TB to test it.
> > > > 
> > > > I've got the result (only the log file) from a thinderbox for 4.x.
> > > > Here is the very last phase:
> > > > ====================<phase 7: make package>====================
> > > > ===>  Building package for gnat-gcc-3.4.6
> > > > Creating package /tmp/packages/All/gnat-gcc-3.4.6.tgz
> > > > Registering depends: ldconfig_compat-1.0_8 rc_subr-1.31_1.
> > > > Registering conflicts: gcc-3.4.*.
> > > > Creating gzip'd tar ball in '/tmp/packages/All/gnat-gcc-3.4.6.tgz'
> > > > Deleting gnat-gcc-3.4.6
> > > > pkg_delete: unexec command for 'rmdir libdata/ldconfig >/dev/null 2>&1' failed  [1]
> > > > pkg_delete: couldn't entirely delete package (perhaps the packing list is
> > > > incorrectly specified?)
> > > > 
> > > > === Checking filesystem state
> > > > Deleting libarchive-1.2.53,1
> > > > Deleting ldconfig_compat-1.0_8
> > > > Deleting gmake-3.81_1
> > > > Deleting bison-1.75_2,1
> > > > Deleting gettext-0.14.5_2
> > > > Deleting libgnugetopt-1.2
> > > > Deleting m4-1.4.4
> > > > Deleting rc_subr-1.31_1
> > > > Deleting libiconv-1.9.2_2
> > > > Deleting expat-2.0.0_1
> > > > 
> > > > === Checking filesystem state after all packages deleted
> > > > ================================================================
> > > > list of files present on clean system but missing after everything was deinstalled)
> > > > ./usr/X11R6/libdata/ldconfig missing    [2]
> > > > ./usr/X11R6/libdata/ldconfig32 missing  [2]
> > > > ================================================================
> > > > build of /usr/ports/lang/gnat-gcc34 ended at Wed Aug  9 01:50:49 GMT 2006
> > > > 
> > > > 
> > > > And now have some questions.
> > > > [1] I assume that since the output of STDERR is redirected STDOUT,
> > > >     this line actually doesn't cause an error while building.
> > > > [2] Since /usr/X11R6/libdata/ldconfig(32) are not standard for base
> > > >     4.x installation, this error won't occure while building the port
> > > >     at pointyhat.
> > > > 
> > > > The last (and the main) question. I interpret those results as good
> > > > ones and am going to commit my patch (which was tested). Am I right
> > > > here?
> > 
> > > The unexec command should be a @dirrmtry or end with || true to avoid
> > > the warning above.  Also, we really should sync the mtree files for the
> > > ldconfig stuff to 4.X.  But in any event, fixing the @unexec should be
> > > fine for this case.
> > 
> > OK. This is how I understand your answer. ;-)
> > 
> > [1] It is bsd.ports.mk which should be patched:
> > -----
> > Index: bsd.port.mk
> > ===================================================================
> > RCS file: /home/pcvs/ports/Mk/bsd.port.mk,v
> > retrieving revision 1.539
> > diff -u -r1.539 bsd.port.mk
> > --- bsd.port.mk	4 Aug 2006 12:34:41 -0000	1.539
> > +++ bsd.port.mk	11 Aug 2006 09:19:03 -0000
> > @@ -3858,7 +3858,7 @@
> >  		> ${PREFIX}/${LDCONFIG_DIR}/${UNIQUENAME}
> >  	@${ECHO_CMD} ${LDCONFIG_DIR}/${UNIQUENAME} >> ${TMPPLIST}
> >  .if defined(NO_LDCONFIG_MTREE)
> > -	@${ECHO_CMD} "@unexec rmdir ${LDCONFIG_DIR} >/dev/null 2>&1" >> ${TMPPLIST}
> > +	@${ECHO_CMD} "@unexec rmdir ${LDCONFIG_DIR} >/dev/null 2>&1 || true" >> ${TMPPLIST}
> 
> Well, ${TRUE} anyway.
> 
> >  .endif
> >  .endif
> >  .endif
> > -----
> > 
> > [2] This error is an internal error of current TB version and shouldn't
> > occure while building the port at other circumstances (i.e. pointyhat).
> 
> No, I think it will happen on pointyhat.  The ldconfig directories were
> recently added to the 4.X mtree, so bsd.port.mk needs to be updated to
> reflect this.

I'm guilty for all these ldconfig errors / leftovers, but if I had to
say something, libdata/ldconfig{,32} directories shouldn't have been
added to mtree files in branches where the script doesn't have the new
behavior. It only makes it harder to handle.

-- 
Florent Thoumie
flz at FreeBSD.org
FreeBSD Committer
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: This is a digitally signed message part
Url : http://marcuscom.com/pipermail/tinderbox-list/attachments/20060817/f33609e3/attachment.bin