Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#18553 closed defect (worksforme)

'sudo port install gimp' hangs indefinitely

Reported by: kevin.h.kahl@… Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version: 1.7.0
Keywords: Cc:
Port: gimp


OSX 10.5.6 - Newest generation MacBook Pro

Fresh installation of Xcode and X11 SDK from iPhone-dev-sdk-2.2. Fresh installation of MacPorts (1.7.0)

Executing 'sudo port -d install gimp' causes repetitive debug info and seems to infinitely loop. tclsh consumes nearly 100% cpu. I tried more than once and have let it run for more than 1 hour. Output and symptoms nearly identical to that mentioned in ticket #13069 except that it never completes.

Upon request, I can attempt again and attach as many minutes worth of debugging output as you wish.

Attachments (1)

gimp.rdeps.gz (178.4 KB) - added by dbevans (David B. Evans) 12 years ago.
Port gimp dependency tree (compressed)

Download all attachments as: .zip

Change History (11)

comment:1 Changed 12 years ago by jmroot (Joshua Root)

Owner: changed from macports-tickets@… to devans@…
Port: gimp added

What makes you so sure that you don't just have to give it more time, when that was the case in the last ticket? Gimp has an enormous dependency graph.

comment:2 Changed 12 years ago by kevin.h.kahl@…

Thank you, yes, I did consider that, and I confess that I have no way of being certain. I do know that the -v switch produces no output of any kind while the -d switch produces so much (of what looks to be looping, repetitive output) as to be effectively unusable as a way to measure progress. Lacking any usable visual indication of progress, I am only able to use other tools and empirical observation:

  • Tclsh was allowed to consume 68 minutes (!) worth of CPU time before I finally gave up. That's a lot of processing resource consumption on a multi-core 2+GHz CPU. I don't expect an installation task to be particularly compute-intensive.
  • I don't have any indication of heavy disk or network activity.
  • I don't have any idea of what the expected run time is, or even what the command is trying to do. The last ticket mentioned "just having to wait a few minutes". This gives me an impression of minutes, not hours.

Based on the above, for all intents and purposes, this looks like a hang. That's my best guess. Perhaps if someone could tell me what the expected typical run time for a gimp installation might be, or if the tool could output some progress indications, I might have a better sense of whether this really is hung...

comment:3 Changed 12 years ago by dbevans (David B. Evans)

As jmr says gimp has a lot of dependencies so if you are installing from scratch it can take a lot of time to process the dependencies before it actually starts installing. Many dependencies are visited more than once if they are declared in more than one port (MacPorts apparently processes the entire dependency tree without remembering if a dependency was previously processed). So the debug output you should see initially should be repetitive dependency checks as it goes through the tree and you may (will) see some dependencies processed many times which could make you think that it was looping.

If you have none of the dependencies installed (a clean MacPorts installation), then installation of gimp could be an overnight operation.

You might try installing some of the major dependencies first, then move up the tree. For instance, port gimp2 (one of gimp's dependencies) will install the gimp application itself without the additional add on plugins and themes that gimp installs. Significant dependencies of gimp2 are gegl and gtk2 so try installing some of these first and see what happens.

I'd try this sequence:

sudo port install gtk2
sudo port install gegl
sudo port install gimp2
sudo port install gimp

If you really think that there is some looping going on please capture as much of the debug output as you can stand and add as an attachment and I'll compare it to a clean build here. I think the attachment size limit is 1 Mb.

comment:4 Changed 12 years ago by dbevans (David B. Evans)

Just to give you an idea of the magnitude of the task, attached (compressed) is gimp's current dependency tree. From this you can see there are 179865 entries in gimp's dependency tree representing 246 unique ports.

Changed 12 years ago by dbevans (David B. Evans)

Attachment: gimp.rdeps.gz added

Port gimp dependency tree (compressed)

comment:5 Changed 12 years ago by blb@…

Note that, long-term, ticket #18259 should vastly improve this situation.

comment:6 Changed 12 years ago by dbevans (David B. Evans)

Would also help significantly if this process could be taught to skip tracing dependencies for port subtrees that have already been visited. For instance each of the plugins depends on gimp2 so it looks like the whole gimp2 subtree is searched for each one of them when doing it the once first time is really sufficient. But this is off topic of the ticket.

comment:7 in reply to:  6 Changed 12 years ago by jmroot (Joshua Root)

Replying to devans@…:

Would also help significantly if this process could be taught to skip tracing dependencies for port subtrees that have already been visited.

The mportdepends proc actually does do that.

comment:8 Changed 12 years ago by kevin.h.kahl@…

Success. Please close / resolve this ticket.

The order of installation recommended above was successful. Thank you, devans, for the suggested order of installation. Usable progress was reported throughout each stage and at no time did the system appear to be hung. I hope that this commentary helps others in the future. Each stage did indeed take time, and the overall process consumed much of a day. However, after completing the first three installation steps, the command "sudo port install gimp" almost immediately began reporting progress and was ultimately successful.

I wholeheartedly support the other comments in this discussion that suggest ways to make to dependency traversal more efficient. I have installed Gimp under several other environments (both binary: Debian Linux, Fedora/Red Hat Linux, and build-from-source: Gentoo/emerge/portage) and never before experienced anything like what I reported in the initial ticket description.

Thank you for hosting this "non-bug" discussion and for providing meaningful and useful suggestions and support. Please keep up the good work!

comment:9 Changed 12 years ago by dbevans (David B. Evans)

Resolution: worksforme
Status: newclosed

Glad its working for you.

comment:10 Changed 12 years ago by (none)

Milestone: Port Bugs

Milestone Port Bugs deleted

Note: See TracTickets for help on using tickets.