firebird-2.5.1.26351.0 cannot build with xinetd use flag: dosbin bin/fb_inet_server fails. Reproducible: Always Actual Results: Build/merge fails
I can confirm this problem too problem is coused by the superclassic.patch, if removed, everything compile ok
Looks like USE superserver is needed to get fb_inet_server built... but USE superserver requires USE -xinetd, then, I don't understand why USE xinetd pretends to install that :/ # SuperServer if use superserver ; then dosbin bin/{fbguard,fbserver} # ClassicServer elif use xinetd ; then dosbin bin/fb_inet_server # SuperClassic else dosbin bin/{fbguard,fb_smp_server} #Temp should not be necessary, need to patch/fix dosym "${D}"/usr/$(get_libdir)/libib_util.so /usr/$(get_libdir)/${PN}/lib/libib_util.so fi
Its likely because its not fb_inet_server, but just inet_server. I likely forgot to modify things to rename inet_server to fb_inet_server. Then again likely just need to modify the ebuild, - dosbin bin/fb_inet_server + dosbin bin/inet_server That would likely address the issue, and I do not believe this is version specific so still effects the only remaining version in tree.
*** Bug 562422 has been marked as a duplicate of this bug. ***
(In reply to William L. Thomson Jr. from comment #3) > Its likely because its not fb_inet_server, but just inet_server. I likely > forgot to modify things to rename inet_server to fb_inet_server. Then again > likely just need to modify the ebuild, > > - dosbin bin/fb_inet_server > + dosbin bin/inet_server > > That would likely address the issue, and I do not believe this is version > specific so still effects the only remaining version in tree. Just tested this, and it does not correct the problem. The problem comes from the patches. I believe another condition in the test for the superclassic patch should address the issue.
This does correct the issue, tested - use superserver || epatch "${FILESDIR}"/${PN}-2.5.1.26351.0-superclassic.patch + ! use xinetd && epatch "${FILESDIR}"/${PN}-2.5.1.26351.0-superclassic.patch
*** Bug 578230 has been marked as a duplicate of this bug. ***
Thanks, fixed in 2.5.6 by commit 090c438e1fc6fe17eca317421604a29720871bff