gettext-runtime @0.22.5_0 activation failure

[Gandoon (Erik Hedlund)]

This is a weird one, and it bricks a lot of tools and requires reversion to the previous gettext-runtime @0.22.4_0 for me. The error occurs just after the deactivation of the currently active port version, during the activation of the freshly built new version.

Attached is the log and below is the output when the error occurs. Note that the /opt/local/lib/libintl.8.dylib that is first complained about seems to have been successfully built. I am unsure what is the deal with envsubst, does the lstat fail because of a previous fault or is this the actual problem?

Any ideas?

a ./opt/local/lib/libintl.dylib
a ./opt/local/lib/libintl.8.dylib
a ./opt/local/lib/libintl.a
a ./opt/local/include/libintl.h
a ./opt/local/bin/envsubst
a ./opt/local/bin/gettext
a ./opt/local/bin/gettext.sh
a ./opt/local/bin/ngettext
--->  Deactivating gettext-runtime @0.22.4_0
--->  Cleaning gettext-runtime
--->  Removing work directory for gettext-runtime
--->  Activating gettext-runtime @0.22.5_0
dyld: Library not loaded: /opt/local/lib/libintl.8.dylib
  Referenced from: /opt/local/bin/xz
  Reason: image not found
Error: Failed to activate gettext-runtime: Image error: Source file /opt/local/var/macports/software/gettext-runtime/mpextracttjpKsmWw/opt/local/bin/envsubst does not appear to exist (cannot lstat it).  Unable to activate port gettext-runtime.
    while executing
"throw registry::image-error "Image error: Source file $srcfile does not appear to exist (cannot lstat it).  Unable to activate port [$port name].""
    ("foreach" body line 8)
    invoked from within
"foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be able to install links, we test if we can lst..."
    invoked from within
"registry::write {
            foreach file $imagefiles {
                set srcfile "${extracted_dir}${file}"

                # To be able to instal..."
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_gettext/gettext-runtime/main.log for details.
Error: Couldn't activate gettext-runtime 0.22.5_0: 1
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

[Gandoon (Erik Hedlund)]

gettext-runtime activation error

[jmroot (Joshua Root)]

You appear to have set portarchivetype txz. That will unfortunately fail when xz or one of its dependencies is being upgraded (or if you ever uninstall the xz port) because base uses the xz command to extract the archives, and macOS doesn't ship it. You can get around that by creating a separate xz installation and configuring base to use it.

[ryandesign (Ryan Carsten Schmidt)]

Changing the portarchivetype also means you cannot receive our binaries and will have to spend a lot of time compiling everything yourself. So changing portarchivetype is not recommended.

[Gandoon (Erik Hedlund)]

Replying to jmroot:

You appear to have set portarchivetype txz. That will unfortunately fail when xz or one of its dependencies is being upgraded (or if you ever uninstall the xz port) because base uses the xz command to extract the archives, and macOS doesn't ship it. You can get around that by creating a separate xz installation and configuring base to use it.

Thank you, that is most helpful. I have run into this a few times before, especially with the xz port itself and I figured out the hard way that I need to manually change the ´portarchivetype´ to e.g. ´tbz2´ to make it work when upgrading that specific port. After doing the same for gettext-runtime as well, of course that solved the problem. Now I know that that seems to be required for gettext-runtime as well (I probably should have known this, but I guess I forgot about it). I don't think I ran into this problem like this recently so it slipped my mind.

This is all on me I guess. You may close this ticket as it was only my configuration that messed things up.

[Gandoon (Erik Hedlund)]

Replying to ryandesign:

Changing the portarchivetype also means you cannot receive our binaries and will have to spend a lot of time compiling everything yourself. So changing portarchivetype is not recommended.

That is perfectly fine in my case as I am always compiling everything from source anyway (I have build from source set as the default). I just need to remember when to temporarily switch portarchivetype which I missed in this case.

[jmroot (Joshua Root)]

Replying to Gandoon:

This is all on me I guess. You may close this ticket as it was only my configuration that messed things up.

We can call this a duplicate of the existing tickets for improvements to our xz handling, I guess.