May 2013 - macports-tickets - lists.macosforge.org

[MacPorts] #26582: darcs takes forever to install - can we install a prebuilt binary instead?
by MacPorts 09 Jun '13

09 Jun '13

#26582: darcs takes forever to install - can we install a prebuilt binary instead? -----------------------------+---------------------------------------------- Reporter: kowey@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: | Port: -----------------------------+---------------------------------------------- Hello! We have a sort of longstanding problem in the Darcs community, which I'm hoping MacPorts could help with. 1. Installing Darcs requires installing GHC, which for various reasons, takes a very long time to install. 2. Often the kinds of people who install Darcs are "involuntary" users, ie. folks who don't care about version control systems, but just want to install Darcs so they can grab some source tree 3. These people (already yak-shave impeded from completing their main task) type "sudo port install darcs"... and find that it doesn't complete until 12 hours or later or something absurd 4. Therefore they decide that they hate Darcs. This is a sort of recurring pattern that hurts Darcs reputation a lot. We'd love to make a better first impression on our users. Can MacPorts help? Installing a version control system is a case where taking a very long time to install can be extremely harmful to the first time user experience, because the first time you decide to install that system is often when you're impatient to get something else done and are definitely not prepared to wait. Would it be at all possible for the Darcs port to install a prebuilt binary by default? If it helps, we now have an official MacOS X binary for Darcs (which we did not before 2010). A variant that does this would be better than nothing, but I worry that it would only be marginally useful unless it was a default, or failing that, unless the Darcs port could somehow jump up and down and say "Hey! You should use the binary instead!" Thanks! -- Ticket URL: <https://trac.macports.org/ticket/26582> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 8

[MacPorts] #39284: Haskell Platform is out of date
by MacPorts 08 Jun '13

08 Jun '13

#39284: Haskell Platform is out of date -----------------------------+-------------------------------- Reporter: karl.smeltzer@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: haskell-platform -----------------------------+-------------------------------- A new version (2013.2) of the Haskell Platform is now available with many useful updates. -- Ticket URL: <https://trac.macports.org/ticket/39284> MacPorts <http://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #39030: upgrade outdated fails (due to atlas upgrade problem) on OSX 10.6.8
by MacPorts 08 Jun '13

08 Jun '13

#39030: upgrade outdated fails (due to atlas upgrade problem) on OSX 10.6.8 ------------------------------+-------------------------------- Reporter: joel@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: upgrade outdated | Port: atlas ------------------------------+-------------------------------- I ran sudo port upgrade outdated. atlas was the first upgrade and at first it failed at the "---> Building Atlas" step. Following the instructions in the Ticket Guidelines, I tried "sudo port clean atlas" and then tried to "upgrade outdated" again. It failed again (log file attached). Following the instructions in the Ticket Guidelines again, I tried to uninstall atlas, intending to reinstall it. I tried "sudo port uninstall atlas", but got an error asking me to specify the full version. After typing "sudo port installed atlas" I then tried "sudo port uninstall atlas @3.9.47_0+gcc44". I received the following error message: "---> Unable to uninstall atlas @3.9.47_0+gcc44, the following ports depend on it: ---> py26-numpy @1.6.0_0+atlas+gcc44" Ticket #34712 seems to be about a similar problem and it says the problem was fixed, but I seem to be having the same problem. I'm not sure what to do next. I can't uninstall and reinstall atlas, and I haven't found another way to get the port upgrade to work. I'm filing a ticket here because it seems to be a bug. Or, at least after following the steps in the ticket posting guidelines, I haven't been able to rule out this being a bug. -- Ticket URL: <https://trac.macports.org/ticket/39030> MacPorts <http://www.macports.org/> Ports system for OS X

1 9

[MacPorts] #32862: libQGLViewer @2.3.10_0 has the wrong path in /opt/local/lib/cmake/FindQGLViewer.cmake
by MacPorts 08 Jun '13

08 Jun '13

#32862: libQGLViewer @2.3.10_0 has the wrong path in /opt/local/lib/cmake/FindQGLViewer.cmake -----------------------------------+---------------------------------------- Reporter: josephwinston@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: -----------------------------------+---------------------------------------- When installing in the normal places, all the paths in /opt/local/lib/cmake/FindQGLViewer.cmake use /usr instead of /opt -- Ticket URL: <https://trac.macports.org/ticket/32862> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #38218: default optflags should be -Os rather than -O2
by MacPorts 08 Jun '13

08 Jun '13

#38218: default optflags should be -Os rather than -O2 ------------------------+-------------------------------- Reporter: jeremyhu@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Keywords: | Port: ------------------------+-------------------------------- All the kids are doing it. -Os will result in smaller text allowing for more optimal use of spacial locality in the text cache. As an added benefit, ppc will benefit in areas where -O2 results in text segments that are too large for reloc (#37839) -- Ticket URL: <https://trac.macports.org/ticket/38218> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 13

[MacPorts] #38034: Error while cleaning: "Failed to locate 'bsdmake' in path"
by MacPorts 08 Jun '13

08 Jun '13

