Sup peeps, just opening a thread in the hopes we keep our posts in a single thread about wine 7. So we can keep all info compiled in a single place.
I’m using ge-rc2, so far so good. Lutris ofc with all the good stuff enabled.
Spec:
I’m still using the .py script fix, but is it still needed?
Cheers.
This is no longer needed in Wine 6.23 and later
its done ( WineHQ - Wine Announcement - The Wine team is proud to announce that the stable release Wine 7.0 ) , looks really nice, i hope now for Proton 7 soon 
The 64-bit Windows-on-Windows (WoW64) architecture is implemented, and supports running a 32-bit Windows application inside a 64-bit Unix host process
This means what I think it means? F to the i686 libs?
It’s not available on the source repos yet for Ubuntu/Mint distros (Wine HQ’s own source repo).
imo they should only do an announcement when the package is available for all in their repository.
They say in their news stream 7.0 is released, not on their own repos it isn’t.
$ apt policy wine-stable
wine-stable:
Installed: (none)
Candidate: 6.0.2~focal-1
Version table:
6.0.2~focal-1 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
6.0.1~focal-1 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
6.0.0~focal-1 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
5.0.4~focal-1 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
5.0.3~focal 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
5.0.2~focal 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
5.0.1~focal 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
4.0.4~focal 500
500 https://dl.winehq.org/wine-builds/ubuntu focal/main amd64 Packages
Wine 7.0 has been released by Wine as per the release notes: it is available from https://dl.winehq.org/wine/source/7.0/wine-7.0.tar.xz
That the volunteer package builders haven’t completed the packaging (and testing) for various distributions is a separate issue. That is not part of the release - the code is the release, not what someone does downline with it.
If you are desperate to use Wine 7.0, then use 7.0-rc6 from the winehq-devel release and pin it until someone updates the packages. Release Candidate 6 was the final one that was moved directly to the full release without changes. To be honest: in my experience winehq-devel given Wine’s release strategy is perfectly stable for most users. Yes, rc6 works quite happily for Eve Online.
@Zoiie - I suspect Wine would be very happy with you volunteering to help them do the packaging (and testing) for the many distributions that they kindly provide free packages for.
There are many volunteers work on Wine, and other open source projects, including people within the Eve Community - I am grateful for their efforts and their hard (and often unappreciated) work.
https://forum.winehq.org/viewtopic.php?t=34748
is there book filings for this 501c we can read?
Valve sure benefit from Wine, as do Codeweavers.
If there’s a financial transparancy report let me know.
You trying to force a point over your mistake. That’s not going to be beneficial to anybody other than your ego.
@Terak_Romaller is totally correct. Wine software is done, packing it is totally optional. If they do, they do only to make others life easier.
Now the donation transparency is another topic, and does not change the fact a lot of people not donating ■■■■ is still using the software.
o7.
Pretty sure Valve benefit as does CCP since we’re using it to PAY for services/products from them.
Valve are not on the sidelines of Wine. CCP rode Wine on Mac before native. Got a link to CCP’s donation of finance / skill time for the benefits they reaped?
So please, spare me the “poor little backroom/garage FOSS project”. It’s as much backroom as Linux kernel is these days.
I’m not discussing that, I’m discussing the fact you are just throwing arguments around the package question.
What you saying is the essence of free software, that’s why we have a lot of license options.
Take 5 and organize your thoughts.
I’m not actually clear on what people are arguing about here, so apologies if what I’m about to say is irrelevant, but my understanding was that Valve has a partnership directly with CodeWeavers and sponsors a decent amount of the work they do.
I wouldn’t say that CodeWeavers “benefits” from Wine, rather that CodeWeavers IS Wine, as they pay most if not all of the core contributors to work on the project. I pay for a CrossOver license that I don’t use because it’s one of the ways to directly support Wine development.
And the Ubuntu Wine-Stable 7.0 packages are up.
24 hours, not bad.
And you will see bugs come in for the packaging drop location change to /opt and environment variables not accounting for that I bet. Cue lots of app launching issues reported.
I just seen this happen in a VM that 6.0.2 worked fine.
This is why I always test stuff in a VM before live machines. A nice clean snapshotted VM that’s a pure clean distro installation.
Perhaps wait for 7.0.1 if you don’t like to tinker 
6 RC’s and I see this (one RC per week?)
Distro is a clean Mint 20.3 installation setup for this purpose.
EVEmon doesn’t seem to like this version, worse than 6.0.2, even after copying a valid char token across from Windows app data folder since it won’t add characters even on 6.0.2 but it worked once the settings that contained the token was copied across, that’s not even working on 7.0.0.
I have not seen EVEMon work at all since switching to SSO for authentication. It cannot because Wine’s HTTP.sys driver does not support HTTPS, and that’s what EVEMon uses to try and handle SSO. You must be using a really old version of EVEMon if it was working at all.
Also, you could be facing issues due to deprecated ESI endpoints depending on which particular fork and version of EVEMon you’re using. It’s been abandoned by maintainers several times now (including GitHub - peterhaneve/evemon: A lightweight, easy-to-use standalone Windows application designed to assist you in keeping track of your EVE Online character progression., which is the most common one). You might give GitHub - mgoeppner/evemon: A lightweight, easy-to-use standalone Windows application designed to assist you in keeping track of your EVE Online character progression. a try with your profile-copy trick since they updated it to support the latest ESI endpoints.
I am using the latest EveMon, the HttpListener fails for adding characters on 6.0.2, however if you copied the AppData settings.xml that contains your character reference from a Windows installation that worked (I also have a Windows VM) and token you can get it to work on 6.0.2, however, on 7.0.0, that just flat out fails now. The token will expire after a period of time so this is a periodic thing you have to do.
These forks of Evemon are looking like they’re violating the upstream license they forked from by not including the upstream license, see here https://forums.eveonline.com/t/evemon-license-and-proprietary-file-content so there is maybe a chance they could get taken down from github if it is not addressed.
They should be including the upstream license in their fork, not just add in their own license willy nilly and forget about the upstream commitment. You don’t want to ignore license commitments on FOSS as it WILL get reported by the FOSS community, they take that stuff seriously, as seriously as HAM’s and their radio spectrum.
Reports here GitHub Support
imo it is better that we get a cleanroom app for Eve and one that will compile and work across platforms using a better toolkit.
Sure, that would be amazing. Are you volunteering to lead that charge?
Yes I am doing one privately currently.
However, I am certainally concerned that the forks of the upstream Evemon are not adhereing to the upstream license that I can see, please correct me if I am wrong but the upstream license whilst has very few limitations, does have one commitment, to include the upstream license downstream, it looks to me the downstream forks simply just took it and slapped on their own alternative GPL license without following the upstream license commitment.
That’s great to hear! Please keep us posted, especially if it matures enough to be open sourced/accept contributions.
However, I am certainally concerned that the forks of the upstream Evemon are not adhereing to the upstream license that I can see
Couldn’t this be fixed by just submitting a PR with the original upstream license? I am not a licensing lawyer but I don’t see any obvious reasons as to why that’d be an issue
Sure I could raise an issue ticket (but I am not on github) but this is something any developer would/should check before taking on something, certinally is not courtesy to just ignore it, and if it was any other major FOSS project the hammer of outrage would have been on it by now.
Especially for such a simple and very liberal, with a simple commitment, it’s not hard to see the commitment, it’s one of the simplest liberal licenses you can get and they simply just ignored it and appropriated it with a new license.
Surprised it was allowed to continue for so long without it being called out, one should be grateful for very liberal and succinct licenses like that.
Sure, I guess I’m just asking what the purpose of worrying/complaining about it is, when you have the ability to take action on it (directly in this case via PR). That’s the beauty of OSS, if something’s broke you can help fix it