https://bugs.winehq.org/show_bug.cgi?id=51877
Bug ID: 51877 Summary: improve POSIX compatibility for wine-staging's patches/gitapply.sh Product: Wine-staging Version: 6.19 Hardware: x86-64 OS: other Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: damjan.jov@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com
Created attachment 70802 --> https://bugs.winehq.org/attachment.cgi?id=70802 Makes patches/gitapply.sh more POSIX compatible
wine-staging's patches/patchinstall.sh can apply patches using Git commands, or CLI tools. It prefers Git commands, but when it detects that some parent directory is a Git repository, it passes --nogit to patches/gitapply.sh, which then starts using CLI tools which use various Linuxisms.
On FreeBSD, the Git commands work, but since the Ports tree can itself be a Git repository, and Wine extracts under it (by default), they cannot always be used, falling back to CLI tools with Linuxisms that break.
This patch makes patches/gitapply.sh more POSIX compatible, and gets it working on FreeBSD.
https://bugs.winehq.org/show_bug.cgi?id=51877
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- That /usr/local/bin/gzip looks awkward; shouldn't it be the user's responsibility to make sure "gzip" is in $PATH?
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #2 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Zebediah Figura from comment #1)
That /usr/local/bin/gzip looks awkward; shouldn't it be the user's responsibility to make sure "gzip" is in $PATH?
Maybe. On FreeBSD the GNU gzip goes into /usr/local/bin, its own one into /usr/bin.
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- (In reply to Damjan Jovanovic from comment #2)
(In reply to Zebediah Figura from comment #1)
That /usr/local/bin/gzip looks awkward; shouldn't it be the user's responsibility to make sure "gzip" is in $PATH?
Maybe. On FreeBSD the GNU gzip goes into /usr/local/bin, its own one into /usr/bin.
Oh, okay, I'm used to /usr/local/bin being the designated install directory for user-compiled software.
Out of curiosity, what prevents us from using BSD gzip?
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #4 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Zebediah Figura from comment #3)
(In reply to Damjan Jovanovic from comment #2)
(In reply to Zebediah Figura from comment #1)
That /usr/local/bin/gzip looks awkward; shouldn't it be the user's responsibility to make sure "gzip" is in $PATH?
Maybe. On FreeBSD the GNU gzip goes into /usr/local/bin, its own one into /usr/bin.
Oh, okay, I'm used to /usr/local/bin being the designated install directory for user-compiled software.
Out of curiosity, what prevents us from using BSD gzip?
For some reason, patches/gitapply.sh explicitly checks for BSD gzip and fails if found:
# Detect BSD - we check this first to error out as early as possible if gzip -V 2>&1 | grep -q "BSD"; then echo "This script is not compatible with *BSD utilities. Please install git," >&2 echo "which provides the same functionality and will be used instead."
&2
exit 1 fi
https://bugs.winehq.org/show_bug.cgi?id=51877
Gerald Pfeifer gerald@pfeifer.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gerald@pfeifer.com
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #5 from Gerald Pfeifer gerald@pfeifer.com ---
For some reason, patches/gitapply.sh explicitly checks for BSD gzip and fails if found:
What happens if you remove this check, Damjan?
Or, maybe question to Zebediah: any chance of finding why this was added originally?
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #6 from Zebediah Figura z.figura12@gmail.com --- (In reply to Gerald Pfeifer from comment #5)
For some reason, patches/gitapply.sh explicitly checks for BSD gzip and fails if found:
What happens if you remove this check, Damjan?
Or, maybe question to Zebediah: any chance of finding why this was added originally?
It was added by c594bca17. That's not particularly helpful, but I suspect it's not about gzip specifically as about avoiding BSD in general.
If the script works on BSD (with Damjan's patches) there's probably no reason to worry about it. Although, frankly, I kind of would rather get rid of that script entirely and just require git.
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #7 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Gerald Pfeifer from comment #5)
For some reason, patches/gitapply.sh explicitly checks for BSD gzip and fails if found:
What happens if you remove this check, Damjan?
Apparently the patches apply and it builds perfectly.
Or, maybe question to Zebediah: any chance of finding why this was added originally?
It was added by:
---snip--- commit c594bca17a959351f845ce8713cd4410ba248df9 Author: Michael Müller michael@fds-team.de Date: Thu Jun 5 21:20:54 2014 +0200
Error out in git apply script on *BSD. ---snip---
It could be a bug or missing feature in an old version of FreeBSD that was fixed since. The original gzip imported from NetBSD in 2007 still works (with FreeBSD 13's zlib), so maybe it was some zlib bug or missing feature, or temporary gzip regression in some in-between version. Or older wine-staging used gzip in a different way that broke it at that time.
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #8 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Zebediah Figura from comment #6)
Although, frankly, I kind of would rather get rid of that script entirely and just require git.
Using Git doesn't seem possible when a parent directory in the path to wine-staging is a git repository, eg. when FreeBSD's Ports is itself a Git repo. Do you plan to remove support for that?
https://bugs.winehq.org/show_bug.cgi?id=51877
Damjan Jovanovic damjan.jov@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #70802|0 |1 is obsolete| |
--- Comment #9 from Damjan Jovanovic damjan.jov@gmail.com --- Created attachment 70874 --> https://bugs.winehq.org/attachment.cgi?id=70874 Makes patches/gitapply.sh more POSIX compatible, v2
Patch v2, simplified, uses BSD's gzip.
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #10 from Zebediah Figura z.figura12@gmail.com --- (In reply to Damjan Jovanovic from comment #8)
(In reply to Zebediah Figura from comment #6)
Although, frankly, I kind of would rather get rid of that script entirely and just require git.
Using Git doesn't seem possible when a parent directory in the path to wine-staging is a git repository, eg. when FreeBSD's Ports is itself a Git repo. Do you plan to remove support for that?
That is a really weird setup; are you actually creating a new repository with the files contained in wine-staging? So as to effectively reinvent its VCS?
It's not a huge problem, and I'm sure that freebsd has some weird build system requirements that make it necessary, but sheesh, that is very head-tilting.
Maybe we could just use --no-index?
But it's probably not really worth bothering about this; I guess the easiest thing to do is just take Damjan's patches as-is.
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #11 from Gerald Pfeifer gerald@pfeifer.com --- (In reply to Zebediah Figura from comment #10)
Using Git doesn't seem possible when a parent directory in the path to wine-staging is a git repository, eg. when FreeBSD's Ports is itself a Git repo. Do you plan to remove support for that?
That is a really weird setup; are you actually creating a new repository with the files contained in wine-staging? So as to effectively reinvent its VCS?
The FreeBSD ports tree is maintained in Git. In Linux terms, think of this being a tree of (unpacked) source RPMs that resides in Git. Additional changes are stored as patches that are applied to the upstream archives after these have been unpacked.
Doing this unpacking and patching in the tree is not what I have been doing, but apparently it generally works.
Maybe we could just use --no-index?
Damjan?
But it's probably not really worth bothering about this; I guess the easiest thing to do is just take Damjan's patches as-is.
There's some parts of the currently proposed patch that are generic, such as the hunks to remove the dependency on `du -b`, Lines 66-72 and Lines 135-141; could you apply those for now?
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #12 from Damjan Jovanovic damjan.jov@gmail.com --- (In reply to Zebediah Figura from comment #6)
Although, frankly, I kind of would rather get rid of that script entirely and just require git.
Apparently, that's possible.
All that's needed to get "git apply" working when a parent directory is a Git repository, is to either: * Pass the --directory path/to/patch/base/directory option to "git apply" * Even easier: set the environment variable GIT_DIR=. which will stop it from searching parent directories for a Git repository.
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #13 from Damjan Jovanovic damjan.jov@gmail.com --- Created attachment 71032 --> https://bugs.winehq.org/attachment.cgi?id=71032 Get git-apply working when a parent directory is a Git repository
This patch fixes the "git apply" backend when a parent directory is a Git repository.
It's independent of my previous patch, which only fixes the "patch" backend. You could accept both patches.
https://bugs.winehq.org/show_bug.cgi?id=51877
mata sutupud@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud@yahoo.com
--- Comment #14 from mata sutupud@yahoo.com --- It seems that with patchinstall.sh now being replaced by patchinstall.py the issue from above happens also with that.
When trying to build in a git subdirectory, patches are simply skipped, when adding the "--verbose" option to "git apply" it shows "Skiped patch ..." for everything.
It took me a while to figure out that I hadn't actually built wine-staging this way since nothing indicated any problem. Just because I had my PKGBUILD file in a git repo.
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #15 from Zeb Figura z.figura12@gmail.com --- Sorry for dropping this on the floor. Hopefully this works now with cf29ed121d9d0dc73370be7c0081ec31ce3faf0e?
https://bugs.winehq.org/show_bug.cgi?id=51877
--- Comment #16 from mata sutupud@yahoo.com --- I should probably have mentioned that the default backend was used, which calls "patches/gitapply.sh", and "git apply" is called from there (line 113).
The changes from cf29ed121d9d0dc73370be7c0081ec31ce3faf0e don't really affect that. It now shows an error when trying to run with "--backend git-apply" error: '--index' outside a repository Seems since the .git directory does not exist at that location, --index can't be used.
But with the patch backend it still only appears to apply the patches if "git apply" is called and the target directory isn't within a git repository, but not a wine git repository itself. Adding "--git-dir .git" there too (but without --index) makes it work - even tough the .git direcotry isn't found. It also works when invoked with "--nogit" from the python script.
-
WineHQ Bugzilla