On 11/11/2017 11:49, Andreas K. Huettel wrote: > Hi all, > > in the next days I'll likely re-add keywords to glibc-2.26. So, if you > haven't > fixed your package for build failures yet, now would be the time. > > The tracker is https://bugs.gentoo.org/show_bug.cgi?id=glibc-2.26 with > appropriate subtrackers. > > 1) Your package needs RPC (and already now fails to build with sys-libs/ > glibc[-rpc]). > > See https://wiki.gentoo.org/wiki/Project:Toolchain/RPC_implementation for a > detailed guide. > > 2) Your package uses NIS/YP functionality, and builds against / links to > libnsl. > > Add a dependeny (DEPEND and RDEPEND): > net-libs/libnsl:0= > > You can already safely do this now ( =net-libs/libnsl-0 is a dummy, stable on > all arches, installs no files, depends on <sys-libs/glibc-2.26 ), and as an > additional bonus will get the subslot rebuild automagically once libnsl is > updated. > > (The unbundled libnsl has increased soversion, libnsl.so.2. glibc will keep > installing libnsl.so.1 as compatibility library for binary packages, but > without headers etc.) > > 3) Your package needs internal data structures and fails with undefined types. > > Ping me. Most likely problem and fix are already known. >
I take it Python was fixed to handle this? I have my main MIPS machine tied up on catalyst for the next few days, so I can't verify right now. Initial catalyst runs ~2 weeks ago indicated glibc-2.26 caused Python to fail its build because either the RPC or NIS module failed to build (I forget which). -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 6144R/F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
