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

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 12 Mar '15

12 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by rjvbertin@…): Hmmm: https://guide.macports.org/#development.obsolete-portgroup {{{ Note It is important to specify replaced_by BEFORE the PortGroup line! }}} O:-) -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:27> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #46624: charm @ 1.8.0+ : Weird entries in charm's "Edit" menu
by MacPorts 12 Mar '15

12 Mar '15

#46624: charm @ 1.8.0+ : Weird entries in charm's "Edit" menu --------------------+-------------------------------- Reporter: mk@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: charm --------------------+-------------------------------- There are as many "Start Dictation..." menu items in the "Edit" menu as (sub)tasks are defined by the user. Is this a bug or a feature? Shall I attach a screenshot? -- Ticket URL: <https://trac.macports.org/ticket/46624> MacPorts <https://www.macports.org/> Ports system for OS X

1 13

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 12 Mar '15

12 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by mojca@…): Replying to [comment:25 ryandesign@…]: > Replying to [comment:23 mojca@…]: > > > I guess I should have stated that the OOT had to be set before including the port group (did you test that?). > > Portgroups should not be written to require that. No, I didn't test that, but I agree with Ryan here. -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:26> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

Re: [MacPorts] #33259: cmake portgroup: out of source build option, possibly by default
by MacPorts 12 Mar '15

12 Mar '15

#33259: cmake portgroup: out of source build option, possibly by default ---------------------------+-------------------------------- Reporter: ryandesign@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Resolution: | Keywords: Port: | ---------------------------+-------------------------------- Comment (by ryandesign@…): Replying to [comment:23 mojca@…]: > Setting something like > {{{ > configure.dir ${workpath}/build/i386 > }}} > would probably no longer resolve "`../${worksrcdir}`" properly. I believe that using `${worksrcpath}` is safer from that respect. Yes, you're right. Replying to [comment:24 rjvbertin@…]: > The role of `default` would be to set a default value that is applied when the variable hasn't been set already, no? That was how I saw its use in any case, Yes, that's correct. It sets a default, which ports can still override if needed. Notably, if you write `default someoption {somevalue}`, then it does not matter if the portfile sets someoption to another value before or after including the portgroup; it'll work either way (the portfile's value will be used and the default will not). Whereas if you wrote `someoption somevalue` in a portgroup, if a portfile set the value before including the portgroup, the portgroup's value would override the portfile's. > I guess I should have stated that the OOT had to be set before including the port group (did you test that?). Portgroups should not be written to require that. -- Ticket URL: <https://trac.macports.org/ticket/33259#comment:25> MacPorts <https://www.macports.org/> Ports system for OS X

1 0

[MacPorts] #47127: cmake portgroup: use ninja and/or speed up destroot install?
by MacPorts 12 Mar '15

12 Mar '15

#47127: cmake portgroup: use ninja and/or speed up destroot install? -------------------------+-------------------------------- Reporter: rjvbertin@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: -------------------------+-------------------------------- Since we're discussion the cmake portgroup (https://trac.macports.org/ticket/33259) there some other enhancements that might be investigated. CMake can use a Ninja generator that create ninja.build files instead of Makefiles. Ninja is much more efficient than make, and using it should speed up even one-time builds from what I understand. Alternatively, the Makefiles created with the default generator have an install target that speeds up the installation considerably for larger projects: `install/fast`. My understanding is that it skips the entire verification of the build phases the install depends on, verification which is redundant in the MacPorts workflow. So instead of first going through the whole build sequence to verify if everything is indeed really built and up-to-date, it will start the install immediately. This may not be a break-through speed-up for regular users who still have to wait for a full build to complete (but then it should be perfectly equal to them too whether a build is done OOT or not ;)). For port maintainers this is different: I for one find myself repeating the destroot step quite often in order to get it exactly right, and I'd appreciate not having to wait for a superfluous check that has output flowing over my screen for sometimes long minutes. -- Ticket URL: <https://trac.macports.org/ticket/47127> MacPorts <https://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #47121: "runhaskell" command fails during build
by MacPorts 12 Mar '15

12 Mar '15

#47121: "runhaskell" command fails during build --------------------------------+-------------------------------- Reporter: twilsonco@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: build,install,fail | Port: hs-language-c --------------------------------+-------------------------------- See attached log. During build, the command "runhaskell" exits with status 1. Also many warnings of missing directories during ghc check even though ghc (7.8.3_2) is installed and active. -- Ticket URL: <https://trac.macports.org/ticket/47121> MacPorts <https://www.macports.org/> Ports system for OS X

