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

[MacPorts] #20686: gsed fails to handle non-ASCII characters (bytes with top-bit set) in C locale
by MacPorts 13 Sep '14

13 Sep '14

#20686: gsed fails to handle non-ASCII characters (bytes with top-bit set) in C locale ---------------------------------+------------------------------------------ Reporter: vinc17@… | Owner: nox@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.7.1 Keywords: | Port: gsed ---------------------------------+------------------------------------------ For instance: {{{ $ echo "abécd" | LC_ALL=C gsed -e 's/.*//' écd }}} With the sed from Mac OS X and GNU sed under GNU/Linux, one gets a blank line, thus I suppose that this is what the user expects even though é isn't part of the US-ASCII character set specified by the C locale (and even though the result could depend on the encoding with some expressions). The consequence is that building ocaml fails if gsed is installed with the with_default_names variant (see bug #20275). -- Ticket URL: <http://trac.macports.org/ticket/20686> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 12

[MacPorts] #20976: viewcvs is now called viewvc
by MacPorts 13 Sep '14

13 Sep '14

#20976: viewcvs is now called viewvc -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: ryandesign@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.0 Keywords: | Port: viewcvs, viewvc -------------------------------------+-------------------------------------- viewcvs changed names to viewvc some time ago since it now supports RCSes other than CVS. The viewcvs port should be copied to a new viewvc port and updated, and the old viewcvs port should state that viewvc replaces it, using the new replaced_by keyword. -- Ticket URL: <http://trac.macports.org/ticket/20976> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #26450: gdb does not work for debugging gcc45 C++ programs
by MacPorts 12 Sep '14

12 Sep '14

#26450: gdb does not work for debugging gcc45 C++ programs --------------------------------+------------------------------------------- Reporter: bumens@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: | Port: gdb --------------------------------+------------------------------------------- Neither fsf-gdb nor fsf-gdbtui work for debugging C++ programs. They're finding errors where no errors are, it's even not possible to try out because it's not possible to debug until the main() entry (with gdb command "start"). In contrast, MacPorts' cgdb works, as well as Apple's gdb (both don't work very well because of the too old release of GNU's gdb they're made of). -- Ticket URL: <http://trac.macports.org/ticket/26450> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 10

[MacPorts] #30877: iStumbler +use_source does not compile on a case sensitive FS
by MacPorts 12 Sep '14

12 Sep '14

#30877: iStumbler +use_source does not compile on a case sensitive FS -----------------------------------------+---------------------------------- Reporter: greisberger@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: istumbler -----------------------------------------+---------------------------------- The use_source variant does not compile on my system: OS: Snow Leopard 10.6.8 Arch: x86_64 FS: case sensitive XCode: 4.0.2 From what I saw in the log file, I think that it's a case sensitivity problem: {{{ :info:destroot /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_istumbler/istumbler/work/iStumbler/Plugins/AirPort/AirPort.pch:6:28: error: Plugins/Plugins.h: No such file or directory :info:destroot /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_istumbler/istumbler/work/iStumbler/Plugins/AirPort/AirPort.pch:7:34: error: RadioStore/RadioStore.h: No such file or directory :info:destroot /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_aqua_istumbler/istumbler/work/iStumbler/Plugins/AirPort/AirPort.pch:8:36: error: FourCorners/FourCorners.h: No such file or directory }}} Is there a mechanism in macports to be able to build a port in a temporary case insensitive disk image? -- Ticket URL: <https://trac.macports.org/ticket/30877> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #30127: arm-elf-gcc @4.6.0 presence of hdf4 port prevents arm-elf-gcc from building
by MacPorts 12 Sep '14

12 Sep '14

#30127: arm-elf-gcc @4.6.0 presence of hdf4 port prevents arm-elf-gcc from building ---------------------------------------+------------------------------------ Reporter: michael@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: arm-elf-gcc ---------------------------------------+------------------------------------ If HDF4 is installed (and activated), then arm-elf-gcc (and possibly other gcc versions) fail to build: {{{ :info:build /usr/bin/gcc-4.2 -I/opt/local/include -c -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-ma ..... :info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_mirror.aarnet.edu .au_macports-portfiles_cross_arm-elf- gcc/work/gcc-4.6.0/gcc/config/arm/arm.c -o arm.o :info:build In file included from /opt/local/include/hdf.h:20, :info:build from /opt/local/include/df.h:35, :info:build from /opt/local/var/macports/build/_opt_local_var_macports_sources_mirror.aarnet.edu .au_macports-portfiles_cross_arm-elf- gcc/work/gcc-4.6.0/gcc/config/arm/arm.c:55: :info:build /opt/local/include/hdfi.h:1613:29: error: attempt to use poisoned "malloc" :info:build /opt/local/include/hdfi.h:1614:29: error: attempt to use poisoned "calloc" :info:build /opt/local/include/hdfi.h:1616:29: error: attempt to use poisoned "realloc" :info:build /opt/local/include/hdfi.h:1636:37: error: attempt to use poisoned "strdup" }}} De-activating the HDF4 port before installing gcc fixes this problem. This seems to be the result of: * unfortunate naming of a global header by hdf (fixed in HDF5) * poor ordering of header paths (gcc internal paths should have priority -- the header is included from arm.c with double quotes not angle brackets, ie #include "df.h" not #include <df.h>) Can this be fixed with, at the very least, a warning to the unwary? The df.h header is not installed by gcc so it should be safe to reactivate HDF4. -- Ticket URL: <https://trac.macports.org/ticket/30127> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #31106: arm-none-linux-gnueabi-gcc 2005q3-2_0 Segmentation fault during build
by MacPorts 12 Sep '14

12 Sep '14

#31106: arm-none-linux-gnueabi-gcc 2005q3-2_0 Segmentation fault during build ----------------------------------+----------------------------------------- Reporter: jan.koehnlein@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.2 Keywords: | Port: ----------------------------------+----------------------------------------- Tried to install with sudo port install arm-none-linux-gnueabi-gcc on MacOSX Lion 10.7, Xcode Version 4.1 -- Ticket URL: <https://trac.macports.org/ticket/31106> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[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] #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

[MacPorts] #30868: Update grok to version 1.20110630.1
by MacPorts 08 Sep '14

08 Sep '14

#30868: Update grok to version 1.20110630.1 ---------------------------+------------------------------------------------ Reporter: kentk@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.1 Keywords: | Port: grok ---------------------------+------------------------------------------------ Updated and added the appropriate test flags. -- Ticket URL: <https://trac.macports.org/ticket/30868> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #28504: ldns-tools, drill: fix livecheck
by MacPorts 08 Sep '14

08 Sep '14

#28504: ldns-tools, drill: fix livecheck -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: marius.rieder@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.2 Keywords: | Port: ldns-tools, drill -------------------------------------+-------------------------------------- The livecheck for ldns-tools and drill should probably be fixed: {{{ $ port livecheck drill ldns-tools drill seems to have been updated (port version: 1.6.8, new version: 0.9.2) Error: cannot check if ldns-tools was updated (The requested URL returned error: 406) }}} The livecheck for ldns was recently fixed in r76395. -- Ticket URL: <https://trac.macports.org/ticket/28504> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1