# Samuli Suominen <ssuominen@gentoo.org> (01 Oct 2009) # No support in emul-linux-x86-sdl, bug 286625 app-emulation/wine openal # Samuli Suominen <ssuominen@gentoo.org> (30 Sep 2009) # No support in emul-linux-x86-baselibs, bug 283089 app-emulation/wine jpeg # Jeremy Olexa <darkside@gentoo.org> (06 Sep 2009) # Mask wine[mp3] because it fails to build. bug 283860 # Mask wine[gsm] because it fails to build. bug 283875 app-emulation/wine gsm mp3 # 31 Dec 2007: Peter Weller <welp@gentoo.org> # Mask dbus, hal, nas and scanner USE flags; # Bug 203680 # 28 Oct 2008: Diego Pettenò <flameeyes@gentoo.org> # Mask GnuTLS (not available as 32-bit library) app-emulation/wine dbus hal ldap nas scanner gnutls gphoto2 The last two masks seem to be removable, according to: http://bugs.gentoo.org/show_bug.cgi?id=273793 http://bugs.gentoo.org/show_bug.cgi?id=283912
Can't be done before the new emul- pkgs are stable.
the emul pkgs are marked testing, newer wine packages are also testing. isn't it possible to set the mask to <=app-emulation/wine-1.1.30?
(In reply to comment #2) > the emul pkgs are marked testing, newer wine packages are also testing. isn't > it possible to set the mask to <=app-emulation/wine-1.1.30? > You are correct, but I'm not convinced if it's worth the hassle... when we can simply remove all the masks at the same time in 30 days when the new emul- pkgs go stable. Moving to amd64@ anyway if they want to start tracking this.
Have anybody tried to rebuild all wine versions (they are a lot) for checking if they really work with that USEs locally unmasked and new emul- packages? If all of them work with them unmasked, I would simply go for dropping the mask once new emul set is stabled and adjust wine RDEPEND to force people to install the new versions
Maybe more people will test it, if there's something like this in einfo: "If you use the newest set of emul-linux-x86 packages and need extended features on wine, you can try unmasking the masked useflags by adding "app-emulation/wine -openal -jpeg -gsm -mp3 -dbus -hal -nas -scanner -gnutls -gphoto2" (or subset) to /etc/portage/profile/package.use.mask"
Maybe we could bump wine's RDEP to new emul set in their testing ebuilds and unmask affected USE flags for them under amd64. In the future, we could also drop the mask for current stable wine releases also (or leave masked if wine team think they won't work for any reason) Adding wine team to CC list for letting them tell us their opinion since they know wine much better than me (and, anyway, even if I am willing to bump the RDEP on testing wine ebuilds, I won't do that without asking for their opinion before)
it'll be easier if we wait for the required emul deps to go stable so that we can keep the deps the same across all wine versions. then i dont have to revert/wait for other packages in order to stabilize wine versions. so if the emul packages in question are stable, feel to make the changes to the ebuilds/masks. otherwise let's wait for them to stabilize.
OK, we will wait then Thanks
The following USEs will be unmasked then: openal jpeg gsm dbus nas gnutls ldap While the following will have to wait: capi -> bug 292938 gphoto2 -> bug 286563 hal -> I really doubt if it's really needed (as hal is being deprecated), what feature misses wine without it? mp3 -> bug 299490 scanner -> bug 299505
i wouldnt worry about the hal dep. ive never used it myself, but maybe i'm biased.
*** Bug 300999 has been marked as a duplicate of this bug. ***
btw, Unmasking USE="jpeg" is out of the question without handling bug 300782 first, libjpeg.so.7 is obsolete :-)
(In reply to comment #12) > btw, Unmasking USE="jpeg" is out of the question without handling bug 300782 > first, libjpeg.so.7 is obsolete :-) > Why does it need to be handled first? jpeg-7 is still the "standard", I mean, it's the stable release in the tree and the one that most of us should be using just now. On the other hand, jpeg-8 is still hardmasked, and I would prefer to get it in testing (and near to go stable) for generating a new emul-linux-x86* set with all libs linked against it
(In reply to comment #13) > > btw, Unmasking USE="jpeg" is out of the question without handling bug 300782 > > first, libjpeg.so.7 is obsolete :-) > Why does it need to be handled first? jpeg-7 is still the "standard", I mean, > it's the stable release in the tree and the one that most of us should be Because they need to be in sync for wine to work, we can't have it breaking soon as jpeg-8 is unmasked, so unless the new packages are created... the USE flag will stay masked > using > just now. On the other hand, jpeg-8 is still hardmasked, and I would prefer to > get it in testing (and near to go stable) for generating a new emul-linux-x86* > set with all libs linked against it It's only masked because we are waiting for new emul-linux-x86-* pkgs (amd64) and icedtea6-bin (java).
I updated the package.use.mask file and cleaned it up a bit, it looks like this now, # Samuli Suominen <ssuominen@gentoo.org> (02 Feb 2009) # esd, bug 301824 # mp3, bug 283860 # jpeg, bug 283089, 303255, 299149 # capi, 292938 # ghoto2, 286563 # scanner, 299505 app-emulation/wine capi esd gphoto2 hal jpeg mp3 scanner
Sorry, it looks like this now, # Samuli Suominen <ssuominen@gentoo.org> (02 Feb 2009) # esd, bug 301824 # mp3, bug 283860, 299490 # jpeg, bug 283089, 303255, 299149 # capi, 292938 # ghoto2, 286563 # scanner, 299505 # hal, 299149 app-emulation/wine capi esd gphoto2 hal jpeg mp3 scanner
At least last version (1.1.38) works with jpeg enabled (unmasking first USE), I've tested it with World of Warcraft launcher (and patcher) which does not start unless jpeg is enabled.
Sorry, I've updated things and it now requires version 8 and does not work again.
I can confirm it does not work : I unmasked the jpeg flag, and this is what i get : Wrong JPEG library version: library is 70, caller expects 80 Seems libjpeg8 should be included in emul-linux-x86, or wine should link to the libjpeg7 32 bits.
(In reply to comment #19) > Seems libjpeg8 should be included in emul-linux-x86, or wine should link to the > libjpeg7 32 bits. > It's already included in testing versions from 20100220
I installed app-emulation/emul-linux-x86-baselibs-20100220, unmasked jpeg flag in wine, recompiled wine and this works fine (tested with SC2 Beta launcher & WoW Launched, which both require jpeg support).
USE=jpeg unmasked, nothing left in this bug, USE=mp3 will be handled in bug 299490
(In reply to comment #16) > Sorry, it looks like this now, > # Samuli Suominen <ssuominen@gentoo.org> (02 Feb 2009) > # scanner, 299505 > app-emulation/wine capi esd gphoto2 hal jpeg mp3 scanner It looks like bug 299505 has been fixed for a long time so scanner should probably be unmasked. Denis.
+ 22 Jan 2011; Pacho Ramos <pacho@gentoo.org> arch/amd64/ChangeLog, + arch/amd64/package.use.mask: + Update wine package.use.mask entry. + (also libgphoto and capi stuff are not included)
(In reply to comment #24) > + 22 Jan 2011; Pacho Ramos <pacho@gentoo.org> arch/amd64/ChangeLog, > + arch/amd64/package.use.mask: > + Update wine package.use.mask entry. > + > (also libgphoto and capi stuff are not included) > not -> now
