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

[MacPorts] #24529: libao 1.0.0_0 errors in cmus 2.3.1_1
by MacPorts 18 May '11

18 May '11

#24529: libao 1.0.0_0 errors in cmus 2.3.1_1 ------------------------------------+--------------------------------------- Reporter: Ink_Blot2001@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.2 Keywords: | Port: libao, cmus ------------------------------------+--------------------------------------- I'm not sure which port is at fault, but the issue occurs when I attempted to play a FLAC file in cmus 2.3.1_1+flac with libao 1.0.0_0+darwin. This occurred on a PPC machine running 10.4.11 with all ports up to date. The following is the error received in the terminal: {{{ ao_macosx ERROR: Unrecognized channel name " " in channel matrix " " ao_macosx ERROR: Input channel matrix invalid; ignoring ao_macosx ERROR: Could not configure output endianness ao_macosx ERROR: Failed to start audio output => -10867 Error: opening audio device: Operation not supported by device }}} -- Ticket URL: <http://trac.macports.org/ticket/24529> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #29485: gcc44 failed to complete when doing "sudo port upgrade outdated"
by MacPorts 18 May '11

18 May '11

#29485: gcc44 failed to complete when doing "sudo port upgrade outdated" ---------------------------------+------------------------------------------ Reporter: dgh@… | Owner: macports-tickets@… Type: submission | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: ---------------------------------+------------------------------------------ OSX 10.6.5. Performed selfupdate and the upgrade outdated commands. The gcc44 portfile has Revision 78606. After letting it run overnight, I did a quick defect search and found defect #24541. This closed ticket said the gcc configuration process was confused by a symlink in /usr/include. I looked in my /usr/include directory and found many symlinks associated with tcl/tk (attached is list of symlink files). After moving these files to a subdirectory, gcc44 promptly completed with no errors. I didnt save the log file from the build that took forever, but Im sure I could recreate it. I dont think this is a defect in the gcc44 portfile, but I do think this could be a defect in the gcc configuration process, following up on irrelevant symlinks. The symlinks were made months ago. I dont remember what install I was performing that created the symlinks. At the time I was interest in various python modules so I could have installed something from the macpython site that made these links. This anomaly deserves higher visibility. Maybe the resolution is warning messages from the portfile, maybe its a bugreport to the gcc owners, maybe its just a hint in the documentation that this symlinks will confuse some ports. -- Ticket URL: <https://trac.macports.org/ticket/29485> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #22530: [Ruby] Specify arbitrary gem sources in a Portfile
by MacPorts 18 May '11

18 May '11

#22530: [Ruby] Specify arbitrary gem sources in a Portfile ---------------------------------+------------------------------------------ Reporter: dreamcat4@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: base | Version: 1.8.1 Keywords: | Port: ---------------------------------+------------------------------------------ Hi, This is related to ticket #22406. I believe we need to let people specify arbitrary gem sources in their portfiles. It may be better in the long run to provide this. Then for the most common sources provide a wrapper. Example: http://gems.opscode.com -- Ticket URL: <http://trac.macports.org/ticket/22530> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #19049: port activation fails with "Error: port activate failed: Not a directory"
by MacPorts 18 May '11

18 May '11

#19049: port activation fails with "Error: port activate failed: Not a directory" --------------------------------------+------------------------------------- Reporter: julio.lopez@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: base | Version: 1.7.0 Keywords: | Port: --------------------------------------+------------------------------------- The way symbolic links to directories are handled in the registry's file map causes failed installation for various ports. Examples are reported in #16068, #18878, #18380, #16599, #17404 among others. Besides the failed installation, the registry and the file map are left in an inconsistent state. The packages are said to be installed, however their contents are not added to the file map and not all the files are appropriately installed. There are workarounds that the port maintainers have put in place for some of the problems. Since this issue is causing bugs in many packages, it'd be desirable if this is handled at the port base level, perhaps in the registry or the file map. Also, it'd be a good idea to include in the documentation a clear explanation and a recommendation for the maintainers about the rule used to handle symbolic links to directories. The specific problem is that a package A may create a symlink to a directory where some of it's files are installed. When a different package B tries to add a file in a directory where the aforementioned symlink is in the path, then the installation fails with: {{{ DEBUG: Not a directory while executing "filemap set file_map $file $port" (procedure "receipt_flat::register_file" line 11) invoked from within "${macports::registry.format}::register_file $file $port" (procedure "registry::register_file" line 3) invoked from within "registry::register_file $file $name" (procedure "portimage::activate" line 65) invoked from within "portimage::activate $portname [composite_version $portversion [array get variations]] [array get options]" Error: port activate failed: Not a directory }}} For example, in the situation reported in #16068, python25 (e.g., @2.5.4_0) creates the following symbolic link: {{{ $ pwd /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib $ ls -l total 8 lrwxr-xr-x 1 root admin 24 Mar 13 11:41 python2.5 -> /opt/local/lib/python2.5 }}} The py25-pyqt4 port tries to add a file under: {{{ /opt/local/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5 /site-packages/PyQt4/__init__.py }}} However, this fails because the link created by python25 is now in the file map and it does not correspond to a directory. The following excerpt from ${prefix}/var/macports/sources/rsync.macports.org/release/base/src/pextlib1.0/filemap.c shows where the test is performed and the taken action. The Set function (in filemap.c) is in the code path for the following TCL statement: {{{ filemap set filemapVarName path value }}} {{{ int Set(SNode** ioRoot, const char* inPath, const char* inValue) { int theResult = 0; ... if (theCurrentChar == '/') { if (theSubnode->fNodeType != kNode) { theResult = ENOTDIR; break; } ... }}} I hope this helps. Also, it'd be desirable to have command line tools (e.g., portadmin <command>) to test the integrity of the file map and the registry and be able to rebuild or fix an inconsistent file map. -- Ticket URL: <http://trac.macports.org/ticket/19049> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #19908: dry-run option (-y) not honored everywhere
by MacPorts 18 May '11

