From owner-freebsd-ports@freebsd.org Sun Jan 17 05:58:10 2016 Return-Path: Delivered-To: freebsd-ports@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A4668A6DAFA for ; Sun, 17 Jan 2016 05:58:10 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from mouf.net (mouf.net [IPv6:2607:fc50:0:4400:216:3eff:fe69:33b3]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "mouf.net", Issuer "mouf.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 564BD1CEC for ; Sun, 17 Jan 2016 05:58:10 +0000 (UTC) (envelope-from swills@FreeBSD.org) Received: from [0.0.0.0] (cpe-071-065-239-148.nc.res.rr.com [71.65.239.148] (may be forged)) (authenticated bits=0) by mouf.net (8.14.9/8.14.9) with ESMTP id u0H5vwMC032695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 17 Jan 2016 05:58:04 GMT (envelope-from swills@FreeBSD.org) Subject: Re: Rubygem .js files fubar? To: Matthew Seaman , freebsd-ports@freebsd.org References: <5693DB57.7090407@freebsd.org> <5694DF6C.3000204@infracaninophile.co.uk> From: Steve Wills X-Enigmail-Draft-Status: N1110 Message-ID: <569B2D66.2070006@FreeBSD.org> Date: Sun, 17 Jan 2016 00:57:58 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0 MIME-Version: 1.0 In-Reply-To: <5694DF6C.3000204@infracaninophile.co.uk> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mouf.net [199.48.129.64]); Sun, 17 Jan 2016 05:58:05 +0000 (UTC) X-Virus-Scanned: clamav-milter 0.99 at mouf.net X-Virus-Status: Clean X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jan 2016 05:58:10 -0000 Hi, On 01/12/16 06:11 AM, Matthew Seaman wrote: > On 01/11/16 16:41, Matthew Seaman wrote: >> lucid-nonsense:...svn2git-2.3.2/rdoc/js:% ls -la >> total 140 >> drwxr-xr-x 2 matthew wheel 576 Jan 11 16:20 ./ >> drwxr-xr-x 7 matthew wheel 640 Jan 11 13:01 ../ >> -rw-r--r-- 1 matthew wheel 4666 Jan 11 13:01 darkfish.js >> -rw-r--r-- 1 matthew wheel 91669 Jan 11 13:01 jquery.js >> -rw-r--r-- 1 matthew wheel 3663 Jan 11 13:01 navigation.js >> -rw-r--r-- 1 matthew wheel 1127 Jan 11 13:01 navigation.js.gz >> -rw-r--r-- 1 matthew wheel 2992 Jan 11 13:01 search.js >> -rw-r--r-- 1 matthew wheel 3310 Jan 11 13:01 search_index.js >> -rw-r--r-- 1 matthew wheel 920 Jan 11 13:01 search_index.js.gz >> -rw-r--r-- 1 matthew wheel 6603 Jan 11 13:01 searcher.js >> -rw-r--r-- 1 matthew wheel 1791 Jan 11 13:01 searcher.js.gz >> >> As far as I can tell these are boilerplate installed by something to do >> with rdoc. A quick find(1) over my /usr/local/lib/ruby shows this same >> pattern in a number of installed rubygems. >> >> What's going on here? >> >> This makes poudriere sad, although the error message doesn't say >> anything about "I can't decompress this, because there's already a >> decompressed copy in the way" instead claiming the .gz files refer to >> some path under staging. > > So, it seems this affects every rubygem port -- there's compressed and > uncompressed copies of the same files installed for each and every gem. > And they all fail 'poudriere testport'. I can't recall all the details as it's been a while since I looked at this, but basically the original file name is getting stored in the .gz file (see gzip's -n flag). Fixing this will take patching ruby's ext/zlib/zlib.c. (rubygem is just calling that.) I've looked at patching this, but not completed it. I'll try to work on it some more. As for why the original file isn't deleted, I'm not sure. I don't see this in my local tree, but I have some changes that may be masking it. Poudriere is just grepping files for references to the wrkdir path and finding them. > Given that, I think I'll commit rubygem-svn2git as it seems to be > working at least as well as any other rubygem port. > This is fine. Steve