#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 12 years ago by neverpanic (Clemens Lang)
comment:2 Changed 12 years ago by ballapete (Peter "Pete" Dyballa)
Replying to cal@…:
This looks like an upgrade script gone wrong.
make installof your update to 2.3.0 should have rundepup_portfiles.tclwhich 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 12 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 12 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 12 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 12 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 installthere.
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 12 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 12 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 installof your update to 2.3.0 should have rundepup_portfiles.tclwhich 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