18 May '11

#19908: dry-run option (-y) not honored everywhere ------------------------------+--------------------------------------------- Reporter: blb@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: MacPorts Future Component: base | Version: 1.8.0 Keywords: | Port: ------------------------------+--------------------------------------------- At least uninstall appears to not honor the dry-run option (-y): {{{ $ port -dy uninstall gimp2 ---> Deactivating gimp2 @2.6.6_1+darwin_9+x11 DEBUG: deactivating link: /mp/share/man/man5/gimprc.5.gz DEBUG: error deleting "/mp/share/man/man5/gimprc.5.gz": permission denied while executing "_deactivate_contents $name $imagefiles" (procedure "portimage::deactivate" line 52) invoked from within "portimage::deactivate $portname ${version}_${revision}${variants} $optionslist" (procedure "portuninstall::uninstall" line 88) invoked from within "portuninstall::uninstall $portname [composite_version $portversion [array get variations]] [array get options]" Error: port uninstall failed: error deleting "/mp/share/man/man5/gimprc.5.gz": permission denied }}} (It failed since I didn't use sudo, as I didn't want it actually uninstalling). Initially ran into this trying it with --follow-dependents to see if that would show a recursive dependent list. -- Ticket URL: <http://trac.macports.org/ticket/19908> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #29495: DBus doesn't launch, Digikam and other apps hang
by MacPorts 18 May '11

18 May '11

#29495: DBus doesn't launch, Digikam and other apps hang --------------------------------------------+------------------------------- Reporter: macports.mexon@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: --------------------------------------------+------------------------------- During installation, I noticed two messages: # launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist # 'sudo chown -R $USER ~/Library/Preferences/KDE' I did both of these. launchctl fails like this: $ launchctl load /Library/LaunchAgents/org.freedesktop.dbus-session.plist nothing found to load This is apparently a symptom of having "<key>Disabled</key>" in org.freedesktop.dbus-session.plist. To fix that, I found a "-w" flag from somewhere on the internet: launchctl load -w /Library/LaunchAgents/org.freedesktop.dbus-session.plist That doesn't do anything, and there's no process with "dbus" in the name in the process table. If I then run digikam or kanagram or any other KDE application, the program just hangs. -- Ticket URL: <https://trac.macports.org/ticket/29495> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #28770: Create py27-nltk
by MacPorts 18 May '11

18 May '11

#28770: Create py27-nltk --------------------------------+------------------------------------------- Reporter: pierre@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: python, nltk | Port: py26-nltk --------------------------------+------------------------------------------- At the moment nltk is only available through those ports: py-nltk, py25-nltk, py26-nltk Since the all its dependencies exist in py27 version, it would be great to create py27-nltk. Library Dependencies: py27-numpy, py27-matplotlib, py27-yaml Thanks -- Ticket URL: <https://trac.macports.org/ticket/28770> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #29494: Need xmlsec 1.2.18
by MacPorts 18 May '11

18 May '11

#29494: Need xmlsec 1.2.18 --------------------------------+------------------------------------------- Reporter: nsowatsk@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: xmlsec 1.2.18 | Port: xmlsec --------------------------------+------------------------------------------- {{{ Hi The latest ports version of xmlsec is 1.2.16. It has this bug: https://bugzilla.gnome.org/show_bug.cgi?id=631258 The latest version of xmlsec is 1.2.18. Could we have that version made available please? Many thanks Nathan }}} -- Ticket URL: <https://trac.macports.org/ticket/29494> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #24625: flac-1.2.1 - fails to build for i386 arch on Snow Leopard
by MacPorts 18 May '11

18 May '11

#24625: flac-1.2.1 - fails to build for i386 arch on Snow Leopard ---------------------------------+------------------------------------------ Reporter: nzaidenberg@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.2 Keywords: | Port: ---------------------------------+------------------------------------------ flac 1.2.1 fails to build for build arch i386 (compiled on x86_64) had to change makefiles manually -- Ticket URL: <http://trac.macports.org/ticket/24625> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #29085: NLTK Ports upgrade to 2.0.1rc1
by MacPorts 18 May '11

18 May '11

#29085: NLTK Ports upgrade to 2.0.1rc1 -----------------------------------+---------------------------------------- Reporter: stevenbird1@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: haspatch maintainer | Port: py-nltk py25-nltk py26-nltk -----------------------------------+---------------------------------------- Updated port for NLTK (http://nltk.org/) -- Ticket URL: <https://trac.macports.org/ticket/29085> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2