April 2014 - macports-tickets - lists.macosforge.org

[MacPorts] #40943: rpm54: please update to 5.4.14
by MacPorts 12 Sep '14

12 Sep '14

#40943: rpm54: please update to 5.4.14 --------------------+-------------------------------- Reporter: jpo@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Keywords: | Port: rpm54 --------------------+-------------------------------- Please update rpm54 to the latest upstream version. * RPM Files Repository[[BR]] http://rpm5.org/files/rpm/rpm-5.4/ {{{ rpm-5.4.9-0.20120508.src.rpm 08-May-2012 13:51 7.3M rpm-5.4.10-0.20120706.src.rpm 06-Jul-2012 20:05 7.5M rpm-5.4.11-0.20130708.src.rpm 08-Jul-2013 20:22 12M rpm-5.4.12-0.20130725.src.rpm 25-Jul-2013 23:34 13M rpm-5.4.13-0.20130819.src.rpm 19-Aug-2013 19:44 13M rpm-5.4.14-0.20131024.src.rpm 24-Oct-2013 17:24 13M }}} -- Ticket URL: <https://trac.macports.org/ticket/40943> MacPorts <http://www.macports.org/> Ports system for OS X

1 2

[MacPorts] #37320: tbb: add universal variant
by MacPorts 11 Sep '14

11 Sep '14

#37320: tbb: add universal variant --------------------------+--------------------- Reporter: ryandesign@… | Owner: mnick@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: tbb --------------------------+--------------------- The tbb port should have a universal variant if possible. Due to the build system's insistence on nonstandard variables to indicate desired architecture, I wouldn't even attempt this without using the muniversal portgroup. This was proposed before and a patch provided as part of #25208 but was ignored or forgotten. -- Ticket URL: <https://trac.macports.org/ticket/37320> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 10

[MacPorts] #22506: new port: go google's new programming language
by MacPorts 11 Sep '14

11 Sep '14

#22506: new port: go google's new programming language ---------------------------------+------------------------------------------ Reporter: nefar@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.1 Keywords: | Port: go-devel ---------------------------------+------------------------------------------ Maybe it should be called go-lang instead of go, but here it is. -- Ticket URL: <http://trac.macports.org/ticket/22506> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #32501: erlang @R14B04 +odbc Patch for bug in Erlang ODBC configure scripts
by MacPorts 11 Sep '14

11 Sep '14

