| Summary: | app-emulation/wine-{vanilla,staging} USE="-X -ncurses": rm: cannot remove '{wineconsole.exe*,fakedlls/wineconsole.exe*}': No such file or directory | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | z4 <z4> |
| Component: | Current packages | Assignee: | Wine Maintainers <wine> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | ionen, jstein, opal |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
Pull requests welcome https://wiki.gentoo.org/wiki/GitHub_Pull_Requests You're free to make the ebuild do anything you like for your personal install, but what you're suggesting here is not a proper fix, or a fix at all (you'd still be running the command against a completely bogus path).
There absolutely are good reasons for commands such as 'rm' to 'die' if they can't do what they're meant to do, just like there are good reasons for not using '-f' (for one, we should know if we're actually removing things or not).
Anyblue, this issue seems to have possibly started during the transition from 'app-emulation/wine' to 'app-emulation/wine-vanilla' etc., where the line
rm "${D}usr/$(get_libdir)"/wine/{,fakedlls/}wineconsole.exe* || die
changes to
rm "${D%/}${MY_PREFIX}/$(get_libdir)"/wine/{,fakedlls/}wineconsole.exe* || die
which means the path is incorrectly set to, for example:
/usr/lib/wine-vanilla-9999/lib64
It should be:
/usr/lib64/wine-vanilla-9999/
Builds with USE="mingw" would still fail, even if the path was correct, because the 'fakedlls' directory will not exist. :]
I do wonder a little if 'games-emulation/dosbox' alone isn't enough for your use-case.
Either way, thanks for the report!
After an ebuild .../wine-vanilla... install
with commented-out "rm ... || die"'s, here's where the files are actually at in the filepath:
hercules /var/tmp/portage/app-emulation/wine-vanilla-5.0.1 # find image/ -name "wineconsole.exe*"
image/usr/lib64/wine-vanilla-5.0.1/wine/wineconsole.exe.so
image/usr/lib64/wine-vanilla-5.0.1/wine/fakedlls/wineconsole.exe
image/usr/lib/wine-vanilla-5.0.1/wine/wineconsole.exe.so
image/usr/lib/wine-vanilla-5.0.1/wine/fakedlls/wineconsole.exe
Note the "lib" and "lib64" location in the path.
Now look at:
rm "${D%/}${MY_PREFIX}/$(get_libdir)"/wine/{,fakedlls/}wineconsole.exe* || die
and also look at:
MY_PREFIX="${EPREFIX}/usr/lib/wine-${WINE_VARIANT}"
See the problem? $(get_libdir) in the rm ... command above is incorrect. The path is hard-coded to ${EPREFIX}/usr/lib/wine-${WINE_VARIANT} when in reality, the wineconsole.exe* files are actually at:
MY_PREFIX="${EPREFIX}/usr/lib/wine-${WINE_VARIANT}"
MY_PREFIX64="${EPREFIX}/usr/lib64/wine-${WINE_VARIANT}"
at
rm "${D%/}${MY_PREFIX}"/wine/{,fakedlls/}wineconsole.exe* || die
rm "${D%/}${MY_PREFIX64}"/wine/{,fakedlls/}wineconsole.exe* || die
being the correct paths.
But given that MY_PREFIX is used for several different purposes in the ebuild, I don't know how you massage that hard-coded path with $(get_libdir) to come up with something sane.
For me, I went with the simple solution: I dropped the $(get_libdir), added MY_PREFIX64, all as above. Works great. I can submit a pull request if you think this is an acceptable solution, or someone wants to get fancy with the multilib stuff and figure out a way to fix the hard-coded MY_PREFIX to include both ${EPREFIX}/usr/lib... and ${EPREFIX}/usr/lib64... but that may have some nasty side-effects and I didn't want to complicate this any further.
In my original analysis, I left out the possibility that an error such as this would have been in the ebuild file in the first place, hence I assumed the files were just never generated by wine-vanilla instead of being misplaced. I thought perhaps an update to upstream would have prevented the wineconsole.exe's from ever being built with my USE flags, so failing an rm ... with a || die seemed like massive overkill. Nevertheless, it is possible that such a scenario may arise in the future.
In general, it is good practice to make sure a file actually exists before trying to delete it. In this case, the brute force method actually exposed a bug in the ebuild so it all ended well. However, I'd suggest something like this for the rm ... || die construct (and this is in addition to the MY_PREFIX{64}/$(get_libdir) fixes above:
rm_wineconsole() {
if ( shopt -s failglob; : "${D%/}${MY_PREFIX}"/wine/{,fakedlls/}wineconsole.exe* ) 2>/dev/null; then
rm "${D%/}${MY_PREFIX}"/wine/{,fakedlls/}wineconsole.exe* || die
fi
if ( shopt -s failglob; : "${D%/}${MY_PREFIX64}"/wine/{,fakedlls/}wineconsole.exe* ) 2>/dev/null; then
rm "${D%/}${MY_PREFIX64}"/wine/{,fakedlls/}wineconsole.exe* || die
fi
}
But that might be a matter of taste and which way you want to go to be future-proof. You can still hard-fail || die if the file doesn't exist and you think it should, and that would be more clear, but to each his own.
Thanks! I already worked out a fix as well, yesterday, but sleep got me before pushing it into the wild. It's a bit different from what you did, but should work as well as far as I can tell (I simply changed the path a bit). Another alternative to 'rm' that I know people use for this kind of things, is 'find' in combination with its '-delete' action. I, too, first thought an upstream change caused this (733ed056502 [1] looked very suspicious), but indeed, in the end it was something in the ebuild itself after all. I don't know if it ever worked (I didn't make the change), and '-X' is not something people test too often, so we never got reports about it either... until now. :] 1. https://source.winehq.org/git/wine.git/commit/733ed056502 The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/wine.git/commit/?id=1da7c1fde9bce5ef524caa97743152921b84213d commit 1da7c1fde9bce5ef524caa97743152921b84213d Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2020-12-04 02:09:23 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2020-12-04 02:37:35 +0000 app-emulation/wine-staging: adjust path to wineconsole removal Bug: https://bugs.gentoo.org/757999 Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> app-emulation/wine-staging/wine-staging-5.22-r2.ebuild | 14 +++++++++++--- app-emulation/wine-staging/wine-staging-9999.ebuild | 14 +++++++++++--- 2 files changed, 22 insertions(+), 6 deletions(-) https://gitweb.gentoo.org/repo/proj/wine.git/commit/?id=14deadb457c34a5f053217b4fa0bc720209973ba commit 14deadb457c34a5f053217b4fa0bc720209973ba Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2020-12-03 07:25:35 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2020-12-04 02:35:10 +0000 app-emulation/wine-vanilla: adjust path to wineconsole removal Bug: https://bugs.gentoo.org/757999 Package-Manager: Portage-3.0.11, Repoman-3.0.2 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> app-emulation/wine-vanilla/wine-vanilla-5.22-r2.ebuild | 14 +++++++++++--- app-emulation/wine-vanilla/wine-vanilla-9999.ebuild | 14 +++++++++++--- 2 files changed, 22 insertions(+), 6 deletions(-) Great...thanks for the fix. This is still an issue in wine-staging-6.11. The actual file paths are not directly under the wine/ folder any longer. Also, the fakedlls/ folder does not exist. ./usr/lib/wine-staging-6.11/wine/i386-windows/wineconsole.exe ./usr/lib/wine-staging-6.11/wine/i386-unix/wineconsole.exe.so ./usr/lib64/wine-staging-6.11/wine/x86_64-unix/wineconsole.exe.so ./usr/lib64/wine-staging-6.11/wine/x86_64-windows/wineconsole.exe Yeah, looks like the path has changed once more again. Thanks for the report! The saga continues with 6.15, albeit slightly different root cause...this patch fixes it. Sorry for the informal formatting...
diff --git a/app-emulation/wine-vanilla/wine-vanilla-6.15.ebuild b/app-emulation/wine-vanilla/wine-vanilla-6.15.ebuild
index 7b3156ca675..c8382b65439 100644
--- a/app-emulation/wine-vanilla/wine-vanilla-6.15.ebuild
+++ b/app-emulation/wine-vanilla/wine-vanilla-6.15.ebuild
@@ -505,7 +505,7 @@ multilib_src_install_all() {
if ! use mingw; then
rm_wineconsole() {
- rm "${D%/}/usr/$(get_libdir)/wine-${WINE_VARIANT}"/wine/{,fakedlls/}wineconsole.exe* || die
+ rm "${D%/}/usr/$(get_libdir)/wine-${WINE_VARIANT}"/wine/*/wineconsole.exe* || die
}
else
rm_wineconsole() {
I think it needs a bit more than that to take care all of the different USE conditions. I am working on it, but it's going a bit slower than it should due to health issues and things. The '/*/' may seem a bit over-broad, but look at comment #7. Covers all the ABI* cases. I can vouch for the minimalistic USE flag approach: # equery u app-emulation/wine-vanilla [ Legend : U - final flag setting for installation] [ : I - package is installed with flag ] [ Colors : set, unset ] * Found these USE flags for app-emulation/wine-vanilla-6.15: U I - - X : Add support for X11 - - abi_x86_32 : 32-bit (x86) libraries + + abi_x86_64 : 64-bit (amd64) libraries - - alsa : Add support for media-libs/alsa-lib (Advanced Linux Sound Architecture) - - capi : Enable ISDN support via CAPI - - cups : Add support for CUPS (Common Unix Printing System) - - custom-cflags : Bypass strip-flags; use at your own peril + + dos : Pull in games-emulation/dosbox to run DOS applications - - faudio : Pull in app-emulation/faudio to provide XAudio2 functionality - - fontconfig : Support for configuring and customizing font access via media-libs/fontconfig - - gecko : Add support for the Gecko engine when using iexplore - - gphoto2 : Add digital camera support - - gsm : Add support for the gsm lossy speech compression codec - - gssapi : Use GSSAPI (Kerberos SSP support) - - gstreamer : Use media-libs/gstreamer to provide DirectShow functionality; - - jpeg : Add JPEG image support - - kerberos : Add kerberos support - - lcms : Add lcms support (color management engine) - - ldap : Add LDAP support (Lightweight Directory Access Protocol) - - mingw : Build PE files using a MinGW cross compiler - - mono : Add support for .NET using Wine's Mono add-on - - mp3 : Add support for reading mp3 files - - netapi : Use libnetapi from net-fs/samba to support Windows networks in netapi32.dll - - nls : Add Native Language Support (using gettext - GNU locale utilities) - - odbc : Add ODBC Support (Open DataBase Connectivity) - - openal : Add support for the Open Audio Library - - opencl : Enable OpenCL support - - opengl : Add support for OpenGL (3D graphics) - - osmesa : Add support for OpenGL in bitmaps using libOSMesa - - oss : Add support for OSS (Open Sound System) - - pcap : Support packet capture software (e.g. wireshark) - - perl : Install helpers written in perl (winedump/winemaker) - - png : Add support for libpng (PNG images) - - prelink : Run prelink on DLLs during build; For Gentoo hardened, do not disable if you do not know what this means as it can break things at runtime - - pulseaudio : Add support for PulseAudio sound server - - realtime : Pull in sys-auth/rtkit for low-latency pulseaudio support - - run-exes : Use Wine to open and run .EXE and .MSI files - - samba : Add support for NTLM auth. See: https://web.archive.org/web/20160108 123008/http://wiki.winehq.org:80/NtlmAuthSetupGuide and https://web. archive.org/web/20150906013746/http://wiki.winehq.org/NtlmSigningAnd Sealing (these pages are not currently in the updated WineHQ Wiki). - - scanner : Add support for scanner hardware (e.g. build the sane frontend in kdegraphics) - - sdl : Add support for gamepad detection using SDL - - ssl : Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security) - - test : Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently) + + threads : Add threads support for various packages. Usually pthreads - - truetype : Add support for FreeType and/or FreeType2 fonts - - udev : Use virtual/libudev to provide plug and play support - - udisks : Enable storage management support (automounting, volume monitoring, etc) - - unwind : Use sys-libs/libunwind to unwind the stack - - usb : Use virtual/libusb to provide USB support - - v4l : Enable support for video4linux (using linux-headers or userspace libv4l libraries) - - vkd3d : Use app-emulation/vkd3d to provide Direct3D 12 support - - vulkan : Enable Vulkan drivers - - xcomposite : Enable support for the Xorg composite extension - - xinerama : Add support for querying multi-monitor screen geometry through the Xinerama API - - xml : Add support for XML files Well, it should at least fail to build (install) with USE="mingw", though the same change might be enough for that part. I've been thinking of getting rid of the the globs to make it clearer what is being removed, and from where, but I wouldn't mind if something like this was merged before I get to it (see comment 2). For reference, the versions affected with this newest change are from 6.8 to current release. - https://source.winehq.org/git/wine.git/commit/c59126d403d - https://source.winehq.org/git/wine.git/commit/893febda143 I'm now thinking of removing the removal bits altogether, as I don't see what issue it is fixing any longer (and it looks like wineconsole might in some way be useful even without X or ncurses, according to comment in the removal of the curses backend [1]... though at this time I have no idea if that would require X and/or something else). Let us know if there are any problems currently with having wineconsole around with builds using USE="-X"! 1. https://source.winehq.org/git/wine.git/commit/05628e169db Yep, that is the exact use case for which I opened this bug in the first place. If something breaks, I'll post back...Thanks. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/proj/wine.git/commit/?id=ac0bc5018440b22a10921bb7fc9429ebef2a982c commit ac0bc5018440b22a10921bb7fc9429ebef2a982c Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2021-09-03 10:47:58 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2021-09-03 10:47:58 +0000 app-emulation/wine-staging: remove removal of wineconsole The path has changed since release 6.8, and while it could be fixed, at this time, removing wineconsole might do more harm than good. Bug: https://bugs.gentoo.org/551124 Bug: https://bugs.gentoo.org/757999 Package-Manager: Portage-3.0.22, Repoman-3.0.3 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> app-emulation/wine-staging/wine-staging-6.10.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.11.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.12.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.13.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.14.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.15.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.16.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.8.ebuild | 18 ------------------ app-emulation/wine-staging/wine-staging-6.9.ebuild | 18 ------------------ 9 files changed, 162 deletions(-) https://gitweb.gentoo.org/repo/proj/wine.git/commit/?id=447fccda775f8975614a8449661bade99ac1d5f0 commit 447fccda775f8975614a8449661bade99ac1d5f0 Author: Jimi Huotari <chiitoo@gentoo.org> AuthorDate: 2021-09-03 10:43:02 +0000 Commit: Jimi Huotari <chiitoo@gentoo.org> CommitDate: 2021-09-03 10:43:02 +0000 app-emulation/wine-vanilla: remove removal of wineconsole The path has changed since release 6.8, and while it could be fixed, at this time, removing wineconsole might do more harm than good. Bug: https://bugs.gentoo.org/551124 Bug: https://bugs.gentoo.org/757999 Package-Manager: Portage-3.0.22, Repoman-3.0.3 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> app-emulation/wine-vanilla/wine-vanilla-6.10.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.11.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.12.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.13.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.14.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.15.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.16.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.8.ebuild | 18 ------------------ app-emulation/wine-vanilla/wine-vanilla-6.9.ebuild | 18 ------------------ 9 files changed, 162 deletions(-) Think this was meant to be closed by the above when it got sync to ::gentoo -X works fine last I tried (can disable all flags even), and ncurses is gone. Don't think there's anything left to do here. |
I'm trying to build wine-vanilla, and the compile phase is fine, but the installation phase has an error in it. Pertinent USE flags: app-emulation/wine-vanilla -* abi_x86_32 abi_x86_64 threads dos I hate the fact that I even have to pollute the universe with this travesty of a Windows relic, but unfortunately, Intel has been sitting in Microsoft's lap longer than democrats have been committing voter fraud. Here's the faulty code from recent wine ebuild files (pick a version, they're the same); # Remove wineconsole if neither backend is installed #551124 if ! use X && ! use ncurses; then rm "${D%/}${MY_PREFIX}"/bin/wineconsole* || die rm "${D%/}${MY_MANDIR}"/man1/wineconsole* || die rm_wineconsole() { rm "${D%/}${MY_PREFIX}/$(get_libdir)"/wine/{,fakedlls/}wineconsole.exe* || die } multilib_foreach_abi rm_wineconsole fi What's wrong you say? Why would anyone "... || die" on a failed remove? In this environment, if the 'rm ...' fails, that means the file never existed in the first place, which means that the mission of the 'rm ...', i.e., get rid of the offending file, is thus by default already achieved. Hardly a "... || die" -worthy event. If the file was supposed to exist, but doesn't, the "... || die" belongs to the creator, not the deleter. Please get rid of the "|| die" construct and add a '-f' to the 'rm ...' so we can get on with our lives. Absolutely ridiculous logic...