net-im/corebird-1.7.4 build actually fails as explained in this upstream bug report: https://github.com/baedert/corebird/issues/820 that resulted in this upstream patch to fix the issue: https://github.com/baedert/corebird/commit/ea7e4123dab2374ae53389fdc2c03e0cfb6e1bea
also gstreamer use flag disabled fails corebird build as it is still looking for gstreamer to be installed while building.
When cloning github project repository on branch cb-1.7, ./configure --disable-video --disable-spellcheck works outside portage scope
What I did to make configure successful: $ git clone --branch cb-1.7 https://github.com/baedert/corebird.git $ cd corebird $ ln -s /usr/bin/valac-0.36 ./valac $ export PATH=$HOME/corebird:$PATH $ libtoolize --force $ aclocal $ autoheader $ automake --force-missing --add-missing $ autoconf $ ./configure --disable-video --disable-spellcheck $ ./config.status --recheck
Created attachment 532064 [details] corebird-1.7.4-r1.ebuild I found a way to make a working ebuild on my system.
Quick notes about gstreamer handling in corebird ebuild: * Probably should not depend on gst-plugins-bad[X] (the X USE flag specifically), as that for -bad just provides X11 support to vnc plugin (needs USE=vnc too) and EGL x11 windowing support in gst-plugins-bad-1.12.x and older. The USE=X dep on gst-plugins-base is more likely to be correct though, if it explicitly creates an ximagesink or xvimagesink, but that needs full gst_element_factory_make calls review. * Despite the check getting removed, the application still hopes to make use of gtksink (but might just not provide some features at runtime if not found), so it's probably still good to runtime depend on it, just buildtime depend isn't necessary then. * gst-plugins-bad[gtk] will be moved away to gst-plugins-good (it was promoted upstream from bad to good). I'm not sure yet if it will be a gst-plugins-good[gtk] or a separate gst-plugins-gtk package - I hope the latter. I will file proper transition bug accordingly, and make it possible to work with either old gstreamer (where it's still in -bad) or new gstreamer (where it's in -good) - if a new gst-plugins-gtk package is made, I'll probably just make a fake virtual 1.12.4 version of it, that simply pulls in gst-plugins-bad[gtk], while newer version ships it itself, so it'll be possible to just depend on gst-plugins-gtk and not worry about it.
(In reply to Quentin R. from comment #4) > Created attachment 532064 [details] > corebird-1.7.4-r1.ebuild > > I found a way to make a working ebuild on my system. You just deleted the eautoreconf call, right? I think that's all quite strange - the build system bugged me in the past, too. But right now I wonder if *any* work in the ebuild will do any good, since > Corebird will stop working mid-August: https://www.patreon.com/posts/corebirds-future-18921328 (https://github.com/baedert/corebird/commit/28f866f833a2e5956644e7c9b88ba8f880e36a5f#diff-04c6e90faac2675aa89e2176d2eec7d8)
(In reply to Moritz Schlarb from comment #6) > You just deleted the eautoreconf call, right? > > I think that's all quite strange - the build system bugged me in the past, > too. Yes, that's what I did, and then build succeeded. > But right now I wonder if *any* work in the ebuild will do any good, since > > > Corebird will stop working mid-August: https://www.patreon.com/posts/corebirds-future-18921328 > (https://github.com/baedert/corebird/commit/ > 28f866f833a2e5956644e7c9b88ba8f880e36a5f#diff- > 04c6e90faac2675aa89e2176d2eec7d8) I heard of that and I agree. Corebird ebuild should be set for a removal actually.
