Playonlinux and Office 2007

[vitamin]

To sum up, here is what we have planned.
We're going to make some rules into POL scripts. If these rules are not followed (mostly for games that need patched wine version), we will tell the user that winehq can't be reponsible for any bugs found.

That's a great news!

It would be nice to have a "tainted" flag of sorts for a specific game. So we can ask user of POL if their setup is clean and we can continue on troubleshooting or request installing game under vanilla Wine.

[oiaohm]

qparis Nice to here. 3 important points and one optional idea.

1) As vitamin said a tainted flag on error reporting of the program using patched version of wine. You can bet users will forget they agreed when they come and report to us. Nice if we can point to log file and say you are using tainted version with the following added.

2) Patched version support is not black and white. To get to shades of gray regarding patched versions of wine we have to know what was added what you are nicely going to grant.

Sometimes we will support patched versions sometimes we will not depending on what was added and if it truly relevant to application at hand. When we get down into silver and bronze rated games we cannot be too picky.

If a developer is working on the patch to get it mainlined at times the developer maybe seeking feedback in the bugzilla on issues with the patch. So at times POL users running the patch on different hardware and distribution combinations can be handy to wine Quality before its mainlined. Like the on going dib engine one of wine oldest still open bugs.

This is purely wine support people and wine developers digression if patched versions will be supported and changes patch by patch. You current wording appears to be a flat no and that is not 100 percent correct. Its a high probability of a flat no and will be a flat no if we don't know what patch was applied.

Yes past scriptor your end most likely cause of misunderstanding on this since we could not be sure what patch/es was applied so automatically getting flat no status.

This area might be a section we here might have to consider formalizing maybe providing a way for developers to tag bug/patches of interest they want feedback on. I do expect as we go threw the process to find somethings wine own processes could be bettered.

3) There is a need for an option to run script with each bug fix library added 1 at a time and support persons order is about the only thing missing.

Yes clean and building back up is something we have todo with some bugs to locate when the bug enters. Particularly with likes of conflicting reports. Ie game works but intro video does not. Game does not work but intro videos play. Now what one is the third party libs or is it something deeper. Debuging these things is a pain in the tail. But it has to be done to make progress.

1 optional) A little extra on that patched version of wine agree screen reference to bug patch or patches are from so users can check out if it still required in newer versions of wine. Does happen that sometimes patch has be revised or better yet merged. I would put this in a POL end user niceness item so they can work out if the install script is out of date. It will happen. Also so they can provide feedback on some of the proto patches in development. Yes I sux at how to word this right. The optional is not something you have to rush todo.

With the list of changes without mine here. I do see future with quite decent relations between POL and wine. It will take a while for all the support people to be accepting. Nothing is overnight in this world.

[dE_logics]

Hi

I'm PlayOnLinux and PlayOnMac author.

Let me make some points clearer.

We are aware that PlayOnLinux is not helpful for wine developers and things are going to change.

@ doh123, If we write our own functions, it's because winetricks is unable to interact with PlayOnLinux/PlayOnMac GUI. I chatted with Dan Kegel and he told me that he would modify winetricks to be able to interact with POL gui.

@ oiaohm, In the past, we had a scriptor which made a lot of crappy things in our scripts. He decided to patch every wine version without asking the user. I want to say that we are AGAINST this method and we are correcting the scripts ! Now, we patch wine very very very rarely (for two or three games like Worms World Party), and we explain to the user that it's not an official wine build, and neither winehq nor PlayOnLinux is not responsible for it. User has to check "I agree" to install these version

To sum up, here is what we have planned.
We're going to make some rules into POL scripts. If these rules are not followed (mostly for games that need patched wine version), we will tell the user that winehq can't be reponsible for any bugs found.

When an user install a script, it will :
- Use winetricks for all librairies
- When a script do something (installing a librairie with winetricks, making the prefix, editing a file of the game, and whatever), it will log it into a file in english ! So it will be easy to understand. We have also planned to write why do we do that (which problem we want to encounter). Scriptors will just have to use for example :
- POL_Comment "Installing this library to fix black screen problem (Bug xxx)"
- With this log file, we will also include a lot of information about the computer of the user (cpu info, graphic card, memory, distro, winetricks version used ...)
- We will also attach information about the wine build used (which will NOT be patched). It will contain a dpkg --get-selections on the machine that build the wine version (develelopement libraries) (wine versions are build on debian)
- The user will have access to this log file very easily.
- To help debugging, we have planned to build Wine everyday from the git repository and make it available into PlayOnLinux