1 8

[MacPorts] #47123: tig @2.0.3 New version 2.3 available
by MacPorts 12 Mar '15

12 Mar '15

#47123: tig @2.0.3 New version 2.3 available ----------------------------+-------------------------------- Reporter: xuchunyang56@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Keywords: | Port: tig ----------------------------+-------------------------------- -- Ticket URL: <https://trac.macports.org/ticket/47123> MacPorts <https://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #47120: libfdk-aac update to @0.1.4
by MacPorts 12 Mar '15

12 Mar '15

#47120: libfdk-aac update to @0.1.4 ---------------------------------+-------------------------------- Reporter: mopihopi@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: maintainer haspatch | Port: libfdk-aac ---------------------------------+-------------------------------- Update libfdk-aac to version 0.1.4. The source patch that was previously applied is now integrated upstream, so the old patch file is no longer needed. This version requires rebuilding ffmpeg and ffmpeg-devel if the +nonfree variant was used. If desired I can make a patch to revbump those ports. -- Ticket URL: <https://trac.macports.org/ticket/47120> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #47091: openssl header, library versions inconsistent
by MacPorts 12 Mar '15

12 Mar '15

#47091: openssl header, library versions inconsistent ------------------------+-------------------------------- Reporter: urilabob@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: | Port: openssl ------------------------+-------------------------------- According to macports, all ports are currently up-to-date. Running the configure file for nxssh, I get: {{{ ./configure --includedir=/opt/local/include/openssl --with-ssl- dir=/opt/local/bin/openssl . . . checking OpenSSL header version... 9081af (OpenSSL 0.9.8za 5 Jun 2014) checking OpenSSL library version... 9081cf (OpenSSL 0.9.8zc 15 Oct 2014) checking whether OpenSSL's headers match the library... no configure: error: Your OpenSSL headers do not match your library. Check config.log for details. }}} The error message seems to be correct (the versions really do not match). I apologise if it's a mis-configuration or misunderstanding on my part. Could someone check, and if necessary update the headers in the port? I could run configure with --without-openssl-header-check, but without deeper knowledge than I have, that seems dangerous. -- Ticket URL: <https://trac.macports.org/ticket/47091> MacPorts <https://www.macports.org/> Ports system for OS X

1 3

[MacPorts] #47095: GQRX mdmg build fails
by MacPorts 12 Mar '15

12 Mar '15

#47095: GQRX mdmg build fails ------------------------+-------------------------------- Reporter: macports@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.3 Keywords: gqrx mdmg | Port: gqrx ------------------------+-------------------------------- I'm trying to build an mdmg package of GQRX to install on a different OSX box. Everything seems to build ok, but the issue is in constructing the final package. It seems a file is missing. The command I give is : {{{ sudo port mdmg gqrx +xquartz }}} It fails after a while with this in the error log: {{{ :info:pkg cp: /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gqrx/gqrx/work/gqrx-20150307-component.pkg: No such file or directory :info:pkg Command failed: cp -PR /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gqrx/gqrx/work/gqrx-20150307-component.pkg /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gqrx/gqrx/work/mpkg_packages :info:pkg Exit code: 1 :error:pkg org.macports.mpkg for port gqrx returned: command execution failed :debug:pkg Error code: CHILDSTATUS 66797 1 :debug:pkg Backtrace: command execution failed while executing "system "cp -PR ${pkgpath} ${packages_path}"" (procedure "package_mpkg" line 55) invoked from within "package_mpkg $subport $epoch $version $revision" (procedure "portmpkg::mpkg_main" line 9) invoked from within "portmpkg::mpkg_main org.macports.mpkg" ("eval" body line 1) invoked from within "eval $procedure $targetname" :info:pkg Warning: targets not executed for gqrx: org.macports.mdmg org.macports.mpkg :notice:pkg Please see the log file for port gqrx for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_science_gqrx/gqrx/main.log }}} The file gqrx-20150307-component.pkg isn't created anywhere. Copying gqrx-20150307.pkg to gqrx-20150307-component.pkg fails with an error relating to bundles, so I'm guessing it's not the right answer. I've cleaned GQRX prior to building, I've gone in and wiped out the build directory too, but I still eventually get the same error. Any ideas? David -- Ticket URL: <https://trac.macports.org/ticket/47095> MacPorts <https://www.macports.org/> Ports system for OS X

1 12