dzip @2.9 Error: Failed to patch dzip: command execution failed

[RobK88]

The latest version of the port fails to patch dzip.

$ sudo port clean  M2VDownsizer
--->  Cleaning M2VDownsizer
Grinchs-MacBook-Pro:~ grinch$ sudo port -vst install dzip
--->  Computing dependencies for dzip.
--->  Applying patches to dzip
--->  Applying Makefile.linux.diff
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/work/dz29src" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/archivers/dzip/files/Makefile.linux.diff'
patching file Makefile.linux
Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file Makefile.linux.rej
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/work/dz29src" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/archivers/dzip/files/Makefile.linux.diff'
Exit code: 1
Error: Failed to patch dzip: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port dzip failed

[RobK88]

I also get:

$ sudo port clean  M2VDownsizer
--->  Cleaning M2VDownsizer
$ sudo port -vst install dzip +universal
Error: Requested variants "+universal" do not match those the build was started with: "".
Error: Please use the same variants again, or run 'port clean dzip' first to remove the existing partially completed build.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port dzip failed
$ sudo port clean  M2VDownsizer
--->  Cleaning M2VDownsizer
Grinchs-MacBook-Pro:~ grinch$ sudo port -vst install dzip +universal
Error: Requested variants "+universal" do not match those the build was started with: "".
Error: Please use the same variants again, or run 'port clean dzip' first to remove the existing partially completed build.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port dzip failed

[ryandesign (Ryan Carsten Schmidt)]

As the error message says, you have to sudo port clean dzip first.

[RobK88]

I did that.

I also tried sudo port clean -all dzip. But still no luck.

After the changes to the port yesterday, the Makefile.linux patch no longer patches as expected.

Grinchs-MacBook-Pro:~ grinch$ sudo port clean --all dzip
--->  Cleaning dzip
Grinchs-MacBook-Pro:~ grinch$ sudo port -vst install dzip +universal
--->  Computing dependencies for dzip.
--->  Fetching distfiles for dzip
--->  dz29src.zip does not exist in /opt/local/var/macports/distfiles/dzip
--->  Attempting to fetch dz29src.zip from http://distfiles.macports.org/dzip
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   98k  100   98k    0     0   564k      0 --:--:-- --:--:-- --:--:--  566k
--->  Verifying checksums for dzip
--->  Checksumming dz29src.zip
--->  Extracting dzip
--->  Extracting dz29src.zip
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/work/dz29src" && /usr/bin/unzip -q '/opt/local/var/macports/distfiles/dzip/dz29src.zip' -d /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/work/dz29src 
||g>  Patching Makefile.linux: s|
--->  Applying patches to dzip
--->  Applying Makefile.linux.diff
Executing:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/work/dz29src" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/archivers/dzip/files/Makefile.linux.diff'
patching file Makefile.linux
Hunk #2 FAILED at 24.
1 out of 2 hunks FAILED -- saving rejects to file Makefile.linux.rej
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/work/dz29src" && /usr/bin/patch -p0 < '/opt/local/var/macports/sources/rsync.macports.org/macports/release/tarballs/ports/archivers/dzip/files/Makefile.linux.diff'
Exit code: 1
Error: Failed to patch dzip: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_archivers_dzip/dzip/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port dzip failed

[jmroot (Joshua Root)]

I can't reproduce this locally (I made sure the patch applied before pushing, of course). Could be some oddity with git's line ending handling, given that the Makefile starts out with DOS line endings?

[jmroot (Joshua Root)]

In baa8fa3a23cdea2cee68acf7965d9faf44242db0/macports-ports (master):

dzip: don't patch in a newline

See: #65696

[RobK88]

Yes. It has something to do with the line endings in the Makefile and the resulting patch file

I downloaded the source file manually, made your changes to the Makefile and recreated the Makefile.linux.diff using:

diff -u Makefile.linux.orig Makefile.linux > Makefile.linux.diff

And the resulting .diff file shows and upside down question mark (used in Spanaish) and a new line at the end of every line (when show invisibles is on in BBEdit).

And my newly created patch file fails to patch the source in my local MacPorts repo (just like in my bug report)

