From owner-freebsd-gecko@FreeBSD.ORG Sun Apr 7 13:00:03 2013 Return-Path: Delivered-To: gecko@smarthost.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id DC0708E4 for ; Sun, 7 Apr 2013 13:00:03 +0000 (UTC) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id CF682B20 for ; Sun, 7 Apr 2013 13:00:03 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.6/8.14.6) with ESMTP id r37D001E099436 for ; Sun, 7 Apr 2013 13:00:00 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.6/8.14.6/Submit) id r37D00FM099435; Sun, 7 Apr 2013 13:00:00 GMT (envelope-from gnats) Date: Sun, 7 Apr 2013 13:00:00 GMT Message-Id: <201304071300.r37D00FM099435@freefall.freebsd.org> To: gecko@FreeBSD.org From: Jan Beich Subject: Re: ports/177644: building mail/thunderbird fails X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: Jan Beich List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Apr 2013 13:00:03 -0000 The following reply was made to PR ports/177644; it has been noted by GNATS. From: Jan Beich To: Tsurutani Naoki Cc: bug-followup@freebsd.org Subject: Re: ports/177644: building mail/thunderbird fails Date: Sun, 07 Apr 2013 15:52:41 +0300 Tsurutani Naoki writes: > I am very sorry, for I missed the message. > I thought no significant change is applied to the minor release. Some 8.2 workarounds were actually used by 7.x which meant they couldn't have been dropped at esr17 branch point. And extending the support for 7.x/8.2 until esr24 in September was extra maintainance without pointyhat (or portmgr) help. > I do not want to update my OS, for I am apprehensive that the result > of some important > calculation might be effected. If it would not happen, I can update > to recent 8-STABLE... There're a few more ways out: 1/ apply the pointed out base commits and run regression tests 2/ revert the pointed out gecko commits and partly maintain yourself 3/ be paranoiac and not update at all Exactly why ports updates or operator running unrelated software cannot alter the calculation results is smth missing from the context.