December 2015 - macports-tickets - lists.macosforge.org

[MacPorts] #47741: dbus @1.8.16: update to 1.8.18
by MacPorts 04 Feb '16

04 Feb '16

#47741: dbus @1.8.16: update to 1.8.18 ----------------------------+-------------------------------- Reporter: mschamschula@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: haspatch | Port: dbus ----------------------------+-------------------------------- dbus has ben updated to version 1.8.18: {{{ The “unicorn rifts” release. Security hardening: • On Unix platforms, change the default configuration for the session bus to only allow EXTERNAL authentication (secure kernel-mediated credentials-passing), as was already done for the system bus. This avoids falling back to DBUS_COOKIE_SHA1, which relies on strongly unpredictable pseudo-random numbers; under certain circumstances (/dev/urandom unreadable or malloc() returns NULL), dbus could fall back to using rand(), which does not have the desired unpredictability. The fallback to rand() has not been changed in this stable-branch since the necessary code changes for correct error-handling are rather intrusive. If you are using D-Bus over the (unencrypted!) tcp: or nonce-tcp: transport, in conjunction with DBUS_COOKIE_SHA1 and a shared home directory using NFS or similar, you will need to reconfigure the session bus to accept DBUS_COOKIE_SHA1 by commenting out the <auth> element. This configuration is not recommended. (fd.o #90414, Simon McVittie) Other fixes: • Add locking to DBusCounter's reference count and notify function (fd.o #89297, Adrian Szyndela) • Ensure that DBusTransport's reference count is protected by the corresponding DBusConnection's lock (fd.o #90312, Adrian Szyndela) • On Windows, listen on the same port for IPv4 and IPv6 (previously broken by an endianness mistake), and fix a failure to bind TCP sockets on approximately 1 attempt in 256 (fd.o #87999, Ralf Habacker) • Correctly release DBusServer mutex before early-return if we run out of memory while copying authentication mechanisms (fd.o #90021, Ralf Habacker) • Correctly initialize all fields of DBusTypeReader (fd.o #90021; Ralf Habacker, Simon McVittie) • Fix some missing \n in verbose (debug log) messages (fd.o #90004, Ralf Habacker) • Clean up some memory leaks in test code (fd.o #90021, Ralf Habacker) }}} -- Ticket URL: <https://trac.macports.org/ticket/47741> MacPorts <https://www.macports.org/> Ports system for OS X

1 14

[MacPorts] #48114: cccc-3.1.4 fails to build
by MacPorts 04 Feb '16

04 Feb '16

#48114: cccc-3.1.4 fails to build ----------------------------------------+-------------------------------- Reporter: schmieder.matthias@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.3.3 Keywords: yosemite,erase,Xcode 6.3.2 | Port: cccc ----------------------------------------+-------------------------------- Hi, just tried to install cccc an my MacBook Pro with Yosemite installed but it failed. The log output brings up the following error message {{{ ./cccc_tbl.cc:99:7: error: use of undeclared identifier 'erase' erase(value_iterator); ^ this-> }}} tracing the error down I found a missing scope in said function. '''cccc_tbl.cpp:92''' {{{ template<class T> bool CCCC_Table<T>::remove(T* old_item_ptr) { bool retval=false; typename map_t::iterator value_iterator=map_t::find(old_item_ptr->key()); if(value_iterator!=map_t::end()) { erase(value_iterator); retval=true; } return retval; } }}} changing '''cccc_tbl.cpp:99''' to {{{ map_t::erase(value_iterator); }}} fixed to problem. I added to log file as well as a patch file to this ticket. BR Matthias -- Ticket URL: <https://trac.macports.org/ticket/48114> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way).
by MacPorts 03 Feb '16

03 Feb '16