Something strange is happening.

[RobK88]

Strange Line Ending in Patch file

[ryandesign (Ryan Carsten Schmidt)]

It's not terribly strange; all of the text files in dzip's source archive simply ship with DOS line endings. The CR part of DOS line endings will show up in some tools as ¿ or ^M. In many of my ports when I want to patch a file that has DOS line endings I have the Portfile convert the line endings to Unix first. For example:

post-extract {
    # Convert DOS to UNIX line endings so we can patch
    reinplace "s|\r||g" ${worksrcpath}/Makefile.linux
}

The patchfile will then need to be adjusted accordingly.

[ryandesign (Ryan Carsten Schmidt)]

Excuse me; I see the dzip portfile already has that conversion block. So the patchfile will need to have Unix line endings, not DOS line endings.

[ryandesign (Ryan Carsten Schmidt)]

...which it already does, so there should be no problem.

[jmroot (Joshua Root)]

The commit referenced in comment:5 attempts to leave well enough alone by removing the failing second hunk of the patch, which just added a newline to the end of the file.

[RobK88]

Making some progress. Was able to get the patch to patch!

1. Downloaded the source
2. ran dos2unix Makefile.linux
3. Duplicated Makefile.linux to Makefile.linux.orig
4. Made changes to Makefile.linux
5. Ran diff -u Makefile.linux.orig Makefile.linux > Makefile.linux.diff
6. Copied Makefile.linux.diff to my local repo

Note I did not add the missing linefeed to the end of the last line in either Makefile.linux or Makefile.linux.orig.

Now the patch works but the port fails to build... One step forward.... :-)

P.S. I have not changed the port file. It is the latest Portfile that Josh changed yesterday.

$ sudo port clean --all dzip
--->  Cleaning dzip
Grinchs-MacBook-Pro:~ grinch$ sudo port install -vst dzip
--->  Computing dependencies for dzip
--->  Fetching distfiles for dzip
--->  Attempting to fetch dz29src.zip from http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/dzip
--->  Verifying checksums for dzip                                                   
--->  Extracting dzip
--->  Applying patches to dzip
--->  Configuring dzip
--->  Building dzip
Error: Failed to build dzip: command execution failed
Error: See /opt/local/var/macports/logs/_Users_grinch_Development_MacPorts_local-repo_ports_archivers_dzip/dzip/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.
Error: Processing of port dzip failed

[RobK88]

Working Patch file

[RobK88]

main.log from failed build in my local repo

[RobK88]

P.S. Just curious. What does following line in the Portfile do?

variant universal {}

[RobK88]

The build error being generated from my build in my local repo relates to sysroot:

clang: warning: no such sysroot directory:

It looks like new Portfile tries to set sysroot with unexpected results:

build.env       CC=${configure.cc} \
                "CFLAGS=${configure.cflags} [get_canonical_archflags cc] -isysroot${configure.sdkroot}"

[RobK88]

I was able to build the port once I removed the sysroot statement from the Portfile:

build.env       CC=${configure.cc} \
                "CFLAGS=${configure.cflags} [get_canonical_archflags cc]"

See attached Portfile and patch file.

$ sudo port clean --all dzip
--->  Cleaning dzip
$ sudo port install -vs dzip +universal
--->  Computing dependencies for dzip
--->  Fetching distfiles for dzip
--->  Attempting to fetch dz29src.zip from http://ykf.ca.distfiles.macports.org/MacPorts/mpdistfiles/dzip
--->  Verifying checksums for dzip
--->  Extracting dzip
--->  Applying patches to dzip
--->  Configuring dzip
--->  Building dzip
--->  Staging dzip into destroot                         
--->  Installing dzip @2.9_0+universal
--->  Deactivating dzip @2.9_0
--->  Cleaning dzip
--->  Activating dzip @2.9_0+universal
--->  Cleaning dzip
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.

$ file /opt/local/bin/dzip
/opt/local/bin/dzip: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [i386:Mach-O executable i386]
/opt/local/bin/dzip (for architecture x86_64):	Mach-O 64-bit executable x86_64
/opt/local/bin/dzip (for architecture i386):	Mach-O executable i386

