June 2016 - macports-tickets - lists.macosforge.org

[MacPorts] #51619: qt5.depends_component procedure
by MacPorts 14 Jun '16

14 Jun '16

#51619: qt5.depends_component procedure -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: qt5, qt5-kde -------------------------+-------------------------------- This is a fork of ticket #50966 I would like to request the introduction of a procedure to facilitate declaring dependencies on specific Qt5 components in the Qt5 PortGroup, which would become almost a necessity once my `qt5-kde` port is committed. Such a procedure would make it possible for any port to depend on qt5 or qt5-kde (or qt5-devel or qt5-kde-devel) without having to figure out individually how to set up the path: style dependencies. This procedure would remain in the wrapper/header Qt5 PortGroup once `port:qt5-kde` is committed, and come after the actual Qt5 PortGroup payload has been included. Examples: {{{ qt5.depends_component qtbase qtsvg qt3d }}} would pull in the qtbase, qtsvg and qt3d subports from `port:qt5` (or `port:qt5-kde` if that's the one installed). or simply {{{ qt5.depends_component qt5 qtwebengine }}} would indicate a dependency on `port:qt5` and `port:qt5-qtwebengine` (or `port:qt5-kde` and `port:qt5-kde-qtwebengine`). Being able to depend on the main port as a virtual component is required for ports where the dependency information from the Qt5 PortGroup is overridden, like it is in `port:py-pyqt5`. The procedure also provides support for an *optional* table of dependency patterns that can be declared in the specific PortGroup (cf. qt5_component_lib in qt5-kde-1.0.tcl in #50966); this is the basis for depending transparently on the subports of either `qt5` or `qt5-devel`. I've been testing this procedure quite extensively with the new `py-pyqt5` port. NB: my KF5 PortGroup provides a comparable `kf5.depends_frameworks function which serves a comparable role (and makes dependency declarations quite a bit more readable). -- Ticket URL: <https://trac.macports.org/ticket/51619> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #50966: Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family
by MacPorts 14 Jun '16

14 Jun '16

#50966: Qt5 PortGroup files; preparing for port:qt5-kde and the KF5 port family -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: qt5, qt5-kde -------------------------+-------------------------------- I'm submitting my proposed changes to the Qt5 PortGroup inn another attempt to gain some attention for and traction on the subject of the KF5 port family which have a strong (*) dependency on a Qt5 version with dedicated patches. This family and the corresponding `port:qt5-kde` are currently in extended testing and ought to be committed in a hopefully not-too-far future. The changes are relatively straightforward and aim to maximise the extent to which users will be able to install either of the Qt5 ports as an alternative, much like this is currently possible with `-devel` ports. - A Qt5 KDE PortGroup (qt5-kde-1.0.tcl) is introduced that provides the configuration details for `port:qt5-kde`. It also defines and sets the variant `+qt5kde`. - The current qt5-1.0.tcl single-file PortGroup is renamed to qt5-mac-1.0.tcl (and can be renamed to anything else deemed more appropriate) - The Qt5 1.0 PortGroup (qt5-1.0.tcl) is replaced with a "header PortGroup", i.e. it includes one of the 2 PortGroup alternatives. The Qt5 KDE PortGroup is included if and only if 1) a port includes it explicitly; `PortGroup qt5-kde 1.0` (making it incompatible with a set-up where `port:qt5` is installed and active). 2) `port:qt5-kde` has been installed by the user. This is the only scenario in which a regular port will use qt5-kde "by default". 3) No Qt5 port has been installed when the user installs a Qt5-dependent that indicates a preference to qt5-kde, i.e.: {{{ set qt5.prefer_kde yes PortGroup qt5 1.0 }}} In all other cases, the current Qt5 PortGroup and `port:qt5` are used. The `+qt5kde` variant ensures that binary builds of Qt5-dependent port can be distinguished as a function of what Qt5 port they are built against. Ports built against `port:qt5` appear to work fine against `port:qt5-kde`, but the reverse is less likely to be true, esp. for KF5 ports that were built against `port:qt5-kde`. It would be possible to declare the `qt5kde` variant in the "header" PortGroup, and use it instead of or in addition to `qt5.prefer_kde`. I have no objection against that but think that it may give a bit too much control to users which either doesn't make much sense (telling a port to use "the other Qt5 port", = the one not installed) or is redundant or even counter productive. The Qt5 "header" PortGroup also introduces a procedure to facilitate declaring dependencies on specific Qt5 components, e.g. {{{ qt5.depends_component qtbase qtsvg qt3d }}} this expands to the appropriate subports dependencies (i.e. on `qt5-qtbase, qt5-qtsvg, qt5-qt3d` or `qt5-kde-qtbase, qt5-kde-qtsvg, qt5 -kde-qt3d`). The procedure has initial support for an optional table of dependency patterns that can be declared in the specific PortGroup (cf. `qt5_component_lib` in qt5-kde-1.0.tcl ; there is an expansion issue with the use of variables in the elements of that table that I haven't been able to figure out yet). Note that `port:qt5-kde` only provides a true subport for QtWebEngine; the remaining component subports are stubs that depend on `port:qt5-kde`. *) The KF5 dependency on `port:qt5-kde` is strong but obligatory only in the sense that using a "stock" Qt5 breaks a lot of functionality and would require significant patching that just doesn't make sense for something like MacPorts of almost all KF5 ports. -- Ticket URL: <https://trac.macports.org/ticket/50966> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #51604: Update request for port whizard v2.2.7 -> v2.2.8
by MacPorts 14 Jun '16

