If this is a Duplicate, please mark it as such. I only searched for wine. According to https://www.winehq.org/ and the associated Release Announcement noted in the URL, 1.8.1 is the current Stable release, so why is Gentoo's Stable release still 1.6.2? If something is broken, please attach the associated bug. I'm asking because 1.6.2 to 1.9.5 is to big of a jump for me, and while user masking is acceptable, it is not preferred, as 1.6.2 has been stable as long as I can remember.
I don't see 1.8.1 in the tree, so first we need to bump.
(In reply to Tomáš Mózes from comment #1) > I don't see 1.8.1 in the tree, so first we need to bump. Do I need to create another Bug that is a Tracker only, and Mark this bug as Depends On: <the new Tracker I create>? I.e., there could be a valid reason our Wine has lagged behind WineHQ
Yes, there is an intention to stabilize the 1.8 branch and wine-1.8 is ready for stabilization. I'd prefer that our stable wine 1.8 use the official gstreamer 1.0 patchset, but upstream never released that under the 1.8 branch. Once again though, I'd rather not be hosting a custom patchset for stable. There is currently a request to the upstream wine stable maintainer to include this in 1.8.2. 1.8.1 was never bumped because Wine Staging never released a patchset for 1.8.1 and I'd rather not have a stable candidate in package.use.stable.mask and not have staging support. I'd also rather not have to host a custom staging patch just for 1.8.1. I've cc'd the Staging devs in case they'd like to weigh in on making an official release for 1.8.1. These reasons are why I sort of stalled on bumping and/or stabilizing a 1.8 ebuild.
(In reply to NP-Hardass from comment #3) > Yes, there is an intention to stabilize the 1.8 branch and wine-1.8 is ready > for stabilization. > > I'd prefer that our stable wine 1.8 use the official gstreamer 1.0 patchset, > but upstream never released that under the 1.8 branch. Once again though, > I'd rather not be hosting a custom patchset for stable. There is currently a > request to the upstream wine stable maintainer to include this in 1.8.2. > > 1.8.1 was never bumped because Wine Staging never released a patchset for > 1.8.1 and I'd rather not have a stable candidate in package.use.stable.mask > and not have staging support. I'd also rather not have to host a custom > staging patch just for 1.8.1. I've cc'd the Staging devs in case they'd > like to weigh in on making an official release for 1.8.1. > > These reasons are why I sort of stalled on bumping and/or stabilizing a 1.8 > ebuild. In that case, I'll create a Tracker style bug and mark this one depends... IMHO what you stated is one of the reasons I prefer a source based distribution.
Added Depends
(In reply to Carter Young from comment #5) > Added Depends Please add associated Blockers etc in the newly created Tracker Bug. If possible patchset is needed, could we possibly submit this upstream. If needed, I'll do it. I don't mind stepping on peoples toes if it fixes an issue.
Thanks for sharing the latest info NP-Hardass. In that I don't see a point of having another bug #578272 open. This is useful for cases when it depends on other packages, but this is solely a matter of wine and upstream. Let's keep this open with the info from NP-Hardass so that anybody else who seeks for 1.8.1 knows. I'm closing #578272 as I see no point of having it open. NP-Hardass stated he wants to bump and stabilize 1.8.x, so it's on upstream now. Thanks for your interest Carter, maybe try to convince upstream to get it going ;)
*** Bug 578272 has been marked as a duplicate of this bug. ***
This has now been officially reported upstream: See https://bugs.winehq.org/show_bug.cgi?id=40363
(In reply to NP-Hardass from comment #3) > I've cc'd the Staging devs in case they'd > like to weigh in on making an official release for 1.8.1. Seems like you forgot that. I've already added an statement to the WineHQ bug report linked below.
"Staging" is genereally used for branches NOT stable. It's nonsense to wait for a staging patchset in the stable branch.
(In reply to Carter Young from comment #9) > This has now been officially reported upstream: > > See https://bugs.winehq.org/show_bug.cgi?id=40363 Based on the discussion upstream, they have released a patch set. I don't think they will do it the next time. As such, I'd like to propose an ebuild split. Copy all app-emulation/wine >=1.7 packages that are ~arch to app-emulation/wine-staging, and make the staging flag REQUIRED, i.e. IUSE=staging, along with the other USE Flags, then remove the staging USE Flag from the app-emulation/wine package, and block/mask staging if the package is currently installed, i.e. emerge -av wine would show: app-emulation/wine USE=( ... (-staging) ...)
An ebuild "wine-staging" wouldn't be that bad, other distrbutions do so. Taken literally, they're different upstreams, so it would be consequent.
The ebuild is there (thank you NP-Hardass!!) and now the testing and stabilization.
(In reply to Yanestra from comment #14) > The ebuild is there (thank you NP-Hardass!!) and now the testing and > stabilization. No problem. Took a little time to get the backport of the new gstreamer 1.0 code, but here it is... Now, we can have our new stables on gst 1.0 and not have to worry about issues when the gnome project moves to drop gst 0.10. As far as splitting is concerned, I'm considering this staging release as Gentoo, downstream, stable. I'll split staging off into it's own separate package when I have the time to clean up and merge the content in the wine-a-holics overlay. Closing this bug, feel free to open a new one if you run into any issues with the ebuild for wine 1.8.1
