search

Gcenx / macOS_Wine_builds

Official Winehq macOS Packages
459 stars 23 forks source link

wine-7.22 packages are delayed due to Bug 54009 #51

Closed Gcenx closed 1 year ago

Gcenx commented 1 year ago

I’ll only provide packages after this is resolved, there’s a proposed patch that if merged I’ll apply.

oscarbg commented 1 year ago

Related to missing wine 8.0rcX builds? Or waiting for final 8.0 release?

Gcenx commented 1 year ago

Related to missing wine 8.0rcX builds? Or waiting for final 8.0 release?

Not related I’ve just been busy with work and rather ill (sick with the flu Christmas week). The bug was resolved in a later commit that first landed in wine-8.0-rc1.

I usually skip packing -rcx releases.


I’m still pushing commits to macports-wine for wine-8.0-rcx releases, these only get build on my m1 mini just to confirm it builds.

ADTC commented 1 year ago

@Gcenx thank you for this project. I'm wondering why you're not the official maintainer of macOS Wine. It looks like you're unofficially doing it anyway, why not make it official?

Also, I noticed that the wine-stable cask has not been updated for almost a year now. Should I use wine-staging instead? Is there any significant advantage to using either of them?

Gcenx commented 1 year ago

@Gcenx thank you for this project. I'm wondering why you're not the official maintainer of macOS Wine. It looks like you're unofficially doing it anyway, why not make it official?

These packages are already considered official see https://www.winehq.org/pipermail/wine-devel/2021-July/191504.html
That’s why brew allowed updating there wine casks to these packages.

Also, I noticed that the wine-stable cask has not been updated for almost a year now.

I’ve seen little point bumping from 7.0 to 7.0.1 for these packages when 8.0 is around the corner.

The changes right after wine-7.0 made the amount of patches that could be cherry-picked into the stable branch few and far between.

The thing to remember is wine-stable had this name as it should be the most stable only receiving known fixes in point releases.

Should I use wine-staging instead? Is there any significant advantage to using either of them?

If your running something that mission critical then you’d want wine-stable, if you want the latest and greatest you install wine-devel

The remaining wine-staging is different as that’s wine-devel plus additional patchset that are ether not currently ready to be merged upstream or simply can’t be merged (e.g winemac.dev no flicker)

ADTC commented 1 year ago

These packages are already considered official see https://www.winehq.org/pipermail/wine-devel/2021-July/191504.html That’s why brew allowed updating there wine casks to these packages.

That's great. I'm just wondering why the download page of WineHQ has no mention of your versions, and only points to the very old 5.0 (etc.) and shows "Maintainer: none" instead pointing to your repository to get 7.0 and showing your name as maintainer. Oh well, must be politics. 😅

Looking forward to 8.0 !

Gcenx commented 1 year ago

The reason Winehq wasn’t updated is bug 52354

That bug affected macOS High Sierra and below so it didn’t make sense to provide packaged that listed “macOS High Sierra and later” when it didn’t function on macOS High Sierra. This was recently resolved however.

Once wine-8.0 is released we (Gijs, Julliard and myself) will discuss getting packages pushed directly to Winehq.