#43859 closed defect (worksforme)
New port version fails to uninstall ports: '": file name too long'
Reported by: | ballapete (Peter "Pete" Dyballa) | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.3.0 |
Keywords: | Cc: | ||
Port: |
Description
After performing a selfupdate I wanted to uninstall the old deactivated ports. This fails à la:
---> Uninstalling tiff @4.0.3_2 Error: port uninstall failed: error deleting "/opt/local/var/macports/registry/portfiles/tiff-4.0.3_2/# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 # $Id: Portfile 113360 2013-11-14 14:28:06Z mojca@macports.org $ PortSystem 1.0 PortGroup xcodeversion 1.0 PortGroup muniversal 1.0 name tiff version 4.0.3 revision 2 categories graphics platforms darwin license BSD maintainers nomaintainer description Library and tools for dealing with Tag Image File Format long_description \ This software provides support for the Tag Image File \ Format (TIFF), a widely used format for storing image \ data. Included in this software distribution is a \ library, libtiff, for reading and writing TIFF, a small \ collection of tools for doing simple manipulations of \ TIFF images on UNIX systems, documentation on the library \ and tools. A small assortment of TIFF-related software \ for UNIX that has been contributed by others is also \ included. The library is capable of dealing with images \ that are written to follow the 5.0 or 6.0 TIFF spec. \ There is also considerable support for some of the more \ esoteric portions of the 6.0 TIFF spec. homepage http:/www.remotesensing.org/libtiff master_sites http:/download.osgeo.org/libtiff/ \ ftp:/ftp.remotesensing.org/pub/libtiff/ \ http:/dl.maptools.org/dl/libtiff/ \ freebsd checksums rmd160 eacd725fb3c299682c1c2e508049d98acd170f31 \ sha256 ea1aebe282319537fb2d4d7805f478dd4e0e05c33d0928baba76a7c963684872 depends_lib port:jpeg \ port:xz \ port:zlib test.run yes test.target check use_autoreconf yes autoreconf.args -fvi patchfiles patch-int64.diff configure.args --disable-jbig \ --with-docdir=${prefix}/share/doc/${name} \ --with-jpeg-include-dir=${prefix}/include \ --with-jpeg-lib-dir=${prefix}/lib \ --with-lzma-include-dir=${prefix}/include \ --with-lzma-lib-dir=${prefix}/lib \ --with-zlib-include-dir=${prefix}/include \ --with-zlib-lib-dir=${prefix}/lib configure.ldflags-append \ -headerpad_max_install_names use_parallel_build yes platform macosx { # Tiger does not have 64-bit OpenGL. if {${os.major} > 8 || (![variant_isset universal] && ![string match *64* $build_arch]) || ([variant_isset universal] && ![string match *64* $universal_archs])} { configure.args-append --with-apple-opengl-framework } } minimum_xcodeversions {9 3.1} # tools/tiffgt.c incorrectly uses HAVE_APPLE_OPENGL_FRAMEWORK rather than HAVE_OPENGL_GL_H configure.cppflags-append \ -DHAVE_APPLE_OPENGL_FRAMEWORK variant jbig description {Enable JBIG support} { depends_lib-append port:jbigkit configure.args-delete --disable-jbig configure.args-append --enable-jbig } livecheck.type regex livecheck.url http:/www.remotesensing.org/libtiff/ livecheck.regex {v(\d+(?:\.\d+)*)</a>} ": file name too long
Change History (8)
comment:1 follow-up: 2 Changed 10 years ago by neverpanic (Clemens Lang)
comment:2 Changed 10 years ago by ballapete (Peter "Pete" Dyballa)
Replying to cal@…:
This looks like an upgrade script gone wrong.
make install
of your update to 2.3.0 should have rundepup_portfiles.tcl
which should have moved the Portfiles from the registry to the filesystem and replaced the Portfiles in the registry database with the names of the directories. Apparently that didn't happen for you.
Yes, there was a bug with two Perl files with a bit special names …
Can you please post the output of
sqlite3 $prefix/var/macports/registry/registry.db 'SELECT * FROM metadata'
pete 135 /\ sqlite3 /opt/local/var/macports/registry/registry.db 'SELECT * FROM metadata' version|1.200 created|1334908737 portfiles_update_needed|1
comment:3 follow-up: 4 Changed 10 years ago by neverpanic (Clemens Lang)
The portfiles_update_needed
key tells us the conversion needs to be done but hasn't been completed yet. If you can, please run "sudo make install" from the source tree again. Let me know if you need help finding the proper source tree (e.g. if you updated using selfupdate).
comment:4 Changed 10 years ago by ballapete (Peter "Pete" Dyballa)
Replying to cal@…:
If you can, please run "sudo make install" from the source tree again. Let me know if you need help finding the proper source tree (e.g. if you updated using selfupdate).
I have no idea where this source tree can be… I invoked 'port selfupdate' and during this port indeed updated itself…
comment:5 follow-up: 6 Changed 10 years ago by neverpanic (Clemens Lang)
In that case it's in /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base
. Run sudo make install
there.
comment:6 follow-up: 7 Changed 10 years ago by ballapete (Peter "Pete" Dyballa)
Replying to cal@…:
In that case it's in
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base
. Runsudo make install
there.
I had to configure and and build again, the sources were already clean – and it seems that the uninstall jobs had been executed despite the error messages. Uninstall now works quite silently.
comment:7 follow-up: 8 Changed 10 years ago by neverpanic (Clemens Lang)
Resolution: | → worksforme |
---|---|
Status: | new → closed |
Replying to Peter_Dyballa@…:
I had to configure and and build again, the sources were already clean
I wasn't aware that MacPorts runs distclean. It might just be the next rsync that deletes the configuration data, though.
and it seems that the uninstall jobs had been executed despite the error messages. Uninstall now works quite silently.
Yes. On uninstall, the Portfiles are only loaded to execute possible pre/post-deactivate
jobs, but even if that fails the removal continues.
Glad you could solve the issue. I'm not sure that's something we should build into MacPorts to detect, as it's probably very uncommon.
comment:8 Changed 10 years ago by regnauld@…
Replying to cal@…:
Glad you could solve the issue. I'm not sure that's something we should build into MacPorts to detect, as it's probably very uncommon.
Hmm, I have exactly the same problem, so I found this post. Tried following the instructions, but now:
Darwin 13.2.0 Darwin Kernel Version 13.2.0: Thu Apr 17 23:03:13 PDT 2014; root:xnu-2422.100.13~1/RELEASE_X86_64 x86_64 i386 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.2.0 Thread model: posix
Similar output from sqlite3:
version|1.200 created|1311408569 portfiles_update_needed|1
and tried to reinstall from:
/opt/local/var/macports/sources/rsync.macports.org/release/tarballs/base
(had to make clean, configure, and make install).
Install fails with:
Processing 1 of 1382: Xaw3d-1.5E_4.darwin_13.i386.tbz2 Command failed: /usr/bin/tar -cjf /opt/local/var/macports/software/Xaw3d/Xaw3d-1.5E_4.darwin_13.i386.tbz2 -T /opt/local/var/macports/software/Xaw3d/tarlist > /opt/local/var/macports/software/Xaw3d/error.log 2>&1
Log contains:
tar: Removing leading '/' from member names tar: /opt/local/include/X11/Xaw3d/Template.c: Cannot stat: No such file or directory tar: /opt/local/include/X11/Xaw3d/Template.h: Cannot stat: No such file or directory tar: /opt/local/include/X11/Xaw3d/TemplateP.h: Cannot stat: No such file or directory tar: /opt/local/lib/libXaw3d.8.0.dylib: Cannot stat: No such file or directory tar: Error exit delayed from previous errors.
... and I can't continue (can't reinstall macports, can't finish upgrading).
So, doesn't seem to be uncommon.
This looks like an upgrade script gone wrong.
make install
of your update to 2.3.0 should have rundepup_portfiles.tcl
which should have moved the Portfiles from the registry to the filesystem and replaced the Portfiles in the registry database with the names of the directories. Apparently that didn't happen for you.Can you please post the output of