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

[MacPorts] #40527: py27-pyqt4 installation failing on snowleopard
by MacPorts 02 Oct '13

02 Oct '13

#40527: py27-pyqt4 installation failing on snowleopard --------------------------+-------------------------------- Reporter: srirajpaul@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Keywords: | Port: --------------------------+-------------------------------- I was trying to install py27-pyqt4 on my mac. But it is failing. It looks like is having some problem with Qt. Attaching the log file. -- Ticket URL: <https://trac.macports.org/ticket/40527> MacPorts <http://www.macports.org/> Ports system for OS X

1 7

[MacPorts] #38572: glib2: fix livecheck
by MacPorts 02 Oct '13

02 Oct '13

#38572: glib2: fix livecheck -------------------------+-------------------------- Reporter: cal@… | Owner: ryandesign@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: glib2 -------------------------+-------------------------- The glib2 livecheck does not detect new stable releases. Since glib2 is a GNOME project, it uses the "even majors are new stable releases" versioning scheme. The following patch takes that into account. Note that according to this new livecheck, glib2 is outdated (and the new version of gtk3, which is also outdated, requires a glib2 update). -- Ticket URL: <https://trac.macports.org/ticket/38572> MacPorts <http://www.macports.org/> Ports system for OS X

1 6

[MacPorts] #40144: libgnomeui +no_x11 has unsubstituted @SM_LIBS@ in pkgconfig
by MacPorts 02 Oct '13

02 Oct '13

#40144: libgnomeui +no_x11 has unsubstituted @SM_LIBS@ in pkgconfig ----------------------+-------------------------------- Reporter: daniel@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Keywords: | Port: libgnomeui ----------------------+-------------------------------- See: {{{ $ grep Libs /opt/local/lib/pkgconfig/libgnomeui-2.0.pc Libs: -L${libdir} -lgnomeui-2 @SM_LIBS@ }}} This causes other builds (py27-gnome, for instance) to fail. It seems like r107414 is the culprit here. -- Ticket URL: <https://trac.macports.org/ticket/40144> MacPorts <http://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #39319: netcdf-fortran: NETCDF.mod install location varies with universal variant
by MacPorts 02 Oct '13

02 Oct '13

#39319: netcdf-fortran: NETCDF.mod install location varies with universal variant --------------------------+---------------------------- Reporter: ryandesign@… | Owner: takeshi@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: netcdf-fortran --------------------------+---------------------------- netcdf-fortran installs NETCDF.mod to a different location depending on whether or not the universal variant is used: {{{ $ port -v -q installed netcdf-fortran netcdf-fortran @4.2_6+gcc47 (active) platform='darwin 12' archs='x86_64' netcdf-fortran @4.2_6+gcc47+universal platform='darwin 12' archs='i386 x86_64' $ port contents netcdf-fortran | grep mod /opt/local/include/NETCDF.mod /opt/local/include/TYPESIZES.mod $ sudo port activate netcdf-fortran @4.2_6+gcc47+universal ---> Computing dependencies for netcdf-fortran ---> Deactivating netcdf-fortran @4.2_6+gcc47 ---> Activating netcdf-fortran @4.2_6+gcc47+universal ---> Cleaning netcdf-fortran $ port contents netcdf-fortran | grep mod /opt/local/include/TYPESIZES.mod /opt/local/include/mods32/NETCDF.mod /opt/local/include/mods64/NETCDF.mod }}} How are ports that want to use NETCDF.mod meant to deal with this situation? Currently it is leading to build failures like comment:ticket:38995:10. -- Ticket URL: <https://trac.macports.org/ticket/39319> MacPorts <http://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #40613: epstool: unable to open output file './epsobj/xnodll.o'
by MacPorts 02 Oct '13

02 Oct '13

