dns/djbdns [do-package] Error code 1

[Michael Gmelin]

On Mon, 3 Mar 2014 23:31:29 +0100
"bapt at FreeBSD.org" <bapt at FreeBSD.org> wrote:

> On Mon, Mar 03, 2014 at 11:04:12PM +0100, Michael Gmelin wrote:
> > On Thu, 27 Feb 2014 11:47:51 -0800
> > David Thiel <lx at redundancy.redundancy.org> wrote:
> > 
> > > On 02/27, Michael Gmelin wrote:
> > > > I stumbled over the same problem today on 10.0, make NO_STAGE=1
> > > > install worked for me on the first attempt though. I can also
> > > > confirm the problem with dnscache-conf when installing the
> > > > binary package using "pkg install".
> > > 
> > > Can you confirm the exact version you installed via pkg install,
> > > including PORTREVISION?
> > 
> > [3/3] Installing djbdns-1.05_17,1... done
> > 
> >  pkg info djbdns
> >  configuration file djbdns-1.05_17,1
> > Name           : djbdns
> > Version        : 1.05_17,1
> > Installed on   : Mon Mar  3 20:24:26 UTC 2014
> > Origin         : dns/djbdns
> > Architecture   : freebsd:10:x86:64
> > Prefix         : /usr/local
> > Categories     : dns
> > Maintainer     : lx at FreeBSD.org
> > WWW            : http://cr.yp.to/djbdns.html
> > Comment        : Collection of secure and reliable DNS tools
> > Options        :
> >         ADD_USERS      : off
> >         DNSCURVE       : off
> >         DUMPCACHE      : off
> >         IGNOREIP       : off
> >         IP6            : off
> >         JUMBO          : off
> >         MAN            : on
> >         PERSISTENT_MMAP: off
> >         SRV            : off
> > Flat size      : 801KiB
> > Description    :
> > 
> > Bapt's latest fixes (1.05_18,1) seem to solve this, *but*...
> > 
> > > 
> > > > I'm not certain about the maintainer situation of the port, if
> > > > you want me to I could take a closer look at this in a few days.
> > > 
> > > The difficulty here is that the maintainer can't reproduce the
> > > problem at all, and I'm not intimately familiar with the
> > > internals of stage support. I don't see anything in the port that
> > > looks timing-dependent, so I'm not sure where to go.
> > 
> > unfortunately now it seems like staging is not working reliably. I
> > noticed this while building on a host that actually runs dnscache
> > (it's reproducible about 90% of the time):
> > 
> > # make clean stage
> > 
> > ...
> > 
> > ===>   Generating temporary packing list
> > ./install
> > install: fatal: unable to write .../bin/dnscache: text busy
> > *** Error code 111
> > 
> > Stop.
> > make[2]: stopped in /usr/ports/dns/djbdns/work/djbdns-1.05
> > *** Error code 1
> > 
> > Stop.
> > make[1]: stopped in /usr/ports/dns/djbdns
> > *** Error code 1
> > 
> > Stop.
> > make: stopped in /usr/ports/dns/djbdns
> > 
> > Which simply means, that ./install is trying to overwrite the
> > running /usr/local/bin/dnscache.
> > 
> > MAKE_JOBS_UNSAFE works here, so there's probably a parallel
> > execution problem which messes up the conf-home logic/workaround.
> > If I introduce "sleep 1" to the pre-install target things work as
> > expected. Also, if I run "make clean; make; sleep 1; make stage"
> > everything is ok.
> > 
> > My theory is, that overwriting ${WRKSRC}/conf-home only results
> > in the desired effect, if its new timestamp is clearly newer to
> > trigger rebuilds of all dependencies.
> > 
> > When comparing build outputs, I noticed that in a working build
> > "./auto-str auto_home `head -1 conf-home > auto_home.c`" got called,
> > while on malfunctioning builds it wouldn't. Rebuilding auto_home.c
> > depends directly on auto-str and conf-home.
> > 
> > My trivial solution is to also remove auto_home.c as part of
> > the pre-install target, which *seems* to fix the problem, since it
> > makes sure that conf-home gets turned into a news auto_home.c which
> > in turn is used when creating auto_home.o and linking install and
> > instcheck.
> > 
> > Makes sense?
> > 
> > Patch (also attached for those receiving this directly):
> > 
> 
> That's a good catch!, I took my solution from debian packaging, but I
> think I have missed something out there, the timestamp should have
> been taken in account in my patch, I may have missed something, I go
> digging again in debian package to see what I missed, but your
> invesgation helps for sure
> 
> 

Hi Bapt,

Any chance you could commit this until there's time for a better
solution? This would stop the build from breaking frequently.

Thanks,
Michael






-- 
Michael Gmelin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20140309/2cfecd2b/attachment.sig>