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

[MacPorts] #22312: readline-6.0.000_2 configuration fails on i386 with +universal
by MacPorts 12 Apr '14

12 Apr '14

#22312: readline-6.0.000_2 configuration fails on i386 with +universal ------------------------------------------------+--------------------------- Reporter: steini@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.1 Keywords: readline, configuration, universal | Port: readline ------------------------------------------------+--------------------------- Hi, I'm trying to build this port with the +universal modifier but it fails in configuration step. I'm on a 1st gen. MacbookPro with only a CoreDuo (so no possibility to execute x86_64. but i need this for linking against) -- Ticket URL: <http://trac.macports.org/ticket/22312> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #37286: Update py-netcdf4 to 1.0.2 and add Python 3.x ports
by MacPorts 11 Apr '14

11 Apr '14

#37286: Update py-netcdf4 to 1.0.2 and add Python 3.x ports --------------------+-------------------------------- Reporter: mkr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: py-netcdf4 --------------------+-------------------------------- -- Ticket URL: <https://trac.macports.org/ticket/37286> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #36865: AppKiDo: update to 0.992
by MacPorts 08 Apr '14

08 Apr '14

#36865: AppKiDo: update to 0.992 --------------------------+----------------------------- Reporter: ryandesign@… | Owner: michael.klein@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: AppKiDo --------------------------+----------------------------- {{{ $ port livecheck AppKiDo AppKiDo seems to have been updated (port version: 0.988, new version: 0.992) }}} -- Ticket URL: <https://trac.macports.org/ticket/36865> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #33036: sdcc update port to 3.1.0
by MacPorts 08 Apr '14

08 Apr '14

#33036: sdcc update port to 3.1.0 --------------------------------------+------------------------------------- Reporter: lara.dougan@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: haspatch | Port: sdcc --------------------------------------+------------------------------------- Hi. Here is a patch to update SDCC to version 3.1.0. I also removed avr and x51 then added variants for them because they are unsupported by SDCC now. -- Ticket URL: <https://trac.macports.org/ticket/33036> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 8

[MacPorts] #32533: txt2regex: noarch; license; manpage location
by MacPorts 08 Apr '14

08 Apr '14

#32533: txt2regex: noarch; license; manpage location -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: grrr@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: haspatch | Port: txt2regex -------------------------------------+-------------------------------------- The txt2regex port installs a manpage, but with the wrong extension (".man" instead of the required ".1"), so "man txt2regex" doesn't actually find it. The attached Portfile patch fixes this, and indicates that the port doesn't install any architecture-specific files, and builds and installs the localized message catalogs. It does this by removing the custom destroot phase the Portfile had been using, and instead patching the Makefile to work properly. The Makefile patch makes the following changes: * Introduces PREFIX variable and uses it instead of assuming /usr * Fixes how DESTDIR is handled so that DESTDIR doesn't get written into the final txt2regex script * Replaces "echo -n" (which doesn't work as intended on POSIX-compliant systems like Snow Leopard and higher) with "printf" * Installs manpage The Makefile patch should be suitable for submission to the developers of this software, if they're interested. -- Ticket URL: <https://trac.macports.org/ticket/32533> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #37732: fortran compilers don't accept -arch flags
by MacPorts 08 Apr '14

08 Apr '14

#37732: fortran compilers don't accept -arch flags ---------------------+-------------------------------- Reporter: mojca@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: base | Version: 2.1.2 Keywords: | Port: ---------------------+-------------------------------- gfortran-mp-4.X fails when the compiler flag {{{-arch xxx}}} is set. On the other hand {{{g95}}} simply ignores the flag (it has no influence). {{{ > gfortran-mp-4.5 -arch x86_64 a.f f951: error: unrecognized command line option "-arch" }}} This seems in contradiction to the information on http://www.microscopy.cen.dtu.dk/computing/fortran/index.html though which provides a counter example: {{{ gfortran -arch x86_64 -arch i386 -arch ppc hello.f -o hello }}} so I'm still confused a bit. It seems that one can use {{{-m32}}} with both to get 32-bit i386 binaries, but I cannot try it out without recompiling gcc with {{{+universal}}} and I don't know yet how to make universal binaries with that approach. If I try to use cmake Portgroup (but I didn't yet test without it), it automatically adds {{{-arch x86_64}}} to FFLAGS and the compilation fails. See also #37034 and #37688. After writing the description I have also found this ticket #20361 and r54236 which made me believe that the wrong behaviour might have been fixed earlier and introduced again later (but I didn't try to understand the tcl code). -- Ticket URL: <https://trac.macports.org/ticket/37732> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 20

[MacPorts] #25686: Add crypto variants to openssl & use system zlib
by MacPorts 07 Apr '14

07 Apr '14

#25686: Add crypto variants to openssl & use system zlib ------------------------------------+--------------------------------------- Reporter: michaelld@… | Owner: mww@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: | Port: openssl ------------------------------------+--------------------------------------- OpenSSL 1.0.0a allows for extensions for md2, kerberos, and others as well as moves to using system (MacPorts) provided zlib. I'm attaching a patch to the current (1.0.0a, epoch 1, revision 0) Portfile to allow these changes. The default install isn't changed, and in my testing openssl works just before with or without the variants (the variants are plugin extensions and headers, and do not impact the application). -- Ticket URL: <http://trac.macports.org/ticket/25686> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 12

[MacPorts] #39573: quickfix python bindings
by MacPorts 07 Apr '14

07 Apr '14

#39573: quickfix python bindings ---------------------+-------------------------------- Reporter: mtb19@… | Owner: macports-tickets@… Type: request | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: ---------------------+-------------------------------- quickfix has bindings for several languages, including python. These are enabled by (e.g.): {{{ ./configure ... --with-python=.../include/python[X].[Y] ... }}} It would be nice to have py-quickfix packages in addition to the base package. I am new to authoring Portfiles. For example, I do not know if these should belong as variants to devel/quickfix (because they are built using the same sources), or if they should be in a separate Portfile in (e.g.) python/py[XY]-quickfix. I would be willing to take a stab at this if someone could point me to a similarly built library as an example.... -- Ticket URL: <https://trac.macports.org/ticket/39573> MacPorts <http://www.macports.org/> Ports system for OS X

1 4

[MacPorts] #32652: gvfs cannot open remote urls
by MacPorts 07 Apr '14

07 Apr '14

#32652: gvfs cannot open remote urls ------------------------------+--------------------------------------------- Reporter: brandon@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.3 Keywords: gtk, gvfs | Port: gvfs ------------------------------+--------------------------------------------- This may be related more deeply to Gio but gvfs cannot open remote uri's. There is a [https://trac.macports.org/ticket/32020 similar bug] reported for Gimp but this is a more general issue that I also experience when programming with Giomm and trying to use Giomm::File to open remote uris. [[BR]] /opt/local/bin/gvfs-open http://www.macports.com [[BR]] gvfs-open: http://www.macports.com: error opening location: Operation not supported -- Ticket URL: <https://trac.macports.org/ticket/32652> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #38301: Latest Ocropus doesn't get along with iulib
by MacPorts 07 Apr '14

07 Apr '14

#38301: Latest Ocropus doesn't get along with iulib ------------------------+-------------------------------- Reporter: tgamblin@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: ocropus | Port: ocropus ------------------------+-------------------------------- There are a bunch of ambiguous calls in the current octopus due to duplicate routines in the latest iulib. This causes ocropus and iulib not to get along. Attaching the build output. -- Ticket URL: <https://trac.macports.org/ticket/38301> MacPorts <http://www.macports.org/> Ports system for OS X

1 3