With all that efforts, PlayOnLinux scripts wil - I hope - help you to debug very easily

If you have any other suggestion, do not hesitate.

Believe me, we really want to help you, and not to make things difficult for you.
It is very hard, we have a lot of scripts (~500), two million downloaded each year and an ancient scriptor made a lot of ugly things.

We just need you to be comprehensive, we promise we will do a lot of effort.

So you patch the wine build if you install an application from the repository. If we just download the wine version using playonlinux, then wont be patched right?

[mulx]

Hi,

Yes, if you download Wine package from here: http://wine.playonlinux.com/linux-i386/ all .pol except those who have an suffix between the version and .pol aren't patched.

For example:
PlayOnLinux-wine-1.3.0.pol => no patch, compiled from source of WineHQ website.
PlayOnLinux-wine-1.3.1-ubi-drm.pol => patched. Based on release 1.3.1 of WineHQ and patched with a patch for avoid "ubi-drm". Patchs applied are included into the .pol.

You can open a .pol without using PlayOnLinux by renaming it to .tar.bz2.

Bests regards,
MulX.
PlayOnLinux-staff and responsible of PlayOnLinux WineBuild.

[dE_logics]

Hi,

Yes, if you download Wine package from here: http://wine.playonlinux.com/linux-i386/ all .pol except those who have an suffix between the version and .pol aren't patched.

For example:
PlayOnLinux-wine-1.3.0.pol => no patch, compiled from source of WineHQ website.
PlayOnLinux-wine-1.3.1-ubi-drm.pol => patched. Based on release 1.3.1 of WineHQ and patched with a patch for avoid "ubi-drm". Patchs applied are included into the .pol.

You can open a .pol without using PlayOnLinux by renaming it to .tar.bz2.

Bests regards,
MulX.
PlayOnLinux-staff and responsible of PlayOnLinux WineBuild.

Ok, that's a good source. Now I've something to say in Bugzilla.

[oiaohm]

PlayOnLinux-wine-1.3.1-ubi-drm.pol

Sorry to say ubi-drm and the like mean pure nothing to us doing wine support. We are normally after the exact patch applied and where it from normally should be a bug in wine bugzilla.

That is one of the out standing issues.

[DanKegel]

PlayOnLinux-wine-1.3.1-ubi-drm.pol => patched. Based on release 1.3.1 of WineHQ and patched with a patch for avoid "ubi-drm". Patchs applied are included into the .pol.

You can open a .pol without using PlayOnLinux by renaming it to .tar.bz2..

Do you store your wine patches in a source code control system
somewhere, e.g. github?

[qparis]

Patches are included in .pol packages

[oiaohm]

Patches are included in .pol packages

qparis. That is the problem. We are not as support people going to download a complete pol file to find out what patch is in it just to answer yes or no.

Seeing the patch file does not tell us what wine bug it is covering.

This is key when we access the wine bugzilla we may see that X bug is now closed and its merged into mainline since X version.

Some of the worst issues of wine not fixing issues for ages have come from the fact of patches being lost as important and not linked to a new bug number.

Yes we need to know if wine bugzilla says a patches requirement is closed. If its still being applied and required on a newer version than where is marked no longer required we have a issue needing a new bug number. Of course we as support people will not be impressed to find this the case since the maintainer of the pol should have been on top of bug status. At least if we know we can attempt to have it corrected.

Really we need a short form that tells us exactly what has been applied. At worse 1 or 2 kb of information. Ie where the patches were from what bug number they are fixing. Also can be the case the patch as been updated.

Avoid DRM would normally be a hack and what is required to make the DRM work would be the correct solution.

Idea that patches included solve the problem is wrong. If the patch cannot be placed in wine bugzilla due to being a game cracking. Then that would be a true case of 100 percent sure not supported by wine and questionable on legal status in many countries.

Yes some of the .pol's should be marked legally questionable and people should check there countries own legal requirements before using.

Really DanKegel for simplest management wine bugzilla should be holding the patches. But for items outside that something like a github holding them so they can be accessed without downloading a full pol file would be useful.

Lot of us who do support stress our download quotas enough without extra.

[GNU_Raziel]

Hi,

