Re: linux-ppc harfbuzz GUB build error

[Hans Aikema]

> On 22 Dec 2016, at 18:20, Hans Aikema <address@hidden> wrote:
> 
> 
>> On 22 Dec 2016, at 14:05, Masamichi Hosoda <address@hidden> wrote:
>> 
>>>>>> In my environments, autoconf does not raise such error.
>>>>>> Do you set the "set -u" or "set -o nounset" somewhere?
>>>>>> If so, would you remove the setting?
>>>>> The set -u (or to be complete set -ux) I discovered inside
>>>>> 
>>>>> /home/gub/gub/target/freebsd-x86/src/lilypond-git.sv.gnu.org--lilypond.git-master/smart-configure.sh
>>>>> 
>>>>> which was the command that was called when the error was signalled
>>>> 
>>>> I've noticed that smart-autogen.sh has "set -ux" and it is invoked from 
>>>> GUB.
>>>> If I understand correctly, "set -u" and "set -x" etc. do not carry over
>>>> into child processes.
>>>> 
>>>> However, at least in your log file,
>>>> "set -x" seems to be carried over to the child process.
>>>> From smart-autogen.sh through autogen.sh to autoconf,
>>>> all scripts are setted trace mode.
>>>> 
>>> [...snip...]
>>>> 
>>>> Perhaps, also "set -u" is carried over in your environment
>>>> and it is not carried over in my environment.
>>>> 
>>>> I have no idea.
>>>> But, in CentOS, /bin/sh is symbolic link to bash,
>>>> whereas in Ubuntu, /bin/sh is dash.
>>>> I think that this difference is influenced.
>>> 
>>> Anyway, I've noticed that if the environment variable SHELLOPTS exists,
>>> "set -ux" and "set -e" carry over to the child processes.
>>> There may be other conditions that it carries over.
>>> 
>>> In order to avoid this issue,
>>> there is a way to "set +ux" before invoking the child process.
>>> So I've created a patch for LilyPond's smart-autogen.sh and 
>>> smart-configure.sh.
>>> 
>>> https://sourceforge.net/p/testlilyissues/issues/5013/
>>> https://codereview.appspot.com/319870043/
>> 
>> It has been merged.
>> Probably the issue on CentOS has been solved.
> 
> Retrying a CentOS build alongside trial-and-error builds with minimal Ubuntu 
> environment
> My current minimal ubuntu-based build is running the base dockerized 
> ubuntu:xenial image extended with
>        g++-multilib  \
>        git  \
>        ca-certificates  \
>        zip  \
>        unzip  \
>        make  \
>        python  \
>        file  \
>        xz-utils  \
>        gettext  \
>        curl  \
>        p7zip-full  \
>        texlive-xetex \
> 
> might still need more packages before it’s up and running
> 
> The ubuntu minimal environment builds alread led to a couple of updates in my 
> gub fork (https://github.com/aikebah/gub) for URLs that are wget-able, but 
> not curl-able as curl is not following the http 301 moved permanently 
> redirects (at least python.org and freedesktop.org …. new minimal ubuntu 
> build running to see if more packages fail the bootstrap when only curl is 
> available.
> 
> once I pass the gub bootstrap I’ll create a pull-request for the URL updates
> 
Note: my assumption was that it is a curl vs wget availability issue that 
caused my HTTPError() on download, but upon further inspection it seems a 
python library that is used for the downloads…. no clue yet why on my system it 
failes for HTTP 301-ed URL, whereas it apparently works fine for others. Could 
this be related to python-version of the host on which gub is running?