Opened 13 years ago

Closed 13 years ago

#26956 closed defect (fixed)

vtk5 +qt4_mac post-destroot error

Reported by: jjstickel@… Owned by: michaelld (Michael Dickens)
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: qt4 Cc: adfernandes (Andrew Fernandes)
Port: vtk5

Description

Just tried to install vtk5 with qt4_mac variant, and got this error:

$ sudo port -uv install vtk5 +qt4_mac +python26 +data -tcltk
... all looks OK ...
Error: Target org.macports.destroot returned: can't read "qt_plugins_dir": no such variable
Warning: the following items did not execute (for vtk5): org.macports.activate org.macports.destroot org.macports.install
Log for vtk5 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_svn.macports.org_trunk_dports_graphics_vtk5/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

I see "${qt_plugins_dir}" begin used in the post-destroot phase for the qt4_mac variant in the Portfile. I'm guessing this has something to do with the qt4 PortGroup, but I know little about portgroups.

Change History (17)

comment:1 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: michaelld@… added

I see similar problems with several other ports following the qt4-mac 4.7.0 / qt4 portgroup update. Michael?

comment:2 Changed 13 years ago by michaelld (Michael Dickens)

Hmm .. do "set" variables inside variants not carry through into stages nested inside those variants? That seems like a common theme in my local testing & what's being reported. If not, do I have to set the variables in a top-level "if" statement testing whether or not the variant is set?

comment:3 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)

setting a variable in a variant is a local variable to the variant, unless the variable is also set somewhere in the global part of the portfile which makes it a global variable, or unless you say "global thevariablename" in the variant.

comment:4 Changed 13 years ago by michaelld (Michael Dickens)

That's what I thought too. The following will cause the issue:

variant qt4_mac {
    PortGroup     qt4 1.0
    post-destroot {
        xinstall -m 755 -d ${destroot}${qt_plugins_dir}/designer
    }
}

where "qt_plugins_dir" is 'set' in the portgroup (really, it is), but is not being picked up by the nested 'post-destroot' stage. I'll play around with this & see what I can come up with as a work-around -- unless you know what the issue is off the top of your head.

comment:5 Changed 13 years ago by jjstickel@…

I have using svn to sync - could that be the problem? I'm currently trying to reinstall after syncing with rsync. I will report back after awhile.

comment:6 Changed 13 years ago by jjstickel@…

No... same error.

comment:7 Changed 13 years ago by michaelld (Michael Dickens)

OK; I'll play around with how the PortGroup is included & see if I can come up with a workaround. Probably won't get to it until tonight though. Seems like this is issue is also in a few others ports too.

comment:8 Changed 13 years ago by michaelld (Michael Dickens)

Owner: changed from macports-tickets@… to michaelld@…

I just checked in r72687, which hopefully addresses this particular issue. Please do a "selfupdate", clean this port, and try installing again. I'm leaving this ticket open for now.

comment:9 Changed 13 years ago by jjstickel@…

Now I get:

$ sudo port -uv install vtk5 +qt4_mac +python26 +data -tcltk
...
Error: Target org.macports.destroot returned: error renaming "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_vtk5/work/destroot/opt/local/plugins/designer/libQVTKWidgetPlugin.dylib" to "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_vtk5/work/destroot/opt/local/share/qt4/plugins/designer/libQVTKWidgetPlugin.dylib": file already exists
Warning: the following items did not execute (for vtk5): org.macports.activate org.macports.destroot org.macports.install
Log for vtk5 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_graphics_vtk5/main.log
Error: Status 1 encountered during processing.
To report a bug, see <http://guide.macports.org/#project.tickets>

comment:10 Changed 13 years ago by michaelld (Michael Dickens)

@jjstickel: I don't think the Portfile was updated, so your command tried to re-do 'destroot' which generated the error because the file copy had already been done. Please do:

sudo port clean vtk5
sudo port selfupdate
sudo port -uv install vtk5 +qt4_mac +python26 +data -tcltk

and see if that works for you.

comment:11 Changed 13 years ago by michaelld (Michael Dickens)

Cc: michaelld@… removed

Cc Me!

comment:12 in reply to:  10 ; Changed 13 years ago by jjstickel@…

Replying to michaelld@…:

@jjstickel: I don't think the Portfile was updated, so your command tried to re-do 'destroot' which generated the error because the file copy had already been done. Please do:

sudo port clean vtk5
sudo port selfupdate
sudo port -uv install vtk5 +qt4_mac +python26 +data -tcltk

and see if that works for you.

That's what I did (well, I did the selfupdate before the clean). Even if I missed the clean, I am pretty sure it would auto-clean due to the updated portfile.

comment:13 in reply to:  12 Changed 13 years ago by jjstickel@…

Replying to jjstickel@…:

Replying to michaelld@…:

@jjstickel: I don't think the Portfile was updated, so your command tried to re-do 'destroot' which generated the error because the file copy had already been done. Please do:

sudo port clean vtk5
sudo port selfupdate
sudo port -uv install vtk5 +qt4_mac +python26 +data -tcltk

and see if that works for you.

That's what I did (well, I did the selfupdate before the clean). Even if I missed the clean, I am pretty sure it would auto-clean due to the updated portfile.

OK, not sure what happened, but it seems to be working now.

comment:14 Changed 13 years ago by jjstickel@…

I did notice another bug: ${vtkdest} is not being understood in the "data" variant section. I worked around it by not using the data variant. Rather than opening another ticket, I mention it here since it is related (global vs. local variables).

comment:15 in reply to:  14 Changed 13 years ago by adfernandes (Andrew Fernandes)

Whups - sorry people - I did something kinda' bad and checked in a revision to vtk-5.6.1 without searching first (the port was marked nomaintainer; I've offered my hat, but with openmaintainer). I fixed the ${vtkdest} problem by simply setting the variable at both post-destroot phases. Bad practice, I know, but it got the job done. :-(

comment:16 Changed 13 years ago by adfernandes (Andrew Fernandes)

Cc: adfernandes@… added

Cc Me!

comment:17 Changed 13 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: newclosed

adfernandes: No problem.

Seems like this ticket is fixed so I'm closing it; please do:

sudo port clean root
sudo port selfupdate
sudo port install root +qt_mac [+other_variants]

and see if the issue of this ticket is fixed & if not then reopen it.

Note: See TracTickets for help on using tickets.