i'm POL/POM main scritor. Like it was already said, we use only patches posted and tested in AppDB bug reports, which seriously limit possible sources.

Also, ubi-drm build is bad exemple since Ubisoft updated DRM short after this patch release so it do not work, you need to disable (crack) DRM to make Assassin's Creed 2 and PoP-The Forgotten Sands to work (don't know if other game use this DRM). This wine build will be deleted soon.

A good example is 1.2.2-MousePatch build, a mandatory patch to make Mass Effet 1&2 and Borderlands to be playable. Without this patch you cannot turn 360°.

Also note that patching vanilla wine is the last resort solution for us...We do what we have to do to please POL/POM users, they want to enjoy their games under Linux/OSX.

Like qparis said, he will upadte POL/POM so it generate clear logs, which will, for sure, include bug ID when a patch is used so you will be able to track it down easily.

Regards,

GNU_Raziel

[qparis]

Ok, I understand.

We will do our best to make things clearer for you. But as GNU_Raziel said, we use patches very very rarely. I think there is only two patches used in our script. One for Worms World Party, and the other for a mouse problem (Ask GNU_Raziel)

We want to include in the log files every bug we need to work around.
Example of what a line of the log file could look like :

* Installed wine patched wine version 1.2.2 with the following patch http://bugs2.winehq.org/attachment.cgi?id=31558 to correct bug 2082 (DirectDraw games only showing black screen)

[oiaohm]

qparis thanks that is what we need. I would consider the full bug link for users.

Most people don't notice that you can vote on bugs you class as important and need fixing. Yes its just a guide to developers to help developers decide order of what they work on. Wine have multi levels of reporting that we need people using.

GNU_Raziel You are following our ideas on patching. With the little clearer information as what is coming. We will be able to work closer with each other.

For us the more testers the better reports we have in appdb the better and the better bug reports. The tricky part is having everyone submitting complete information.

GNU_Raziel some cases when we are debuging applications we use patches not on the appdb reports when testing. But the patches will be connect to a bug number from most support people around wine.

Most common has been DIB engine patches. We are not forbidding experimentation with patches.

Key things is we know what the mix is so we can group same with same and we can get feedback both ways if the patch works or if the patch is now a lemon. As you saw with the DRM patch what appears to be a good patch can turn lemon very fast.

GNU_Raziel basically for progress we need experimental parts at times to get testing. Even more experimental the development branch. So I see the restriction to just appdb patches as too strict to cover all cases.

Knowing what was done and the means to drop back to unpatched to work out if the patch is now dud is our requirements. Really as long as we can determine what is going on we will be tollerent. And as long as user of POL or Wine is tollerent to us going threw the steps to work out what is going on.

Yes we have ones in the wine camp that are like I have installed X version wine application don't work make it work. We look at reports and find out the application does not work with X version but a slightly older one does. Then when they will no step back to the older version they cannot work out why support just ends. This bad behavior I don't expect POL users to be 100 percent free of. We have not been able to make wine normal community 100 percent free of.

One of the common annoyances even with wine to a point that I am trying to stamp out in wine. With wine users you get people saying Wine current version. Instead of stating wine version in use. I do see a little bit of the same problem from POL users. Recent example. it works in POL but not Wine 1.3.8. Lot of questions latter you find out that the program inside POL it is Wine 1.3.4 the last know test of the program working. This is basically POL being used in the same bad way as current version.

I except we are most likely never going to be 100 percent free of this problem. Its just something to keep in mind when doing interface design its something that needs to be thought about how applications are displayed if wine version in use could be made more clearly displayed. Just like us people on the POL side should discourage bad reporting. POL using wine <number> should be encouraged. Most likely help with your tracking of problems as well.

Maybe even maintaining a section in both our FAQ telling users how to get wine version in use out of POL. This is really a last resort I know how badly end users don't read FAQ's these days.

There is imperfection on both sides. At-least we now have dialog and progress along the right paths. Hopefully along the way GNU_Raziel you can get more freedom to make stuff work and we end up with better reporting and testing to work with for future versions of wine.

Wine development can only end when Windows is dead and Wine has caught up to it. Testing and Reporting is going to be a on going thing for a long time to come.

I am more than willing to share what commonly have or see issues with in the #winehq irc on freenode. Hopefully one day people using open source and reporting correctly would be natural. Its still very unnatural for lots of open source programs out there. POL might solve some of the problem for wine.

