On 2025-09-17 05:48, Jakob Bohm via Cygwin wrote:
Hi List,
Solution further down!
On 9/17/2025 3:49 AM, Brian Inglis via Cygwin wrote:
On 2025-09-16 18:11, Jakob Bohm via Cygwin wrote:
On 9/16/2025 8:49 PM, Brian Inglis via Cygwin wrote:
On 2025-09-16 03:20, Jakob Bohm via Cygwin wrote:
I was looking into trying out some local modifications to a cygwin
packaged program. Thus I installed the sources via setup.exe then
copied /usr/src/* to a working directory and tried to rebuild the
package with the cygport all command. But Even with different
packages and unchanged sources, cygport keeps failing with an error
that the first patch in the source will not apply.
What should I do to get to a buildable state?
Steps to reproduce (using bash as a simpler test example):
Note that above line clarifies that bash was just used as a test example
to show it was an issue in cygport, not the specific packageI am trying
to build. Equivalently, any changes specific to the bash package are
irrelevant, including your comments about redhat URL specifics.
Reemphasizing this, as I kept getting replies highly specific to bash,
when bash was just a random choice from the setup.exe menus.
$ cd
$ mkdir cygsrc
$ cd cygsrc
$ cp -par /usr/src/* .
$ cd bash-5.2.21-1.src
$ cygport bash.cygport all
$ cygport --version
Results:
*** Info: Trying to enable case sensitivity on /home/me/cygsrc/
bash-5.2.21-1.src/bash-5.2.21-1.x86_64
>>> Preparing bash-5.2.21-1.x86_64
>>> Unpacking source bash-5.2.21.tar.gz
*** ERROR: patch bash-2.03-profile.patch will not apply
cygport 0.37.2
Copyright (C) 2020 Cygport authors
.
Without knowing the actual source package, version, and patch, it is hard to
help.
It is also easier to diagnose if we can see a verbatim transcript of
commands run and output shown.
But here is a transcript of trying the undocumented (not in man cygport) --
debug option (with username substituted by "me")
It is in `man cygport` for me:
$ man cygport | grep debug
--debug
enable debugging messages
OK, admitted, it was on the manpage, I just overlooked it. Also the
debug output seems to be both too verbose and too incomplete for anyone
but the cygport author to understand.
Try `cygport --help` for better info: we should probably use `help2man` to
update man pages, if there are mismatches.
$ cygport --debug bash.cygport all
+ shift
+ true
+ case ${1} in
+ break
+ argv=('/usr/bin/cygport' 'bash.cygport' 'all')
+ declare -ar argv
+ declare -ir argc=3
+ defined 'argv[1]'
+ (( 1 != 1 ))
+ '[' -n bash.cygport ']'
+ return 0
+ defined 'argv[2]'
+ (( 1 != 1 ))
+ '[' -n all ']'
+ return 0
+ source /usr/share/cygport/lib/check_funcs.cygpart
+ echo -e '\e[1;39m>>> Preparing bash-5.2.21-1.x86_64\e[0;0m'
>>> Preparing bash-5.2.21-1.x86_64
/home/me/cygsrc/bash-5.2.21-1.src/bash-5.2.21.tar.gz ']'
+ '[' -f /home/me/cygsrc/bash-5.2.21-1.src/bash-2.03-profile.patch -a '!' -f
bash-2.03-profile.patch ']'
+ cd /home/me/cygsrc/bash-5.2.21-1.src/bash-5.2.21-1.x86_64/origsrc
+ unpack_cmd='tar xf'
+ __step 'Unpacking source bash-5.2.21.tar.gz'
+ echo -e '>>> Unpacking source bash-5.2.21.tar.gz'
>>> Unpacking source bash-5.2.21.tar.gz
+ tar xf /home/me/cygsrc/bash-5.2.21-1.src/bash-5.2.21.tar.gz
+ '[' '!' -d /home/me/cygsrc/bash-5.2.21-1.src/bash-5.2.21-1.x86_64/origsrc/
bash-5.2.21 ']'
+ chmod +x /home/me/cygsrc/bash-5.2.21-1.src/bash-5.2.21-1.x86_64/origsrc/
bash-5.2.21
+ cd /home/me/cygsrc/bash-5.2.21-1.src/bash-5.2.21-1.x86_64/origsrc/bash-5.2.21
+ cygpatch /home/me/cygsrc/bash-5.2.21-1.src/bash-2.03-profile.patch
+ patch -N -s --dry-run -p1 -i /home/me/cygsrc/bash-5.2.21-1.src/bash-2.03-
profile.patch
+ error 'patch bash-2.03-profile.patch will not apply'
+ case $? in
+ local errorcode=1
+ echo -e '\e[1;31m*** ERROR:\e[0;0m patch bash-2.03-profile.patch will not
apply'
*** ERROR: patch bash-2.03-profile.patch will not apply
+ exit 1
me@MACHINE ~/cygsrc/bash-5.2.21-1.src
Try running:
$ cd /home/me/cygsrc/bash-5.2.21-1.src/bash-5.2.21-1.x86_64/origsrc/bash-5.2.21
$ patch --verbose -N -s --dry-run -p1 -i /home/me/cygsrc/bash-5.2.21-1.src/
bash-2.03-profile.patch
Again, a suggestion specific to bash, but I can try.
And patch --verbose gave a meaningful error message suppressed by cygport,
even in debug mode: the CYGWIN tmp dir was still mounted to the
cygwin64\tmp default location, thus writable only by admins/wheel, not
developers or other non-wheel users.
Are we talking Windows or some Unix filesystem?
Previously (Cygwin >= 1.7 ~2000) /tmp was created by Cygwin Setup, perms 01777
a=rwxt set by /etc/postinstall/bash.sh, later (~2008) perms were set in Cygwin
Setup, owned by install account and group; more recently owned by install
account and Administrators group.
Problems can be caused if Cygwin directories and perms are backed up and
restored using Windows utilities that do not retain verbatim ACLs, rather than
Cygwin utilities like rsync, that try to retain POSIX perms and ACLs.
Any other settings are likely to be admins responsible for the host system, or
using Windows utilities on Cygwin files, assuming they DTRT.
Who sets up POSIX compatible systems with non-world-writeable /tmp directories?
Fix was to add this comment and line to /etc/fstab as root, then
restarting all processes that access cygwin1.dll shared memory. These
lines really should be the sane default.
###### Solution!!!!!!
# Map Windows per user temp dir to CYGWIN /tmp dir
none /tmp usertemp binary,posix=1,noacl,dos,user 0 0
(noacl needed because the cygwin core code uses a broken old algorithm that
adds NTACL entries for user NONE and generally causes ACL corruption) .
PGA; PTC; feel free to offer patches to improve the implementation while
maintaining Cygwin and POSIX compatibility.
You are expected to run cygport from within the directory where the package
sources including the <PACKAGE>.cygport were downloaded or installed
(often / usr/src/<PACKAGE>).
Not sure how the statements below applies to an already populated complete
src directory for the test package (which happens to be bash).
By default, if you use download/fetch/wget/get/...all cygport will re-
download any sources or patches which are not local or in its upstream cache
defined as ${DISTDIR:-$HOME/Downloads}, and they may have changed.
Also incorrect versions of unlabelled/unversioned sources or patches may be
found in its upstream cache and used.
If anything is not found locally, and what that means may vary by source, it
will be checked for in the upstream source cache ${DISTDIR:-$HOME/Downloads},
and what is available locally or in the upstream source cache may not be the
same file used in the original build!
I have no idea where your sources originated without seeing the whole
transcript, including downloadall or equivalent, but wcurl/tar/prep works for me:
As I wrote repeatedly, these are the sources installed by setup.exe
when checking the "src" box for a package, nothing exotic or manual.
$ wcurl https://mirror.cpsc.ucalgary.ca/mirror/cygwin.com/x86_64/release/bash/
bash-5.2.21-1-src.tar.xz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10.4M 100 10.4M 0 0 19.8M 0 --:--:-- --:--:-- --:--:-- 19.9M
$ tar -xf bash-5.2.21-1-src.tar.xz
$ cd bash-5.2.21-1.src
$ cygport --version
cygport 0.37.2
Copyright (C) 2020 Cygport authors # -> needs updated!
...
$ cygport bash.cygport prep
*** Info: Trying to enable case sensitivity on /usr/src/bash/
bash-5.2.21-1.src/bash-5.2.21-1.x86_64
>>> Preparing bash-5.2.21-1.x86_64
>>> Unpacking source bash-5.2.21.tar.gz
*** Info: applying patch bash-2.03-profile.patch (-p1):
patching file config-top.h
Hunk #1 succeeded at 23 (offset -3 lines).
*** Info: applying patch bash-2.05a-interpreter.patch (-p1):
...
>>> Preparing working source directory
*** Info: applying patch bash-5.2.21-1.src.patch (-p2):
patching file doc/man.pages
patching file support/bashbug.sh
I also built a bunch of updated packages from sources last weekend with no
issues, and got nearly identical results on our CI system, from which the
updated packages were deployed to the mirrors.
Perhaps check no other instances of required utilities are prior to Cygwin's
on your PATH:
PATH in cygwin console has /usr/local/bin and /usr/bin as first elements,
so that was not the issue. Issue is that cygport does a bunch of
unrelated things before invoking patch in a way that requires write access
to /tmp which failsdue to cygwin defaulting to a root-owned /tmp .
Then cygport further adds to the confusion by claiming that it is an issue
withpatching, not /tmp/ access.
> (snip long example of using which to check PATH of lots of tools)
And mounts were subtly wrong (/tmp implicitly included in the root mount
to a root-owned software dir)
Do you mean Administrators?
Ownerships should not matter if perms and ACLs are set properly, which they
should be using only Cygwin packages on directories below the Cygwin root mount.
--
Take care. Thanks, Brian Inglis Calgary, Alberta, Canada
La perfection est atteinte Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher but when there is no more to cut
-- Antoine de Saint-Exupéry
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation: https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
