Hi Gary, * Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 04:45:14PM CEST: > Ralf Wildenhues wrote: > > > >Wow. I'm quite impressed! 8-) > > Amazing what one can do when locked in a room for a weekend with > nothing but an internet connection, and a fully stocked fridge!
I thought arch can do without internet connection. Surely for me it would improve throughput to be without connection then.. ;-) > >>Looking forward to making the alpha release, > > > >Yep, me too. I've got a handful of own patches sitting here, which I'd > >like to push out before, but I'll probably agree to drop anything that > >will cost me more than a couple of days to push out. > > Sure thing. > > I'm afraid I don't understand the locking problem cited as the > last release blocking issue on the kicks-ass RoadMap, otherwise > I would have tackled that one too. I'm almost inclined to ignore it for the release. One example of it goes as follows: User uses LIBTOOL = /usr/bin/libtool in his Makefile. That `libtool' has need_locks=yes Now, the build tree is below a different mount point than /usr. This code in ltmain: | # Lock this critical section if it is needed | # We use this script file to make the link, it avoids creating a new file | if test "$need_locks" = yes; then | until $opt_dry_run || ln "$progpath" "$lockfile" 2>/dev/null; do | func_echo "Waiting for $lockfile to be removed" | sleep 2 | done | elif test "$need_locks" = warn; then will then deadlock. Or, instead of /usr/bin/libtool, LIBTOOL points inside some build tree of a different but related package (as I believe was in the bug report). Point is, it's actually nontrivial to assume any file name in the build tree to certainly be present, unless you also accept to create $OBJDIR in any case. And then you still need to be careful to do that, too. See the referenced mail for more thoughts about a solution. This issue is much less likely to actually hit anyone since the boilerplate patches are in place. Cheers, Ralf
