[gentoo-user] nonfatal() not supported error in glibc binary install

[gentoo-user] nonfatal() not supported error in glibc binary install

[Bruce Schultz]

Hi,

I'm trying to update a system using binary packages build on another 
system. I get this error for glibc:

  >>> Emerging binary (1 of 1) sys-libs/glibc-2.19-r1::gentoo
  * glibc-2.19-r1.tbz2 MD5 SHA1 size ;-) 
...                              [ ok ]
  >>> Extracting info

  >>> Failed to emerge sys-libs/glibc-2.19-r1, Log file:

  >>> '/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/build.log'

  * Messages for package sys-libs/glibc-2.19-r1:

  * ERROR: sys-libs/glibc-2.19-r1::gentoo failed (setup phase):
  *   nonfatal() not supported in this EAPI
  *
  * Call stack:
  *               ebuild.sh, line   93:  Called pkg_setup
  *             environment, line 2870:  Called eblit-run 'pkg_setup'
  *             environment, line  987:  Called eblit-glibc-pkg_setup
  *             environment, line  843:  Called glibc_run_test '#include 
<pwd.h>
  * int main(){return getpwuid(0)==0;}
  * '
  *             environment, line 2085:  Called glibc_compile_test '' 
'#include <pwd.h>
  * int main(){return getpwuid(0)==0;}
  * '
  *             environment, line 1998:  Called nonfatal 'emake' '-s' 
'glibc-test'
  *   isolated-functions.sh, line   92:  Called die
  * The specific snippet of code:
  *              die "$FUNCNAME() not supported in this EAPI"
  *
  * If you need support, post the output of `emerge --info 
'=sys-libs/glibc-2.19-r1::gentoo'`,
  * the complete build log and the output of `emerge -pqv 
'=sys-libs/glibc-2.19-r1::gentoo'`.
  * The complete build log is located at 
'/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/build.log'.
  * The ebuild environment file is located at 
'/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/environment'.
  * Working directory: '/var/tmp/portage/sys-libs/glibc-2.19-r1/temp'
  * S: '/var/tmp/portage/sys-libs/glibc-2.19-r1/work/glibc-2.19'


The build log is mostly useless:
cat /var/tmp/portage/sys-libs/glibc-2.19-r1/temp/build.log
  >>> Extracting info
  * Package:    sys-libs/glibc-2.19-r1
  * Repository: gentoo
  * USE:        hardened elibc_glibc amd64 abi_x86_64 userland_GNU 
kernel_linux
  * FEATURES:   preserve-libs sandbox userpriv usersandbox


I've tried updating to the latest portage (2.2.14_rc1) on both systems 
involved, but that doesn't help.

Also, it fails with the same error with emerge -k on the system that 
built the package.

It's currently compiling on my target system, so its not something 
that's blocking me, but I suspect its a bug in the ebuild or portage. 
Googling the error messages hasn't found anything revealing. Has anyone 
else come across this? Any suggestions on what to do about it?

Cheers
Bruce
--
:b

[gentoo-user] Re: nonfatal() not supported error in glibc binary install

[walt]

On 10/04/2014 09:15 PM, Bruce Schultz wrote:
> Hi,
> 
> I'm trying to update a system using binary packages build on another system. I get this error for glibc:
> 
>  >>> Emerging binary (1 of 1) sys-libs/glibc-2.19-r1::gentoo
>  * glibc-2.19-r1.tbz2 MD5 SHA1 size ;-) ...                              [ ok ]
>  >>> Extracting info
> 
>  >>> Failed to emerge sys-libs/glibc-2.19-r1, Log file:
> 
>  >>> '/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/build.log'
> 
>  * Messages for package sys-libs/glibc-2.19-r1:
> 
>  * ERROR: sys-libs/glibc-2.19-r1::gentoo failed (setup phase):
>  *   nonfatal() not supported in this EAPI
>  *
>  * Call stack:
>  *               ebuild.sh, line   93:  Called pkg_setup
>  *             environment, line 2870:  Called eblit-run 'pkg_setup'
>  *             environment, line  987:  Called eblit-glibc-pkg_setup
>  *             environment, line  843:  Called glibc_run_test '#include <pwd.h>
>  * int main(){return getpwuid(0)==0;}
>  * '
>  *             environment, line 2085:  Called glibc_compile_test '' '#include <pwd.h>
>  * int main(){return getpwuid(0)==0;}
>  * '
>  *             environment, line 1998:  Called nonfatal 'emake' '-s' 'glibc-test'
>  *   isolated-functions.sh, line   92:  Called die
>  * The specific snippet of code:
>  *   
          die "$FUNCNAME() not supported in this EAPI"

