Bug #595838 resulted in a major upgrade to yp-tools. Unfortunately that version is not compatible with the old version of ypserv and as a result this leaves Gentoo installations with broken NIS implementations. I suggest that either all NIS packages (yp-tools, ypbind and ypserv) are updated at the same time or the new (and incompatible) yp-tools is masked for the time being.
Upstream lists 4.0 as the current version: http://www.linux-nis.org/nis/ypserv/index.html
I couldn't bump this. I will attach the ebuild and patches I have tried... but it fails to compile with: yp.h:38:23: error: unknown type name 'ypresp_key_val' int (*encode)(ypresp_key_val *val, void *data); ^ yp.h:59:38: error: unknown type name 'ypreq_key' extern enum clnt_stat ypproc_match_2(ypreq_key *, ypresp_val *, CLIENT *); ^ I am not sure if maybe we could take a snapshot from https://github.com/thkukuk/ypserv/commits/master as Fedora is doing :/
Created attachment 486672 [details] ypserv-4.0.ebuild
Created attachment 486674 [details, diff] ypserv-4.0-headers.patch
Created attachment 486676 [details, diff] ypserv-4.0-systemd.patch
newer yp-tools went to stable because of glibc stabilization... and this is without maintainer and hard to bump... I would treeclean it then
Created attachment 513576 [details, diff] ypserv-4.0-systemd.patch @Pacho: Could you explain why you say this package is "hard to bump"? With a small fix in your systemd patch to support GCC 7 (by which "#if FOO" is invalid if FOO is undefined), your ypserv-4.0.ebuild builds fine on my system (USE=-systemd).
> GCC 7 (by which "#if FOO" is invalid if FOO is undefined) Say what? Both C99 and C11 explicitly state that any identifier not defined as a macro should be replaced by 0. Can't GCC compile C anymore?
(In reply to Marcus Comstedt from comment #8) > > GCC 7 (by which "#if FOO" is invalid if FOO is undefined) > > Say what? Both C99 and C11 explicitly state that any identifier not defined > as a macro should be replaced by 0. Can't GCC compile C anymore? My diagnosis of the situation was incorrect. Rather than "undefined," I should have said, "defined as empty." And in that case, even GCC 4.8.3 complains, so I guess Pacho didn't test with USE=-systemd. x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -D_REENTRANT=1 -DCONFDIR=\"/etc\" -DYPMAPDIR=\"/var/yp\" -DUSE_SD_NOTIFY= -I. -I.. -I.. -I.. -I. -I/usr/include/tirpc -I/usr/include/tirpc -march=native -O3 -ggdb -pipe -W -Wall -Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wstrict-prototypes -c -o access.o access.c access.c:31:18: error: #if with no expression #if USE_SD_NOTIFY ^ access.c: In function 'announce_ready': access.c:292:18: error: #if with no expression #if USE_SD_NOTIFY ^ gmake[2]: *** [Makefile:603: access.o] Error 1
Right. Skipping -DUSE_SD_NOTIFY completely would have worked, but -DUSE_SD_NOTIFY= is clearly wrong. It looks like an oversight and your fix seems correct to me. Carry on. :-)
Removed from the tree