I'm trying to install MS office 2007 standard trial using Playonlinux on Wine 1.3.8.
I need to install stuff like MSXML, .net 2 etc... but when I start installing them, a dialog pops up saying 'choose a prefix to patch'... and the list below is empty.
If I forward the dialog just closes.
Playonlinux and Office 2007
Re: Playonlinux and Office 2007
PlayOnLinux is not supported here. This forum is for plain Wine.dE_logics wrote:I'm trying to install MS office 2007 standard trial using Playonlinux on Wine 1.3.8.
I need to install stuff like MSXML, .net 2 etc... but when I start installing them, a dialog pops up saying 'choose a prefix to patch'... and the list below is empty.
If I forward the dialog just closes.
http://wiki.winehq.org/FAQ#head-aeffd8e ... c926cb1235
If you want help here, reinstall in a clean wineprefix following the howto in the AppDB.
http://appdb.winehq.org/objectManager.p ... n&iId=4992
Well yeah, Wine is a 32-bit app (if you intend to run 32-bit windows programs). And you need those libraries anyway.dE_logics wrote:Without Gentoo, that's the hardest thing to do (specially in debian, it asks for 32 bit jpeg libraries ... and many more stuff).
And if you having difficulties with your distro compiling Wine, refer to your distro support with help installing all the required pieces.
If you don't install self-compiled Wine and run it directly from the source/compile dir then you won't have any conflicts with packaged Wine.dE_logics wrote:+ I have to update it manually every time.. it will bypass the package manager.
The Debian community is equally hopeless on this.vitamin wrote:Well yeah, Wine is a 32-bit app (if you intend to run 32-bit windows programs). And you need those libraries anyway.dE_logics wrote:Without Gentoo, that's the hardest thing to do (specially in debian, it asks for 32 bit jpeg libraries ... and many more stuff).
And if you having difficulties with your distro compiling Wine, refer to your distro support with help installing all the required pieces.
If you don't install self-compiled Wine and run it directly from the source/compile dir then you won't have any conflicts with packaged Wine.dE_logics wrote:+ I have to update it manually every time.. it will bypass the package manager.
@All :
Just for the record :
-PlayOnLinux DO NOT modify wine, it use VANILLA wine, compiled from official sources.
-POL help to manage wine version easily so you can have 25 versions of wine installed WITHOUT any problem with POL. It's heaven for tests.
-POL if a patched wine is available for an application, the patch come from AppDB and NOWHERE else.
-POL is an advanced front-end, it's only purpose is to easy the install process
-POL use small functions that do EXACTLY the same as winetricks, it's just truncated in small unique functions instead of have a big monolithic script. So it's easily reproducible with winetricks.
So once and for all, POL tests/bug report regarding WINE are valid since it's VANILLA wine or patched from available AppDB fix, so self-made patches.
@austin987 :
Post first on POL forum, it's better if you want help regarding POL itself.
For god sake why should we forced to used wine+winetricks when there is a great and easy front-end doing the SAME things but all automated and 100x faster...
It's like absolutely wanting to set a fire with two sylex when you have a lighter available and working...
Same for PlayOnMac.
Just for the record :
-PlayOnLinux DO NOT modify wine, it use VANILLA wine, compiled from official sources.
-POL help to manage wine version easily so you can have 25 versions of wine installed WITHOUT any problem with POL. It's heaven for tests.
-POL if a patched wine is available for an application, the patch come from AppDB and NOWHERE else.
-POL is an advanced front-end, it's only purpose is to easy the install process
-POL use small functions that do EXACTLY the same as winetricks, it's just truncated in small unique functions instead of have a big monolithic script. So it's easily reproducible with winetricks.
So once and for all, POL tests/bug report regarding WINE are valid since it's VANILLA wine or patched from available AppDB fix, so self-made patches.
@austin987 :
Post first on POL forum, it's better if you want help regarding POL itself.
For god sake why should we forced to used wine+winetricks when there is a great and easy front-end doing the SAME things but all automated and 100x faster...
It's like absolutely wanting to set a fire with two sylex when you have a lighter available and working...
Same for PlayOnMac.
I mean NO self-made patches, my bad, didn't re-read.
And Tests using patched wine are accepted here, as long as it's warned in the test (see many game test in AppDB). And, so far, the ONLY game using an AppDB patch in POL database is Worms Armageddon.
But well, you don't want Bug report/test if we're using POL/POM, as you like, you will not have a single one, since POL/POM team and users test a lot of games it's a loss for wine devs, I personally don't care as long I found the games I want in POL/POM.
I have no intention of doing manual installation when easy and automated ones are aviable with POL/POM as for most of users if not all.
It's up to you, accept bug report/test with POL/POM (as long as wine version, dependencies and any reg/game modifications and so are explained, like any other test/bug report) or not.
And Tests using patched wine are accepted here, as long as it's warned in the test (see many game test in AppDB). And, so far, the ONLY game using an AppDB patch in POL database is Worms Armageddon.
But well, you don't want Bug report/test if we're using POL/POM, as you like, you will not have a single one, since POL/POM team and users test a lot of games it's a loss for wine devs, I personally don't care as long I found the games I want in POL/POM.
I have no intention of doing manual installation when easy and automated ones are aviable with POL/POM as for most of users if not all.
It's up to you, accept bug report/test with POL/POM (as long as wine version, dependencies and any reg/game modifications and so are explained, like any other test/bug report) or not.
If it works for you, by all means use it. But as you say, POL has its own forum and its own AppDB, and that's where questions and reports about it belong. The same is true of any other third party app. This site is for plain Wine.winefan62 wrote:I have no intention of doing manual installation when easy and automated ones are aviable with POL/POM as for most of users if not all.
Yes, it's as ridiculous as reporting a POL bug here.winefan62 wrote:LOL reporting on POL forum a WINE bug...ridiculous...
What you don't seem to understand is that when someone encounters a problem using a third party app, the first thing that needs to be ruled out as a possible source of the problem is the third party app. To do that, the user needs to test the app in a clean wineprefix using plain Wine. If the problem goes away, it's not a Wine bug. If it persists, we go on to the next step. That's just basic troubleshooting.
winefan62 "dependencies and any reg" These modifications are the problem they can cause failure to run when application should run perfectly without them.
I am regularly telling people off for over using winetricks as well. Only install what you need for the program no more.
Before a bug is reported to wine a few things need to happen. Maybe you can clean POL up so it does what we need.
Number 1 running wine without any alterations with the application. Then add each alteration as the wine errors show its need. This process could be made automated to detect when fixes are no longer required so no longer apply them. Problem of POL it is straight up install the lot and pray. This is over installing leading to POL failures that don't happen when you follow the proper install patern of only installing what is required nothing more.
Some case the issue is wine has added support for X lib and now MS binary of that lib and wine own version are fighting. So automated installs can cause failures by installing parts that are no longer wine compatible or required.
Basically POL gets treated the same as people who abuse winetricks.
Also AppDB code patches are invalid in fact. All code patches should be in the bugzilla. Really all alterations in the guides in appdb really should have a bug number explain it. Yes lot of maintainers in the appdb are sloppy. POL is using instructions that are not correctly backed either.
I like when people say POL is exactly the same a winetricks. Winetricks is bundled as a huge single script to make script updating simple. Winetricks takes regular updates to stay working.
Basically its bull crap to say POL does the same as winetricks. POL scripts normally do the same as a old out of date version of winetricks that has been updated due to issues caused by wine functionally increasing. So there are a lot of POL failures that trace to there scripts being old and out of date compared to current winetricks.
Really it would be better of POL dumped all there own scripts and just used winetricks todo the job with auto updating from winetricks. That way it would truly be exactly the same.
POL is doing the wrong things for us to be able to support them. Install process is rushed so required steps are skilled for diagnostics.
winefan62 problem is POL is short minded. They have only cared about getting the applications to run. Not having automated diagnostics to help when they don't. So we can get the diagnostic information we need from systems we know work. Person has to go back to manual install.
Yes we saying we don't support it because it don't help us working out the problem.
Yes I would love to see POL and us giving support be able to be friends but that can not happen until POL starts adding systems to help people through the error diagnostic process.
Yes the person coming in say I installing in POL now fix really is just annoying because they will not in most cases do the manual install we require. Since they will not do what we want. POL needs to create a way for those people todo our test pattern and give us our data in a way they will not notice.
I am regularly telling people off for over using winetricks as well. Only install what you need for the program no more.
Before a bug is reported to wine a few things need to happen. Maybe you can clean POL up so it does what we need.
Number 1 running wine without any alterations with the application. Then add each alteration as the wine errors show its need. This process could be made automated to detect when fixes are no longer required so no longer apply them. Problem of POL it is straight up install the lot and pray. This is over installing leading to POL failures that don't happen when you follow the proper install patern of only installing what is required nothing more.
Some case the issue is wine has added support for X lib and now MS binary of that lib and wine own version are fighting. So automated installs can cause failures by installing parts that are no longer wine compatible or required.
Basically POL gets treated the same as people who abuse winetricks.
Also AppDB code patches are invalid in fact. All code patches should be in the bugzilla. Really all alterations in the guides in appdb really should have a bug number explain it. Yes lot of maintainers in the appdb are sloppy. POL is using instructions that are not correctly backed either.
I like when people say POL is exactly the same a winetricks. Winetricks is bundled as a huge single script to make script updating simple. Winetricks takes regular updates to stay working.
Basically its bull crap to say POL does the same as winetricks. POL scripts normally do the same as a old out of date version of winetricks that has been updated due to issues caused by wine functionally increasing. So there are a lot of POL failures that trace to there scripts being old and out of date compared to current winetricks.
Really it would be better of POL dumped all there own scripts and just used winetricks todo the job with auto updating from winetricks. That way it would truly be exactly the same.
POL is doing the wrong things for us to be able to support them. Install process is rushed so required steps are skilled for diagnostics.
winefan62 problem is POL is short minded. They have only cared about getting the applications to run. Not having automated diagnostics to help when they don't. So we can get the diagnostic information we need from systems we know work. Person has to go back to manual install.
Yes we saying we don't support it because it don't help us working out the problem.
Yes I would love to see POL and us giving support be able to be friends but that can not happen until POL starts adding systems to help people through the error diagnostic process.
Yes the person coming in say I installing in POL now fix really is just annoying because they will not in most cases do the manual install we require. Since they will not do what we want. POL needs to create a way for those people todo our test pattern and give us our data in a way they will not notice.
By the way, I'm chatting with the author of PlayOnLinux about
improving relations between the two projects. A few guidelines
about how to report bugs to winehq will probably go a long way.
As a start, I'm stepping him through how to do vanilla wine
bug reports. Hopefully once he has some experience with how we
do things, he can spread the word.
improving relations between the two projects. A few guidelines
about how to report bugs to winehq will probably go a long way.
As a start, I'm stepping him through how to do vanilla wine
bug reports. Hopefully once he has some experience with how we
do things, he can spread the word.
1-POL already use Vanilla wine, builded from official sources, no modification.DanKegel wrote:By the way, I'm chatting with the author of PlayOnLinux about
improving relations between the two projects. A few guidelines
about how to report bugs to winehq will probably go a long way.
As a start, I'm stepping him through how to do vanilla wine
bug reports. Hopefully once he has some experience with how we
do things, he can spread the word.
2-A child can reproduce POL script with wine+winetricks ince POl functions are the SAME as winetricks do but instead of a monolithic monster with 90£ useless functions (for a gamer), they use small simple usefull functions like nstalling d3dx9 dlls or dotnet or vcrun...only th usefull part of winetricks (again, for a gamer).
3-POL use tips/tweaks/modifications reported on AppDB tests and AppDB tests only to make the game WORKING, like disabling hardware cursor for Kotor, ect...So arguing about modifications (not you Dan) is ridiculous.
4-POL v4 will use full python language for scripts, no more bash code you wil definitly don't want tests from it.
I perfectly understand you need to be absolutely sure problems come from wine or the game only, but in his actual form, POL is a GUI doing BASH commands, the EXACT same bash commands you will do installing the game by hand.
Don't tell me, when you see wine error output like this "err:ole:RevokeDragDrop invalid hwnd 0x1012c" it's POL fault, this is indeed wine error output.
Now when POL users report POL bugs (GUI bugs) here it's absolutely normal you tell them it's POL related but when they report wine problems, it's neither fair nor normal to tell them it's POL fault.
I don't know if you saw the post about it, but there's a Debian 1.3.8 package available for testing. http://forum.winehq.org/viewtopic.php?t=10467dE_logics wrote:Yup, I'm currently using pol on Debian... very useful app. Unfortunately POL is outdated too on Debian.
As for Office 2007, that has been installable without any tweaks since Wine 1.1.3. The AppDB entry for Office 2007 has a list of versions to avoid because of known regressions, but it should install fine to a clean wineprefix in other old versions.
winefan62 Please read my responses and stop being a twit.
I am one of the longest people assisting users to get wine up and running.
Yes using the winetricks upto date in one case made the program issue with POL not appear. Due to the fact it was override alterations due to changes in wine for dotnet. This here is one of our biggest issues with POL. It would be simpler for these parts if POL dropped having there own scripts for it and just used winetricks like everyone else.
Yes I know its a 192 kb file. Advantage is that is single version. If I need to retest with the same scripts the person used I grab the one file and I can. So I can bug report winetricks as well
Even if it was a 1 mb file I would not care from a support point of view. Key thing is that everyone is installing all those parts the same way from the same script. We will want command line users and POL users to be aligned so making appdb entries simpler. POL making there own subscripts independant to winetricks just adds another possible area of difference.
Items are simple to debug is the number of variables are kept to a min.
Also instructions in the appdb may not be current to developer status. Bugs are. Being based purely off appdb can be trying to make programs run with out of date instructions so can be suffering from bugs that should not exist.
But when something goes wrong and the program does not work. Every alteration has to be tested. I learnt this from a game called roll-cage.
Each alteration can cause a program to take a different internal code path.
If this is going to change to yes I will be happier. One of the current issues is winetricks maybe updated and POL is not so POL user I cannot simply say update your winetricks and try again and see problem go by by.
We don't want to have to be debugging more than we have to. Asking a person what version winetricks they have checking that its working saves us doing support hours.
Even when we see that in normal wine we go back and to a clean prefix and test each addition. Its all about code paths. Adding native parts or altering registry keys can change the internal code path of the application causing it to use a different set of functions.
Ie one combination of parts the application can work perfectly another it can fail. Now if the bug is coming only from a particular combination we need to know. Could be a runtime. This is part of diagnostics.
Basically we need POL users to be able to follow our methods. Other wise POL has to take care of itself.
POL is making it hard for us to tell what is at fault. Is it the program not working or is it the additions that POL has added to so called make the program run.
DanKegel is walking the POL author through how debuging methods. What I have listed here over and over.
Something plays up go back to no alterations and then test and add each alteration 1 at a time to see if problem will magically disappear. Hopefully locate where the bug is coming from.
Basically you cannot ask us to support POL at this stage and refuse to install wine manually so you can follow our debuging methods. If users don't want to follow manual diagnostics at this stage they should bug report to POL and hopefully someone there will come and follow our process or alter POL so it can follow our process.
Yes POL is heading in the right direction to be compadible with people like me. But its not there yet there are still issues where it cannot follow the debugging methods.
Yes the debugging method compatibility is one of keystone for us to be able to support POL and share POL results across all users of wine. And from what I am seeing is the last keystone left then we will be able to bridge the user-bases.
Basically stop argueing that POL is fine and start working on how we can get the last keystone so it works.
I am one of the longest people assisting users to get wine up and running.
I have not disputed this. But in past for some programs POL has used custom versions and not displayed to users that they are so they bug report to us wrong. Yes we are happy with move here to the correct path.1-POL already use Vanilla wine, builded from official sources, no modification.
This is a lie. POL script has screwed up installs of dotnet due to using out of date method. Also has had issues in past of installed d3dx9 dlls without overrides when they now require overrides due to wine having own versions. So exposing errors that don't exist in clean or if person used the current winetricks at the time.2-A child can reproduce POL script with wine+winetricks ince POl functions are the SAME as winetricks do but instead of a monolithic monster with 90£ useless functions (for a gamer), they use small simple usefull functions like nstalling d3dx9 dlls or dotnet or vcrun...only th usefull part of winetricks (again, for a gamer).
Yes using the winetricks upto date in one case made the program issue with POL not appear. Due to the fact it was override alterations due to changes in wine for dotnet. This here is one of our biggest issues with POL. It would be simpler for these parts if POL dropped having there own scripts for it and just used winetricks like everyone else.
Yes I know its a 192 kb file. Advantage is that is single version. If I need to retest with the same scripts the person used I grab the one file and I can. So I can bug report winetricks as well
Even if it was a 1 mb file I would not care from a support point of view. Key thing is that everyone is installing all those parts the same way from the same script. We will want command line users and POL users to be aligned so making appdb entries simpler. POL making there own subscripts independant to winetricks just adds another possible area of difference.
Items are simple to debug is the number of variables are kept to a min.
There are issues here. There should be matching Bug numbers for these alterations. Yes wine here is not without our own internal problems. Where appdb maintainers write up howtos then forget to take out bug reports. Bug reports are what developers use to trace down what they should be fixing.3-POL use tips/tweaks/modifications reported on AppDB tests and AppDB tests only to make the game WORKING, like disabling hardware cursor for Kotor, ect...So arguing about modifications (not you Dan) is ridiculous.
Also instructions in the appdb may not be current to developer status. Bugs are. Being based purely off appdb can be trying to make programs run with out of date instructions so can be suffering from bugs that should not exist.
But when something goes wrong and the program does not work. Every alteration has to be tested. I learnt this from a game called roll-cage.
Each alteration can cause a program to take a different internal code path.
Why do we maintain winetricks. We don't trust people todo exactly the same long processes from the command line. And we don't want to have to read a long process for installing like IE and so on. Yes winetricks does not ship with wine but its the official way to install native code parts we support. No point saying the exact same bash commands. Were those compads executed from a version numbed script that we can trace to an exact version of winetricks yes or no. Current answer is no so what POL does just makes our live harder.4-POL v4 will use full python language for scripts, no more bash code you wil definitly don't want tests from it.
I perfectly understand you need to be absolutely sure problems come from wine or the game only, but in his actual form, POL is a GUI doing BASH commands, the EXACT same bash commands you will do installing the game by hand.
If this is going to change to yes I will be happier. One of the current issues is winetricks maybe updated and POL is not so POL user I cannot simply say update your winetricks and try again and see problem go by by.
We don't want to have to be debugging more than we have to. Asking a person what version winetricks they have checking that its working saves us doing support hours.
Problem is this is your lack of skill. I have seen RevokeDragDrop be POL only for an application due to list of alterations POL did. We will reject all items that have not been tested by our methods so get over it.Don't tell me, when you see wine error output like this "err:ole:RevokeDragDrop invalid hwnd 0x1012c" it's POL fault, this is indeed wine error output.
Now when POL users report POL bugs (GUI bugs) here it's absolutely normal you tell them it's POL related but when they report wine problems, it's neither fair nor normal to tell them it's POL fault.
Even when we see that in normal wine we go back and to a clean prefix and test each addition. Its all about code paths. Adding native parts or altering registry keys can change the internal code path of the application causing it to use a different set of functions.
Ie one combination of parts the application can work perfectly another it can fail. Now if the bug is coming only from a particular combination we need to know. Could be a runtime. This is part of diagnostics.
Basically we need POL users to be able to follow our methods. Other wise POL has to take care of itself.
POL is making it hard for us to tell what is at fault. Is it the program not working or is it the additions that POL has added to so called make the program run.
DanKegel is walking the POL author through how debuging methods. What I have listed here over and over.
Something plays up go back to no alterations and then test and add each alteration 1 at a time to see if problem will magically disappear. Hopefully locate where the bug is coming from.
Basically you cannot ask us to support POL at this stage and refuse to install wine manually so you can follow our debuging methods. If users don't want to follow manual diagnostics at this stage they should bug report to POL and hopefully someone there will come and follow our process or alter POL so it can follow our process.
Yes POL is heading in the right direction to be compadible with people like me. But its not there yet there are still issues where it cannot follow the debugging methods.
Yes the debugging method compatibility is one of keystone for us to be able to support POL and share POL results across all users of wine. And from what I am seeing is the last keystone left then we will be able to bridge the user-bases.
Basically stop argueing that POL is fine and start working on how we can get the last keystone so it works.
why does POL waste time making their own scripts when Winetricks works so good?oiaohm wrote: If this is going to change to yes I will be happier. One of the current issues is winetricks maybe updated and POL is not so POL user I cannot simply say update your winetricks and try again and see problem go by by.
We don't want to have to be debugging more than we have to. Asking a person what version winetricks they have checking that its working saves us doing support hours.
In Wineskin I just made a GUI front end to control Winetricks, and even an update button so anyone using it can get the latest version automatically... but why reinvent the wheel? Seems like a total waste of time to not use Winetricks.
I don't know doh123.
But Wineskin is another that has problem when it comes to the process that has to be done when a failure happens.
Other than that Wineskin is basically fine. Yes front end desigeners at this stage have skipped over the debugging and then wonder why we don't want to support there front end. I don't find the wineskin guys go bad if there is a issue with there application install process they normally take it debug it by our style and report it.
Wineskin 1 keystone of being able to integrate in. Problem is its not a simple keystone to make.
But Wineskin is another that has problem when it comes to the process that has to be done when a failure happens.
Other than that Wineskin is basically fine. Yes front end desigeners at this stage have skipped over the debugging and then wonder why we don't want to support there front end. I don't find the wineskin guys go bad if there is a issue with there application install process they normally take it debug it by our style and report it.
Wineskin 1 keystone of being able to integrate in. Problem is its not a simple keystone to make.
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.
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.