#50058: Executables installed by pip are not linked into macports path (and are not “select”able in any way). -----------------------+-------------------------------- Reporter: william@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: pip -----------------------+-------------------------------- There's some prior discussion of this problem at https://github.com/pypa/pip/issues/113 In short: when I install a python package using pip, its executables are installed into the appropriately versioned python tree, but those executables are not symlinked to somewhere which is on my PATH. In my example, I have installed macports' pip, and have `port select`ed `python35` and `pip35`. I then used pip to install the aws cli tools, `sudo pip install aws`. The `aws` binary is installed by `pip` at `/opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/aws`. So far so good. The problem is that that path is not on my `PATH` (of course … `port select` can't alter my path, only the individual symlinks in `/opt/local/bin` to the objects which are owned by that particular port for which `port select` was run). I would naively expect at first glance that issuing a `sudo port select pip pip35` would cause any binaries ''subsequently'' installed by that version of pip to be linked into my macports path `/opt/local/bin`. Of course that doean't happen with a standard `pip`. There follows the question of how to achieve this, since standard `pip` doesn't know it's supposed to do something about any binaries installed /after/ the `port select` operation, other than to install them in the appropriate place in the python heirarchy for the selected version of `pip`. This puts the question firmly in MacPorts' world, as per the latest comments on the github issue. Beporter's comment (third from last in that github issue at the time of writing) echos my feeling here … I would expect that something installed with the currently selected version of pip would end up on my path, though I completely understand why it doesn't at present. There's clearly some precedent for linking binaries to do with a specific python version directly in this way, since for example idle is linked thus on my installation, so the desired end result (I end up with a link `/opt/local/bin/aws -> /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/aws`) would be consistent with this: {{{ idle -> /opt/local/bin/idle3.5 idle2.7 -> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/bin/idle2.7 idle3 -> /opt/local/bin/idle3.5 idle3.4 -> /opt/local/Library/Frameworks/Python.framework/Versions/3.4/bin/idle3.4 idle3.5 -> /opt/local/Library/Frameworks/Python.framework/Versions/3.5/bin/idle3.5 }}} One way to achieve this (the “best” that I can think of so far) would be to modify MacPorts' `pip` so that when a given version of `pip` installs a binary it also links that into `/opt/local/bin`. This shouldn't be too hard to achieve but it's pretty invasive w.r.t. `pip`'s behaviour. It would, though, solve the oddness seen by me and others leading to `pip`-installed executables not appearing on my path. The `port select pip pipXX` command would also need on each invocation either to invoke `pip` or examine `pip`'s registry in order to unlink the executables which were installed by the version of `pip` being deselected, and link those owned by the version of `pip` being selected. Not rocket science, but a bit complicated. The alternative would seem to be to provide stub ports of some sort which use `pip` as the installation method under the hood but which handle the symlinking by providing `port select` machinery for each such port. That feels like a maintenance drag though (keeping up with `pip`'s repositories …) (Footnote: I can see that there's an existing port `py-awscli` which should provide what I need for now specifically in my example `aws` case, though it's pretty outdated, but that doesn't negate the general point about `pip` and paths in this bug …) -- Ticket URL: <https://trac.macports.org/ticket/50058> MacPorts <https://www.macports.org/> Ports system for OS X

1 6

[MacPorts] #50091: Build SDL_image-1.2.12 [El Capitan] fails; grep: /opt/local/lib/libXext.la: No such file
by MacPorts 03 Feb '16

03 Feb '16

#50091: Build SDL_image-1.2.12 [El Capitan] fails; grep: /opt/local/lib/libXext.la: No such file ----------------------------------+-------------------------------- Reporter: david@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: py-game libSDL_image | Port: py-game ----------------------------------+-------------------------------- build Executing org.macports.build (libsdl_image)fails. MACOSX_DEPLOYMENT_TARGET='10.11' info:build grep: /opt/local/lib/libXext.la: No such file -- Ticket URL: <https://trac.macports.org/ticket/50091> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #50017: build fails with gsl-related error
by MacPorts 03 Feb '16

03 Feb '16

