Wine 7 discussion thread

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.

1 Like

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.

2 Likes

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 :slight_smile:

6 RC’s and I see this :slight_smile: (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

Which requires me to create a burner github account for that purpose. I don’t use github )

Which would’ve already taken less time and effort to do than what you’ve spent writing up these posts :wink: But you do you

I thought it was important to highlight this issue, it was something that I found when I was looking through their repo that stuck out. Thought I was seeing things tbh and hoped somebody would set me right that they did follow the license and show me it in the repo.

Gotcha, apologies then, the original posts came off more as complaining/shaming to me, but sounds like that was my mistake. Again I’m not a licensing lawyer but I can try to take some time to look at the original repos later and see if anything sticks out to me about the licensing.

thats their schtick… whine and complain about things (like having to be omega to set up a 3rd party dev account, but can be alpha after the fact.) or wanting win10 users to be treated like linux.

So wuts the verdict on Wine 7 for gaming, Eve for example?

I am only testing the environment and apps not games in a VM.

Is it worth moving from Proton 5.0-10 (later Proton versions won’t launch on Mint 20 for some odd reason, and 5.0-10 won’t use Vulkan for Eve) to Wine 7.0.0?

Not worth it for Evemon, it’s dead, but, for Eve?

Eve has been running fine for me on the Wine 7 RC’s (I still haven’t upgraded to the stable build). Note that I use wine-staging rather than vanilla, with the latest DXVK.

When installing wine-stable from the winehq repo using the wine-stable .deb it doesn’t set up the sym links or environment PATH to the /opt/wine-stable/bin , is there a package that installs the symlinks to the bin rather than use the environment since symlinks can be changed without reloading the environment profile?

I’m not sure unfortunately–I use Arch (btw :stuck_out_tongue: ). Hopefully someone else here uses the deb package and can help out. If not, there is also the winehq channel in IRC