From owner-freebsd-arch@FreeBSD.ORG Wed Feb 15 22:28:09 2012 Return-Path: Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2B6C106564A; Wed, 15 Feb 2012 22:28:09 +0000 (UTC) (envelope-from gabor@FreeBSD.org) Received: from server.mypc.hu (server.mypc.hu [87.229.73.95]) by mx1.freebsd.org (Postfix) with ESMTP id 3622B8FC17; Wed, 15 Feb 2012 22:28:09 +0000 (UTC) Received: from server.mypc.hu (localhost [127.0.0.1]) by server.mypc.hu (Postfix) with ESMTP id 14DCD14E6D22; Wed, 15 Feb 2012 23:09:54 +0100 (CET) X-Virus-Scanned: amavisd-new at server.mypc.hu Received: from server.mypc.hu ([127.0.0.1]) by server.mypc.hu (server.mypc.hu [127.0.0.1]) (amavisd-new, port 10024) with LMTP id RhzvfDVn87E4; Wed, 15 Feb 2012 23:09:52 +0100 (CET) Received: from [192.168.1.117] (catv-80-98-232-12.catv.broadband.hu [80.98.232.12]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by server.mypc.hu (Postfix) with ESMTPSA id 1007914E6CF4; Wed, 15 Feb 2012 23:09:52 +0100 (CET) Message-ID: <4F3C2D2D.5000402@FreeBSD.org> Date: Wed, 15 Feb 2012 23:09:49 +0100 From: Gabor Kovesdan User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0a2) Gecko/20111124 Thunderbird/10.0a2 MIME-Version: 1.0 To: Andriy Gapon References: <4F3C28DD.1020003@FreeBSD.org> In-Reply-To: <4F3C28DD.1020003@FreeBSD.org> Content-Type: text/plain; charset=x-viet-vps; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arch@FreeBSD.org Subject: Re: bsd/citrus iconv X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 22:28:09 -0000 On 2012.02.15. 22:51, Andriy Gapon wrote: > maybe we could already start building bsd/citrus iconv and using it for > something instead of just having it in the tree? > Maybe initially without exposing the lib to anything outside the base system > (ports), just using it for things in the base system like libkiconv... It would be nice but there are some known bugs in iconv, which I haven't addressed yet. I have it on my TODO list but at the moment I'm working on the regex code and I'd like to bring it to a good shape so that people can start to test it and provide feedback while I work on iconv. Also, it is not really possible to avoid exposing it. Configure scripts are quite diverse and some ports will fail with this implementation. This has to be investigated as well. The best would be to fix the problem and provide higher compatibility. So I definitely think it should be opt-in for some time more until I can address those problems. Or if there are volunteers I can give a list of known bugs / issues. Gabor