November 2012 - macports-tickets - lists.macosforge.org

[MacPorts] #28856: GraphicsMagick @1.3.12 Add jpeg2 variant
by MacPorts 30 Jan '13

30 Jan '13

#28856: GraphicsMagick @1.3.12 Add jpeg2 variant ----------------------------------------------+----------------------------- Reporter: joel@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Low | Milestone: Component: ports | Version: 1.9.2 Keywords: GraphicsMagick port jpeg2000 jp2 | Port: GraphicsMagick ----------------------------------------------+----------------------------- GraphicsMagick disabled JPEG 2000 support by default. I needed it activated. Initially I just edited the Portfile to change the --with-jp2 to "yes" but then I though it should be an option. Easy enough to add, right? See attached patch file. -- Ticket URL: <https://trac.macports.org/ticket/28856> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #27738: webkit-gtk parallel build issue
by MacPorts 30 Jan '13

30 Jan '13

#27738: webkit-gtk parallel build issue -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: devans@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: webkit-gtk -------------------------------------+-------------------------------------- webkit-gtk has a strange build problem for me on Snow Leopard. I get this error: {{{ CXX JavaScriptCore/pcre/libJavaScriptCore_la-pcre_tables.lo In file included from JavaScriptCore/pcre/pcre_tables.cpp:73: JavaScriptCore/pcre/chartables.c:13: error: conflicting declaration 'const unsigned char jsc_pcre_default_tables [0u]' JavaScriptCore/pcre/pcre_internal.h:382: error: 'jsc_pcre_default_tables' has a previous declaration as 'const unsigned char jsc_pcre_default_tables [480]' JavaScriptCore/pcre/chartables.c:32: error: expected primary-expression at end of input JavaScriptCore/pcre/chartables.c:32: error: expected `}' at end of input make[1]: *** [JavaScriptCore/pcre/libJavaScriptCore_la-pcre_tables.lo] Error 1 make: *** [all] Error 2 }}} Line 382 of pcre_internal.h reads: {{{ extern const unsigned char jsc_pcre_default_tables[tables_length]; }}} And earlier in that file we have: {{{ #define cbit_length 96 /* Length of the cbits table */ }}} {{{ #define cbits_offset 256 #define ctypes_offset (cbits_offset + cbit_length) #define tables_length (ctypes_offset + 128) }}} So that looks fine. But in chartables.c on line 13 we have: {{{ const unsigned char jsc_pcre_default_tables[0] = { }}} That's wrong. And in fact, chartables.c ends with the line: {{{ /* This table is a case flipping table. */ }}} (There should be a lot more after that line.) If I manually run dftables (the program that creates chartables.c), a complete correct-looking file is created. If I delete chartables.c and rerun the port install, it recreates chartables.c correctly. I think it's a parallel build issue. dftables tries to read values from pcre_internal.h, and this will fail if pcre_internal.h has not been written yet. -- Ticket URL: <https://trac.macports.org/ticket/27738> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #31930: pyside build fail
by MacPorts 29 Jan '13

29 Jan '13

#31930: pyside build fail -----------------------------------------+---------------------------------- Reporter: public@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: pyside qt python | Port: py27-pyside -----------------------------------------+---------------------------------- Although I already managed to build and install py27-pyside I am having problems with the latest update. I even tried uninstalling all Qt related dependencies but still no luck. I have attached my build log -- Ticket URL: <https://trac.macports.org/ticket/31930> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #35982: qt4-mac & Qt4 portgroup: clang spec for qmake
by MacPorts 29 Jan '13

29 Jan '13

