port upgrade -u py25-wxpython fails to deactivate old version

[yaseppochi (Stephen J. Turnbull)]

I thought I reported this yesterday, but maybe I only clicked on "preview"? Can't find that report, but if this turns out to be a dupe, sorry.

Not sure if this is a bug in the port program or in the py25-wxpython port, but since I've never seen anything like it before, I'm assuming it's in py25-wxpython.

Mac OS X 10.5.8
MacBook Pro (Intel Core Duo)
port compiled from r88339
old version of py25-wxpython @2.8.9.1_0
new version of py25-wxpython @2.8.12.1_0

After a successful build, activation of @2.8.12.1_0 fails trying to deactivate @2.8.9.1_0 like this:

wideload:src/MacPorts 13:57$ sudo port -d -v -f uninstall py25-wxpython @2.8.9.1_0 2>&1   
Password:
DEBUG: no portfile in registry for py25-wxpython @2.8.9.1_0
--->  Unable to uninstall py25-wxpython @2.8.9.1_0, the following ports depend on it:
--->  	bittorrent @5.2.0_1
Warning: Uninstall forced.  Proceeding despite dependencies.
DEBUG: no portfile in registry for py25-wxpython @2.8.9.1_0
--->  Deactivating py25-wxpython @2.8.9.1_0
--->  Unable to deactivate py25-wxpython @2.8.9.1_0, the following ports depend on it:
--->  	bittorrent @5.2.0_1
Warning: Deactivate forced.  Proceeding despite dependencies.
DEBUG: this entry does not own the given file
    while executing
"$port deactivate $imagefiles"
    invoked from within
"registry::write {
            $port deactivate $imagefiles
            foreach file $files {
                _deactivate_file $file
            }
    ..."
    (procedure "_deactivate_contents" line 37)
    invoked from within
"_deactivate_contents $requested [$requested files] $force"
    (procedure "portimage::deactivate" line 54)
    invoked from within
"portimage::deactivate $portname $version $revision $variants [array get options]"
    (procedure "uninstall" line 91)
    invoked from within
"uninstall $portname $version $revision $variants $optionslist"
    (procedure "registry_uninstall::uninstall_composite" line 5)
    invoked from within
"registry_uninstall::uninstall_composite $portname $composite_version [array get options]"
Error: port uninstall failed: this entry does not own the given file

[ryandesign (Ryan Carsten Schmidt)]

First, from the summary line of this ticket:

port upgrade -u py25-wxpython fails to deactivate old version

Single-letter flags like -u have no effect unless you place them right after the port command, i.e. "port -u upgrade py25-wxpython".

Next, from the command you showed in the description:

sudo port -d -v -f uninstall py25-wxpython @2.8.9.1_0 2>&1   

It's unnecessary to specify -v (verbose) when you've already specified -d (debug). Debug output is verbose output plus more.

Next, to the errors in your log:

DEBUG: no portfile in registry for py25-wxpython @2.8.9.1_0

This shows this py25-wxpython was installed some time ago with an old version of MacPorts, before we started storing installed ports' Portfiles in the registry. This shouldn't be a problem. We only store the Portfiles so that any custom deactivate code can be run, and py25-wxpython does not have any custom deactivate code.

DEBUG: this entry does not own the given file

This seems to be the real problem, but I haven't seen this error before and don't know what it means. It sounds like there is something wrong in your registry but I don't know how to identify it or correct it.

I'm sure however that it's nothing specific to the py25-wxpython portfile; it's not really possible for individual ports to affect the way in which MacPorts activates and deactivates ports; that's a base function.

[yaseppochi (Stephen J. Turnbull)]

Replying to ryandesign@…:

port upgrade -u py25-wxpython fails to deactivate old version

sudo port -d -v -f uninstall py25-wxpython @2.8.9.1_0 2>&1

Sorry about those. I gave up trying to remember port's options, which I find to be unintuitive, years ago. The aliases I normally use DTRT (but those aliases also do a bunch of things I didn't want to wait for).

DEBUG: this entry does not own the given file

This seems to be the real problem, but I haven't seen this error before and don't know what it means. It sounds like there is something wrong in your registry but I don't know how to identify it or correct it.

Figures. I do an svn up and port sync at least once a week ... one wonders how such a thing can go undetected for so long. :-(

Unfortunately, Tcl makes no sense to me so I'm not going to try to hack in a printf (or whatever it's called in Tcl). If you have any suggestions as to where a printf might be useful and how to write it in Tcl, I don't mind hacking the code.

[yaseppochi (Stephen J. Turnbull)]

I don't have time to mess with this for a few days (in particular, I have *not* yet tried the manual update procedure mentioned in ticket #32686), so there's no hurry on a response. But if somebody has advice on what to look for, or the SQL needed to rip out a broken DB entry by the roots, I'd be very grateful.

I'm now up to r89291, and the automatic upgrade described in ticket #32686 is apparently working (other ports can now be handled fine), but it does not repair this. I still cannot upgrade or uninstall py25-wxpython, and now I'm seeing this after some but not all ports are upgraded:

--->  Updating database of binaries: 4%Error: Updating database of binaries failed
an invalid file was passed
    while executing
"$f path"
    ("foreach" body line 6)
    invoked from within
"foreach f $files {
                    if {![macports::ui_isset ports_debug]} {
                        ui_msg -nonewline "\r$macports::ui_prefix Upda..."
    invoked from within
"try {
                ui_msg -nonewline "$macports::ui_prefix Updating database of binaries"
                set i 1
                foreach f $files ..."
    invoked from within
"registry::write {
            try {
                ui_msg -nonewline "$macports::ui_prefix Updating database of binaries"
                set i 1
   ..."
    (procedure "revupgrade_scanandrebuild" line 8)
    invoked from within
"revupgrade_scanandrebuild broken_port_counts $opts"
    (procedure "macports::revupgrade" line 5)
    invoked from within
"macports::revupgrade $opts"
    (procedure "action_revupgrade" line 2)
    invoked from within
"action_revupgrade $action $portlist $opts"
    (procedure "action_upgrade" line 24)
    invoked from within
"$action_proc $action $portlist [array get global_options]"
    (procedure "process_cmd" line 95)
    invoked from within
"process_cmd $remaining_args"
    invoked from within
"if { [llength $remaining_args] > 0 } {

    # If there are remaining arguments, process those as a command
    set exit_status [process_cmd $remaining..."
    (file "/opt/local/bin/port" line 4760)

I'll report back what I find out when I try the manual upgrade.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #50808. There was also a mention on the mailing list at ​https://lists.macosforge.org/pipermail/macports-dev/2012-February/017837.html.