time to submit an ebuild to make users happy.. Reproducible: Always
Created attachment 121419 [details] ebuild (2007-06-07)
ebuild is in the sunrise overlay: http://overlays.gentoo.org/proj/sunrise/browser/reviewed/x11-apps/yukon
Remove the multiple ABI support from it. Only glibc is doing that. Everything else should work for the current ABI.
(In reply to comment #3) > Remove the multiple ABI support from it. Ok, but users will request a 32bit version for amd64 platforms, what should I tell them? Right now, all users compile it from sources, that works more or less, but what's the point having an ebuild if the users still have to compile it themselves? Why will they need a 32bit version? Because wine is 32bit even on amd64, and a 64bit version of yukon doesn't work with wine.
Sunrise ebuild will likely need a version bump (not tested since unable to compile seom). Current (and only) version in http://dbservice.com/ftpdir/tom/yukon/trunk/ is 1.0.103, while the Sunrise ebuild is versioned 1.0.97.
Created attachment 130699 [details, diff] Patch to make ebuild "103 compatible"
Removed from sunrise. Overwriting libraries installed by x11-libs/libX11 and messing with opengl selection managed by eselect-opengl is totally a no go. Feel free to re-add once it's separate from the rest of system in a sane way. WONTFIX.
(In reply to comment #7) > Removed from sunrise. Overwriting libraries installed by x11-libs/libX11 and > messing with opengl selection managed by eselect-opengl is totally a no go. > > Feel free to re-add once it's separate from the rest of system in a sane way. > Yukon was designed not to overwrite other libraries. Can I see some proof of the overwriting? Apart from the ebuild not working because of the missing tarball (which I can regenerate), I don't see why yukon would behave like you describe. And with Dennis' patch applied, I still don't see why it would overwrite anything: >>> Completed installing yukon-1.0.103 into /var/tmp/portage/x11-apps/yukon-1.0.103/image/ strip: x86_64-pc-linux-gnu-strip --strip-unneeded -R .comment usr/lib64/yukon/libGL.so.1 usr/lib64/yukon/libX11.so.6 usr/lib64/yukon/yukon-core-lib usr/lib32/yukon/libGL.so.1 usr/lib32/yukon/libX11.so.6 usr/lib32/yukon/yukon-core-lib ./ ./usr/ ./usr/lib64/ ./usr/lib64/yukon/ ./usr/lib64/yukon/yukon-core-lib ./usr/lib64/yukon/libX11.so.6 ./usr/lib64/yukon/libGL.so.1 ./usr/lib64/yukon/libGL.so.native ./usr/lib64/yukon/libX11.so.native ./usr/lib32/ ./usr/lib32/yukon/ ./usr/lib32/yukon/yukon-core-lib ./usr/lib32/yukon/libX11.so.6 ./usr/lib32/yukon/libGL.so.1 ./usr/lib32/yukon/libGL.so.native ./usr/lib32/yukon/libX11.so.native ./usr/bin/ ./usr/bin/yukon ./etc/ ./etc/yukon/ ./etc/yukon/system/ ./etc/yukon/system/amd64 ./etc/yukon/system/x86 >>> Done.
Created attachment 167598 [details] yukon-1.0.103.ebuild (In reply to comment #3) > Remove the multiple ABI support from it. Only glibc is doing that. Everything I made this ebuild without ABI support. It worked fine for me. I emerged it and tested the application and all went fine.
any option for svn ebuild or to put tarball somewhere so people can use it?
The official homepage is here: https://devel.neopsis.com/projects/yukon, there are instructions where to find the svn repository and how to build it. However I no longer work on the project and nobody else is maintaining it either.
Is this submission still valid? * Upstream is gone and moved too GitHub, where it didn't receive any relevant update in more than one decade. * It depends on seom (https://bugs.gentoo.org/151988) from the same developers it had the same fate as yukon: vanished upstream and moved to GitHub where it lays abandoned. * The main developer himself said he no longer works in the project and nobody else does: https://bugs.gentoo.org/181216#c11 There are probably better alternatives nowadays for OpenGL capturing and given that it has been abandoned for years, it probably doesn't even work. Time to close this?
