From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mark H Weaver Subject: Re: [PATCH] gnu: Add ruby 1.8.7 Date: Mon, 27 Oct 2014 00:11:44 -0400 Message-ID: <87k33m179b.fsf@netris.org> References: <20141026203111.GA20849@thebird.nl> <87wq7mpfs0.fsf@yeeloong.lan> <20141026234436.GA21721@thebird.nl> <87siiap9s5.fsf@yeeloong.lan> <20141027015650.GB21971@thebird.nl> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:46417) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xibev-0000XC-Qg for guix-devel@gnu.org; Mon, 27 Oct 2014 00:12:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xibeq-0007cE-GO for guix-devel@gnu.org; Mon, 27 Oct 2014 00:11:57 -0400 Received: from world.peace.net ([96.39.62.75]:49145) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xibeq-0007c8-CY for guix-devel@gnu.org; Mon, 27 Oct 2014 00:11:52 -0400 In-Reply-To: <20141027015650.GB21971@thebird.nl> (Pjotr Prins's message of "Mon, 27 Oct 2014 02:56:50 +0100") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org To: Pjotr Prins Cc: guix-devel@gnu.org Pjotr Prins writes: > On Sun, Oct 26, 2014 at 09:43:22PM -0400, Mark H Weaver wrote: >> In broad strokes, we use the GNU changelog conventions: >> >> http://www.gnu.org/prep/standards/html_node/Change-Logs.html >> >> but with some minor formatting differences. However, the best thing is >> to look in the commit history for examples close to what you're doing. >> >> There is brief mention of this in the "Submitting Patches" section of >> the HACKING file in the source tree. > > I read those earlier. I used a commit message we used before. I think > that if you are serious about convention you should point to a real > list of allowed standard messages. The commit log is full of examples, but I agree that it would be good to have more documentation on this. There's a lot to do, and we're a small team. > Now it looks arbitrary and makes the submitter look stupid. I agree that the conventions are arbitrary, and could probably use improvement, but I also think there's some value in keeping things consistent. I don't think it makes you look stupid. I'm sorry if I came off that way. >> >> It looks like the 'native-search-paths' field needs to be overridden, >> >> since the existing one has "2.1.3" in it. >> > >> > I don't think it is used by 1.8.7. Does that matter? >> >> Yes, otherwise users who install ruby 1.8.7 will be advised to set >> GEM_PATH to $HOME/.guix-profile/lib/ruby/gems/2.1.3. > > Ah, that is what it is for. Actually the build did not give me that > message. The message is supposed to be shown when you install the package using "guix package -i", but I see that it wasn't working. The reason is that "lib/ruby/gems/2.1.3" doesn't actually exist in the built ruby package. Instead, there's "lib/ruby/gems/2.1.0". I guess that should be fixed in a separate commit. If the search-path-specification contains a directory that exists and is not already in your GEM_PATH, you should see the message when you install ruby, or when you run "guix package --search-paths". > I DO get a load of messages such as > > strip:/gnu/store/icz59y35qqmm4jcrnkqx7d73xlzsq0lq-ruby-1.8.7-p374/lib/ruby/1.8/rexml/attlistdecl.rb: > File format not recognized > > is there a way to prevent files with a .rb extension or ruby shebang > to be stripped? In theory the default 'strip' phase could be replaced by one that's more selective, but please don't do that. The problem happens in almost every package, so the improvements should be made in the default 'strip' phase. The relevant procedure is 'strip' in guix/build/gnu-build-system.scm, but beware that changing that file (or just about anything else in that directory) will trigger a full rebuild of all packages. It would be nice to do at some point, but it's quite far down on our TODO list. Regards, Mark