#32501: erlang @R14B04 +odbc Patch for bug in Erlang ODBC configure scripts -------------------------------------+-------------------------------------- Reporter: chad@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: | Port: erlang -------------------------------------+-------------------------------------- Following is an email exchange which clearly describes the issue this patch is intended to fix: Found the problem. It's a bug in the configure scripts located in lib/odbc of the Erlang source code, which hard code '-liodbc' when $host_os is darwin -- this prevents anyone from being able to properly link against a unixODBC install on OS X, which needs '-lodbc' instead. In my case, via MacPorts, this apparently meant it was using the MacPorts unixODBC headers, but linking against the default OS X iODBC lib, which I'm guessing is what led to the weird behavior I was seeing. I've created a patch for the MacPorts version of Erlang, but I'm pretty autoconf clueless, so all it does is hard code '-lodbc' in place of '-liodbc', which is clearly not the right upstream solution. ;) If there's anything else I can do to help fix this bug, please let me know. Thanks, Chad On Dec 9, 2011, at 6:05 AM, Ingela Andin wrote: Hi! Sound like a problem in the odbc-driver (if I remember correctly iodbc is the name of the most common driver on MAC) sql_wvarchar is defined to be Unicode encoded as UTF16 little endian. Regards Ingela Erlang/OTP team - Ericsson AB 2011/12/1, Chad Phillips -- Apartment Lines <chad(a)apartmentlines.com>: According to http://www.erlang.org/doc/apps/odbc/databases.html#type, the SQL_WVARCHAR ODBC data type should be translated by Erlang's ODBC driver to "Unicode binary encoded as UTF16 little endian." This works as expected on Linux, but I'm having issues on OS X, where it appears it's getting translated to UTF32 little endian, instead of UTF16 little endian. I'm using Erlang R14B04 on both machines, with the exact same database table, does anybody have an idea why this might be occurring, and how to remedy it? Additional info below for those interested. Thanks! Chad {{{ TABLE ON BOTH ARCHITECTURES: CREATE TABLE `foo` ( `bar` varchar(255) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8; LINUX ERLANG SESSION: (alaem@scratch)1> odbc:start(). ok (alaem@scratch)2> {ok, Ref} = odbc:connect("DSN=testing;Option=3", []). {ok,<0.90.0>} (alaem@scratch)3> odbc:describe_table(Ref, "foo"). {ok,[{"bar",{sql_wvarchar,255}}]} (alaem@scratch)4> odbc:select_count(Ref, "SELECT * FROM foo"). {ok,1} (alaem@scratch)5> {selected, Columns, [{Bar}]} = odbc:next(Ref). {selected,["bar"],[{<<98,0,97,0,122,0>>}]} (alaem@scratch)6> unicode:characters_to_list(Bar, {utf16, little}). "baz" (alaem@scratch)7> unicode:characters_to_list(Bar, {utf32, little}). {error,[],<<98,0,97,0,122,0>>} OS X ERLANG SESSION: (alaem@colossus)1> odbc:start(). ok (alaem@colossus)2> {ok, Ref} = odbc:connect("DSN=testing;Option=3", []). {ok,<0.90.0>} (alaem@colossus)3> odbc:describe_table(Ref, "foo"). {ok,[{"bar",{sql_wvarchar,255}}]} (alaem@colossus)4> odbc:select_count(Ref, "SELECT * FROM foo"). {ok,1} (alaem@colossus)5> {selected, Columns, [{Bar}]} = odbc:next(Ref). {selected,["bar"],[{<<98,0,0,0,97,0,0,0,122,0,0,0>>}]} (alaem@colossus)6> unicode:characters_to_list(Bar, {utf16, little}). [98,0,97,0,122,0] (alaem@colossus)7> unicode:characters_to_list(Bar, {utf32, little}). "baz" }}} -- Ticket URL: <https://trac.macports.org/ticket/32501> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 8

[MacPorts] #39704: EMBOSS: update to 6.5.7
by MacPorts 11 Sep '14

11 Sep '14

#39704: EMBOSS: update to 6.5.7 --------------------------+------------------------- Reporter: ryandesign@… | Owner: mike.thon@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: EMBOSS --------------------------+------------------------- {{{ $ port livecheck EMBOSS EMBOSS seems to have been updated (port version: 6.3.1, new version: 6.5.7) }}} -- Ticket URL: <https://trac.macports.org/ticket/39704> MacPorts <http://www.macports.org/> Ports system for OS X

1 1

[MacPorts] #40376: py-xhtml2pdf: missing dependency
by MacPorts 10 Sep '14

10 Sep '14

#40376: py-xhtml2pdf: missing dependency -------------------------------------+-------------------------------- Reporter: pierreetienne.meunier@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.0 Keywords: | Port: py-xhtml2pdf -------------------------------------+-------------------------------- It turns out that py-xhtml2pdf depends on port:py-six, but this is not in the current Portfile. -- Ticket URL: <https://trac.macports.org/ticket/40376> MacPorts <http://www.macports.org/> Ports system for OS X

1 5

[MacPorts] #42312: Update percona-server and percona to 5.6.x
by MacPorts 09 Sep '14

09 Sep '14