14 Jun '16

#51604: Update request for port whizard v2.2.7 -> v2.2.8 ------------------------------+-------------------------------- Reporter: juergen.reuter@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: update | Port: wizard ------------------------------+-------------------------------- Please upgrade the port whizard from v2.2.7 to v2.2.8. Portfile patch is attached. -- Ticket URL: <https://trac.macports.org/ticket/51604> MacPorts <https://www.macports.org/> Ports system for OS X

1 4

[MacPorts] #51601: attempted install of xorg-libXdmcp fails to find destroot
by MacPorts 14 Jun '16

14 Jun '16

#51601: attempted install of xorg-libXdmcp fails to find destroot -----------------------+-------------------------------- Reporter: martzrl@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: -----------------------+-------------------------------- bash-3.2$ sudo port install xorg-libXdmcp ---> Installing xorg-libXdmcp @1.1.2_0 Error: org.macports.install for port xorg-libXdmcp returned: no destroot found at: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports .org_release_tarballs_ports_x11_xorg-libXdmcp/xorg-libXdmcp/work/destroot while executing "create_archive $location $portarchivetype" (procedure "portinstall::install_main" line 22) invoked from within "portinstall::install_main org.macports.install" ("eval" body line 1) invoked from within "eval $procedure $targetname" :info:install Warning: targets not executed for xorg-libXdmcp: org.macports.activate org.macports.install :notice:install Please see the log file for port xorg-libXdmcp for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports .org_release_tarballs_ports_x11_xorg-libXdmcp/xorg-libXdmcp/main.log -- Ticket URL: <https://trac.macports.org/ticket/51601> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #51605: Hugin App bundles not finding binaries
by MacPorts 14 Jun '16

14 Jun '16

#51605: Hugin App bundles not finding binaries ---------------------------+-------------------------------- Reporter: rpspringuel@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: hugin-app ---------------------------+-------------------------------- On Mac OS 10.10.5, hugin-app creates app bundles in the MacPorts folder. The command-line tools, naturally, are in `/opt/local/bin`. However, when launching processes using the GUI apps, the program looks for the command line tools in the same location as the GUI apps by default. Now, while I've been able to correct this via the preferences inside hugin for enblend and enfuse, I can't seem to correct this for nona and exiftool. I've been able to bypass the problem for nona by creating a symlink from where the GUI is looking (`/Applications/MacPorts/PTBatchGUI.app/Contents/MacOS/nona`) to where nona actually is (`/opt/local/bin/nona`), but said solution is likely to be fragile and break when MacPorts updates hugin in the future. Something similar seems to be occuring with exiftool, which is installed as /opt/local/bin/exiftool-5.22 (i.e. the PERL versionnumber is appended). However, in this case the log file isn't descriptive enough for me to tell where it's looking for exiftool so I don't know where to put the symlink to get around this (`/usr/local/bin` doesn't work). When I reported this([https://answers.launchpad.net/hugin/+question/294894]) to the hugin developers, I got the following response: > In our CMake build system there are 2 possibilities to build on Mac: > 1. A *nix way: Here the tools are installed and search in a fixed path, which is given during building. (For the external tools, like enblend, enfuse, exiftool, also the PATH environment variable is taken into account to search for the program.) > 2. Building an OS/X bundle. In this case all the tools are bundled into a bundled and searched in the bundled. > > Here it sounds there is something mixed up. I don't know what the > MacPort maintainer do to build it (which patches are applied and with > which options it is build). So please report your problems to the > MacPort maintainers. -- Ticket URL: <https://trac.macports.org/ticket/51605> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #51616: openscad @2015.03-3 build error
by MacPorts 13 Jun '16

13 Jun '16

#51616: openscad @2015.03-3 build error --------------------+------------------------ Reporter: mf2k@… | Owner: dstrubbe@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: openscad --------------------+------------------------ El Capitan. 10.11.5. Xcode 7.3.1. I think this is the error: {{{ :info:build In file included from src/scadlexer.cpp:3: :info:build src/scadlexer.h:5:10: fatal error: 'Qsci/qsciglobal.h' file not found :info:build #include <Qsci/qsciglobal.h> :info:build ^ :info:build 1 error generated. }}} -- Ticket URL: <https://trac.macports.org/ticket/51616> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #51612: mkoctfile linker error - configure.ac produces wrong MKOCTFILE_DL_LDFLAGS (PATCH)
by MacPorts 13 Jun '16

