emacs-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#42948: closed ((wrap-program) bug)


From: GNU bug Tracking System
Subject: bug#42948: closed ((wrap-program) bug)
Date: Thu, 20 Aug 2020 16:58:01 +0000

Your message dated Thu, 20 Aug 2020 12:57:15 -0400
with message-id <5ECBDDD2-2FDC-4386-9564-8DF12218D0DB@lepiller.eu>
and subject line Re: bug#42948: (wrap-program) bug
has caused the debbugs.gnu.org bug report #42948,
regarding (wrap-program) bug
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs@gnu.org.)


-- 
42948: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=42948
GNU Bug Tracking System
Contact help-debbugs@gnu.org with problems
--- Begin Message --- Subject: (wrap-program) bug Date: Thu, 20 Aug 2020 17:44:01 +0545
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

Attachment: ruby-ronn-ng.patch
Description: Text Data

Attachment: ruby-ronn-ng.scm
Description: Text Data

Attachment: ruby-ronn-ng-standalone.scm
Description: Text Data


--- End Message ---
--- Begin Message --- Subject: Re: bug#42948: (wrap-program) bug Date: Thu, 20 Aug 2020 12:57:15 -0400 User-agent: K-9 Mail for Android 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@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

--- End Message ---

reply via email to

[Prev in Thread] Current Thread [Next in Thread]