From owner-freebsd-gnome@FreeBSD.ORG Mon Oct 17 12:54:46 2011 Return-Path: Delivered-To: gnome@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 25DA91065675; Mon, 17 Oct 2011 12:54:46 +0000 (UTC) (envelope-from itetcu@FreeBSD.org) Received: from worf.ds9.tecnik93.com (worf.ds9.tecnik93.com [81.196.207.130]) by mx1.freebsd.org (Postfix) with ESMTP id B0EE18FC18; Mon, 17 Oct 2011 12:54:45 +0000 (UTC) Received: from localhost (unknown [81.181.146.246]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by worf.ds9.tecnik93.com (Postfix) with ESMTPSA id AAE0D22C5486; Mon, 17 Oct 2011 15:35:52 +0300 (EEST) Date: Mon, 17 Oct 2011 15:35:51 +0300 From: Ion-Mihai Tetcu To: ports@FreeBSD.org Message-ID: <20111017153551.23281532@tetcu.info> In-Reply-To: <20111011063602.GO68552@droso.net> References: <20111011063602.GO68552@droso.net> X-Mailer: Claws Mail 3.7.10 (GTK+ 2.24.6; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 17 Oct 2011 16:06:27 +0000 Cc: dinoex@FreeBSD.org, naddy@FreeBSD.org, autotools@FreeBSD.org, current@FreeBSD.org, kuriyama@FreeBSD.org, stas@FreeBSD.org, skv@FreeBSD.org, python@FreeBSD.org, portmgr@FreeBSD.org, gnome@FreeBSD.org, roam@FreeBSD.org, Erwin Lansing , mm@FreeBSD.org Subject: [UPDATE] Re: Update on ports on 10.0 X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Oct 2011 12:54:46 -0000 On Tue, 11 Oct 2011 08:36:03 +0200 Erwin Lansing wrote: > Since the release has been pushed back some more since the last mail, > we do have some time to test a possible fix for the issues we're > seeing with libtool on FreeBSD 10.0. However, fixing libtool is only > part of the problem as hundreds, if not thousands, of ports roll > their own detection and need to be fixed individually. We are > currently running a fixed libtool (ports/161404) to assess how many > ports are fixed by this patch and how many need to be patches > manually before deciding how to move forward. Other options include > the big find/grep/awk solution that has been posted several times and > fiddling with uname to go to FreeBSD 9.99 for a while, while ports > can be fixed. > > Hopefully, we can move forward in a day or two, but needless to say > this needs a lot of testing both on 10.0 and earlier releases so we > are sure we don't break backwards compatability, especially on 9.0 > that is soon to be released. For those that cannot wait a few days, > several patches have been proposed on the lists, of which dougb's > seems most complete, so I recommend applying one of those locally. > Please note that these are not tested widely and may break when the > final fix is committed. > > To conclude with some "fun" facts, only 232 ports break on HEAD > currently. Unfortunately, some of these are pretty high profile and > prevent almost 19.000 other ports from building, leaving only slighty > more than 3000 ports to build successfully. 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. Depending on this number and how long the whole process will take, we can decide what solution to adopt. If possible we'd like to avoid the big hammer of an uname fiddle or find/grep/sed/... (which most probably won't work for all ports anyway, irrespective of how smart it will be). If we need to adopt one of these hacks, it will be via some conditional KNOB in each port Makefile, in order to have an easy way to know which ports are fixed and which not, and an easy way to turn it off for test builds without it in the future. Basically we do not want to shove the dirt under the carpet, were it will rot for years. YOU can help by sending portmgr@ patches for above ports (or any other you know is broken) for the next -exp run. And PLEASE, pretty please once you have a patch that fixes this problem submit it upstream and bug upstream about it. (committers: please check this is the case when committing a patch from a PR). Thanks! -- IOnut