Summary: | Adjust package.use.mask for wine according to the new emul-linux-x86 set | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | ScytheMan <scytheman666> |
Component: | New packages | Assignee: | AMD64 Project <amd64> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | chris.burroughs, denilsonsa, gentoo, hauschild.markus, maciej.blizinski, nbowler, pacho, renchap, StormByte, tomaszg, wine |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 300782, 303255 | ||
Bug Blocks: | 165270 |
Description
ScytheMan
2009-12-31 18:27:37 UTC
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 |