Description of problem:as above Version-Release number of selected component (if applicable): How reproducible:always Steps to Reproduce: 1.install wine64 plus the 32-bit wine support (needed 2.download the Xray viewer from https://www.qldxray.com.au/referrers/image-and-report-delivery/queensland-x-ray-inteleviewer 3.install it under wine64. Note error message during installation: MESA-INTEL: warning: Haswell Vulkan support is incomplete 4. Try and run it: fails, I'll attach popup after registering this bug 5. Subsequent attempts to run the program from icon installed on desktop fail Tony Inteleviewer have long prided themselves on how well their app runs under wine - rightly so. Installs and runs perfectly under M8 and many earlier versions.
Created attachment 13865 [details] error on win64 program start unexpected popup on attempting start of inteleviewer. A bit cryptic and perhaps beside the point of the Haswell Vulcan issue
Created attachment 13866 [details] log of installing win64 program under wine
The first "untrunsted application launcher" message is for security... it wants to be sure you want to start it... unfortunately not much we can do about that "MESA-INTEL: warning: Haswell Vulkan support is incomplete" If I recall correctly Haswell GPU doesn't really supports features needed for proper Vulkan support. Intel officially supports Vulkan on Skylake or newer on Windows and Broadwell or newer on Linux. Support for Ivy Bridge and Haswell is unofficial and incomplete and it probably won't be complete in near future or even at all since most hw driver devs primarily focus on current/recent/new hw
Thanks Thomas for commenting. I understand absolutely nothing. But this seems important: > Installs and runs perfectly under M8 and many earlier versions So what has gone wrong now?
CC: (none) => tmb
CC: (none) => lewyssmith
Ha, haven't entirely got my brain around this but explanation may be simple. I think the wine setup of exec script attached to desktop icon for just-installed win64 exe file on M9 may be corrupt. M9 desktop icon: env WINEPREFIX="/home/tony/.wine/dosdevices/d:/.wine" wine C:\\\\users\\\\Public\\\\Desktop\\\\InteleViewer\\ \\(64-bit\\).lnk M8 desktop icon: env WINEPREFIX="/home/tony/.wine" wine C:\\windows\\command\\start.exe /Unix /home/tony/.wine/dosdevices/c:/users/Public/Desktop/InteleViewer\ \(64-bit\).lnk winecfg shows same drives in both M8 and M9: C: ../drive_c D: /home/tony Z: / The fix: just copied the correct M8 string from M8 partition, plonked it in my terminal prompt in M9 and inteleviewer started normally. This is a quite reproducible bug, in that multiple installs of inteleviewer under M9 produce the same exec script as above. Tony
Nice detective work! This is definitely & easily fixable, as you have shown. Assigning to tv for Wine.
Assignee: bugsquad => thierry.vignaudSummary: windows 64 bit program wine install fails:MESA-INTEL: warning: Haswell Vulkan support is incomplete => windows 64 bit program wine install fails:MESA-INTEL: warning: Haswell Vulkan support is incomplete. Worked M8. Believe fault is definition of M9 WINEPREFIXKeywords: (none) => FOR_ERRATA9Source RPM: (none) => wine-8.0-7.mga9.src.rpmCC: lewyssmith, tmb => (none)
In passing, my original title for this bug is now wrong/irrelevant - nothing to do with the Haswell Vulkan message - which appears same during a successful M8 install and doesn't stop apps working in either M8 or M9. Likewise I guess no need for an Errata9 comment on this - not for this reason anyway. Tony
Great you found it I let the FOR_ERRATA stand until fixed, as this is a regression from mga8. And if not fixed at release, it do deserve an entry in errata, with the workaround tip. I would believe a wrong WINEPREFIX will hit may applications, but with different misleading error messages like this one about Vulkan in your case.
CC: (none) => fri
Trying to re-visit this bug and ran into unexpected problem. If my memory is correct the Intelleviewer program referenced above has always needed wine32 present to install on wine64, despite callint itself a 64-bit program. I assume there must be some 32-bit code in there somewhere. Issue now is that MCC says that wine32 package for 32-bit support on wine can't be installed. - No further info there. (Had done a reboot after installing wine64 on this newly-installed but fully updated system.) Attempting wine32 from urpmi gives: # urpmi wine32 The following packages can't be installed because they depend on packages that are older than the installed ones: libdri-drivers-23.1.5-2.mga9 libmesagl1-23.1.5-2.mga9 libgl1-1.6.0-1.mga9 libcairo2-1.17.6-2.mga9 libgldispatch0-1.6.0-1.mga9 libpoppler-glib8-23.02.0-1.mga9 libharfbuzz0-7.0.1-1.mga9 libsane1-1.1.1-4.mga9 libglx0-1.6.0-1.mga9 libfreetype6-2.13.0-1.mga9 wine32-8.0-7.mga9 libfontconfig1-2.14.2-1.mga9 libpoppler126-23.02.0-1.mga9 Continue installation anyway? (Y/n) I chose not to continue pending advice from here! Tony
Status comment: (none) => WINEPREFIX fix in C5, version conflicts in C9Summary: windows 64 bit program wine install fails:MESA-INTEL: warning: Haswell Vulkan support is incomplete. Worked M8. Believe fault is definition of M9 WINEPREFIX => WINE: Problematic WINEPREFIX, and dep version conflicts
Keywords: FOR_ERRATA9 => IN_ERRATA9
(In reply to Tony Blackwell from comment #9) > The following packages can't be installed because they depend on packages > that are older than the installed ones: Most likely the corresponding 32bit repos to the already available 64bit ones are not enabled, i.e. repo "Core Updates", a 64bit repo, is enabled while repo "Core 32bit Updates" is not, similar to bug #29205. Regards.
CC: (none) => arusanu
I've split off the issue of wine32 no longer installing in M9 into new bug 32633. Seems important enough in its own right to separate from this. Tony
thanks Aurelian for very prompt reply. Not something I'd thought of but I don't think is the explanation here - see my detailed response in bug 32633 where I've also taken the liberty of transposing your suggestion above. Regards, Tony
OK, bug 32633 resolved. I guess we are back to Morgan's comment 8, leting the original bug stand for the moment as per his comment there. Thankyou all for very speedy assistance with the split-off bug, now fixed. Regards to all, Tony
The problem here is not fixed. Installing a program with wine64 still generates corrupt string/ Attempting to run an installed program from its icon on the linux desktop results in a popup displaying the same faulty string as reported in comment 5 above. See attached pic of screen popup 'Untrusted Application Launcher'
Created attachment 14230 [details] popp on failure to start wine-installed program
Where do we go from here in getting the corect string installed?
(In reply to Tony Blackwell from comment #15) This looks like your desktop icon doesn't have the executable bit set, hence the security check/challenge. Try to set it with "chmod u+x your_file.desktop".
True, but I should have said I'd deliberately unset it to give the popup window with the wine prefix strings visible. With the executeable bit set, the desktop icon just fails silently. Problem is the wineprefix string is still completely garbled as I understand it, so its never going to successfully call the program. As per comment 5 above, M8 generates the correct wine prefix. Where does the fix need to happen here?
The string formats for WINEPREFIX and executable paths in the .desktop file for both M9/M8 are valid for wine. One other thing to try is to replace " wine " with " win64 " in .desktop file for Mageia9. If that works then wine should be updated to 8.0.1 at least, see https://bugs.winehq.org/show_bug.cgi?id=54371 .
Reassigning to all packagers collectively, because currently maintdb says "nobody" is wine's maintainer
CC: (none) => marja11Assignee: thierry.vignaud => pkg-bugs
For me, this generated command attached to the desktop icon for a program newly-installed under wine fails to start my program: env WINEPREFIX="/home/tony/.wine/dosdevices/d:/.wine" wine C:\\\\users\\\\Public\\\\Desktop\\\\InteleViewer\\ \\(64-bit\\).lnk but if I copy this from my m8 icon and drop it into a command prompt, then the app starts: env WINEPREFIX="/home/tony/.wine" wine C:\\windows\\command\\start.exe /Unix /home/tony/.wine/dosdevices/c:/users/Public/Desktop/InteleViewer\ \(64-bit\).lnk Why is the generated WINEPREFIX string different in M9 and does anyone else find the M9 string works for them??
It seems that my claim that path formats should work either way(comment #19) is wrong, sorry for that. However, using VM's, I tested installation of your program in Mageia 8, 9 and cauldron and, for all of them, the generated desktop files are identical and all of them are launching the program just fine, no need to modify them. These were straight up installs, i.e. have wine64/wine32 installed and double click the installer, no customization needed. It might be something specific to your system setup/environment that triggers this. To be clear, my tests were carried using default Mageia settings for KDE Plasma as DE and bash environment for terminal within a clean wine prefix. I cannot reproduce your issues nor the desktop icon file you used for Mageia 8 and to fix your desktop file on Mageia 9. You may try to reinstall your application in a clean wine prefix, preferably using a new test user account to have a pristine environment and to avoid data/setup lost from your current account.
Aurelian, thanks for your interest and attention as I muddle through this. Could you please post here a copy of your M9-generated env string from the icon which successfully starts your wine-installed program in M9.. (and also from your M8 if you still have any working installations left). I had tested this on a brand-new install of M9 before bug-reporting it and had the same problems there, but will do so again. I'll make time to follow your suggestions. Tony
Created attachment 14261 [details] wine valid "Exec=" formats for .desktop files Here it is: Mageia-8: env WINEPREFIX="/home/testuser/.wine" wine C:\\\\windows\\\\command\\\\start.exe /Unix /home/testuser/.wine/dosdevices/c:/users/Public/Desktop/InteleViewer\\ \\(64-bit\\).lnk Mageia-9: env WINEPREFIX="/home/testuser/.wine/dosdevices/d:/.wine" wine C:\\\\users\\\\Public\\\\Desktop\\\\InteleViewer\\ \\(64-bit\\).lnk In Mageia 9, wine works with both formats. Attached is a file of vary env formats that work for my system. Also, under KDE Plasma, to test/check validity of a *.desktop file from terminal run "kioclient5 exec $PathToFile/$FileName.desktop".