Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Mark H Weaver]

kei@openmailbox.org (Kei Kebreau) writes:

> kkebreau pushed a commit to branch master
> in repository guix.
>
> commit 5143517c9969d17b48cbb60e1103633bc0cfb430
> Author: Kei Kebreau <kei@openmailbox.org>
> Date:   Fri Jul 7 22:58:27 2017 -0400
>
>     gnu: wxmaxima: Update to 17.05.0.
>     
>     * gnu/packages/maths.scm (wxmaxima): Update to 17.05.0.
>     [source]: Update URL and add file-name.
>     [native-inputs]: Add autoconf, automake and gettext-minimal.
>     [arguments]: Add 'autoconf' phase.

[...]

> @@ -2172,6 +2176,10 @@ point numbers.")
>         ("shared-mime-info" ,shared-mime-info)))
>      (arguments
>       `(#:phases (modify-phases %standard-phases
> +                  (add-before
> +                   'configure 'autoconf
> +                   (lambda _
> +                     (zero? (system* "./bootstrap"))))

In general, autoconf-style phases like this should be put after the
'unpack' phase, not before the 'configure' phase.  The reason is that on
some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
needs to be able to operate on the generated configure script.

When you move the phase earlier, you may then find that you need to
launch the 'bootstrap' script differently, because its shebang will not
be correct.  That's because it will now be run before the
'patch-source-shebangs' phase.

So, the way we normally do this is to run something like:

  (zero? (system* "sh" "bootstrap"))

Grepping for "add-before 'configure" reveals that there are now a rather
large number of instances of this problem.  Oh well.

       Mark

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 1938 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> kei@openmailbox.org (Kei Kebreau) writes:
>
>> kkebreau pushed a commit to branch master
>> in repository guix.
>>
>> commit 5143517c9969d17b48cbb60e1103633bc0cfb430
>> Author: Kei Kebreau <kei@openmailbox.org>
>> Date:   Fri Jul 7 22:58:27 2017 -0400
>>
>>     gnu: wxmaxima: Update to 17.05.0.
>>     
>>     * gnu/packages/maths.scm (wxmaxima): Update to 17.05.0.
>>     [source]: Update URL and add file-name.
>>     [native-inputs]: Add autoconf, automake and gettext-minimal.
>>     [arguments]: Add 'autoconf' phase.
>
> [...]
>
>> @@ -2172,6 +2176,10 @@ point numbers.")
>>         ("shared-mime-info" ,shared-mime-info)))
>>      (arguments
>>       `(#:phases (modify-phases %standard-phases
>> +                  (add-before
>> +                   'configure 'autoconf
>> +                   (lambda _
>> +                     (zero? (system* "./bootstrap"))))
>
> In general, autoconf-style phases like this should be put after the
> 'unpack' phase, not before the 'configure' phase.  The reason is that on
> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
> needs to be able to operate on the generated configure script.
>
> When you move the phase earlier, you may then find that you need to
> launch the 'bootstrap' script differently, because its shebang will not
> be correct.  That's because it will now be run before the
> 'patch-source-shebangs' phase.
>
> So, the way we normally do this is to run something like:
>
>   (zero? (system* "sh" "bootstrap"))
>
> Grepping for "add-before 'configure" reveals that there are now a rather
> large number of instances of this problem.  Oh well.
>
>        Mark

I see. Thank you for the correction.

Do you consider it worth going through the package code and patching
this problem specifically or should it be corrected gradually while
making other changes?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Mark H Weaver]

Kei Kebreau <kei@openmailbox.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> kei@openmailbox.org (Kei Kebreau) writes:
>>
>>> @@ -2172,6 +2176,10 @@ point numbers.")
>>>         ("shared-mime-info" ,shared-mime-info)))
>>>      (arguments
>>>       `(#:phases (modify-phases %standard-phases
>>> +                  (add-before
>>> +                   'configure 'autoconf
>>> +                   (lambda _
>>> +                     (zero? (system* "./bootstrap"))))
>>
>> In general, autoconf-style phases like this should be put after the
>> 'unpack' phase, not before the 'configure' phase.  The reason is that on
>> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
>> needs to be able to operate on the generated configure script.
>>
>> When you move the phase earlier, you may then find that you need to
>> launch the 'bootstrap' script differently, because its shebang will not
>> be correct.  That's because it will now be run before the
>> 'patch-source-shebangs' phase.
>>
>> So, the way we normally do this is to run something like:
>>
>>   (zero? (system* "sh" "bootstrap"))
>>
>> Grepping for "add-before 'configure" reveals that there are now a rather
>> large number of instances of this problem.  Oh well.
>>
>>        Mark
>
> I see. Thank you for the correction.
>
> Do you consider it worth going through the package code and patching
> this problem specifically or should it be corrected gradually while
> making other changes?

If you (or anyone else) is willing to work on this, I think it would be
quite helpful to go through and fix some or all of these problems
proactively.  It's quite common for people to look at existing packages
for examples of how things should be done, so the presence of these
mistakes in our tree will spawn new instances of the same mistake until
they are eradicated :)

Two things to keep in mind:

* If changing a package would trigger a large number of rebuilds, the
  change should be made on 'core-updates' instead.

* For each change on 'master', we should make sure the package still
  builds successfully before pushing it.  That should be enough testing
  for kind of change.

     Thanks!
       Mark

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Kei Kebreau]

[-- Attachment #1: Type: text/plain, Size: 2410 bytes --]

Mark H Weaver <mhw@netris.org> writes:

> Kei Kebreau <kei@openmailbox.org> writes:
>
>> Mark H Weaver <mhw@netris.org> writes:
>>
>>> kei@openmailbox.org (Kei Kebreau) writes:
>>>
>>>> @@ -2172,6 +2176,10 @@ point numbers.")
>>>>         ("shared-mime-info" ,shared-mime-info)))
>>>>      (arguments
>>>>       `(#:phases (modify-phases %standard-phases
>>>> +                  (add-before
>>>> +                   'configure 'autoconf
>>>> +                   (lambda _
>>>> +                     (zero? (system* "./bootstrap"))))
>>>
>>> In general, autoconf-style phases like this should be put after the
>>> 'unpack' phase, not before the 'configure' phase.  The reason is that on
>>> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
>>> needs to be able to operate on the generated configure script.
>>>
>>> When you move the phase earlier, you may then find that you need to
>>> launch the 'bootstrap' script differently, because its shebang will not
>>> be correct.  That's because it will now be run before the
>>> 'patch-source-shebangs' phase.
>>>
>>> So, the way we normally do this is to run something like:
>>>
>>>   (zero? (system* "sh" "bootstrap"))
>>>
>>> Grepping for "add-before 'configure" reveals that there are now a rather
>>> large number of instances of this problem.  Oh well.
>>>
>>>        Mark
>>
>> I see. Thank you for the correction.
>>
>> Do you consider it worth going through the package code and patching
>> this problem specifically or should it be corrected gradually while
>> making other changes?
>
> If you (or anyone else) is willing to work on this, I think it would be
> quite helpful to go through and fix some or all of these problems
> proactively.  It's quite common for people to look at existing packages
> for examples of how things should be done, so the presence of these
> mistakes in our tree will spawn new instances of the same mistake until
> they are eradicated :)
>
> Two things to keep in mind:
>
> * If changing a package would trigger a large number of rebuilds, the
>   change should be made on 'core-updates' instead.
>
> * For each change on 'master', we should make sure the package still
>   builds successfully before pushing it.  That should be enough testing
>   for kind of change.
>
>      Thanks!
>        Mark

I'm leaving this message here to let everyone on the list know that this
patch is being worked on. :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

Re: 01/01: gnu: wxmaxima: Update to 17.05.0.

[Mark H Weaver]

Kei Kebreau <kei@openmailbox.org> writes:

> Mark H Weaver <mhw@netris.org> writes:
>
>> Kei Kebreau <kei@openmailbox.org> writes:
>>
>>> Mark H Weaver <mhw@netris.org> writes:
>>>
>>>> kei@openmailbox.org (Kei Kebreau) writes:
>>>>
>>>>> @@ -2172,6 +2176,10 @@ point numbers.")
>>>>>         ("shared-mime-info" ,shared-mime-info)))
>>>>>      (arguments
>>>>>       `(#:phases (modify-phases %standard-phases
>>>>> +                  (add-before
>>>>> +                   'configure 'autoconf
>>>>> +                   (lambda _
>>>>> +                     (zero? (system* "./bootstrap"))))
>>>>
>>>> In general, autoconf-style phases like this should be put after the
>>>> 'unpack' phase, not before the 'configure' phase.  The reason is that on
>>>> some platforms (e.g. mips64el-linux), the 'patch-usr-bin-file' phase
>>>> needs to be able to operate on the generated configure script.
>>>>
>>>> When you move the phase earlier, you may then find that you need to
>>>> launch the 'bootstrap' script differently, because its shebang will not
>>>> be correct.  That's because it will now be run before the
>>>> 'patch-source-shebangs' phase.
>>>>
>>>> So, the way we normally do this is to run something like:
>>>>
>>>>   (zero? (system* "sh" "bootstrap"))
>>>>
>>>> Grepping for "add-before 'configure" reveals that there are now a rather
>>>> large number of instances of this problem.  Oh well.
>>>>
>>>>        Mark
>>>
>>> I see. Thank you for the correction.
>>>
>>> Do you consider it worth going through the package code and patching
>>> this problem specifically or should it be corrected gradually while
>>> making other changes?
>>
>> If you (or anyone else) is willing to work on this, I think it would be
>> quite helpful to go through and fix some or all of these problems
>> proactively.  It's quite common for people to look at existing packages
>> for examples of how things should be done, so the presence of these
>> mistakes in our tree will spawn new instances of the same mistake until
>> they are eradicated :)
>>
>> Two things to keep in mind:
>>
>> * If changing a package would trigger a large number of rebuilds, the
>>   change should be made on 'core-updates' instead.
>>
>> * For each change on 'master', we should make sure the package still
>>   builds successfully before pushing it.  That should be enough testing
>>   for kind of change.
>>
>>      Thanks!
>>        Mark
>
> I'm leaving this message here to let everyone on the list know that this
> patch is being worked on. :-)

Excellent, thank you!

At this point, you should probably do this work on core-updates.

     Thanks,
       Mark