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.
>From: dE_logics <wineforum-user at winehq.org> >Sent: Nov 29, 2010 7:31 AM >To: wine-users at winehq.org >Subject: [Wine] Playonlinux and Office 2007 > >I'm trying to install MS office 2007 standard trial using Playonlinux on Wine 1.3.8.Ask them for support. This project does not support nor can it support this product. If you delete PlayOnLinux and install Wine, then we can support your efforts. BTW, MS Office 2007, with the exception of Access, works out of the box on Wine 1.3.8. James McKenzie
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.PlayOnLinux is not supported here. This forum is for plain Wine. http://wiki.winehq.org/FAQ#head-aeffd8e1fe7702219fcf87f97834edc926cb1235 If you want help here, reinstall in a clean wineprefix following the howto in the AppDB. http://appdb.winehq.org/objectManager.php?sClass=version&iId=4992
If only I could get that version of WINE for debian...
On 11/29/10 5:55 PM, dE_logics wrote:> If only I could get that version of WINE for debian...Be patient. The development team is WORKING on this. You could go to the wine-development mailing list archive and glean the address where the deb files are being held and help...(subtle hint applied with a sledgehammer time.) James McKenzie
dE_logics wrote:> If only I could get that version of WINE for debian...Compile it from source.
vitamin wrote:> > dE_logics wrote: > > The Debian community is equally hopeless on this. > > There are other distros, you know...Yeah, I originally use gentoo (where you can compile from the trunk). I installed Debian for testing purposes.
winefan62 <wineforum-user at winehq.org> wrote:> >LOL reporting on POL forum a WINE bug...ridiculous... >PlayOnLinux modifies the Wine code in ways that, it appears, you don't understand. The same with CodeWeavers/CrossOver 4Mac or CrossOver 4 Linux. When someone reports a bug in any of these, we ask that the bug be posted there. If it is truly a bug in Wine, a bug report is created in Wine's Bugzilla.>Well, so be it, I have no intention of arguing anymore with you, I will never ever post bug report or tests in AppDB since >you don't want to understand.If it involves PlayOnLinux, we don't want nor need your report. It will be deleted. Again, POL makes changes that they decide, for many reasons, to keep to themselves.> >Even Codeweaver devs are less short minded... >I will not comment on this, but CodeWeavers developers provide much feedback to the Wine project in the form of patches. Other projects do on a hit or miss proposition. It has been a policy of the Wine Project that if you use a fork (POL, WineBottler, CrossOver) you have to report the problem there so that the source can be clarified and if it is 'their' code fixed. Leaves Wine developers free to work on on bugs that exist in Wine code. This has worked well in the past, does today and will into the future. James McKenzie
winefan62 <wineforum-user at winehq.org> wrote:> >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. > >Please stop flogging a dead horse. We don't accept bugs reported from POL USERS.>1-POL already use Vanilla wine, builded from official sources, no modification.Bull. They patch it using patches found in either the Applications Database OR Wine Bugzilla. Neither of these are offical patch sources. Using such patches results in an unsupported Wine configuration. The biggest of these is associated with Bug 421 (Incorporate DIB engine in Wine.)>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).Winetricks is for all Wine users, not just gamers. Dan probably can figure out what parts of POL to pull and incorporate into Winetricks V2 (he has been working on this), so that you can select a program name and the appropriate externals can be incorporated. Maybe he can even (hint, hint, hint) into specific Wine Prefixes for each program.>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.Again, these are called hacks and just cover up what is wrong with Wine's code. This is also called a "modification" in the broad sense of the use of the word.>4-POL v4 will use full python language for scripts, no more bash code you wil definitly don't want tests from it.This will move POL further away from Wine's code. Again, if you have a problem using POL, report it there. Reporting it here, in the future will result in a topic lockout. James McKenzie> >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. > > > > >
mulx <wineforum-user at winehq.org> wrote:> >Hi, > >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.A question we all may have is where do the patches come from? Are they 'suggestions' in the Wine Applictions Database, are they 'hacks' in Bugzilla or are they pending patches submitted to and pending acceptance in the Wine Patches area? Also, if one of the patched .pol files 'breaks' would POL be willing to be the interpeter as to whether this is a Wine bug or a POL induced problem? Would the same apply for POM? Thank you. James McKenzie
"MulX (Aymeric)" <os2mule at gmail.com> wrote:> >Le 10/12/2010 16:51, James Mckenzie a ?crit : >> mulx <wineforum-user at winehq.org> wrote: >>> Hi, >>> >>> 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. >> A question we all may have is where do the patches come from? Are they 'suggestions' in the Wine Applictions Database, are they 'hacks' in Bugzilla or are they pending patches submitted to and pending acceptance in the Wine Patches area? >> >> Also, if one of the patched .pol files 'breaks' would POL be willing to be the interpeter as to whether this is a Wine >> bug or a POL induced problem? Would the same apply for POM? >Hi, >The patchs come normally from the WineHQ Website, but I can't certify >about that because this is done totally automatically. When a user of >POL want a patched version he should provide a .zip with all patchs >needed, on which official Wine release patch will be applied and finally >the name. That's all. >(http://www.playonlinux.com/en/topic-3718-WineBuild_Demand.html) >In other words, they are on their own as neither Wine nor POL will be able to accept a bug report.>I know that the POL-Wine-1.2.1-ddraw include a patch found on the Worms >World Party page from WineHQ AppDB >(http://appdb.winehq.org/objectManager.php?sClass=version&iId=3905). >Yes, some of the 'bugs' are very old. Bug 421 is the oldest outstanding bug and it is a request for enhancement that has seen many hands 'touch' it. If the source of the patch can be found, it may be possible to update the bug report with successes and failures to help troubleshoot and create a 'proper' patch for the problem in the bug report. Also, please keep working with Dan Kegel on incorporating the winetricks scripting method into POL/POM. James McKenzie
mulx wrote:> > 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?
Patches are included in .pol packages
qparis <wineforum-user at winehq.org> wrote:> >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) >qparis this forum is for discussing User problems. It might be a great time to get onto the Wine Developer forum and also read through how to submit patches to Wine, if your patches do solve a problem without breaking other programs. This also applies to other POL/POM folks that have solutions in patch format for problems encountered in Wine. Continue to discuss how POL/POM works so this will be clear to all. Please do have maintainers of POL/POM packages that do not use patches submit/update bug reports to Wine's Bugzilla. Do encourage POL/POM users to continue to provide updates to POL/POM for consolidation as updates for those bug reports. Do NOT create second bug reports if one already exists, but do update those reports. What is not desired is to have a POL/POM user that is using a patched/altered package go directly to Wine's Bugzilla as this would make some reports very lengthy with 'Me Toos' (in other words, "I have that problem too" entries.) Reporting, 25 POL users have this problem should be acceptable. James McKenzie
GNU_Raziel <wineforum-user at winehq.org> wrote:> >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?.Some of these patches have not been included because the are 'hacks' and break other programs. POL/POM has a good policy of building programs into different Wine prefixes, but how are you keeping track of the different Wine builds. (This might be a good topic for Wine Developers, not Wine Users for the time being.)> >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.As I stated to qparis, it has been discussed here, at length, that we would rather the reports go to POL/POM and then Wine. That way you folks will be aware of what is or is not working and the POL/POM project can consolidate Wine bug reports. This would dimish user frustration and keep information in a proper channel. What does qparis and you think of the application of this process? Again, it is my opinion (and from what I've read the opinion of other Wine Developers/testers.) James McKenzie
oiaohm <wineforum-user at winehq.org> wrote:> >>GNU_Raziel wrote: >>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. >One of the major problems I can find is that the forum passwords and the Applications Database passwords are not synchronized. Thus when a user finds a problem or wants to report that 'all is well' they have to create a second account. Some folks have even stated this and they would like to report but tracking multiple userids and passwords is a problem for them.> >> 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. >The problem is not a lack of funds, it is a total lack of time for most people. Once the program does what they want it to, they stop trying to improve things. Thus we get regressions that are not discovered until 'someone new' comes in and states "The Applications Database has ProgramX rated Platinum and I cannot even get it to run". Then we discover that a patch three versions back broke the program. Very hard to fix now. If we had someone with a lot of time that could just pick up a program and test it DAILY, then we would be further ahead in removing/fixing regressions. Susan Cragin was doing this for Dragon Naturally Speaking until either something happened in her life or she just gave up.> >We try to get app maintainers in the appdb to keep on reporting status of there apps. >But they, too have this thing called 'real life' and sometimes do not run their program for three or four versions. Again, it would be nice if they did so for each release version and maybe more often.> >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. >There are folks that did not run their program except when Wine 1.0.1 was released. Now they are trying to update to Wine 1.2 and find that the program no longer installs. There were approximately 3500 patch commits between the two releases over a two year span. Regression testing this is very tedious, time-consuming and may point to multiple patches contributing to the inability to run the program. Not a good situation. This leads to the "I don't want to run a development build, it might break my system" problem. Creating a third category of "Testing builds" or beta runs, may aleviate this, but that increases the complexity of Wine code and tracking these builds.> >You will see the games with more regular reporting on the appdb will have less over all issues. >True.> >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. >And those people should be running different Linux distributions and different hardware. Some patches will only affect a limited number of people. Thus, a proposed 'fix' that breaks some people but not others can be detected and corrected quickly.> >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. >How often does Ubuntu/Fedora/Debian do a full release. Maybe once every six months. However, a patch/fix from them may break Wine or vice versa. These problems need to be identified and corrected.> >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. >Standing still will not result in death, but you will find yourself falling further and further behind. If Wine releases a development/test build, POL should at least try to see if it breaks or improves program use. If it breaks programs, this needs to be reported, quickly. If it improves program usage, that needs to go into the Applications Database. This could be done by the POL package maintainer as part of their duties, just like it is supposed to be a part of the duties of a Wine Application Maintainer.> >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. >I agree. One, two maybe three users per package that can report successes or failures back to the POL/POM project is all we need. This maybe out of thousands of POL/POM users. This will help POL and Wine detect breakages and improvements quickly and prevent what is becoming 'regression hell' when we find out that Office 2007 will not install and could not be installed for several Wine releases. We need to discover that 'rouge' patches do or do not work so that the patch creator will be encouraged to fix the patch so that it meets Wine's high standards and to move some patches from 'hack' status to 'committed' status. I am of the opinion that POL is an excellent place for this to happen, but it appears that the people who run the POL/POM project are being reluctant in doing so. James McKenzie> > > >