#42312: Update percona-server and percona to 5.6.x ---------------------+-------------------------------- Reporter: mark@… | Owner: macports-tickets@… Type: update | Status: new Priority: Not set | Milestone: Component: ports | Version: 2.2.1 Keywords: | Port: percona ---------------------+-------------------------------- Percona now has 5.6 as their GA -- Ticket URL: <https://trac.macports.org/ticket/42312> MacPorts <http://www.macports.org/> Ports system for OS X

1 4

[MacPorts] #41600: bison 3.0.1 is out
by MacPorts 09 Sep '14

09 Sep '14

#41600: bison 3.0.1 is out -----------------------------+-------------------------------- Reporter: akim.demaille@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.2.1 Keywords: | Port: bison -----------------------------+-------------------------------- This version addresses the problem of the yacc man page. {{{ --- /opt/local/var/macports/sources/rsync.macports.org/release/tarballs/ports/devel/bison/Portfile 2013-08-03 00:30:21.000000000 +0200 +++ /tmp/Portfile 2013-11-29 18:30:50.000000000 +0100 @@ -1,9 +1,10 @@ +# -*- coding: utf-8; mode: tcl; tab-width: 4; indent-tabs-mode: nil; c -basic-offset: 4 -*- vim:fenc=utf-8:ft=tcl:et:sw=4:ts=4:sts=4 # $Id: Portfile 108830 2013-08-02 22:11:18Z jeremyhu(a)macports.org $ PortSystem 1.0 name bison -version 2.7.1 +version 3.0.1 epoch 1 categories devel maintainers mww @@ -20,8 +21,8 @@ homepage http://www.gnu.org/software/bison/ master_sites gnu -checksums rmd160 933257e61c1098160d4fd71063f340b2ee304671 \ - sha256 b409adcbf245baadb68d2f66accf6fdca5e282cafec1b865f4b5e963ba8ea7fb +checksums rmd160 bc2357e0253857e6c5b19ad1b4c6e5f27472bd28 \ + sha256 944efb03b46d831cef452bfa44620e5b30f7de999902a70d96021a0a77f5a2cb use_xz yes depends_lib port:gettext port:m4 port:libiconv @@ -46,10 +47,6 @@ calc++-scanner.cc calc++-scanner.ll calc++.cc location.hh \ position.hh stack.hh test \ ${destroot}${docdir}/examples/calc++ - # yacc manpage gets installed even with '--disable-yacc' - if {! [variant_isset yacc]} { - delete ${destroot}${prefix}/share/man/man1/yacc.1 - } } variant yacc description "enable yacc compatibility" { @@ -59,4 +56,3 @@ livecheck.type regex livecheck.url http://ftp.gnu.org/gnu/bison/?C=M&O=D livecheck.regex ${name}-(\\d+(?:\\.\\d+)*) - }}} -- Ticket URL: <https://trac.macports.org/ticket/41600> MacPorts <http://www.macports.org/> Ports system for OS X

1 14

[MacPorts] #42582: Building p5.14-libapreq2 fails (upgrade)
by MacPorts 09 Sep '14

09 Sep '14

#42582: Building p5.14-libapreq2 fails (upgrade) ------------------------+-------------------------------- Reporter: st.graef@… | Owner: macports-tickets@… Type: defect | Status: new Priority: High | Milestone: Component: ports | Version: 2.2.1 Keywords: | Port: p5.14-libapreq2 ------------------------+-------------------------------- :info:build Command failed: cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-libapreq2/p5.14-libapreq2/work/libapreq2-2.13" && /usr/bin/make -j4 -w all :info:build Exit code: 2 :error:build org.macports.build for port p5.14-libapreq2 returned: command execution failed :debug:build Error code: CHILDSTATUS 17851 2 :debug:build Backtrace: command execution failed while executing "system -nice 0 $fullcmdstring" ("eval" body line 1) invoked from within "eval system $notty $nice \$fullcmdstring" invoked from within "command_exec build" (procedure "portbuild::build_main" line 8) invoked from within "$procedure $targetname" :info:build Warning: targets not executed for p5.14-libapreq2: org.macports.activate org.macports.build org.macports.destroot org.macports.install :notice:build Please see the log file for port p5.14-libapreq2 for details: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_perl_p5-libapreq2/p5.14-libapreq2/main.log -- Ticket URL: <https://trac.macports.org/ticket/42582> MacPorts <http://www.macports.org/> Ports system for OS X