#40613: epstool: unable to open output file './epsobj/xnodll.o' ---------------------+---------------------- Reporter: mojca@… | Owner: master@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: epstool ---------------------+---------------------- Upgrading epstool fails with: {{{ :info:build /usr/bin/clang -I./src -I./epsobj -I/opt/local/include -DX11 -DUNIX -DNONAG -Wall -Wstrict-prototypes -Wmissing-declarations -Wmissing-prototypes -fno-builtin -fno-common -Wcast-qual -Wwrite-strings -g -o ./epsobj/xnodll.o -c ./src/xnodll.c :info:build mkdir ./epsobj :info:build error: unable to open output file './epsobj/xnodll.o': 'Error opening output file './epsobj/xnodll.o'' :info:build 1 error generated. :info:build echo "dummy" > ./epsobj/lib.rsp :info:build make: *** [epsobj/xnodll.o] Error 1 :info:build make: *** Waiting for unfinished jobs.... }}} To me this looks like the wrong order of commands, that is: {{{ mkdir ./epsobj }}} should probably happen before the compiler tries to write to `-o ./epsobj/xnodll.o` After repeating the build it seems to go through successfully. I suggest to either disable parallel build or try to fix the problem properly, possibly coordinating with upstream developers. -- Ticket URL: <https://trac.macports.org/ticket/40613> MacPorts <http://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #39334: texlive-basic: dvipdfmx fails with png and jpg
by MacPorts 02 Oct '13

02 Oct '13

#39334: texlive-basic: dvipdfmx fails with png and jpg -----------------------+-------------------------------- Reporter: takeshi@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: texlive-basic -----------------------+-------------------------------- dvipdfmx can't convert dvi to pdf if images such as jpg and png are included. The Japanese TeX community has identified that the binary compiled with clang has this problem. I compiled dvipdfmx with macports- gcc-4.7 and it does work. I'm not familiar with how texlive-basic install binaries, but building with configure.compiler=macports-gcc-4.7 doesn't work; it appears that the texlive-basic port doesn't build from source. -- Ticket URL: <https://trac.macports.org/ticket/39334> MacPorts <http://www.macports.org/> Ports system for OS X

1 13

[MacPorts] #39784: Doxygen @1.8.3.1: update to 1.8.4
by MacPorts 02 Oct '13

02 Oct '13

#39784: Doxygen @1.8.3.1: update to 1.8.4 ---------------------+-------------------------------- Reporter: egall@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: doxygen ---------------------+-------------------------------- {{{ Local-Admins-MacBook-Pro:~ root# port -v livecheck doxygen doxygen seems to have been updated (port version: 1.8.3.1, new version: 1.8.4) }}} Changelog link: http://www.stack.nl/~dimitri/doxygen/manual/changelog.html New features of note, that I felt like cherrypicking from the changelog linked above: - "clang-assisted parsing" - enabled with the `--with-libclang` option (we might want to make this a variant; [https://github.com/mxcl/homebrew/blob/master/Library/Formula/doxygen.rb#L13 that's what Homebrew does at least]) - docbook output support (not sure if this requires a new dependency on any of the docbook ports...) - support for documenting UNO packages (the type that OpenOffice uses) - can time itself when running -- Ticket URL: <https://trac.macports.org/ticket/39784> MacPorts <http://www.macports.org/> Ports system for OS X

1 9

[MacPorts] #39086: cmake 2.8.10.2 with macosx_deployment_target 10.7 fails to configure
by MacPorts 02 Oct '13

02 Oct '13