13 Jun '16

#51612: mkoctfile linker error - configure.ac produces wrong MKOCTFILE_DL_LDFLAGS (PATCH) ----------------------------------+-------------------------------- Reporter: friedrich.beckmann@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: octave-devel ----------------------------------+-------------------------------- Hi, i added the problem description upstream: https://savannah.gnu.org/bugs/?48215 The build setup is wrong and mkoctfile does not work. Please find attached a patchfile and a patch for the portfile to use this. Friedrich -- Ticket URL: <https://trac.macports.org/ticket/51612> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #51607: github-1.0.tcl Expects directory to be unzipped & fails if directory not present
by MacPorts 13 Jun '16

13 Jun '16

#51607: github-1.0.tcl Expects directory to be unzipped & fails if directory not present ----------------------------+-------------------------------- Reporter: sonofiron@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: github-1.0.tcl | Port: ----------------------------+-------------------------------- Line 174-177 of github-1.0.tcl performs a glob search expecting a non- standardized format of `author-project-*`. Many of the Portfiles i've generated using this PortGroup fail because the extracted contents are simple binaries, with no author or suffix attached. {{{ if {[file exists [glob ${workpath}/${github.author}-${github.project}-*]] && \ [file isdirectory [glob ${workpath}/${github.author}-${github.project}-*]]} { move [glob ${workpath}/${github.author}-${github.project}-*] ${workpath}/${distname} } }}} Logic must be added to be more inclusive of ${workpath}/${github.project} -- Ticket URL: <https://trac.macports.org/ticket/51607> MacPorts <https://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #51341: ldas-tools@2.4.2_1 + build error: command execution failed
by MacPorts 13 Jun '16

13 Jun '16

#51341: ldas-tools(a)2.4.2_1 + build error: command execution failed ------------------------+-------------------------------- Reporter: yfwang42@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: ldas-tools ------------------------+-------------------------------- I am trying to install LAL suite ( https://wiki.ligo.org/viewauth/DASWG/MacPorts) on OS X EI Captain (version: 10.11.4). However, I couldn't install the "ldas-tools" in this suite. I ran "sudo port clean ldas-tools" and "sudo port install ldas-tools". Then I received the following: {{{ ---> Computing dependencies for ldas-tools ---> Fetching archive for ldas-tools ---> Attempting to fetch ldas- tools-2.4.2_1+python27.darwin_15.x86_64.tbz2 from http://jog.id.packages.macports.org/macports/packages/ldas-tools ---> Attempting to fetch ldas- tools-2.4.2_1+python27.darwin_15.x86_64.tbz2 from http://nou.nc.packages.macports.org/pub/macports/packages.macports.org /ldas-tools ---> Attempting to fetch ldas- tools-2.4.2_1+python27.darwin_15.x86_64.tbz2 from https://packages.macports.org/ldas-tools ---> Fetching distfiles for ldas-tools ---> Verifying checksums for ldas-tools ---> Extracting ldas-tools ---> Applying patches to ldas-tools ---> Configuring ldas-tools ---> Building ldas-tools Error: org.macports.build for port ldas-tools returned: command execution failed Please see the log file for port ldas-tools for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports .org_release_tarballs_ports_science_ldas-tools/ldas-tools/main.log To report a bug, follow the instructions in the guide: http://guide.macports.org/#project.tickets Error: Processing of port ldas-tools failed }}} In the main.log, I found the following error: {{{ :info:build In file included from FrDetector3.cc:1: :info:build ./FrDetector.cc:272:1: error: all paths through this function will call itself [-Werror,-Winfinite -recursion] }}} By the way, my Xcode version is 7.3.1 -- Ticket URL: <https://trac.macports.org/ticket/51341> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #51608: org.macports.build for port ldas-tools returned: command execution failed
by MacPorts 13 Jun '16

13 Jun '16

#51608: org.macports.build for port ldas-tools returned: command execution failed ----------------------------+-------------------------------- Reporter: joseph.mills@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Keywords: | Port: ----------------------------+-------------------------------- I am trying to install lscsoft-deps on OS X El Capitan from https://wiki.ligo.org/viewauth/DASWG/MacPorts but ldas tools keeps failing to install. I have cleaned, updated and upgraded. Output below, and log file attached. http://sea.us.packages.macports.org/macports/packages/ldas-tools ---> Fetching distfiles for ldas-tools ---> Verifying checksums for ldas-tools ---> Extracting ldas-tools ---> Applying patches to ldas-tools ---> Configuring ldas-tools ---> Building ldas-tools Error: org.macports.build for port ldas-tools returned: command execution failed Please see the log file for port ldas-tools for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports .org_release_ports_science_ldas-tools/ldas-tools/main.log Error: Problem while installing ldas-tools There is a previous ticket similar to mine mentioning mentioning a patch, how do I use this? -- Ticket URL: <https://trac.macports.org/ticket/51608> MacPorts <https://www.macports.org/> Ports system for OS X

1 2