#35982: qt4-mac & Qt4 portgroup: clang spec for qmake --------------------------------------------+------------------------------- Reporter: mojca.miklavec.lists@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: qt4-mac --------------------------------------------+------------------------------- This issue came up during inclusion of Goldendict port which currently uses: {{{ configure.cmd ${qt_qmake_cmd} configure.pre_args configure.universal_args-delete --disable-dependency-tracking variant universal {} build.args CC="${configure.cc} [get_canonical_archflags cc]" \ CXX="${configure.cxx} [get_canonical_archflags cxx]" \ LINK="${configure.cxx} [get_canonical_archflags cxx]" \ XXXOBJC="${configure.cc} [get_canonical_archflags cc]" }}} The problem is that {{{${qt_qmake_cmd}}}} from Qt4 portgroup doesn't take sufficient care of choosing the desired compiler. qmake can take a spec file as an argument (something like {{{qmake -spec macx-llvm}}}) and the spec file takes care of setting the compiler and its flags. This is the list of currently installed spec files: {{{ /opt/local/share/qt4/mkspecs/macx-g++/qmake.conf /opt/local/share/qt4/mkspecs/macx-g++40/qmake.conf /opt/local/share/qt4/mkspecs/macx-g++42/qmake.conf /opt/local/share/qt4/mkspecs/macx-icc/qmake.conf /opt/local/share/qt4/mkspecs/macx-llvm/qmake.conf /opt/local/share/qt4/mkspecs/macx-pbuilder/qmake.conf /opt/local/share/qt4/mkspecs/macx-xcode/qmake.conf /opt/local/share/qt4/mkspecs/macx-xlc/qmake.conf }}} I actually miss {{{macx-clang}}} spec being present upstream, but even then I'm not absolutely sure if this would cover all the cases. Most probably there is some further tweaking needed to convince qmake to work as desired (choose the right compiler and flags, possibly handling universal builds as well). -- Ticket URL: <https://trac.macports.org/ticket/35982> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #25264: libmcs: master_sites, bz2
by MacPorts 29 Jan '13

29 Jan '13

#25264: libmcs: master_sites, bz2 -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: jdunn@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.0 Keywords: | Port: libmcs -------------------------------------+-------------------------------------- libmcs uses a master_sites definition that appears to be hosted on a web site owned by you, the port maintainer. Why isn't the port using the project's own download location, http://distfiles.atheme.org/ ? They even have .tbz2 versions there, which are smaller and therefore preferred. Why is the .tar.gz file on your server twice as large as the .tgz file on the project's own server? I tried comparing their contents and they're radically different. What's going on? Which is the real 0.7.1? -- Ticket URL: <http://trac.macports.org/ticket/25264> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #16792: Request for new port: rkhunter
by MacPorts 29 Jan '13

29 Jan '13

#16792: Request for new port: rkhunter -------------------------------+-------------------------------------------- Reporter: ralph(a)cs.cf.ac.uk | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Requests Component: ports | Version: 1.6.0 Keywords: | Port: -------------------------------+-------------------------------------------- This is a request for a port of rkhunter (root kit detection software). -- Ticket URL: <http://trac.macports.org/ticket/16792> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #15466: please include a poortfile for lazarus
by MacPorts 29 Jan '13

29 Jan '13

#15466: please include a poortfile for lazarus -------------------------------------+-------------------------------------- Reporter: jpenguin(a)clovermail.net | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Keywords: | -------------------------------------+-------------------------------------- and all of it dependencies http://wiki.lazarus.freepascal.org/ -- Ticket URL: <http://trac.macports.org/ticket/15466> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #34805: poedit-devel
by MacPorts 29 Jan '13

29 Jan '13