I have isolated-functions.sh in two places:

/usr/lib64/portage/python2.7/isolated-functions.sh
/usr/lib64/portage/python3.3/isolated-functions.sh
but not in /usr/lib64/portage/python3.4 (which I didn't know was installed til now)

You might want to check the target machine for which version of python it's using
and that it has the latest version of portage in /usr/lib/portage/pythonN.N/

Maybe running python-updater would help?

Re: [gentoo-user] Re: nonfatal() not supported error in glibc binary install

[Bruce Schultz]

On 06/10/14 00:05, walt wrote:
> On 10/04/2014 09:15 PM, Bruce Schultz wrote:
>> Hi,
>>
>> I'm trying to update a system using binary packages build on another system. I get this error for glibc:
>>
>>   >>> Emerging binary (1 of 1) sys-libs/glibc-2.19-r1::gentoo
>>   * glibc-2.19-r1.tbz2 MD5 SHA1 size ;-) ...                              [ ok ]
>>   >>> Extracting info
>>
>>   >>> Failed to emerge sys-libs/glibc-2.19-r1, Log file:
>>
>>   >>> '/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/build.log'
>>
>>   * Messages for package sys-libs/glibc-2.19-r1:
>>
>>   * ERROR: sys-libs/glibc-2.19-r1::gentoo failed (setup phase):
>>   *   nonfatal() not supported in this EAPI
>>   *
>>   * Call stack:
>>   *               ebuild.sh, line   93:  Called pkg_setup
>>   *             environment, line 2870:  Called eblit-run 'pkg_setup'
>>   *             environment, line  987:  Called eblit-glibc-pkg_setup
>>   *             environment, line  843:  Called glibc_run_test '#include <pwd.h>
>>   * int main(){return getpwuid(0)==0;}
>>   * '
>>   *             environment, line 2085:  Called glibc_compile_test '' '#include <pwd.h>
>>   * int main(){return getpwuid(0)==0;}
>>   * '
>>   *             environment, line 1998:  Called nonfatal 'emake' '-s' 'glibc-test'
>>   *   isolated-functions.sh, line   92:  Called die
>>   * The specific snippet of code:
>>   *
>            die "$FUNCNAME() not supported in this EAPI"
>
> I have isolated-functions.sh in two places:
>
> /usr/lib64/portage/python2.7/isolated-functions.sh
> /usr/lib64/portage/python3.3/isolated-functions.sh
> but not in /usr/lib64/portage/python3.4 (which I didn't know was installed til now)
>
> You might want to check the target machine for which version of python it's using
> and that it has the latest version of portage in /usr/lib/portage/pythonN.N/
>
> Maybe running python-updater would help?
>
>
Tried switching to python 2.7 but got the same error.

The line of the error in isolated-functions.sh is calling a function 
__eapi_has_nonfatal. That is defined in eapi.sh and checks if ${EAPI} != 
0, 1, 2 or 3, which effectively leave 4 or 5.

It seems that the glibc ebuild is EAPI 0 (from 
/var/db/pkg/sys-libs/glibc-2.19-r1/EAPI).

So I guess that the error means that it tried to run the 
glibc_compile_test and failed for the binary install, so emerge tried to 
raise a nonfatal error, but that wasn't supported by the EAPI and that 
caused the emerge to die.

I wonder if setting EAPI=5 in the ebuild file will help, of if that 
would just cause other problems... I might try that later when I have 
some time...

:B

Re: [gentoo-user] Re: nonfatal() not supported error in glibc binary install

[Bruce Schultz]

On 06/10/14 12:38, Bruce Schultz wrote:
> On 06/10/14 00:05, walt wrote:
>> On 10/04/2014 09:15 PM, Bruce Schultz wrote:
>>> Hi,
>>>
>>> I'm trying to update a system using binary packages build on another 
>>> system. I get this error for glibc:
>>>
>>>   >>> Emerging binary (1 of 1) sys-libs/glibc-2.19-r1::gentoo
>>>   * glibc-2.19-r1.tbz2 MD5 SHA1 size ;-) 
>>> ...                              [ ok ]
>>>   >>> Extracting info
>>>
>>>   >>> Failed to emerge sys-libs/glibc-2.19-r1, Log file:
>>>
>>>   >>> '/var/tmp/portage/sys-libs/glibc-2.19-r1/temp/build.log'
>>>
>>>   * Messages for package sys-libs/glibc-2.19-r1:
>>>
>>>   * ERROR: sys-libs/glibc-2.19-r1::gentoo failed (setup phase):
>>>   *   nonfatal() not supported in this EAPI
>>>   *
>>>   * Call stack:
>>>   *               ebuild.sh, line   93:  Called pkg_setup
>>>   *             environment, line 2870:  Called eblit-run 'pkg_setup'
>>>   *             environment, line  987:  Called eblit-glibc-pkg_setup
>>>   *             environment, line  843:  Called glibc_run_test 
>>> '#include <pwd.h>
>>>   * int main(){return getpwuid(0)==0;}
>>>   * '
>>>   *             environment, line 2085:  Called glibc_compile_test 
>>> '' '#include <pwd.h>
>>>   * int main(){return getpwuid(0)==0;}
>>>   * '
>>>   *             environment, line 1998:  Called nonfatal 'emake' 
>>> '-s' 'glibc-test'
>>>   *   isolated-functions.sh, line   92:  Called die
>>>   * The specific snippet of code:
>>>   *
>>            die "$FUNCNAME() not supported in this EAPI"
>>
>> I have isolated-functions.sh in two places:
>>
>> /usr/lib64/portage/python2.7/isolated-functions.sh
>> /usr/lib64/portage/python3.3/isolated-functions.sh
>> but not in /usr/lib64/portage/python3.4 (which I didn't know was 
>> installed til now)
>>
>> You might want to check the target machine for which version of 
>> python it's using
>> and that it has the latest version of portage in 
>> /usr/lib/portage/pythonN.N/
>>
>> Maybe running python-updater would help?
>>
>>
> Tried switching to python 2.7 but got the same error.
>
> The line of the error in isolated-functions.sh is calling a function 
> __eapi_has_nonfatal. That is defined in eapi.sh and checks if ${EAPI} 
> != 0, 1, 2 or 3, which effectively leave 4 or 5.
>
> It seems that the glibc ebuild is EAPI 0 (from 
> /var/db/pkg/sys-libs/glibc-2.19-r1/EAPI).
>
> So I guess that the error means that it tried to run the 
> glibc_compile_test and failed for the binary install, so emerge tried 
> to raise a nonfatal error, but that wasn't supported by the EAPI and 
> that caused the emerge to die.
>
> I wonder if setting EAPI=5 in the ebuild file will help, of if that 
> would just cause other problems... I might try that later when I have 
> some time...
>
That mostly worked... was going to add it in bugzilla and found this:

https://bugs.gentoo.org/show_bug.cgi?id=523332

Don't know why google didn't find that yesterday for me. So the patch in 
now attached to that bug.

Cheers
Bruce

:B