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

[MacPorts] #37407: py-enable version update to 4.2.0
by MacPorts 03 Jan '13

03 Jan '13

#37407: py-enable version update to 4.2.0 ---------------------------------+-------------------------------- Reporter: jjstickel@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: maintainer haspatch | Port: py-enable ---------------------------------+-------------------------------- Patch attached. I have tested this as a dependency to chaco. -- Ticket URL: <https://trac.macports.org/ticket/37407> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #37295: py-iniparse: update to 0.4
by MacPorts 03 Jan '13

03 Jan '13

#37295: py-iniparse: update to 0.4 --------------------------+------------------------- Reporter: ryandesign@… | Owner: afb@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: py-iniparse --------------------------+------------------------- py-iniparse could be updated to 0.4. -- Ticket URL: <https://trac.macports.org/ticket/37295> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #37391: php-gearman: update to 1.1.0
by MacPorts 03 Jan '13

03 Jan '13

#37391: php-gearman: update to 1.1.0 --------------------------+--------------------------------------- Reporter: ryandesign@… | Owner: rodney.rehm@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: php-gearman, php5-gearman --------------------------+--------------------------------------- Can we update php-gearman and php5-gearman? {{{ php-gearman seems to have been updated (port version: 1.0.2, new version: 1.1.0) php5-gearman seems to have been updated (port version: 1.0.2, new version: 1.1.0) }}} -- Ticket URL: <https://trac.macports.org/ticket/37391> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #37493: New portfile for logtalk-devel
by MacPorts 03 Jan '13

03 Jan '13

#37493: New portfile for logtalk-devel ------------------------+-------------------------------- Reporter: pmoura@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: maintainer | Port: logtalk-devel ------------------------+-------------------------------- New portfile for logtalk-devel. -- Ticket URL: <https://trac.macports.org/ticket/37493> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #37501: clang, llvm: don't use svn
by MacPorts 03 Jan '13

03 Jan '13

#37501: clang, llvm: don't use svn -------------------------+------------------------------------------------- Reporter: | Owner: jeremyhu@… ryandesign@… | Status: new Type: defect | Milestone: Priority: Normal | Version: 2.1.2 Component: ports | Port: clang-2.9, clang-3.0, clang-3.1, Keywords: | clang-3.2, llvm-2.9, llvm-3.0, llvm-3.1, | llvm-3.2 -------------------------+------------------------------------------------- The descriptions of llvm-2.9, llvm-3.0, llvm-3.1 and llvm-3.2 say they are the "svn trunk version" but they're not anymore; they're all stable versions now. The post-extract block of clang-2.9 runs: {{{ system "cd ${worksrcpath}/projects && svn co -r ${compiler_rt_rev} http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt" }}} The post-extract block of clang-3.0 runs: {{{ system "cd ${worksrcpath}/projects && svn co -r ${compiler_rt_rev} http://llvm.org/svn/llvm-project/compiler-rt/branches/release_30 compiler- rt" }}} The post-extract blocks of clang-3.0 and clang-3.1 run: {{{ system "cd ${worksrcpath}/projects && svn co -r ${libcxx_rev} http://llvm.org/svn/llvm-project/libcxx/trunk libcxx" }}} And the post-extract block of clang-3.2 runs: {{{ system "cd ${worksrcpath}/projects && svn co -r ${libcxx_rev} http://llvm.org/svn/llvm-project/libcxx/branches/release_32 libcxx" }}} Is it still necessary to check out additional code from svn now that these ports are stable versions? If so, an extract dependency on bin:svn:subversion should be declared, otherwise this will fail on Tiger when the user has not already installed the subversion port (because Tiger does not come with svn). The post-destroot blocks of clang-2.9, clang-3.0, clang-3.1 and clang-3.2 run: {{{ system "install_name_tool -change @executable_path/../lib/libLLVM-${llvm_version}svn.dylib ${sub_prefix}/lib/libLLVM-${llvm_version}svn.dylib ${destroot}${sub_prefix}/lib/libclang.dylib" }}} Should "svn" be in the name of this library since these are stable versions, not svn trunk versions? -- Ticket URL: <https://trac.macports.org/ticket/37501> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #37388: sonatype-nexus 2.2-01 new port submission
by MacPorts 03 Jan '13

03 Jan '13

#37388: sonatype-nexus 2.2-01 new port submission ---------------------------------+-------------------------------- Reporter: chris@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: haspatch maintainer | Port: sonatype-nexus ---------------------------------+-------------------------------- I've created a port for Sonatype Nexus, a commonly-used http Maven repository, allowing groups to share pre-built artifacts (usually Java) both amongst each other and (if desired) with the world at large. See http://www.sonatype.org/nexus for more information. The Portfile passes "port lint", and after a LOT of trial-and-error, installs cleanly w/o destroying config files when uninstalled. -- Ticket URL: <https://trac.macports.org/ticket/37388> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #37500: gst-plugins-math: checking for GST... no
by MacPorts 03 Jan '13

03 Jan '13