[RobK88]

Fix Portfile and Makefile.linux Patch

[kencu (Ken)]

the port has to check if ${configure.sdkroot} is empty before using it and set it to “/“ if it is empty.

see ​https://github.com/macports/macports-base/pull/183

[jmroot (Joshua Root)]

Replying to kencu:

the port has to check if ${configure.sdkroot} is empty before using it and set it to “/“ if it is empty.

If it needs to be set to /, configure.sysroot is the variable to use. But it's probably unnecessary here.

[jmroot (Joshua Root)]

In 54c814253597466a8e984f870562364a96bba83b/macports-ports (master):

dzip: don't add -isysroot flag

The SDKROOT environment variable should be sufficient for platforms
that require use of an SDK.

See: #65696

[RobK88]

Thanks Josh for updating the Portfile. But to get the port to work, Makefile.linux.diff will need to be replaced with my proposed Patchfile attached to this ticket.

[RobK88]

Please note that every time I try to add a new line at the end of Makefile.linux via the Makefile.linux.diff patch file, the patch fails.

I can only get it to patch if I do NOT try to patch the last line of Makefile.linux by adding a newline. And yes, I am using dos2unix first to ensure that the DOS line ending are not the issue.

So it looks like my proposed patch file (which does not patch the last line) is the only working solution at this time.

FYI -- I will attach the patch rejects file that gets created when I use either Josh's patch file or mine that tries to patch the last line. Looks like one must not try to patch the last line which sounds crazy to me.

[RobK88]

Patch Rejects File that gets created whenever I try to patch the last line of Makefile.linux

[ryandesign (Ryan Carsten Schmidt)]

In 24a384e25be7b98c9481b45d5ef667cc499c9d3e/macports-ports (master):

dzip: Update to 3.0

Closes: #65696

[RobK88]

Thank you Ryan for updating the port from version 2.9 to version 3 using the new Github repo. That is by far the best solution! No need to worry about DOS line ending in the Makefile.

By the way, I was finally able to get dzip@2.9 to build using Josh's patch file (which adds the missing newline to the end of the file).

I needed to change the reinplace statement in the post-extract block with one that uses dos2unix.

That is, I needed to change:

post-extract {
    # Convert DOS to UNIX line endings so we can patch
    reinplace "s|\r||g" ${worksrcpath}/Makefile.linux
}

with

depends_build   port:dos2unix

post-extract {
    # Convert DOS to UNIX line endings so we can patch
    exec dos2unix -q "${worksrcpath}/Makefile.linux"
}

N.B. It is important to use the -q (or quiet) flag with dos2unix.

It looks like dos2unix does more than just replace the line endings.

[ryandesign (Ryan Carsten Schmidt)]

I can't explain why you were having problems with version 2.9 of this port. As far as I know it worked fine for everyone else. I've copy-pasted the same reinplace command to change DOS to UNIX line endings in countless other ports over the years with no complaints. Under the hood, reinplace uses sed, so perhaps if your sed is not working correctly or if you did something strange like replace your macOS sed with a different implementation, like GNU sed, that could account for the problem. If that's what you did, you should undo it.

The use of exec in Portfiles is discouraged because it bypasses MacPorts sandboxing restrictions. Instead, we use system, e.g.:

system -W ${worksrcpath} "dos2unix -q Makefile.linux"

[RobK88]

Thanks Ryan. I just installed XCode and Macports on this Mac running High Sierra a week or so ago. I have only installed a dozen or so ports.

And I am just using the version of sed that came with High Sierra:

$ which sed
/usr/bin/sed

On my Mac, it looks like using reinplace to change the DOS line endings (CRLF) to unix line endings (LF) does work just fine unless the last line of the DOS file is NOT terminated with a CRLF (like is the case with the dzip's Makefile). But dos2unix appears to handle that edge case just fine.

And many thanks for the tip regarding exec. It is good to know that one should be using system -W instead of exec. It is always good to learn something new every day!

P.S. With the system -W approach, I had to change depends_build port:dos2unix to depends_extract port:dos2unix in the portfile to get the port to work. It sure looks like the sandboxing really does work!