cygport 0.37.2 keeps failing with patch will not apply

Jakob Bohm jb-cygwin@wisemo.com
Wed Sep 17 11:48:24 GMT 2025


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.

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) .

>
>>> 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)

Enjoy

Jakob
-- 
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded



More information about the Cygwin mailing list