Currently on the development branch of Fedora (28), an upstream change of glibc is being pushed where the Sun RPC support is removed from our downstream glibc package in favor of the libtirpc library. More details [0].

As a result, when python is trying to build the nis extension, it will complain with:
fatal error: rpc/rpc.h: No such file or directory
#include <rpc/rpc.h>
          ^~~~~~~~~~~
compilation terminated.
 
[0] https://fedoraproject.org/wiki/Changes/SunRPCRemoval

Do you know if installing libtirpc-devel does install required rpc/rpc.h / fixes the issue?

Already tried. Unfortunately it doesn't.

The header is located at /usr/include/tirpc/rpc/rpc.h

> The header is located at /usr/include/tirpc/rpc/rpc.h

configure.ac should be modified to detect tirpc is installed. If yes, setup.py should add /usr/include/tirpc/ to includes to build the "nis" module.

I modified setup.py to look for libtirpc. In case the library is detected, it's added as dependency and /usr/include/tirpc is included in search path.

I think this is a duplicate of #32007.

New changeset f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf by Christian Heimes in branch 'master':
bpo-32521: nis libtirpc (#5137)
https://github.com/python/cpython/commit/f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf

New changeset d55d6825d7bd0fc120c95d579065623ce6392a2f by Christian Heimes (Miss Islington (bot)) in branch '3.6':
[3.6] bpo-32521: nis libtirpc (GH-5137) (#5165)
https://github.com/python/cpython/commit/d55d6825d7bd0fc120c95d579065623ce6392a2f

New changeset ab95b3074ee43098edf3f23b07fb18ef57ee614d by Christian Heimes (Miss Islington (bot)) in branch '2.7':
bpo-32521: nis libtirpc (GH-5137) (#5166)
https://github.com/python/cpython/commit/ab95b3074ee43098edf3f23b07fb18ef57ee614d

Unfortunately the yp_prot.h and ypclnt.h [0] headers have also moved to a different package.

Currently they reside at /usr/include/nsl/rpcsvc/*.h

[0] https://github.com/python/cpython/blob/f3031b8a7ad71d3b6ed05da7f3041d9efbe773cf/Modules/nismodule.c#L18
[1] https://fedoraproject.org/wiki/Changes/NISIPv6

It's not just the headers. The shared library is now /usr/lib64/nsl/libnsl.so.2 instead of /usr/lib64/libnsl.so.1.

New changeset 29a7df78277447cf6b898dfa0b1b42f8da7abc0c by Christian Heimes in branch 'master':
bpo-32521: nis libnsl (#5190)
https://github.com/python/cpython/commit/29a7df78277447cf6b898dfa0b1b42f8da7abc0c

New changeset 12ae40766ea39f09c2ddf6842017ee80f7f3d00b by Christian Heimes in branch '3.6':
[3.6] bpo-32521: nis libnsl (GH-5190) (#5352)
https://github.com/python/cpython/commit/12ae40766ea39f09c2ddf6842017ee80f7f3d00b

New changeset 38487a05cce32536b49dd6c89df7dc85b96eaef4 by Christian Heimes in branch '2.7':
[2.7] bpo-32521: nis libnsl (GH-5190) (#5353)
https://github.com/python/cpython/commit/38487a05cce32536b49dd6c89df7dc85b96eaef4

Reopenning the issue.

python2 is still failing with the fix applied:

gcc -pthread -fPIC -fno-strict-aliasing -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv  -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -mcet -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv  -I. -IInclude -I/builddir/build/BUILD/Python-2.7.14/Include   -c /builddir/build/BUILD/Python-2.7.14/Modules/nismodule.c -o Modules/nismodule.o
/builddir/build/BUILD/Python-2.7.14/Modules/nismodule.c:17:10: fatal error: rpc/rpc.h: No such file or directory
 #include <rpc/rpc.h>
          ^~~~~~~~~~~
compilation terminated.
{standard input}: Assembler messages:
{standard input}: Error: .size expression for nismodule.c does not evaluate to a constant
make: *** [Makefile:1568: Modules/nismodule.o] Error 1
make: *** Waiting for unfinished jobs....

So, if this is a duplicate of #32007, shouldn't it be closed?

It seems to be even more weird. Even with installed libnsl-devel (libnsl-devel-1.2.0-2.5.x86_64 on openSUSE/Tumbleweed) I get this in config.log:

checking for t_open in -lnsl... no

and truly, when grepping for t_open in /usr/include/rpc* I get nothing. When searching for t_open, it seems to be something from Solaris world.

Matej is this about Python 2? Because the solution didn't actually work for Python 2 and on Fedora we had to implement a workaround [0]. Unfortunately there weren't enough free cycles so far to investigate further.

[0] https://src.fedoraproject.org/rpms/python2/c/3056bfd92a4269ad8f9b57cab05af3125e87ca8c?branch=master

> Matej is this about Python 2?

I am currently ONLY on building python 3.7.0, nothing else bothers me at the moment.

Let me summarize my findings, or what I think is the situation (of course, I could be completely wrong):

 * See https://build.opensuse.org/package/show/devel:languages:python:Factory/python3 ... Tumbleweed and Leap 15  (which all have libnsl) fail to be build with libnsl-devel installed. It seems to me that it somehow tries to build nismodule.c, but fails in configure (see above), so it doesn't end up well.

I think the problem is that the Python build system expects libnsl to be the one which is found in Solaris and so it looks for its API. Except, the Linux one is different and doesn't provide the same API. And from there, it goes all down to hell.

With Leap 42.3 (which has glibc-2.27-4.1, but no libnsl, so I guess NIS API is still inside of glibc; is it possible?), nis builds correctly and so it is included.

* Concerning Python 2. I don't see any problems with it. https://build.opensuse.org/package/show/devel:languages:python:Factory/python shows https://is.gd/sbwIf6 that glibc is the same glibc-2.27-4.1, libnsl-devel-1.2.0-2.1, ./configure still fails, but http://download.opensuse.org/repositories/devel:/languages:/python:/Factory/openSUSE_Tumbleweed/x86_64/python-base-2.7.15-112.1.x86_64.rpm still contains /usr/lib64/python2.7/lib-dynload/nis.so module.

OK, so I have no clue and it is all complete mess.

On Fedora after the fix we had also to BuildRequire libnsl2-devel and libtirpc-devel after the glibc change was implemented for the correct headers to be included within the buildroot.

I am not familiar with suse's build system webui to find the logs, but are those packages provided by the distribution?

> On Fedora after the fix we had also to BuildRequire libnsl2-devel and libtirpc-devel after the glibc change was implemented for the correct headers to be included within the buildroot.

libnsl-devel requires libtirpc-devel here, so that isn't the issue.

Closing the issue as python2 is not receiving any more fixes and our downstream workaround is enough for it. Python3 is fine as well.