#50017: build fails with gsl-related error ------------------------+-------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: orpie ------------------------+-------------------------------- Build fails at: {{{ NE -DHAVE_FENV -g -O2" -c mlgsl_sf.c :info:build mlgsl_sf.c:261:51: error: too many arguments to function call, expected 3, have 4 :info:build SF4(ellint_D, Double_val, Double_val, Double_val, GSL_MODE_val) :info:build ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ }}} -- Ticket URL: <https://trac.macports.org/ticket/50017> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #50018: macvim Error: Unable to upgrade port: 1
by MacPorts 02 Feb '16

02 Feb '16

#50018: macvim Error: Unable to upgrade port: 1 ---------------------------------+-------------------------------- Reporter: persramd@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: macvim build 10.7.5 | Port: macvim ---------------------------------+-------------------------------- Hi. I recently am having trouble upgrading macvim (as part of a upgrade outdated). After a selfupdate and clean macvim, I get the following message shown below. I've attached the logfile. {{{ The following build commands failed: CompileC build/MacVim.build/Release/MacVim.build/Objects- normal/i386/MMCoreTextView.o MMCoreTextView.m normal i386 objective-c com.apple.compilers.llvm.clang.1_0.compiler }}} -- Ticket URL: <https://trac.macports.org/ticket/50018> MacPorts <https://www.macports.org/> Ports system for OS X

1 8

[MacPorts] #46792: Paintbrush-2.0.1_0.darwin_14.x86_64.tbz2 -- build error
by MacPorts 01 Feb '16

01 Feb '16

#46792: Paintbrush-2.0.1_0.darwin_14.x86_64.tbz2 -- build error ----------------------+-------------------------------- Reporter: obiwan@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: Paintbrush ----------------------+-------------------------------- OSX 10.10.2, Xcode 6.1.1 ---> Building Paintbrush Error: org.macports.build for port Paintbrush returned: command execution failed A CompileC command failed. A concatenated "cd" command failed. Log file attached: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_graphics_Paintbrush/Paintbrush/main.log -- Ticket URL: <https://trac.macports.org/ticket/46792> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #49694: osc: unsatisfied dependency on vc command
by MacPorts 31 Jan '16

31 Jan '16

#49694: osc: unsatisfied dependency on vc command ----------------------+--------------------------- Reporter: raimue@… | Owner: raimue@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: osc obs-build ----------------------+--------------------------- As reported [https://github.com/openSUSE/osc/issues/177 upstream], osc in MacPorts fails to find vc as dependency. {{{ $ osc vc Error: vc ('/usr/lib/build/vc') command not found Install the build package from http://download.opensuse.org/repositories/openSUSE:/Tools/ }}} vc would be part of build. I am not convinced build itself would be useful on OS X. You definitely won't be able to use a chroot, maybe you could at least instrument a VM for building. However, on a quick glance it looks like all the preparation assume Linux anyway. For example, we cannot even mount a Linux filesystem. Maybe it would make more sense to have a obs-build-helpers or similar that only provides vc(1) and unrpm(1). -- Ticket URL: <https://trac.macports.org/ticket/49694> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #46239: qca and qca-ossl adaptations to qt4-mac +concurrent
by MacPorts 31 Jan '16

31 Jan '16

#46239: qca and qca-ossl adaptations to qt4-mac +concurrent -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: haspatch | Port: qca, qca-ossl -------------------------+-------------------------------- port:qca and port:qca-ossl use hard-coded paths to Qt4 install locations, instead of using the variables provided by the qt4 PortGroup. That breaks installation when qt4-mac is installed +concurrent. Patches are attached to this ticket. -- Ticket URL: <https://trac.macports.org/ticket/46239> MacPorts <https://www.macports.org/> Ports system for OS X

1 21

[MacPorts] #45915: qt5-creator-mac @3.2.2_0 fails to build
by MacPorts 31 Jan '16

31 Jan '16

#45915: qt5-creator-mac @3.2.2_0 fails to build -------------------------+-------------------------------- Reporter: starkhalo@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.2 Keywords: | Port: qt5-creator-mac -------------------------+-------------------------------- log file attached -- Ticket URL: <https://trac.macports.org/ticket/45915> MacPorts <https://www.macports.org/> Ports system for OS X

1 4