For both i586 and x86_64, if wine is rebuilt so must wine-mono and wine-gecko be. Otherwise, launching a wine app gives warnings that suitable versions are missing and offers to download them. The app will run if it does not use .NET or HTML rendering, but as we have the packages in the repositories, they should be kept in sync Reproducible: Steps to Reproduce:
(In reply to Frank Griffin from comment #0) > For both i586 and x86_64, if wine is rebuilt so must wine-mono and > wine-gecko be. Otherwise, launching a wine app gives warnings that suitable > versions are missing and offers to download them. The app will run if it > does not use .NET or HTML rendering, but as we have the packages in the > repositories, they should be kept in sync > Assigning to the maintainer of wine-mono and wine-gecko, even he didn't push wine. And wishing Thierry a great holiday
CC: (none) => marja11, thierry.vignaudAssignee: bugsquad => anssi.hannula
I assume these were split out because of their size, but it would really make sense to recombine them with wine.
I had installed wine (with old wine-gecko and wine-mono) and had no problems booting into my related cauldron before you filed this bug report (but did get the same warning). Funny enough, a few hours after you filed it, and without having installed any updates and without having changed any settings the last two times I had used that cauldron, booting into into hung on "A start job is running for LSB: Allow users to run Windows(tm) applications ...." This morning I found time to boot that cauldron again and check at what time it would time out... it was increased to 14min 26s and then a notice came to check "systemctl status wine.service" and nothing more happened. (no idea whether that can be related, only mentioning it in case it is) @ Anssi In case you're also (about to go) on holiday: of course a great holiday for you, too. I assigned to you because tv had told in a dev mail that he'd be gone for 3 weeks. And because you're registered as maintainer of wine-mono and wine-gecko Feel free to assign back (even if I'd prefer if you'd grab maintainership of wine, too ;-) )
I didn't see any startup hangs, but I note that the warnings do block the execution of any wine application, so maybe your wine.service conditionally invokes something that causes the warning. Did systemctl status give any hints ?
(In reply to Frank Griffin from comment #4) > I didn't see any startup hangs, but I note that the warnings do block the > execution of any wine application, so maybe your wine.service conditionally > invokes something that causes the warning. Did systemctl status give any > hints ? Oops, never replied. I don't remember :-/ I no longer have that install, reinstalled Mga5 to do a very, very slow, step by step upgrade to cauldron while waiting for neoclust to fix kde4=>plasma5 related conflicts that I come across.
Setting as a release blocker so that we don't forget to do this before releasing Mageia 6. Currently at least wine-gecko is out of sync with wine. I think tv had a look at it already but it looks like a tough guy :)
Blocks: (none) => 15527Priority: Normal => release_blocker
CC: (none) => fri
Status comment: (none) => Packages could be dropped if this can't be fixed
Fixed now with: - wine-1.8.4-2.mga6 - wine-gecko-2.44-2.mga6 - wine-mono-4.6.3-1.mga6 I have no more a pupo-up who says me that MONO and GECKO not found in the system. Feel free to reopen if needed!
Resolution: (none) => FIXEDCC: (none) => geiger.david68210Status: NEW => RESOLVED
Blocks: 15527 => (none)
This is back. Updating wine does not automatically rebuild wine-gecko (at least) and maybe wine-mono as well.
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
(In reply to Frank Griffin from comment #8) > This is back. Updating wine does not automatically rebuild wine-gecko (at > least) and maybe wine-mono as well. There is no longer a registered maintainer for wine-gecko and wine-mono, so re-assigning to all packagers collectively However, tv has pushed the last wine updates to cauldron and tmb was the last one to push wine-gecko and wine-mono. They're both in the CC of this report.
CC: (none) => rverschelde, tmbAssignee: anssi.hannula => pkg-bugs
I have a vague memory of requesting that these packages be automatically rebuilt when wine was, and tmb saying that they couldn't be because they were in contrib while wine was in release, so this was must have been in the Mandriva days. Or maybe I'm recalling a different set of packages entirely. Shouldn't prevent it now, though.
Ping ?
Do they still need to be rebuilded for mga9 final ?
CC: (none) => mageia
i downgrade the severity
Priority: release_blocker => High
I notice this was already mentioned in https://wiki.mageia.org/en/Mageia_9_Errata#Various_software And I now improved description there.
Keywords: (none) => IN_ERRATA9
Blocks: (none) => 33903
Blocks: 33903 => (none)
Frank Griffin , you still have this issue with the packages in bug#33903 ?
I haven't noticed this in a while.
(In reply to Frank Griffin from comment #16) > I haven't noticed this in a while. Can you make a test please ?
It's not that simple. After a cauldron update that updates wine, when I launch wine I get a prompt complaining that those packages need to be updated,a dn do I want to download the upstream versions or just ignore the update. I've made much less use of wine lately, and I haven't seen the prompt. I don't know whether someone automated the rebuilds or did them manually. I don't, at this point, know how to re-test this.
(In reply to Frank Griffin from comment #18) > It's not that simple. After a cauldron update that updates wine, when I > launch wine I get a prompt complaining that those packages need to be > updated,a dn do I want to download the upstream versions or just ignore the > update. > > I've made much less use of wine lately, and I haven't seen the prompt. I > don't know whether someone automated the rebuilds or did them manually. I > don't, at this point, know how to re-test this. Thank you for the information
I installed wine32-8.0.2-1.1.mga9 (and its new dependencies) on an x86_64 machine, and I'm now getting the error "Wine could not find a wine-mono package..." and offered to download it. I cancelled the dialog (so, no download), then started it again and this time there was no error message and it seemed to work fine. I didn't try a C# program, though. This system has wine-mono-7.4.0-1.mga9 installed.
CC: (none) => dan
Aurelian I think wine-mono package should be updated to same version that wine in testing
CC: (none) => arusanu
(In reply to katnatek from comment #21) > Aurelian I think wine-mono package should be updated to same version that > wine in testing The wine dependency on mono/gecko versions didn't change with the new wine version. Gecko-2.47.3, Mono-7.4.0 Here are some basic tests to install/use Mono and Gecko, assuming that the Wine installation/upgrade went without complaints. Steps (network off for testing purposes and no $HOME/.wine present). 1) New wine bottle: Run wine configuration to generate a new $HOME/.wine bottle and, by default, install mono if available: >winecfg and close the window. 2) Mono check: Run the Wine uninstaller. ONLY the "Wine Mono Windows Support" should be listed. >wine64 uninstaller and close the window. 3) Gecko install: Run iexplore (empty page with network off, otherwise "winehq.org" page) to auto install gecko (64-bit) in the bottle. >wine64 iexplore >wine64 uninstaller The uninstaller window should now list "Wine Gecko (64-bit)" too. For 32-bit testing(with wine or wine64+wine32 packages installed), use wine instead of wine64. Of course, one might run into some quirks with updating old wine bottles, but that is most likely a wine "feature."
I just launched a wine app after several cauldron upgrades and I notice a number of anomalies: The gecko/mono prompt is back. The wine64 executable has disappeared, apparently replaced by a wine executable, even though the wine64 package is installed. I assume this is fallout from decommissioning 32-bit stuff, but it breaks a lot of existing scripts. wine64 should have been left as a symlink. I really don't understand what the problem is to force rebuild of gecko/mono when wine is updated. Unless you can disable the gecko/mono prompt, the prompt is an annoyance at best and confusing for newbies at the worst in that it may lead them to choose to download non-MGA code.
(In reply to Frank Griffin from comment #23) > The gecko/mono prompt is back. Indeed, "wine-mono" was out of sync with "wine." Changes in "wine/wine-mono" broke a straight rebuild. A new version, wine-mono-10.1.0-1.mga10, should become available soon. At the moment, the "wine-gecko" package should be fine. There are some issues with the current building requirements for "wine-gecko" that aren't met in Cauldron. Hopefully, these will be sorted out before "wine-gecko" needs an upgrade or a rebuild. > The wine64 executable has disappeared. That was an upstream decision. I've put in place some little script to deal with it. Would you try it out and give some feedback? > Unless you can disable the gecko/mono prompt, That's a "wine" prompt, and I'm not sure we should disable it, even if we might figure out how to.
I've done some tests based on comment 22. After uninstalling all the Gecko installs listed at "wine uninstaller" (and, wow, there were a lot of versions on my many-times-upgraded system), AND uninstalling mingw{64,32}-wine-gecko packages, "wine iexplore.exe" said there was no Gecko and offered to download one. I cancelled that, reinstalled the mga9 mingw{64,32}-wine-gecko packages and started "wine iexplore.exe" again. This time, there was no missing Gecko message and the Wine home page was displayed just fine. "wine uninstall" now showed gecko 2.47.3 (32-bit) was installed, presumably a copy from the mingw32-wine-gecko package. That confirms me that our current gecko package version seems to be just fine with the updated wine. However, I'm not sure about mono. Comment 22 says that "Wine Mono Windows Support" should be listed, but I see nothing in the uninstaller that says anything about Mono. Unless the uninstaller itself uses mono, I'd presumably need to run a program that needs mono for wine to care about it.
(In reply to Dan Fandrich from comment #25) > I've done some tests based on comment 22. After uninstalling all the Gecko > installs listed at "wine uninstaller" ... > However, I'm not sure about mono. Comment 22 says that "Wine Mono Windows Support" should be listed, When a NEW bottle is generated by running "winecfg," wine-mono is installed right away, without user interaction and assuming no other extraneous issues occur, like not enough space on the device. "wine uninstaller" should show only wine-mono at this point. For old or existing bottles, "wine uninstaller" should list all installed versions of wine-mono/gecko. Additionally, when you start an old bottle, it should automatically update to the newer versions of Wine, Mono, or Gecko whenever they are necessary or available (?), and again without user interaction. This is how it "should" behave ;). > I'd presumably need to run a program that needs mono for wine to care about it. If there is no wine mono installed in a bottle for whatever reason, you should try to install or run in that bottle a program that needs mono, like KeePass, which should trigger the installation of mono.
I tried installing KeePass-2.59-Setup.exe on wine32 but after choosing a language it complained "The program does not support the version of Windows your computer is running." Can you suggest another mono program to try?
wine-mono/gecko can be manually installed in a wine bottle (the default one here). > WINEPREFIX=$HOME/.wine wine /usr/share/wine/mono/wine-mono-7.4.0/support/winemono-support.msi > WINEPREFIX=$HOME/.wine wine /usr/share/wine/gecko/wine-gecko-2.47.3-x86[_64].msi (In reply to Dan Fandrich from comment #27) > Can you suggest another mono program to try? https://videoconverter.wondershare.com/video-converter-free.html I found it mentioned in a wine-mono bug. The reporter complained about not being able to install it. Many game installers require wine-mono, but they do require a lot more besides wine-mono. (In reply to Dan Fandrich from comment #27) > "The program does not support the version of Windows your computer is running." I would like to see the output of your error. The only snag I hit with KeePass is that it needs the path to system modules to be explicitly loaded. Assuming you are using an x86_64 system, could you run the following steps in a terminal and attach the output: - Remove wine64 and wine32 if installed, then reinstall them to make sure all deps are loaded. - Remove/move default bottle if it exists: rm/mv ~/.wine - Generate new bottle: winecfg - Install KeePass2: > WINEPATH="/usr/i686-w64-mingw32/sys-root/mingw/bin;/usr/x86_64-w64-mingw32/sys-root/mingw/bin" wine KeePass-2.59-Setup.exe - If successful, you may still need to use the WINEPATH to run KeePass. > cd "$HOME/.wine/dosdevices/c:/Program Files/KeePass Password Safe 2"; WINEPATH="/usr/i686-w64-mingw32/sys-root/mingw/bin;/usr/x86_64-w64-mingw32/sys-root/mingw/bin" wine KeePass.exe
I've finally tried those instructions (sorry about the delay). With those instructions I was able to successfully install and run KeepPass. With the newfound knowledge that it can actually work, I have spotted in winecfg that I set the default Windows compatibility version in that bottle to XP at some point, likely while trying to debug some previous issue. Setting WINEPATH wasn't even needed once I spotted that. This was all with wine-mono-7.4.0-1.mga9.noarch installed. If I then remove the wine-mono package and confirm with "wine uninstaller" that no Mono is installed, KeepPass fails to start: 0024:err:mscoree:CLRRuntimeInfo_GetRuntimeHost Wine Mono is not installed wine doesn't offer to install it for me. If I then uninstall KeePass and try to install it again, it installs fine but on launch I get the same "Mono is not installed" message. Nothing triggers the installation of mono as you suggest in comment 26. However, with wine-mono-7.4.0-1.mga9.noarch installed, KeePass works fine and a newer or different version of Mono is NOT downloaded or installed automatically. That tells me that that version of mono is, indeed, compatible with wine-8.0-7.mga9 which is really the heart of this bug. Is there anything left to verify in this bug, or can it now be closed?
I should note my tests in comment 29 were on an x86_64 machine but using the i586 wine binaries.
Clarification request (In reply to Dan Fandrich from comment #29) > I have spotted in winecfg that > I set the default Windows compatibility version in that bottle to XP at some > point, likely while trying to debug some previous issue. And now, what did you set it to? > Setting WINEPATH > wasn't even needed once I spotted that. --- wine-8.0.2-1.1 is in updates_testing, in QA process in Bug 33903 - Wine update request I guess we are done here once that is pushed? We are obviously in mga9 now, presumably fixed in Cauldron. I set flags as I see fit...
Assignee: pkg-bugs => qa-bugsStatus comment: Packages could be dropped if this can't be fixed => Update errata when fixedVersion: Cauldron => 9Depends on: (none) => 33903Keywords: IN_ERRATA9 => FOR_ERRATA9
(In reply to Aurelian R from comment #26) > If there is no wine mono installed in a bottle for whatever reason, you > should try to install or run in that bottle a program that needs mono, like > KeePass, which should trigger the installation of mono. I've recalled it wrong, as Dan noticed in comment 29. When the system's wine-mono is missing or old, Wine does offer to download mono, but only in some cases: when configuring a new bottle or, for an existing bottle, only when updating an already installed and working mono. Wine doesn't trigger installations/updates of mono for app needs or botched configurations. In a bottle configured without mono, if an app needs it, then mono has to be manually installed, as wine will do nothing about it. Similarly, gecko. (In reply to Morgan Leijström from comment #31) > Clarification request Usually, the WINEPATH is not supposed to be used/specified by user. I included in the instructions for detective work if needed.
I read that to mean our packaged software is working as designed, if users have any questions users can ask upstream. Thus I close this as RESOLVED WORKSFORME, with no dependency. --- Please tell if Errata should be changed, and what if so: https://wiki.mageia.org/en/Mageia_9_Errata#Various_software currently say " mga#28814, mga#28840, mga#31989 - Wine missing a few dependencies, especially for 32 bit libs. (Thus also PlayOnLinux.) Manual fix and also other tips here. If launching a wine app gives warnings that suitable versions are missing, see mga#16273. "
Status: REOPENED => RESOLVEDPriority: High => NormalDepends on: 33903 => (none)Resolution: (none) => WORKSFORMEStatus comment: Update errata when fixed => Update errata?