#34805: poedit-devel --------------------------------------------+------------------------------- Reporter: mojca.miklavec.lists@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Keywords: | Port: poedit --------------------------------------------+------------------------------- I would like to request adding poedit-devel port. The reasons why poedit itself is not satisfactory for me: * requires wxWidgets and thus conflicts with, say, gnuplot +wxwidgets_devel * 1.4.6 messes up line breaks and keeps confusing version control There are quite some Lion-specific fixes. On top of what's in Portfile, here are a few more variables from build.properties that might be worth fixing as well before configuring anything: {{{ osx.xcoderoot=/Developer poedit.osx.sdk=10.6 poedit.osx.deploy=10.5 poedit.osx.arch.native=i386 poedit.osx.sdk.path=${osx.xcoderoot}/SDKs/MacOSX${poedit.osx.sdk}.sdk poedit.osx.cc=${osx.xcoderoot}/usr/bin/gcc poedit.osx.cxx=${osx.xcoderoot}/usr/bin/g++ poedit.osx.cflags.sdk=-isysroot ${poedit.osx.sdk.path} -mmacosx-version- min=${poedit.osx.deploy} poedit.osx.ldflags.sdk=${poedit.osx.cflags.sdk} -Wl,-syslibroot,${poedit.osx.sdk.path} -Wl,-macosx_version_min,${poedit.osx.deploy} poedit.osx.cflags=-O2 -ggdb3 ${poedit.osx.cflags.sdk} poedit.osx.ldflags=-ggdb3 ${poedit.osx.ldflags.sdk} }}} as well as some variables in build.xml. But I'm not sure which ones are actually used as I don't get i386 binary despite the quote above. -- Ticket URL: <https://trac.macports.org/ticket/34805> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 16

[MacPorts] #31256: ctags 5.8 creates improper tags file when compiled on OS X Lion
by MacPorts 28 Jan '13

28 Jan '13

#31256: ctags 5.8 creates improper tags file when compiled on OS X Lion ------------------------------+--------------------------------------------- Reporter: echosa@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: ctags lion | Port: ------------------------------+--------------------------------------------- So, as the summary says, ctags 5.8 creates improper tags files when compiled on OS X Lion using the Lion .dmg macports install. However, on Snow Leopard, compiled with the Snow Leopard version of macports, the created tags files are correct. The Lion-compiled ctags binary has the same issues on Snow Leopard, and the Snow Leopard-compiled binary works fine on Lion. (So right now, I'm just using a ctags binary compiled on Snow Leopard to get my work done on Lion.) Here's the command I'm running from my project's root directory: /opt/local/bin/ctags -e -f /path/to/TAGS -R --tag-relative=yes --totals=no --langmap=php:.php --exclude=.svn --PHP-kinds=+cf . I'm running this on a PHP project, obviously. Also, you'll notice the -e flag, making the TAGS file etags compatible. A proper etags reference should basically be of the format: <file>,<size of tag entry> <tag information> A TAGS file will contain many of these. Here's an example of what the ctags compiled with Snow Leopard is (properly) generating. ../../../Volumes/webdev/biosafety/trunk/application/Bootstrap.php,78 class Bootstrap extends Zend_Application_Bootstrap_BootstrapBootstrap33,719 (... extra lines here for the rest of this tag's information ...) The important thing here is the path at the beginning. The ctags compiled on Lion, however, doesn't always have this proper format. Sometimes the path will be /var/some/temp/path/somewhere or, more often, will be nonexistent, like this: ,78 class Bootstrap extends Zend_Application_Bootstrap_BootstrapBootstrap33,719 (... extra lines here for the rest of this tag's information ...) Notice there is no file reference before the first comma. Note that not all of the tags references are bad. Some are proper, a few have paths to /var/somewhere, but the rest have no file reference at all. FYI, the way I'm viewing these TAGS files is by loading them in emacs with visit-tags-table and switching to their buffer, which allows them to be seen in plain text. -- Ticket URL: <https://trac.macports.org/ticket/31256> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 7

[MacPorts] #35072: codeblocks fails with clang, works with llvm-gcc-4.2
by MacPorts 28 Jan '13

28 Jan '13

#35072: codeblocks fails with clang, works with llvm-gcc-4.2 -------------------------------------------+-------------------------------- Reporter: dhuffkc@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.1 Keywords: gcc clang codeblocks compiler | Port: codeblocks -------------------------------------------+-------------------------------- I had to install codeblocks with: sudo port install foo configure.compiler=llvm-gcc-4.2 due to a compile error using default clang compiler. I have XCode 4.3.3 and XCode 4.5 (preview) installed. Should this be fixed in the port or in the original project? Thanks, Don -- Ticket URL: <https://trac.macports.org/ticket/35072> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5