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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 42948 in the body.
You can then email your comments to 42948 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

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

From: Prafulla Giri <pratheblackdiamond <at> gmail.com>
To: bug-guix <at> gnu.org
Subject: (wrap-program) bug
Date: Thu, 20 Aug 2020 17:44:01 +0545

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

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

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

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

[ruby-ronn-ng.scm (text/x-scheme, attachment)]

[ruby-ronn-ng-standalone.scm (text/x-scheme, attachment)]

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

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

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 #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)]

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

From: Julien Lepiller <julien <at> lepiller.eu>
To: Prafulla Giri <pratheblackdiamond <at> gmail.com>,42948-close <at> debbugs.gnu.org
Subject: Re: bug#42948: (wrap-program) bug
Date: Thu, 20 Aug 2020 12:57:15 -0400

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

I see you've posted your patch in another thread, so I'm closing this one as it was a false alarm. Thank you!

On 2020年8月20日 7:59:01 GMT-04:00, Prafulla Giri <pratheblackdiamond <at> gmail.com> wrote:
>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

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

Previous Next

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