GNU bug report logs - #42948
(wrap-program) bug

Previous Next

Full log

Message #11 received at 42948 <at> debbugs.gnu.org (full text, mbox):

From: Prafulla Giri <pratheblackdiamond <at> gmail.com>
To: Julien Lepiller <julien <at> lepiller.eu>
Cc: 42948 <at> debbugs.gnu.org
Subject: Re: bug#42948: (wrap-program) bug
Date: Thu, 20 Aug 2020 21:00:29 +0545

[Message part 1 (text/plain, inline)]

Yes, you are correct. This turned out to be a false alarm. I poked around
with the definition, and, just like you said, everything works.

`ronn` not running was a gempspec issue that I have resolved in the package
definition (patch attached).

Thank you very much for clearing the matter out!

On Thu, Aug 20, 2020 at 6:17 PM Julien Lepiller <julien <at> lepiller.eu> wrote:

> Le Thu, 20 Aug 2020 17:44:01 +0545,
> Prafulla Giri <pratheblackdiamond <at> gmail.com> a écrit :
>
> > Esteemed maintainers,
> >
> > It seems that (wrap-program ...) over-writes the previous wrapping of
> > a package done by the build system.
> >
> > This does not happen for many (wrap-programs) called in the
> > modify-phases section of the package definition itself.
> >
> > Attached is a package definition for ruby-ronn-ng, that demonstrates
> > this issue. The custom (wrap-program)-s
> > called from the package definition seem to over-write the definitions
> > of GEM_ENV as made by the 'wrap %standard-phase
> > of the ruby-build system.
> > The wrappings made by 'wrap %standard-phase can be seen during the
> > custom 'DEBUG phase. The subsequent 'wrap-program1
> > and 'wrap-program2 add more environment variables to the wrapping,
> > but on checking the contents of `which ronn`, once
> > it is installed (using `less $(which ronn)`), it can be verified that
> > the GEM_ENV package definitions have been overwritten.
> >
> > This may just be a ruby-build-system issue. Or perhaps it might be
> > something that permeates over a few more build systems.
> > That still remains to be tested.
> >
> > Attached are a few different versions of the package definitions for
> > ruby-ronn-ng for the ease of those who would like to
> > verify this.
> > 1. ruby-ronn-ng-standalone.scm : To be tested using `guix
> > time-machine -- build --verbosity=2
> > --file=ruby-ronn-ng-standalone.scm`[1] 2. ruby-ronn-ng.scm : To be
> > appended to the end of the gnu/packages/ruby.scm file in local guix
> > checkout, and be tested using the local version
> > 3. ruby-ronn-ng.patch : To be applied to local guix checkout
> >
> > [1] - This package definition needs ruby-mustache, which has only
> > recently been added to guix. Hence, the time-machine.
> >
> > NOTE: `ronn` does not work even with `propagated-inputs`. See this
> > patch as to why:
> >
> https://aur.archlinux.org/cgit/aur.git/tree/0001-allow-mustache-1.0.patch?h=ruby-ronn-ng
>
> Hi,
>
> From what I see, there is no issue here (unless I'm missing something).
> In the built package, I see bin/ronn is a shell wrapper that defines
> the PATH and FOO environment variables and calls bin/.ronn-real.
> bin/.ronn-real itself is a ruby script that defines GEM_PATH and calls
> bin/.real/ronn, which is the actual program.
>
> I don't see anything wrong with that, but I'm not a ruby expert. In
> fact, when running ronn (from its store path directly), I see the
> following error:
>
>
> /gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/2.6.0/rubygems/dependency.rb:313:in
> `to_specs': Could not find 'mustache' (>= 0.7.0, ~> 0.7) - did find:
> [mustache-1.1.1] (Gem::MissingSpecVersionError) Checked in
>
> 'GEM_PATH=/gnu/store/l8jicf1ibzrgff754mvbc5k14fa62s7a-ruby-ronn-ng-0.9.1/lib/ruby/vendor_ruby:/gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/vendor_ruby:/gnu/store/w1a9ndhvvbw76g19fgx4j78kx3aghi4k-ruby-kramdown-2.3.0/lib/ruby/vendor_ruby:/gnu/store/jfbzrfd7i8x46q9c8sw26av6kx7jyr3c-ruby-mustache-1.1.1/lib/ruby/vendor_ruby:/gnu/store/0wsy4yymr5m0wzms0qv5ak5q21g8c6hs-ruby-nokogiri-1.10.9/lib/ruby/vendor_ruby:/gnu/store/7ncf7v5prhv4ir8bgdlxa1rz8ph5mlry-ruby-pkg-config-1.2.5/lib/ruby/vendor_ruby:/gnu/store/924np2k8f04lfjr6l9hzic7drah8bgbb-ruby-mini-portile-2.4.0/lib/ruby/vendor_ruby:/gnu/store/9yqh0g1p5bmxar8dlfp84j4py3j631jv-ruby-2.6.5/lib/ruby/gems/2.6.0',
> execute `gem env` for more information
>
> which suggests that the GEM_PATH is set correctly (after all it found
> mustache), but the dependencies do not have the expected version. Does
> that make sense?
>

[Message part 2 (text/html, inline)]

[ronn-ng-working.patch (text/x-patch, attachment)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.