#39086: cmake 2.8.10.2 with macosx_deployment_target 10.7 fails to configure --------------------+-------------------------------- Reporter: help@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: cmake --------------------+-------------------------------- {{{ $ sudo port install cmake ---> Computing dependencies for cmake ---> Fetching distfiles for cmake ---> Verifying checksum(s) for cmake ---> Extracting cmake ---> Applying patches to cmake ---> Configuring cmake Error: org.macports.configure for port cmake returned: configure failure: command execution failed Please see the log file for port cmake for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_cmake/cmake/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port cmake failed }}} From main.log: {{{ :info:configure CMake Error at Modules/Platform/Darwin.cmake:190 (message): :info:configure CMAKE_OSX_DEPLOYMENT_TARGET is '10.7' but CMAKE_OSX_SYSROOT: :info:configure :info:configure "" :info:configure :info:configure is not set to a MacOSX SDK with a recognized version. Either set :info:configure CMAKE_OSX_SYSROOT to a valid SDK or set CMAKE_OSX_DEPLOYMENT_TARGET to :info:configure empty. :info:configure Call Stack (most recent call first): :info:configure Modules/CMakeSystemSpecificInformation.cmake:36 (include) :info:configure CMakeLists.txt:14 (project) :info:configure :info:configure :info:configure -- Configuring incomplete, errors occurred! }}} Full main.log is attached. Compilation succeeds when macosx_deployment_target isn't set in macports.conf. -- Ticket URL: <https://trac.macports.org/ticket/39086> MacPorts <http://www.macports.org/> Ports system for OS X

1 13

[MacPorts] #40559: doxygen @1.8.5_0+wizard: contains file with literal destroot path
by MacPorts 02 Oct '13

02 Oct '13

#40559: doxygen @1.8.5_0+wizard: contains file with literal destroot path ----------------------+--------------------- Reporter: raimue@… | Owner: css@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Keywords: | Port: doxygen ----------------------+--------------------- After installation of doxygen @1.8.5_0+wizard, I got the following message from rev-upgrade: {{{ ---> Updating database of binaries: 100.0% Warning: Error determining file type of `/opt/local/var/macports/build/_Users_raimue_src_macports_trunk_dports_textproc_doxygen/doxygen/work/destroot/opt/local/share/man/man1/doxywizard.1': lstat(/opt/local/var/macports/build/_Users_raimue_src_macports_trunk_dports_textproc_doxygen/doxygen/work/destroot/opt/local/share/man/man1/doxywizard.1):no such file or directory Warning: A file belonging to the `doxygen' port is missing or unreadable. Consider reinstalling it. }}} And this file is really part of the installed port, with a path that seems absolutely wrong: {{{ $ port -q installed doxygen doxygen @1.8.5_0+wizard (active) $ port contents doxygen Port doxygen contains: /Applications/MacPorts/DoxyWizard.app/Contents/Info.plist /Applications/MacPorts/DoxyWizard.app/Contents/MacOS/DoxyWizard /Applications/MacPorts/DoxyWizard.app/Contents/PkgInfo /Applications/MacPorts/DoxyWizard.app/Contents/Resources/empty.lproj /opt/local/bin/doxygen /opt/local/bin/doxywizard /opt/local/share/man/man1/doxygen.1.gz /opt/local/var/macports/build/_Users_raimue_src_macports_trunk_dports_textproc_doxygen/doxygen/work/destroot/opt/local/share/man/man1/doxywizard.1 }}} -- Ticket URL: <https://trac.macports.org/ticket/40559> MacPorts <http://www.macports.org/> Ports system for OS X

1 6

[MacPorts] #40542: Altas build fails during Octave install
by MacPorts 01 Oct '13

01 Oct '13

#40542: Altas build fails during Octave install --------------------+-------------------------------- Reporter: andy@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Keywords: | Port: --------------------+-------------------------------- Hello, Please forgive me if I've missed something obvious. When I tried to install Octave (sudo port install octave), it chugged away for a while, then froze building atlas. I looked for similar errors, saw that maybe spotlight was a problem, so I disabled it. That didn't unhang things, so I did a control-C and said "sudo port install octave" again. This time I got an error, I'm attaching the log file. Interestingly, when I do a "sudo port clean octave", and then "sudo port install octave", the build tries to pick up where it left off, building atlas. I didn't expect that - I thought it would start at the beginning of the octave install. I'm running Xcode 5 and OS X 10.8.5 Thanks! - Andy Voelkel -- Ticket URL: <https://trac.macports.org/ticket/40542> MacPorts <http://www.macports.org/> Ports system for OS X

1 17