[ebuild U ] app-emulation/wine-0.9.52 [0.9.51] USE="X alsa cups dbus -esd gecko%* hal -jack jpeg -lcms -ldap -nas -ncurses opengl oss -samba% scanner xml" 0 kB with dbus and hal USE flags enabled, wine builds with them disabled, reason being, there's no libhal in emul-libs (at least on those that are actually pulled in by the ebuild). There are no nas libs either (which anyway I have disabled) nor there are SANE libraries (scanner USE flag). Also at least the last wine checks for libgphoto2, without an USE flag for it, and obviously fail to find it. Until those libraries are available on emul-linux-x86, the USE flags should be masked.
not a wine problem
It's also a wine problem if the deps are broken..
i'm not going to add hacks to wine to account for incomplete emul binaries they've been broken for quite a while because we dont provide libxml2 ... but this just shows that precompiled emul libraries are a crappy solution ... you'll have to live with it until a real multilib setup is available if you want to use extraneous stuff on wine, build the libraries yourself
Will take a look into it when I get a chance.
Masked the USE flags with package.use.mask in amd64's profile for now.
Created attachment 155425 [details] wine-1.0_rc3 rewritten common changes: * fixed some dependencies for X,fonts (some was missing since 2006 !) and other features * use-flags added for almost all optional features * hacks removed made it more gentoo-wayish [!] some dependencies may be absent [!] watch out for missing libs on amd64 and openssl bug ! [!] can be compiled fine with win64 on amd64. without 16 and 32bit support and if you unmask some flags though, [!] flag-striper is removed, just don't play with wicked flags or use 'echo "CFLAGS=my_non-wicked_stuff > /etc/portage/env/app-emulation/wine' and everything will be fine. it's always like that ;)
Created attachment 155679 [details] wine-1.0_rc3.ebuild rewritten * fixed bug with -Wl,--as-needed [!] testing needed ! if it's only ldap related then striper should be activated only with 'use ldap'
Created attachment 155681 [details] wine-1.0_rc4.ebuild ebuild for new RC, releasing today. changed a little
any news here?!
Created attachment 170279 [details] wine-1.1.7 now with tls support. and looks like as-needed bug is fixed. but portage ebuild for some reason still hacky as hell and outdated :(
Ok, from what I gather reading this bug is that there is alot of complaining back and forth. We (amd64) don't maintain the wine ebuild and hence why this bug has been rotting because we won't be committing a new ebuild without the maintainer's (wine team) permission . If no other USE flags need to be masked then this bug can be resolved and we all can utilize our time better and "get along" ;)
it really all depends on what libs available in emul-packages. there no much chances in hal support on amd64 but lack of dbus, nas, scanner (sane), tls(gnutls) support easily can be fixed by you, guys. i didn't heard anything about "proper multilib support" or native 64building wine capability for 32bit applications so - isn't it time already to just include this few libs in emul-packs and problem solved? whole thing like with grub2, when we wait for 3 years something to became cool and stable, do nothing about it while patching old stuff. and what about bad ebuilds - afaik wine ebuild hacky because of configuration bugs on amd64 in old releases which is what this Bug about.
(In reply to comment #12) > it really all depends on what libs available in emul-packages. > there no much chances in hal support on amd64 but lack of dbus, nas, scanner > (sane), tls(gnutls) support easily can be fixed by you, guys. > > i didn't heard anything about "proper multilib support" or native 64building > wine capability for 32bit applications so - isn't it time already to just > include this few libs in emul-packs and problem solved? Sure, file bugs for something that is missing. > whole thing like with grub2, when we wait for 3 years something to became cool > and stable, do nothing about it while patching old stuff. Unrelated to this bug and I do not know what you are talking about either. > > and what about bad ebuilds - afaik wine ebuild hacky because of configuration > bugs on amd64 in old releases which is what this Bug about. Again, the amd64 team does not do the wine ebuilds. Thanks for your contributions, I am resolving this bug because it has gone so far off course. Feel free to open new bugs and they will be evaluated as time allows.
