From https://ml.mageia.org/l/msg/dev/2025-01/PaDPLSBG7Jjw14nL73bNVw : In Mageia 9, Wine is really behind, at an early 8.0 Maybe we should aim for an regular update to 9.22 released December upstream, for both Cauldron and mga9. And on Cauldron after that shift to have 10.x - now at RC4 upstream, and later backport if needed. While working on it, also consider open bugs and quirks, some listed here: https://wiki.mageia.org/en/Ways_to_install_programs#Wine and Bug 16273 - wine-mono and wine-gecko must be rebuilt when wine is Bug 32972 - wine doesn't load its dependencies. Bug 33901 - wine-mono doesn't seem to build for SDL2 support. /Morgan
Whiteboard: (none) => MGA9TOOAssignee: bugsquad => pkg-bugsSummary: Updating Wine => Wine update request
I've submitted Wine 8.0.2. This version should fix the issues with loading its dependencies. I went with the conservative approach and updated to the bug-fixing release of Wine-8.0.2. In principle, we can upgrade to Wine-9.0, and even Wine-10.0 could be built for Mageia 9, but there should be consensus on this, as I think it will break the policy on upgrading packages.
CC: (none) => arusanu
(In reply to Aurelian R from comment #1) > I've submitted Wine 8.0.2. > This version should fix the issues with loading its dependencies. > > I went with the conservative approach and updated to the bug-fixing release > of Wine-8.0.2. In principle, we can upgrade to Wine-9.0, and even Wine-10.0 > could be built for Mageia 9, but there should be consensus on this, as I > think it will break the policy on upgrading packages. Then I assign to you
Assignee: pkg-bugs => arusanuCC: arusanu => (none)
Depends on: (none) => 16273
(In reply to Morgan Leijström from comment #0) > Bug 16273 - wine-mono and wine-gecko must be rebuilt when wine is I don't think that statement is right. Wine, indeed, has a hardcoded requirement on wine-gecko and wine-mono versions, which cannot be lower nor higher than Wine's requirement; otherwise, Wine will try to download the hardcoded versions, and, if the download fails or is canceled, some applications will not run. As long as wine-mono and wine-gecko satisfy Wine's version requirements, it is not necessary to rebuild these packages. Any issues here arise only from versions mismatching, IMO.
New wine-8.0.2 is available in the Mageia 9-core/updates_testing repository. The wine issues reported here have been addressed, and wine has been also updated to the latest bug release for version 8.0. Any feedback will be appreciated. Proposed Mageia 9 Advisory: Type: bugfix and upgrade Description: When installed or upgraded, "Wine" does not load all of the libraries it depends on. This update upgrades "Wine" to the bug release version 8.0.2 and fixes loading libraries that "Wine" requires. RPMS: i586: wine-8.0.2-1.mga9.i586.rpm wine-devel-8.0.2-1.mga9.i586.rpm wine32-8.0.2-1.mga9.i586.rpm x86_64: wine64-8.0.2-1.mga9.x86_64.rpm wine64-devel-8.0.2-1.mga9.x86_64.rpm SRPM: wine-8.0.2-1.mga9
Assignee: arusanu => qa-bugsBlocks: (none) => 28814
MGA9-64 server Plasma Wayland on Compaq H000SB. No installation issues. Ref bug 26093 fro testing. Hmmmm, strange thing.... Starting winemine just produces an icon in the panel, but no window shows up. winefile opens, tried to open a txt file, produces a Notepad window that hangs empty. Getting pages full of feedback in the CLI. Install q4wine, that draws in some more packages, configure to use wine64. Now explorer opens, iexplore, notepad, winemine, all OK, but wordpad does not open. Doesn't feel good.
CC: (none) => herman.viaene
RH x86_64 installing /var/cache/urpmi/rpms/mingw32-gcc-12.2.1-3.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw32-winpthreads-static-10.0.0-2.mga9.noarch.rpm /var/cache/urpmi/rpms/mingw32-headers-10.0.0-7.mga9.noarch.rpm /var/cache/urpmi/rpms/libglesv22-1.6.0-1.mga9.i586.rpm //home/katnatek/qa-testing/i586/wine32-8.0.2-1.mga9.i586.rpm /var/cache/urpmi/rpms/mingw32-libjpeg-turbo-2.1.4-1.mga9.noarch.rpm /var/cache/urpmi/rpms/mingw32-wine-gecko-2.47.3-3.mga9.noarch.rpm /var/cache/urpmi/rpms/libmesaglu1-9.0.2-3.mga9.i586.rpm /var/cache/urpmi/rpms/libpcsclite1-1.9.9-1.1.mga9.i586.rpm //home/katnatek/qa-testing/i586/wine-8.0.2-1.mga9.i586.rpm /var/cache/urpmi/rpms/libva2-2.22.0-1.mga9.i586.rpm /var/cache/urpmi/rpms/mingw32-binutils-2.39-2.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw32-gcc-c++-12.2.1-3.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw32-cpp-12.2.1-3.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw32-libtiff-4.4.0-1.mga9.noarch.rpm Preparing... ################################################################################################## 1/15: mingw32-libjpeg-turbo ################################################################################################## 2/15: mingw32-cpp ################################################################################################## 3/15: mingw32-binutils ################################################################################################## 4/15: mingw32-headers ################################################################################################## 5/15: mingw32-winpthreads-static ################################################################################################## 6/15: mingw32-gcc ################################################################################################## 7/15: mingw32-gcc-c++ ################################################################################################## 8/15: mingw32-libtiff ################################################################################################## 9/15: libva2 ################################################################################################## 10/15: libpcsclite1 ################################################################################################## 11/15: libmesaglu1 ################################################################################################## 12/15: libglesv22 ################################################################################################## 13/15: mingw32-wine-gecko ################################################################################################## 14/15: wine ################################################################################################## 15/15: wine32 ################################################################################################## 1/2: removing wine32-1:8.0-7.mga9.i586 ################################################################################################## 2/2: removing wine-1:8.0-7.mga9.i586 ################################################################################################## writing /var/lib/rpm/installed-through-deps.list The following package: mingw64-wine-gecko-2.47.3-3.mga9.noarch is now orphaned, if you wish to remove it, you can use "urpme --auto-orphans" Fetch some mesa i586 packages, that should be good for bug#28814 But is weird the suggestion to remove mingw64-wine-gecko-2.47.3-3.mga9.noarch if I understand well the function is covered by mingw32-wine-gecko-2.47.3-3.mga9.noarch.rpm but still is weird The minesweeper game & notepad start well, @Herman did you enable the 32bit repository?
(In reply to Herman Viaene from comment #5) > Now explorer opens, iexplore, notepad, winemine, all OK, but wordpad does > not open. Wordpad destop entry seems to be broken. It must have been present before but unnoticed until now, I will add an entry in the build spec to watch out for it. The workaround resumes to edit the menu entry: For x86_64: Command line: wine64 wordpad Working directoty:/usr/lib64/wine/x86_64-windows/ For i586: Command line: wine wordpad Working directoty:/usr/lib/wine/i386-windows/ Or run from terminal: On x86_64: $ wine64 /usr/lib64/wine/x86_64-windows/wordpad.exe On i586: $ wine /usr/lib64/wine/i368-windows/wordpad.exe > Starting winemine just produces an icon in the panel, but no window shows up. > winefile opens, tried to open a txt file, produces a Notepad window that > hangs empty. Getting pages full of feedback in the CLI. I cannot reproduce this. > Install q4wine, that draws in some more packages, configure to use wine64. q4wine does need some extra Qt libraries and might pull some other libraries for its own interface but also pulls wine. @Herman Can you confirm that the wine-8.0 was staring normally on that machine before upgrading. Because either the initial upgrade wasn't completed properly before you installed q4wine or the local .wine bottle was broken and somehow got fixed in a second try for these wine apps to start in the end.
@katnatek No, no 32-bit repos enabled. Why should I, nothing in the installation pointed in that direction. @Aurelian This laptop was completely reinstalled about a month ago, but with preserving the home. So I deleted the .wine folder and did my tests in winefile and winemine over and now these work correctly. And your workaround for wordpad is also OK. So presuming this snag will be corrected here, I'll leave the bug open. But if you decide a new bug for that is better, I will not object to you let it go.
@Herman I presume you didn't keep a backup of that wine bottle; It would have been interesting to see if the behavior was reproducible. I will send in a new release for that later today or tomorrow, barring the feedback doesn't get worse. (In reply to katnatek from comment #6) > But is weird the suggestion to remove mingw64-wine-gecko-2.47.3-3.mga9.noarch > if I understand well the function is covered by > mingw32-wine-gecko-2.47.3-3.mga9.noarch.rpm but still is weird Indeed, that is not right. Can you reproduce the error if you do the following: uninstall wine64/wine32 and mingw32(64)-wine-gecko, maybe use urpme --auto-orphans too, then disable Core/Updates_testing(64/32-bits) repos, reinstall old wine64-8.0, re-enable Core/Updates_testing(64/32-bits) repos, and finally check if error persists when installing again wine64-8.0.2.
(In reply to Aurelian R from comment #9) > @Herman I presume you didn't keep a backup of that wine bottle; It would > have been interesting to see if the behavior was reproducible. > I will send in a new release for that later today or tomorrow, barring the > feedback doesn't get worse. > > (In reply to katnatek from comment #6) > > But is weird the suggestion to remove mingw64-wine-gecko-2.47.3-3.mga9.noarch > > if I understand well the function is covered by > > mingw32-wine-gecko-2.47.3-3.mga9.noarch.rpm but still is weird > Indeed, that is not right. > Can you reproduce the error if you do the following: > uninstall wine64/wine32 and mingw32(64)-wine-gecko, maybe use urpme > --auto-orphans too, then disable Core/Updates_testing(64/32-bits) repos, > reinstall old wine64-8.0, re-enable Core/Updates_testing(64/32-bits) repos, > and finally check if error persists when installing again wine64-8.0.2. What I did is with 64 & 32 bit repositories enabled, install wine, then add 32 & 64bit packages to qarepo and update I most test clean install testing packages with current and new profile just with 64b repositories to check if I can reproduce Herman's bug
Without 32b repositories LC_ALL=C urpmi wine No package named wine LC_ALL=C urpmi wine64 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (Installer) (DVD1)") sane-frontends 1.0.14 28.mga9 x86_64 (recommended) (medium "QA Testing (64-bit)") wine64 8.0.2 1.mga9 x86_64 (medium "Core Release") mingw-binutils-generic 2.39 2.mga9 x86_64 mingw-filesystem-base 145 2.mga9 noarch mingw64-SDL2 2.26.3 1.mga9 noarch mingw64-binutils 2.39 2.mga9 x86_64 mingw64-cpp 12.2.1 3.mga9 x86_64 mingw64-crt 10.0.0 2.mga9 noarch mingw64-faudio 22.12 1.mga9 noarch mingw64-filesystem 145 2.mga9 noarch mingw64-gcc 12.2.1 3.mga9 x86_64 mingw64-gcc-c++ 12.2.1 3.mga9 x86_64 mingw64-headers 10.0.0 7.mga9 noarch mingw64-lcms2 2.14 1.mga9 noarch mingw64-libgcc 12.2.1 3.mga9 x86_64 mingw64-libjpeg-turbo 2.1.4 1.mga9 noarch mingw64-libpng 1.6.37 5.mga9 noarch mingw64-libtiff 4.4.0 1.mga9 noarch mingw64-libxml2 2.10.3 1.mga9 noarch mingw64-libxslt 1.1.37 1.mga9 noarch mingw64-vkd3d 1.6 1.mga9 noarch mingw64-win-iconv 0.0.8 3.mga9 noarch mingw64-wine-gecko 2.47.3 3.mga9 noarch (recommended) mingw64-winpthreads 10.0.0 2.mga9 noarch mingw64-winpthreads-static 10.0.0 2.mga9 noarch mingw64-zlib 1.2.13 1.mga9 noarch wine-mono 7.4.0 1.mga9 noarch (recommended) (medium "Core Updates") lib64unixODBC2 2.3.11 1.1.mga9 x86_64 (medium "Tainted Updates") lib64osmesa8 25.0.7 4.mga9.taint> x86_64 1.2GB of additional disk space will be used. 287MB of packages will be retrieved. Proceed with the installation of the 29 packages? (Y/n) y End of installation, one of those message ignored in the gui :P More information on package wine64-8.0.2-1.mga9.x86_64 This is the Win64 version of Wine. This version can only be used to run 64-bit Windows applications as is. For running 32-bit Windows applications, you need to also install the 'wine32' package from the 32-bit repository. Run mineswepper from dolphin started in terminal wine: '/home/katnatek/.wine' is a 32-bit installation, it cannot support 64-bit applications. With clean profile kf.coreaddons: "Could not load plugin from /usr/lib64/qt5/plugins/ffmpegthumbs.so: Failed to extract plugin meta data from '/usr/lib64/qt5/plugins/ffmpegthumbs.so'" kf.kio.widgets: Failed to check which JobView API is supported "The name org.kde.kuiserver was not provided by any .service files" wine: created the configuration directory '/home/katnatek/.wine' 002c:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0048:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0050:fixme:actctx:parse_depend_manifests Could not find dependent assembly L"Microsoft.Windows.Common-Controls" (6.0.0.0) 0048:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 0048:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 0048:err:ole:apartment_get_local_server_stream Failed: 0x80004002 0048:err:ole:start_rpcss Failed to open RpcSs service 0050:err:ole:StdMarshalImpl_MarshalInterface Failed to create ifstub, hr 0x80004002 0050:err:ole:CoMarshalInterface Failed to marshal the interface {6d5140c1-7436-11ce-8034-00aa006009fa}, hr 0x80004002 0050:err:ole:apartment_get_local_server_stream Failed: 0x80004002 0050:fixme:imm:ImeSetActiveContext (000000000001002E, 0): stub 0050:fixme:imm:ImmReleaseContext (0000000000010020, 000000000001002E): stub 002c:fixme:imm:ImeSetActiveContext (0000000000010056, 1): stub 002c:fixme:imm:ImmReleaseContext (0000000000010054, 0000000000010056): stub 008c:fixme:file:NtLockFile I/O completion on lock not implemented yet 008c:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 0094:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-7.4.0\\support\\removeuserinstalls-x86.exe" in experimental wow64 mode 0094:err:module:load_wow64_ntdll failed to load L"\\??\\C:\\windows\\syswow64\\ntdll.dll" error c0000135 0094:err:virtual:virtual_setup_exception stack overflow 1536 bytes addr 0x170025c4c stack 0x610a00 (0x610000-0x611000-0x70fd20) 009c:err:environ:init_peb starting L"Z:\\usr\\share\\wine\\mono\\wine-mono-7.4.0\\support\\installinf-x86.exe" in experimental wow64 mode 009c:err:module:load_wow64_ntdll failed to load L"\\??\\C:\\windows\\syswow64\\ntdll.dll" error c0000135 009c:err:virtual:virtual_setup_exception stack overflow 1536 bytes addr 0x170025c4c stack 0x610a00 (0x610000-0x611000-0x70fd20) 008c:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 1) 008c:fixme:msi:internal_ui_handler internal UI not implemented for message 0x0b000000 (UI level = 1) wine: failed to open L"C:\\windows\\syswow64\\rundll32.exe": c0000135 0110:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0110:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0110:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 0110:fixme:hid:handle_IRP_MN_QUERY_ID Unhandled type 00000005 wine: configuration in L"D:\\.wine" has been updated. 0144:fixme:imm:ImeSetActiveContext (0000000000030044, 1): stub 0144:fixme:imm:ImmReleaseContext (000000000003004E, 0000000000030044): stub The game start without issues In my opinion, wine package should be created as a task package wine-<version>-<release>-<architecture> Require wine<bits>-<version>-<release> and for the 64bit version, recommends wine32-<version>-<release> So I guess the Herman's issue could be a profile issue that was fixed by q4wine
(In reply to katnatek from comment #10) > What I did is with 64 & 32 bit repositories enabled, install wine, then add > 32 & 64bit packages to qarepo and update Let me see if I got this right. On Mageia 9 - x86_64 First, you enabled 64-bit and 32-bit repos. Secondly, you installed the 32-bit Wine package from the 32-bit repo. > ################################################################################################## > 14/15: wine > ################################################################################################## > 15/15: wine32 > > But is weird the suggestion to remove mingw64-wine-gecko-2.47.3-3.mga9.noarch Then the suggestion to remove mingw64-wine-gecko-2.47.3-3.mga9.noarch is correct. You basically installed the 32-bit wine to run only 32-bit bottles on a 64-bit system. In this case the package is not necessary even if the installation is on Magia 9 - x86_64. On Mageia-x86_64, I, for one, like to be able to run both 64-bit and 32-bit apps in the same Wine bottle. Furthermore, there are quite a lot of windows apps that need both 32-bit and 64-bit support. For that, one can install wine64 together with the wine32 package from the i586 repos.
(In reply to Aurelian R from comment #12) > (In reply to katnatek from comment #10) > > What I did is with 64 & 32 bit repositories enabled, install wine, then add > > 32 & 64bit packages to qarepo and update > > Let me see if I got this right. > On Mageia 9 - x86_64 > First, you enabled 64-bit and 32-bit repos. > Secondly, you installed the 32-bit Wine package from the 32-bit repo. > > ################################################################################################## > > 14/15: wine > > ################################################################################################## > > 15/15: wine32 > > > > But is weird the suggestion to remove mingw64-wine-gecko-2.47.3-3.mga9.noarch > Then the suggestion to remove mingw64-wine-gecko-2.47.3-3.mga9.noarch is > correct. You basically installed the 32-bit wine to run only 32-bit bottles > on a 64-bit system. In this case the package is not necessary even if the > installation is on Magia 9 - x86_64. > > On Mageia-x86_64, I, for one, like to be able to run both 64-bit and 32-bit > apps in the same Wine bottle. Furthermore, there are quite a lot of windows > apps that need both 32-bit and 64-bit support. For that, one can install > wine64 together with the wine32 package from the i586 repos. LC_ALL=C urpmi wine To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release (Installer) (DVD1)") sane-frontends 1.0.14 28.mga9 x86_64 (recommended) (medium "Core Release") mingw-binutils-generic 2.39 2.mga9 x86_64 mingw-filesystem-base 145 2.mga9 noarch mingw32-SDL2 2.26.3 1.mga9 noarch mingw32-crt 10.0.0 2.mga9 noarch mingw32-faudio 22.12 1.mga9 noarch mingw32-filesystem 145 2.mga9 noarch mingw32-lcms2 2.14 1.mga9 noarch mingw32-libgcc 12.2.1 3.mga9 x86_64 mingw32-libpng 1.6.37 5.mga9 noarch mingw32-libxml2 2.10.3 1.mga9 noarch mingw32-libxslt 1.1.37 1.mga9 noarch mingw32-vkd3d 1.6 1.mga9 noarch mingw32-win-iconv 0.0.8 3.mga9 noarch mingw32-winpthreads 10.0.0 2.mga9 noarch mingw32-zlib 1.2.13 1.mga9 noarch mingw64-wine-gecko 2.47.3 3.mga9 noarch (recommended) wine-mono 7.4.0 1.mga9 noarch (recommended) (medium "Core 32bit Release") libgsm1 1.0.19 2.mga9 i586 libnl-genl3_200 3.7.0 1.mga9 i586 libnl3_200 3.7.0 1.mga9 i586 libopencl1 2.3.1 2.mga9 i586 libunwind8 1.6.2 3.mga9 i586 libxcomposite1 0.4.6 1.mga9 i586 libxcrypt1 4.4.33 3.mga9 i586 libxcursor1 1.2.1 1.mga9 i586 libxi6 1.8 2.mga9 i586 libxinerama1 1.1.5 1.mga9 i586 libxrandr2 1.5.3 2.mga9 i586 wine 8.0 7.mga9 i586 wine32 8.0 7.mga9 i586 (medium "Core 32bit Updates") libcups2 2.4.6 1.3.mga9 i586 libgstreamer-plugins-base1.0_0 1.22.11 1.2.mga9 i586 libgstreamer1.0_0 1.22.11 1.1.mga9 i586 liborc0.4_0 0.4.33 1.1.mga9 i586 libpcap1 1.10.5 1.mga9 i586 libunixODBC2 2.3.11 1.1.mga9 i586 (medium "Tainted 32bit Updates") libosmesa8 25.0.7 4.mga9.taint> i586 945MB of additional disk space will be used. 227MB of packages will be retrieved. You are right, but acting as a user that don't know how the stack is packaged in mageia I try to install wine and not wine<bits>, that is why I think wine should be an empty task package that bring the required/recommended packages in each arch
RH x86_64 New test clean .wine folder Install current wine64 Test notepad and minesweeper OK installing /var/cache/urpmi/rpms/mingw64-gcc-c++-12.2.1-3.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw64-gcc-12.2.1-3.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw64-cpp-12.2.1-3.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw64-libtiff-4.4.0-1.mga9.noarch.rpm /var/cache/urpmi/rpms/mingw64-binutils-2.39-2.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw64-winpthreads-static-10.0.0-2.mga9.noarch.rpm //home/katnatek/qa-testing/x86_64/wine64-8.0.2-1.mga9.x86_64.rpm /var/cache/urpmi/rpms/mingw64-headers-10.0.0-7.mga9.noarch.rpm /var/cache/urpmi/rpms/mingw64-wine-gecko-2.47.3-3.mga9.noarch.rpm /var/cache/urpmi/rpms/mingw64-libjpeg-turbo-2.1.4-1.mga9.noarch.rpm Preparing... ################################################################################################## 1/10: mingw64-libjpeg-turbo ################################################################################################## 2/10: mingw64-headers ################################################################################################## 3/10: mingw64-winpthreads-static ################################################################################################## 4/10: mingw64-binutils ################################################################################################## 5/10: mingw64-cpp ################################################################################################## 6/10: mingw64-gcc ################################################################################################## 7/10: mingw64-gcc-c++ ################################################################################################## 8/10: mingw64-libtiff ################################################################################################## 9/10: mingw64-wine-gecko ################################################################################################## 10/10: wine64 ################################################################################################## 1/1: removing wine64-1:8.0-7.mga9.x86_64 ################################################################################################## writing /var/lib/rpm/installed-through-deps.list The following package: mingw32-wine-gecko-2.47.3-3.mga9.noarch Test notepad and minesweeper From winefile I can't open text files wine: Read access denied for device L"\\??\\E:\\", FS volume label and serial are not available. wine: Read access denied for device L"\\??\\F:\\", FS volume label and serial are not available. wine: Read access denied for device L"\\??\\G:\\", FS volume label and serial are not available. wine: Read access denied for device L"\\??\\H:\\", FS volume label and serial are not available. wine: Read access denied for device L"\\??\\I:\\", FS volume label and serial are not available. wine: Read access denied for device L"\\??\\J:\\", FS volume label and serial are not available. wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial are not available. I think we need test from more intesive wine users
CC: (none) => Joselp, ezequiel_partida
Please backup your .wine folder before make test in case something break after the update
"Wine"'s default assignment of letters for drives: A: - Historically, this letter was assigned to floppy drives, but I do not currently have one. C: - The "Windows" C: drive for the "Wine" bottle. D: - Your Linux $HOME directory. Z: - Your Linux system root directory "/". The rest of the letters may show the partitions/mounts existing on your system even if they are not active or accessible for any reason. For a basic test purpose, the drives C:, D:,and Z: should show up by default. As D: is the link to your Linux home directory, you should be able to navigate with "Wine File Manager" and open any text file, *.txt, in Notepad. Watch out, the files extension matters more in Windows.
I would try to summarize/list the basic steps to test/validate wine packages. Tip: the environment variable "WINEPREFIX" controls which bottle Wine will use. Ex: generate WineTests bottle: > mkdir -p ~/MyWineBottles/WineTests; WINEPREFIX=~/MyWineBottles/WineTests winecfg Ex: run winemine in "WineTests" bottle: > WINEPREFIX=$HOME/MyWineBottles/WineTests winemine Prepare a Wine bottle with the current version of Wine: Install the current version of wine and run: > mkdir -p $HOME/WinePrev; WINEPREFIX="$HOME/WinePrev" winecfg Save/Rename/Remove the default Wine bottle if it exist > mv $HOME/.wine $HOME/.wine_SAVE_$SRANDOM 1: Install/upgrade wine/wine64 packages without issues Pure 64/32-bit systems: 2: Running core Wine tests: a) Run basic tests (winecfg, winemine ...) in a pristine environment (no "$HOME/.wine"). This step should generate the "$HOME/.wine" bottle, which is the default bottle for Wine. b) Test the update of the Wine bottle "WinePrev" for the new version of Wine. Either rename "$HOME/WinePrev" to "$HOME/.wine" or use the WINEPREFIX variable and run: > WINEPREFIX="$HOME/WinePrev" winecfg . Mixed 64/32-bit install on Mageia-x86_64: 3: Test loading the 32-bit Wine packages on x86_64 systems: When the 32-bit repos are enabled, installing wine64 will install wine32 package, which will allow the 32-bit apps to run with wine64, something like: > wine /usr/lib/wine/i386-windows/wordpad.exe > wine64 /usr/lib/wine/i386-windows/wordpad.exe If wine64 have been installed before enabling 32-bit repos, then either reinstall wine64 or manually install wine32. Assuming all steps are completed successfully, then Wine should, in principle, be able to be installed without issues, to start/create a new Wine bottle, and to update/use an existing Wine bottle. Unfortunately, Wine gives no guarantees that its new versions won't break previously working applications, but it should work with the ones it ships with (notepad, wordpad...). However, the real fun starts with bottles populated already with complex apps like office apps, games... At this point you basically rely on users feedback/observations.
(In reply to Aurelian R from comment #16) > "Wine"'s default assignment of letters for drives: > A: - Historically, this letter was assigned to floppy drives, but I do not > currently have one. > C: - The "Windows" C: drive for the "Wine" bottle. > D: - Your Linux $HOME directory. > Z: - Your Linux system root directory "/". > The rest of the letters may show the partitions/mounts existing on your > system even if they are not active or accessible for any reason. > > For a basic test purpose, the drives C:, D:,and Z: should show up by > default. > As D: is the link to your Linux home directory, you should be able to > navigate with "Wine File Manager" and open any text file, *.txt, in Notepad. > Watch out, the files extension matters more in Windows. The file that not open is in my home folder, but if I open from the notepad, I have no issues, I use wine time ago, buy since some years I just use mageia and applications that run in Linux
I've submitted the fixes for Wine desktop menu entries. It should be become available soon: wine-8.0.2-1.1
New wine-8.0.2 is available in the Mageia 9-core/updates_testing repository. The wine issues reported here have been addressed, and wine has been also updated to the latest bug release for version 8.0. Any feedback will be appreciated. Proposed Mageia 9 Advisory: Type: bugfix and upgrade Description: When installed or upgraded, "Wine" does not load all of the libraries it depends on. This update upgrades "Wine" to the bug release version 8.0.2 and fixes loading libraries that "Wine" requires. RPMS: i586: wine-8.0.2-1.1.mga9.i586.rpm wine-devel-8.0.2-1.1.mga9.i586.rpm wine32-8.0.2-1.1.mga9.i586.rpm x86_64: wine64-8.0.2-1.1.mga9.x86_64.rpm wine64-devel-8.0.2-1.1.mga9.x86_64.rpm SRPM: wine-8.0.2-1.1.mga9
Status comment: (none) => packages in comment 20
Version: Cauldron => 9Source RPM: wine, wine-mono, wine-gecko => wine,Whiteboard: MGA9TOO => (none)
RH x86_64 rpm -q wine64 wine64-8.0.2-1.1.mga9 This time run wine configuration Run file manager Open a txt file without issue Wordpad open without issues and I can open a file Tested with the profile created in previous test Looks good for the moment, I have to install wine32 and need suggestion to test bug#28814
Current package LC_ALL=C urpmi wine32 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core 32bit Release") libnl-genl3_200 3.7.0 1.mga9 i586 libnl3_200 3.7.0 1.mga9 i586 libopencl1 2.3.1 2.mga9 i586 libunwind8 1.6.2 3.mga9 i586 wine32 8.0 7.mga9 i586 (medium "Core 32bit Updates") libgstreamer-plugins-base1.0_0 1.22.11 1.2.mga9 i586 libgstreamer1.0_0 1.22.11 1.1.mga9 i586 liborc0.4_0 0.4.33 1.1.mga9 i586 libpcap1 1.10.5 1.mga9 i586 537MB of additional disk space will be used. 97MB of packages will be retrieved. Proceed with the installation of the 9 packages? (Y/n)n Testing package LC_ALL=C urpmi wine32 To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "QA Testing (32-bit)") wine32 8.0.2 1.1.mga9 i586 (medium "Core Release") mingw32-SDL2 2.26.3 1.mga9 noarch mingw32-binutils 2.39 2.mga9 x86_64 mingw32-cpp 12.2.1 3.mga9 x86_64 mingw32-crt 10.0.0 2.mga9 noarch mingw32-faudio 22.12 1.mga9 noarch mingw32-filesystem 145 2.mga9 noarch mingw32-gcc 12.2.1 3.mga9 x86_64 mingw32-gcc-c++ 12.2.1 3.mga9 x86_64 mingw32-headers 10.0.0 7.mga9 noarch mingw32-lcms2 2.14 1.mga9 noarch mingw32-libgcc 12.2.1 3.mga9 x86_64 mingw32-libjpeg-turbo 2.1.4 1.mga9 noarch mingw32-libpng 1.6.37 5.mga9 noarch mingw32-libtiff 4.4.0 1.mga9 noarch mingw32-libxml2 2.10.3 1.mga9 noarch mingw32-libxslt 1.1.37 1.mga9 noarch mingw32-vkd3d 1.6 1.mga9 noarch mingw32-win-iconv 0.0.8 3.mga9 noarch mingw32-winpthreads 10.0.0 2.mga9 noarch mingw32-winpthreads-static 10.0.0 2.mga9 noarch mingw32-zlib 1.2.13 1.mga9 noarch (medium "Core 32bit Release") libglesv22 1.6.0 1.mga9 i586 libgsm1 1.0.19 2.mga9 i586 libmesaglu1 9.0.2 3.mga9 i586 libnl-genl3_200 3.7.0 1.mga9 i586 libnl3_200 3.7.0 1.mga9 i586 libopencl1 2.3.1 2.mga9 i586 libunwind8 1.6.2 3.mga9 i586 libxcomposite1 0.4.6 1.mga9 i586 libxcrypt1 4.4.33 3.mga9 i586 libxcursor1 1.2.1 1.mga9 i586 libxi6 1.8 2.mga9 i586 libxinerama1 1.1.5 1.mga9 i586 libxrandr2 1.5.3 2.mga9 i586 (medium "Core 32bit Updates") libcups2 2.4.6 1.3.mga9 i586 libgstreamer-plugins-base1.0_0 1.22.11 1.2.mga9 i586 libgstreamer1.0_0 1.22.11 1.1.mga9 i586 liborc0.4_0 0.4.33 1.1.mga9 i586 libpcap1 1.10.5 1.mga9 i586 libpcsclite1 1.9.9 1.1.mga9 i586 libunixODBC2 2.3.11 1.1.mga9 i586 libva2 2.22.0 1.mga9 i586 (recommended) (medium "Tainted 32bit Updates") libosmesa8 25.0.7 4.mga9.taint> i586 904MB of additional disk space will be used. 168MB of packages will be retrieved. Proceed with the installation of the 44 packages? (Y/n) n I think the difference in the list of packages fetched talks better than me ;) Looks good too for the bug#28814
Installed new versions just for 64-bit Winmine opens OK. Winfile gives at the last line in the CLI: wine: Read access denied for device L"\\??\\Z:\\", FS volume label and serial are not available. It opens, I can navigate, but I cannot open any .txt file, giving the same error. I did not see that behavior with 8.0.2-1. And before someone asks, I deleted -wine and tried again, all with same result.
(In reply to Herman Viaene from comment #23) > wine: Read access denied for device L"\\??\\Z:\\", FS volume label and > serial are not available. > It opens, I can navigate, but I cannot open any .txt file, giving the same > error. Unfortunately I cannot reproduce this issue with winefile. I couldn't when katnatek mentioned it for version 8.0.2-1 nor for this one. I have a real hardware install of Mageia 9, and 3 VM setups, but I cannot reproduce this on any setup I have. Can you try to open a *.jpg (png won't work) file with winefile. Mageia's background file should do: /usr/share/mga/backgrounds/default.jpg > winefile 'Z:\usr\share\mga\backgrounds\.' This will test if it is an issue with .txt file extension or for any file extensions. It will also test if wine-gecko is working fine by opening the file in "Wine Internet Explorer."
Can't reproduce the Herman's issue in clean profile @Herman the issue continue if you run wine configurator?
Did whole sequence - old version - delete ~/.wine , new version. And now I found rather accidently what was my problem: When I navigate to some folder in D:/Documents, pick a .txt file and double left click on it, notepad opens OK and displays the contents of the file OK. But when I right click on the same file and then pick "Open" from the context menu, then nothing happens. Happens the same in old 8.0-7 and new 8.0.2-11. So IMHO this is not a regression, but I wonder whether this is expected behavior.
(In reply to Herman Viaene from comment #26) > So IMHO this is not a regression, but I wonder whether this is expected behavior. Different habits, different outcomes. Thanks to your perseverance, guys, we got a clearer picture. The "Open" context menu works fine in wine-10. It got fixed late in the wine-9.* development stage.
Without more breve souls and with the result of the test, as long as the Herman's issue is not a regression, this looks good to me
Whiteboard: (none) => MGA9-64-OKKeywords: (none) => advisoryCC: (none) => andrewsfarm
I'm glad you guys, users with successful experience, have been dealing with this. I gave up on trying to use WINE years ago - could never get it to do the simplest thing. Perhaps it's easier now, but it was very frustrating back then. For the few Windows apps that I simply must use, I have Windows VMs in VirtualBox. Validating on faith in QA.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
This is marked as being blocked by bug 16273, but those packages don't look like they're ready to be pushed so I'll hold off on pushing this one.
CC: (none) => dan
(In reply to Dan Fandrich from comment #30) > This is marked as being blocked by bug 16273, but those packages don't look > like they're ready to be pushed so I'll hold off on pushing this one. Aurelian not consider should be a block, comment #3, trust in his word and if not works as must we can assign that bug to him ;)
Depends on: 16273 => (none)
(In reply to Dan Fandrich from comment #30) > This is marked as being blocked by bug 16273, but those packages don't look > like they're ready to be pushed so I'll hold off on pushing this one. The reporter can't make a test so we can't confirm if the bug persist
Installing the newer wine64 8.0.2 in the testing repository pulls in the packages mingw64-gcc, mingw64-gcc-c++, mingw64-headers, mingw64-cpp, and mingw64-binutils. This does not happen with the wine64 8.0 in the updates repository. Are the compiler packages needed for wine64 common usage?
CC: (none) => mageia
(In reply to PC LX from comment #33) > Are the compiler packages needed for wine64 common usage? These packages are pulled by mingw-libtiff, a package that adds support for TIFF files, and Wine expects it to be available.
(In reply to Aurelian R from comment #34) > (In reply to PC LX from comment #33) > > Are the compiler packages needed for wine64 common usage? > > These packages are pulled by mingw-libtiff, a package that adds support for > TIFF files, and Wine expects it to be available. Yes, it is the package mingw64-libtiff that is pulling the compiler. It needs the libstdc++-6.dll library and it in bundled with the C++ compiler. In cauldron the package mingw64-libstdc++ has the libstdc++-6.dll library. Since, wine is having a minor update, I wonder if its worth to also make the separate package for libstdc++-6.dll in Mageia 9? # urpmf --requires mingw64-libtiff mingw64-libtiff-static:mingw64-libtiff[== 4.4.0-1.mga9] mingw64-libtiff:mingw64(kernel32.dll) mingw64-libtiff:mingw64(libjpeg-62.dll) mingw64-libtiff:mingw64(libssp-0.dll) mingw64-libtiff:mingw64(libstdc++-6.dll) mingw64-libtiff:mingw64(libtiff-5.dll) mingw64-libtiff:mingw64(msvcrt.dll) mingw64-libtiff:mingw64(zlib1.dll) mingw64-libtiff:mingw64-crt mingw64-libtiff:mingw64-filesystem[>= 95] mingw64-libtiff:mingw64-pkg-config # urpmq --whatprovides 'mingw64(libstdc++-6.dll)' mingw64-gcc-c++ # urpmq -l mingw64-gcc-c++ | grep -P '\.dll$' /usr/x86_64-w64-mingw32/sys-root/mingw/bin/libstdc++-6.dll
It looks to me like both this bug and bug 28814 have issues that are claimed to be fixed by wine-8.0.2-1.mga9. Is that true? If so, can we combine both bugs and update the advisory to mention both issues? What testing is still required (for either bug)?
Blocks: (none) => 16273
Blocks: 16273 => (none)
(In reply to Dan Fandrich from comment #30) > This is marked as being blocked by bug 16273, but those packages don't look > like they're ready to be pushed so I'll hold off on pushing this one. I haven't yet seen any reproducible test that needs wine-mono/gecko packages to be rebuilt. Until now, bug 16273 only confirmed that wine starts downloading mono/gecko only when wine packages are out of sync or the wine bottles are misconfigured. (In reply to Dan Fandrich from comment #36) > It looks to me like both this bug and bug 28814 have issues that are claimed > to be fixed by wine-8.0.2-1.mga9. Is that true? If so, can we combine both > bugs and update the advisory to mention both issues? What testing is still > required (for either bug)? katnatek's comment 22 lists all the dependencies in question posed by bug 32972 and bug 28814. Proposed Mageia 9 Advisory: Upgrade Wine to point release version and fix installation issues. Description: Upgrade wine to the latest point release 8.0.2 for bug fixes. Fix installing Wine's mesa and mingw dependencies. References: https://bugs.mageia.org/show_bug.cgi?id=33903 https://bugs.mageia.org/show_bug.cgi?id=32972 https://bugs.mageia.org/show_bug.cgi?id=28814 Package: wine-8.0.2-1.1.mga9
OK Tests also performed by Markus at https://bugs.mageia.org/show_bug.cgi?id=28814#c53
This bug is still marked as validated_update, but with the other questions raised now seeming answered, is QA happy with this now being pushed?
Yes, please push.
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2025-0095.html
Status: NEW => RESOLVEDResolution: (none) => FIXED
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=34763