On Mon, Mar 03, 2014 at 11:04:12PM +0100, Michael Gmelin wrote: > On Thu, 27 Feb 2014 11:47:51 -0800 > David Thiel <l...@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 : l...@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 regards, Bapt
pgpKqdTJG9xiI.pgp
Description: PGP signature