#38034: Error while cleaning: "Failed to locate 'bsdmake' in path" ----------------------+-------------------- Reporter: larryv@… | Owner: cal@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.99 Keywords: | Port: ----------------------+-------------------- Running from trunk at r103010. {{{ % sudo port -d clean agrep DEBUG: Copying /Users/larryv/Library/Preferences/com.apple.dt.Xcode.plist to /opt/local/var/macports/home/Library/Preferences DEBUG: Changing to port directory: /Users/larryv/Projects/MacPorts/trunk/dports/sysutils/agrep DEBUG: OS darwin/12.2.0 (Mac OS X 10.8) arch i386 DEBUG: universal_variant is false, so not adding the default universal variant DEBUG: Running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Finished running callback portconfigure::add_automatic_compiler_dependencies DEBUG: Running callback portbuild::add_automatic_buildsystem_dependencies DEBUG: Failed to locate 'bsdmake' in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its MacPorts configuration time location, did you move it? invoked from within "findBinary bsdmake $portutil::autoconf::bsdmake_path" (procedure "portbuild::build_getmaketype" line 8) invoked from within "portbuild::build_getmaketype" invoked from within "set build.cmd [portbuild::build_getmaketype]" ("uplevel" body line 1) invoked from within "uplevel #0 set $optionName $option_defaults($optionName)" (procedure "default_check" line 11) invoked from within "default_check build.cmd {} r" (read trace on "build.cmd") invoked from within "string match "*bsdmake*" ${build.cmd}" (procedure "portbuild::add_automatic_buildsystem_dependencies" line 4) invoked from within "${callback}" (procedure "port::run_callbacks" line 5) invoked from within "port::run_callbacks" invoked from within "$workername eval port::run_callbacks" (procedure "mportopen" line 59) invoked from within "mportopen $porturl [array get options] [array get requested_variations]" Error: Unable to open port: can't read "build.cmd": Failed to locate 'bsdmake' in path: '/opt/local/bin:/opt/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin' or at its MacPorts configuration time location, did you move it? % }}} -- Ticket URL: <https://trac.macports.org/ticket/38034> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #38010: MacPorts should not ship .la files
by MacPorts 08 Jun '13

08 Jun '13

#38010: MacPorts should not ship .la files -------------------------+------------------- Reporter: jeremyhu@… | Owner: jmr@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.3 Keywords: glibtool la | Port: -------------------------+------------------- base should delete ${prefix}/lib/*.la in our standard destroot phases, and we should have a verification phase which asserts that no ${prefix}/lib/*.la files are installed. These .la files just serve to screw up builds by adding unnecessary links. They are only useful in legacy situations or when building static executables. They have no place on a modern OS. -- Ticket URL: <https://trac.macports.org/ticket/38010> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 30

[MacPorts] #34221: gettext fails to build after osx 10.8 and xcode 4.4 upgrade
by MacPorts 08 Jun '13

08 Jun '13

#34221: gettext fails to build after osx 10.8 and xcode 4.4 upgrade ---------------------------------------+------------------------------------ Reporter: richard.t.lloyd@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.4 Keywords: gettext osx10.8 xcode4.4 | Port: gettext ---------------------------------------+------------------------------------ Working from a clean disk (no macports remnants from previous) I did: 1. cd MacPorts-2.0.4 && ./configure && make && sudo make install 2. sudo port install gettext All goes fine installing the 4 dependencies expat, libiconv, gperf, and ncurses. The problem is with gettext itself. The build sequence hangs at: '''---> Configuring gettext'''. It doesn't return, at least not for 4+ hours, which is this programmer's equivalent to never. Attempting to understand what's happening I've looked at the MacPorts main.log as well as the various config.log files inside gettext. The last active point seems to be in gettext-runtime. I've attached main.log, gettext/config.log, and gettext-runtime/config.log as well as the screen output. Let me know if you need anything else. -- Ticket URL: <https://trac.macports.org/ticket/34221> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 75

[MacPorts] #29838: Generate shared libraries what can be processed with install_name_tool (one step toward shared library relocation)
by MacPorts 08 Jun '13

08 Jun '13

#29838: Generate shared libraries what can be processed with install_name_tool (one step toward shared library relocation) --------------------------------+------------------------------------------- Reporter: gellule.xg@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 1.9.2 Keywords: | Port: --------------------------------+------------------------------------------- "install_name_tool" changes dynamic shared library install names and/or adds, changes or deletes the rpaths recorded in a Mach-O binary. For this tool to work when the install names or rpaths are larger the binary should be built with the ld "headerpad_max_install_names" option. This tool can therefore be used to relocate a shared library outside of the macports tree. The purpose of this ticket is to add to LDFLAGS the "-Wl,-headerpad_max_install_names" option for all ports. A simple approach would be to modify portconfigure.tcl by setting "default configure.ldflags" to: {{{ default configure.ldflags {"-L${prefix}/lib -Wl,-headerpad_max_install_names"} }}} I haven't been able to identify a drawback to this default addition. There is a thread related to this issue that mentions the fact that some ports do erase the default ldflags: [http://lists.macosforge.org/pipermail /macports-dev/2011-March/thread.html#14202] This addition helps with relocation, but does not guarantee it: there could well be other aspects of the built libraries that are not compatible with a relocation. -- Ticket URL: <https://trac.macports.org/ticket/29838> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 8

[MacPorts] #32542: Setting configure.compiler to a MacPorts-provided compiler doesn't add dependency automatically
by MacPorts 08 Jun '13

08 Jun '13

#32542: Setting configure.compiler to a MacPorts-provided compiler doesn't add dependency automatically ------------------------------+--------------------------------------------- Reporter: cal@… | Owner: raimue@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.0.3 Keywords: | Port: ------------------------------+--------------------------------------------- Setting configure.compiler to a compiler provided my MacPorts doesn't automatically add a dependency on this compiler. For an example see the percona port, which sets configure.compiler to apple-gcc-4.2, but doesn't declare a dependency on it. -- Ticket URL: <https://trac.macports.org/ticket/32542> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 32