On 17. Oct 2011, at 20:51 , Stanislav Sedov wrote: Hi,
I shrinked that Cc: list dramatically. > On Mon, 17 Oct 2011 15:35:51 +0300 > Ion-Mihai Tetcu <ite...@freebsd.org> mentioned: > >> >> >> Here's a little status update: >> We iterated through a few -exp runs (basically for ports/161404 -- >> committed and ports/161431 -- skv@ any problem with it?). With those two >> we can build around 7k packages. The majority of the rest can't be built >> because of a few high profile ports that don't package: expat (6581), >> curl (975), jpeg(5057), lcms(1080), libiconv(11180), libltdl(1187), >> libogg(1947), pcre(5737), python27(5935). >> >> http://pointyhat.freebsd.org/errorlogs/i386-10-latest/ >> >> What we'd like to do next is see how many ports we can package after >> individually fixing those above. This will require a few other -exps >> since undoubtedly we'll find other highly-depended-on ports broken that >> weren't tried because of the blockers above. >> > > It doesn't require an exp-run to understand that you won't move much further > with just fixinng these ports. Well, there was a significant update from ~2800 to ~7000 ports by just fixing 2 or 3? I think understanding these and handling them in a well defined manner is a good idea. > patching similar to the patch Ed, Doug and other people proposed. Actually, > that sed one-liner fixed like 99% of the ports in tree, excluding some complex > ones (like GCC). So why not commit that patch as a KNOB to bsd.port.mk like > it was initially proposed and let people use it in individual ports makefiles > to fix them (and portmgr@ can commit the initial bunch of these knobs)? This > is the easiest thing you can do now, and you will be able to abandon it when > the better solution is available (which is unlikely). I think that's what he was saying as a possible next step. If they have the cycles currently while waiting for RC1 to happen let them do it; we are talking in having things within a month not in spring next year already. I would assume that the aforementioned patch might go into the framework, would only be applied if a) OSVERSION>=10... and b) the port has a knob that says "I need this to run". > WRT your "submit upstream" comment, personanlly, I'd argue against this: We damn need it; they need to regen the stuff; it's going to take months if not years to get 80% to that point and a couple of projects might be dead and we might want to use a local patch then but the sed-KNOB is a bandaid that must die again. I would argue that no port must add the KNOB (once it would exist, should it) without having notified upstream. And you might know a lot better than I do but ideally there would be a new official libtool release before that and ideally the libtool people would have by now fixed all the !FreeBSD similar cases... /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. _______________________________________________ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