1 25

[MacPorts] #23558: omniORB +universal fails to build on 10.6.2
by MacPorts 08 Sep '14

08 Sep '14

#23558: omniORB +universal fails to build on 10.6.2 ------------------------------------+--------------------------------------- Reporter: jakub.moskal@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.2 Keywords: 10.6.2 | Port: omniORB ------------------------------------+--------------------------------------- I am trying to upgrade my current installation of omniORB to include the i386 architecture, but it fails. I tried moving the /usr/local to /usr/local.SAVE and cleaning the port, but it still ends up with this error. I need omniORBpy to work in a 32-bit mode.. {{{ port installed omniORB The following ports are currently installed: omniORB @4.1.4_0+python26 (active) }}} {{{ sudo port -u -d upgrade --enforce-variants omniORB +universal [...] /usr/bin/g++-4.2 -c -O2 -arch x86_64 -arch i386 -fno-common -bind_at_load -I/opt/local/include -DIDLMODULE_VERSION="\"0x2630\"" -I/opt/local/Library/Frameworks/Python.framework/Versions/2.6/include -DPYTHON_INCLUDE="<python2.6/Python.h>" -fPIC -I. -I. -I../../../../include -I../../../../include -D__OSVERSION__=1 -D__darwin__ -D__x86__ -o idlexpr.o idlexpr.cc idlexpr.cc:179: error: integer constant is too large for 'long' type idlexpr.cc:881: error: integer constant is too large for 'long' type idlexpr.cc:887: error: integer constant is too large for 'long' type idlexpr.cc:1109: error: integer constant is too large for 'long' type idlexpr.cc:1198: error: integer constant is too large for 'long' type idlexpr.cc: In member function 'IDL_LongLong IdlExpr::evalAsLongLong()': idlexpr.cc:179: warning: comparison is always false due to limited range of data type idlexpr.cc: In member function 'virtual IdlLongLongVal SubExpr::evalAsLongLongV()': idlexpr.cc:881: warning: comparison is always false due to limited range of data type idlexpr.cc:887: warning: comparison is always false due to limited range of data type idlexpr.cc: In member function 'virtual IdlLongLongVal DivExpr::evalAsLongLongV()': idlexpr.cc:1109: warning: comparison is always false due to limited range of data type idlexpr.cc: In member function 'virtual IdlLongLongVal MinusExpr::evalAsLongLongV()': idlexpr.cc:1198: warning: comparison is always false due to limited range of data type lipo: can't figure out the architecture type of: /var/tmp//ccM6g0dx.out make[4]: *** [idlexpr.o] Error 1 make[3]: *** [export] Error 1 make[2]: *** [export] Error 1 make[1]: *** [export] Error 1 make: *** [all] Error 1 Error: Target org.macports.build returned: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_omniORB/work/omniORB-4.1.4" && /usr/bin/make -j2 all " returned error 2 DEBUG: Backtrace: shell command " cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_omniORB/work/omniORB-4.1.4" && /usr/bin/make -j2 all " returned error 2 while executing "command_exec build" (procedure "portbuild::build_main" line 9) invoked from within "$procedure $targetname" Warning: the following items did not execute (for omniORB): org.macports.destroot org.macports.build DEBUG: couldn't read file "/opt/local/share/macports/Tcl/darwintrace1.0/pkgIndex.tcl": no such file or directory while executing "source [file join $dir pkgIndex.tcl]" Error: Unable to upgrade port: 1 }}} -- Ticket URL: <http://trac.macports.org/ticket/23558> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3