#37500: gst-plugins-math: checking for GST... no --------------------------+------------------------------ Reporter: ryandesign@… | Owner: aronnax@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: gst-plugins-math --------------------------+------------------------------ Building gst-plugins-math fails; for example here is the buildbot's report: {{{ checking for pkg-config... checking for pkg-config... /opt/local/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for GST... no configure: error: You need to install or upgrade the GStreamer development packages on your system. On debian-based systems these are libgstreamer0.10-dev and libgstreamer-plugins-base0.10-dev. on RPM-based systems gstreamer0.10-devel, libgstreamer0.10-devel or similar. The minimum version required is 0.10.16. Command failed: cd "/opt/local/var/macports/build /_opt_mports_dports_science_gst-plugins-math/gst-plugins-math/work/gst- plugins-math-0.1.0" && ./configure --prefix=/opt/local }}} That's from the [http://build.macports.org/builders/buildports- snowleopard-x86_64/builds/13445 snow leopard buildbot]; the [https://build.macports.org/builders/buildports-lion-x86_64/builds/6933 lion buildbot] and [https://build.macports.org/builders/buildports-mtln- x86_64/builds/760 mountain lion buildbot] said the same. -- Ticket URL: <https://trac.macports.org/ticket/37500> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #37380: tomcat-native @1.1.22: update to 1.1.24
by MacPorts 03 Jan '13

03 Jan '13

#37380: tomcat-native @1.1.22: update to 1.1.24 ---------------------------+-------------------------------- Reporter: edgtzolvera@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: haspatch | Port: tomcat-native ---------------------------+-------------------------------- Hi, Could you please update the tomcat-native port to 1.1.24 ? (patch file included) -- Ticket URL: <https://trac.macports.org/ticket/37380> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #22872: aiccu - daemondo automatically restarts it, the reason why it exists is because something is broken.....
by MacPorts 03 Jan '13

03 Jan '13

#22872: aiccu - daemondo automatically restarts it, the reason why it exists is because something is broken..... --------------------------------------------------------------------+------- Reporter: jeroen@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 1.8.1 Keywords: aiccu daemondo broken ddos repeat no-logging useraware | Port: aiccu --------------------------------------------------------------------+------- "daemondo launches the daemon directly, rather than indirectly via a script, and therefore it automatically knows how to monitor a daemon process and restart it if it dies." And thus, when aiccu exits because there is an unresolvable error case daemondo automatically restarts it, aiccu exists, daemondo restarts it, aiccu exits..... ad infinitum. Otherwise said: daemondo is not the proper tool for running AICCU in this way as it clearly avoids to check the exit code of AICCU, which exits because there is an error condition, which means it can't do anything else and that user intervention is needed. A couple of solutions that should be applied in this case and most likely in the cases of many other daemons which will abort on startup: - don't use it specifically for AICCU - rate limit the number of 'startups', if it fails X times, then don't start it any more. - If it fails after the first startup, tell the user, and don't start it again. - etc etc etc. From the 'README' file in the AICCU distribution: 8<------------------------------- WARNING: never run AICCU from DaemonTools or a similar automated 'restart' tool/script. When AICCU does not start, it has a reason not to start which it gives on either the stdout or in the (sys)log file. The TIC server *will* automatically disable accounts which are detected to run in this mode. Use 'verbose true' to see more information which is especially handy when starting fails. ------------------------------------->8 Oh and as clearly logging is not configured properly, nor the user ever cares to look at it they will never figure this problem out. Most likely the same goes for a lot of other daemons. In this case it is especially annoying as it will contact the TIC servers of SixXS, which will then have to rate limit the client and disable them, as per the above. Still, the client, which gets repeatedly restarted by daemondo will keep on trying to hammer those TIC servers. Thank you macport folks for another attempt at DDoSSing them. (attempt, as it fails due to the ratelimmitting and fortunately also the limited number of clients of which we had to tell and explain the users that they had a broken client....) But lets solve this properly, as macports is where the problem happens. Please resolve this. Additionally "startupitem.netchange" which is described as "Cause the daemon to be restarted when a change in network state is detected." is completely ridiculous in the case of AICCU as AICCU already KNOWS how to handle network changes, that is why there are "specialized" protocols called heartbeat and AYIYA which AICCU supports. Thus that option can also go to /dev/null for AICCU. -- Ticket URL: <http://trac.macports.org/ticket/22872> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #37503: py-dulwich: universal variant is not universal
by MacPorts 03 Jan '13

03 Jan '13

#37503: py-dulwich: universal variant is not universal --------------------------+-------------------------------- Reporter: ryandesign@… | Owner: mail_ben_schmidt@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: py-dulwich --------------------------+-------------------------------- {{{ $ port -v installed py27-dulwich The following ports are currently installed: py27-dulwich @0.8.7_0+universal (active) platform='darwin 12' archs='i386 x86_64' $ port -q contents py27-dulwich | grep \\.so$ | xargs lipo -info Non-fat file: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/dulwich/_diff_tree.so is architecture: x86_64 Non-fat file: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/dulwich/_objects.so is architecture: x86_64 Non-fat file: /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7 /site-packages/dulwich/_pack.so is architecture: x86_64 }}} I'm attaching the main.log which shows that `-arch` flags are not being used. -- Ticket URL: <https://trac.macports.org/ticket/37503> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 0