[GNU_Raziel]

I understand your point of view regarding experimentation of wine but modt (is not all) POL/POM users don't want to experiment, they just want to have theirs app working as expected.

We "freeze" to a platinum (and if not reported, at least gold) rated wine for each app, it work very good for many games, version used for each app is clearly written in "manage wine version" menu so it's very easy to retrieve. Of course, log system being developed at this moment will include wine version used.

The real problem (for us at least) is Steam...god I hate this thing...with continuous app update, actual steam do not work (or need heavy modifications/dirty fixes) with older wine...which is very problematic because some games, as you stated, work good with older wine but not newer one. Considering this is the most popular digital version provider, it's not wise to "just forget it".

So it's a real pain to freeze wine version to valid working one when steam is involved because, and it's definitely not rare with wine, a game can work good with a version and be broken with another.

Finding a good balance is definitely not easy and digital version providers will not help since they're more and more popular. Make the digital manager app work is not make the game work most of time, too many games need "tricks" to work (and can interact with/broke other games) with wine in it's actual form.

So all this to notice you that, most POL/POM users will probably not report anything since we do all we can to make their apps work "out of the box" from their point of view. I, myself, do not try to add games to POL/POM that are not reported in AppDB as working because I cannot buy a game that will not work just for test/report with wine, I have not enough money for that

[oiaohm]

GNU_Raziel. Wine does not try to forget items Like steam. But its insanely hard to keep working due to how much it changes and limited supplies of testers for it.

Some of those issues we have with games and the like are from lacking people with the software to keep testing and reporting.

So all this to notice you that, most POL/POM users will probably not report anything since we do all we can to make their apps work "out of the box" from their point of view. I, myself, do not try to add games to POL/POM that are not reported in AppDB as working because I cannot buy a game that will not work just for test/report with wine, I have not enough money for that Razz

This is the issue wine people have as well. Also we have issues were games don't work with particular video card drivers and the like.

We try to get app maintainers in the appdb to keep on reporting status of there apps.

Big problems wine has is not enough testing to find regressions. If wine know about regressions inside 1 or 2 versions they can normally be fixed simply. But if wine find out like 10 to 12 down the track. Problem of fixing can be insanely harder because a lot of code can be depending on the alteration that caused the problem.

You will see the games with more regular reporting on the appdb will have less over all issues.

The issue here I know what we need so we can reduce failures. Its testing by the people with the games. Problem have people with the games may not be skilled enough. Now we don't need everyone with the game to report if they did they would overload the appdb. We just need 3 to 4 per game in most cases.

Problem here is freezing on old versions of wine you end up slowly but surely becoming current day hardware and distribution incompatible. So we need to maintain forward movement.

Now how are we going to achieve that on going forward movement and forward movement equals testing. Is one of wine biggest on going problems. To maintain forward movement we need regression testing to remove regressions and lead to test cases to prevent those faults returning.

GNU_Raziel I know its simple to say lets stay still. But we are sitting in a area if we don't stay moving we will die.

Basically wine need your adventure seeking users who are prepared to experiment and report. I know they are a small percentage of your user base just like they are a small percentage of the wine userbase. We need them with a path that they can start out simple.

[GNU_Raziel]

GNU_Raziel. Wine does not try to forget items Like steam. But its insanely hard to keep working due to how much it changes and limited supplies of testers for it.

I was not talking about wine team, I was talking about POL/POM team...Since Steam is very popular we must support it but as you said, it can be insanely hard in some cases.

I also understand your need to feed back every release, I hope the POL/POM log project will help you as much as possible.

And for wine "freezing", I personnaly try to update wine version used when I see bug fixes in changelog, like Dragon Age Origins which used wine-1.3.5 until I saw the dotnet 2.0 fix/replacement with mono 2.8.1 with wine-1.3.9. Since Mono is working far better with wine there is no point not updading.
Another example is AoE 3 which have several fixes with wine-1.3.9 so I also updated used wine version for this game.

The main problem is keeping testing again and again, most users will not want to do it...I personally have approximatively 30 games actually reported working with differents wine version, I cannot re-test them all every two weeks, I don't have time to do that, most of my spare time is eating by adding new games to POL/POM database and maintain/upgrade supported games.

We, when the log system will be available and validated by wine team, will encourage POL/POM users to regularly test new wine version and report of course.

Regards,

GNU_Raziel