Is it OK to stabilize =net-misc/spread-4.3.0 ? If so, please CC all arches which have stable keywords for older versions of this package.
/usr/sbin/spread is not installed and it's needed by init.d script and the other installed tools
It looks like /usr/sbin/spread isn't installed because during the ebuild install phase, it does some additional compile/linking, which fails, and emerge isn't catching the fact that gcc or ld failed and bailing. Same problem exists on their new release of Spread-5.0.0. Seems like a bug in their build system.
I am going to bump 5.0.1 to stable in a few days. I don't thin the 4.x branch of spread is salvageable at this point. For reference, there's an undefined symbol lookup that happens in both the compile //and// install phases that emerge seems incapable of catching. compile phase: x86_64-pc-linux-gnu-gcc -o spmonitor -O2 -ggdb2 -pipe -march=ivybridge -mtune=ivybridge -mfpmath=sse -mmmx -msse -msse2 -msse3 -mssse3 -msse4 -msse4.1 -msse4.2 -maes -mavx -mcx16 -mf16c -mfsgsbase -mfxsr -mpclmul -mpopcnt -mrdrnd -msahf -mxsave -mxsaveopt -mvzeroupper -mavx256-split-unaligned-load -mavx256-split-unaligned-store -maccumulate-outgoing-args -fstack-protector-all -fmodulo-sched -fmodulo-sched-allow-regmoves -ftree-loop-im -ftree-loop-linear -ftree-loop-ivcanon -fgcse-after-reload -fgcse-lm -fgcse-sm -fgcse-las -floop-interchange -ftree-loop-distribution -floop-strip-mine -floop-block -ftree-vectorize -flto=12 -fuse-linker-plugin -fstack-check=no -Wl,-O1 -Wl,--as-needed -Wl,-z,now -Wl,-z,relro -Wl,--sort-common -Wl,--hash-style=gnu -Wl,-flto -fno-lto -fno-use-linker-plugin -rdynamic monitor.o lex.yy.o y.tab.o configuration.o ip_enum.o acm.o -lm -lrt -lnsl -ldl ../libspread-util/lib/libspread-util.a /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libspread-util/lib/libspread-util.a(events.o): in function `E_lookup_function_name': /ramfs/portage/net-misc/spread-4.3.0-r1/work/spread-src-4.3.0/libspread-util/src/events.c:480: undefined reference to `dladdr' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:86: spmonitor] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/ramfs/portage/net-misc/spread-4.3.0-r1/work/spread-src-4.3.0/daemon' make[1]: Entering directory '/ramfs/portage/net-misc/spread-4.3.0-r1/work/spread-src-4.3.0/docs' install phase: /usr/lib/portage/python2.7/ebuild-helpers/xattr/install -c -m 0755 spread /ramfs/portage/net-misc/spread-4.3.0-r1/image//usr/sbin/spread /usr/lib/gcc/x86_64-pc-linux-gnu/8.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ../libspread-util/lib/libspread-util.a(events.o): in function `E_lookup_function_name': /ramfs/portage/net-misc/spread-4.3.0-r1/work/spread-src-4.3.0/libspread-util/src/events.c:480: undefined reference to `dladdr' collect2: error: ld returned 1 exit status make[1]: *** [Makefile:86: spmonitor] Error 1 make[1]: *** Waiting for unfinished jobs.... make[1]: Leaving directory '/ramfs/portage/net-misc/spread-4.3.0-r1/work/spread-src-4.3.0/daemon' make[1]: Entering directory '/ramfs/portage/net-misc/spread-4.3.0-r1/work/spread-src-4.3.0/docs' ../buildtools/mkinstalldirs /ramfs/portage/net-misc/spread-4.3.0-r1/image//usr/share/doc/spread-4.3.0-r1 Both errors look like they're fixed in spread-5.0.1. I only mess with this library because of a local ebuild package set I maintain (until I find time to actually put it in the tree), and one of the libs in that set uses spread. This seems to be a mature, very stable package, as upstream rarely puts updates out. I've just added 5.0.1 to the tree, so going to let that settle, and add a reminder to myself to clean out the ebuilds for 4.1.0 and 4.3.0 in a few days, leaving only 5.0.1 in stable. This will only affect x86 and amd64, so I don't think that's too much of an issue.
Okay, small change of plans. I found an update to the spread-4.x branch on their site, hidden in the NEWS section, v4.4.1. Testing its build out reveals it also corrects the compile/install error and /usr/sbin/spread is properly installed. I'll instead favor 4.4.1 for stabilization in a few days and remove the older 4.x ebuilds. 5.0.1 can sit in ~arch for the time being.
Fixed by removing the older 4.1.0-r1 and 4.3.0-r1 ebuilds, and marking 4.4.1's ebuild stable on x86 and amd64. 5.0.1 can soak in unstable for a while.
