From owner-freebsd-ports@FreeBSD.ORG Sat Feb 8 13:25:28 2014 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DEBB8F14 for ; Sat, 8 Feb 2014 13:25:27 +0000 (UTC) Received: from mail.modirum.com (mail.modirum.com [31.185.27.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 738131B55 for ; Sat, 8 Feb 2014 13:25:26 +0000 (UTC) Received: from [77.87.241.103] (helo=unknown) by mail.modirum.com with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1WC7uE-0005Wn-Nk for freebsd-ports@freebsd.org; Sat, 08 Feb 2014 13:25:14 +0000 Date: Sat, 8 Feb 2014 14:25:24 +0100 From: Matthew Rezny To: freebsd-ports@freebsd.org Subject: Re: WARNING: devel/icu: recent update redners openldap-server and other ports unusable! Message-ID: <20140208142524.0000138a@unknown> Organization: RezTek, s.r.o. X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) In-Reply-To: <20140208012308.GF80056@ithaqua.etoilebsd.net> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SA-Authenticated: Yes X-SA-Exim-Connect-IP: 77.87.241.103 X-SA-Exim-Mail-From: matthew@reztek.cz X-SA-Exim-Scanned: No (on mail.modirum.com); SAEximRunCond expanded to false X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Feb 2014 13:25:28 -0000 > On Fri, Feb 07, 2014 at 10:54:45PM +0100, O. Hartmann wrote: > > > > Today a couple of updates has been introduced, one of them was an > > update of port devel/icu. > > > > I the good manner/tradition of updating UPDATING, I expect a > > warning/hint/advice a couple of days from now - when everybody has > > already stepped into the mess. > > > > On several boxes running 11.0-CURRENT and 9.2-STABLE, updating ports > > including devel/icu renders many ports unusable due to a library > > version bump in libicu. > > > > After updating ports relying on devel/icu via > > > > portmaster -r devel/icu > > > > and the updating of port > > > > net/openldap24-server > > > > (which is openldap-sasl-server in my case), OpenLDAP doesn't start > > anymore on all boxes affected by the update of devel/icu! > > > > I always get the error > > > > 52f5551f hdb_db_init: Initializing HDB database > > 52f5551f olcDbDirectory: value #0: invalid path: Permission denied > > 52f5551f config error processing olcDatabase={1}hdb,cn=config: > > olcDbDirectory: value #0: invalid path: Permission denied 52f5551f > > send_ldap_result: conn=-1 op=0 p=0 52f5551f slapd destroy: freeing > > system resources. 52f5551f syncinfo_free: rid=001 > > 52f5551f slapd stopped. > > 52f5551f connections_destroy: nothing to destroy. > > /usr/local/etc/rc.d/slapd: WARNING: failed to start slapd > > > > > > This obscure > > > > olcDbDirectory: value #0: invalid path: Permission denied > > > > is not obvious to me. The server ran minutes ago BEFORE the update, > > the directories containing the DB5 databases have all the correct > > ownership (ldap:ldap, I suspected first a misconfiguration as this > > error seems typical for a misconfiguration of the ownership). > > > > Does anyone see the same problem? And maybe please would put out > > some notes in UPDATING within a considerable narrow timeframe > > regarding devel/icu! It seems, FreeBSD's ports systems get more and > > more messy. > > > > oh > > devel/icu has nothing to do with openldap, neither with one of > openldap dependency. > > Have you checked the full path to the said DB5 databases and not only > the directory containing those files? > > regards, > Bapt If glib is compiled with the collation fix, it links against icu, thus any port which depends on glib also depends on icu. The update to devel/icu has made quite a mess of one of my systems when it took me by surprise yesterday as well. There are multiple stumbling blocks along the way. glib20 won't build if libiconv is installed from ports. Uninstalling the libiconv port allows glib20 to build against iconv in base. There is a PR with a not yet committed patch that should workaround this. net/avahi-app can't properly upgrade. The port builds libavahi-glib.so and then immediately tries to link against the lib of the same name that is installed rather than the one that was just built. The installed version of that library is linked against old icu which doesn't exist so the link fails. Uninstalling avahi-app first forces the build to use the library compiled against current icu. This is a bug in the port. There was also a problem with hal, which was the tip of the iceburg I hit, but I relieved myself of the dependency on hal before I realized I had a much bigger problem and many ports to rebuild. I did not revisit hal to see if it would build correct after glib was rebuilt against icu, or if it too needed some extra step. Without any entry in UPDATING, I was facing linking problems against glib that didn't make any sense. Current version of glib was installed and the missing symbols weren't even really from glib. It was only when I finally ran pkg_libchk and saw the huge mess of things that wanted libicu.so.50 that the picture finally became clear. Looking at the history of both devel/icu and UPDATING, I see that for the 4.6 and 4.8 updates there was an entry directing users to run portmaster -r icu, but for 5.0 and 5.2 updates there is not entry, so this is the second time there has been an icu bump without any advisory in UPDATING. Please do not neglect this step up when updating ports.