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

[MacPorts] #17018: libgda3 uses string match as if it accepted a regexp
by MacPorts 28 Feb '14

28 Feb '14

#17018: libgda3 uses string match as if it accepted a regexp -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: jwa(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | Port: libgda3 -------------------------------------+-------------------------------------- libgda3 uses the "string match" function as if it accepted a regular expression as its parameter, but it does not; it expects a glob. The string match in the Portfile has thus never worked. The string match could be fixed by changing "`{/Makefile$}`" to "`{*/Makefile}`". However the only Makefile in the source is in the po directory and it does not contain the string to be replaced. If the port is working correctly now, perhaps the entire post-configure part can be removed. -- Ticket URL: <http://trac.macports.org/ticket/17018> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #15648: VPython request
by MacPorts 27 Feb '14

27 Feb '14

#15648: VPython request -------------------------------+-------------------------------------------- Reporter: ralph(a)cs.cf.ac.uk | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Port Requests Component: ports | Version: 1.6.0 Keywords: VPython | -------------------------------+-------------------------------------------- Any chance of a MacPort of VPython? -- Ticket URL: <http://trac.macports.org/ticket/15648> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 21

[MacPorts] #16690: add db46 support for p5-mail-spamassassin
by MacPorts 22 Feb '14

22 Feb '14

#16690: add db46 support for p5-mail-spamassassin ------------------------------------+--------------------------------------- Reporter: 13z73rch3un9(a)gmail.com | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.6.0 Keywords: db46 spamassassin | Port: p5-mail-spamassassin ------------------------------------+--------------------------------------- It would be nice to have support for db46 support for bayesian filters db with spamassassin. How to reproduce: * copy $HOME/.spamassassin/bayes_toks from a reasonably up-to-date linux machine * file(1) should identify the file as "Berkeley DB (Hash, version 9, little-endian)" * running ``spamassassin < /dev/null'' will return the following: [2274] warn: bayes: cannot open bayes databases /Users/lester/.spamassassin/bayes_* R/O: tie failed: Inappropriate file type or format [2274] warn: bayes: cannot open bayes databases /Users/lester/.spamassassin/bayes_* R/O: tie failed: Inappropriate file type or format FYI, if you create the file (by running sa-learn and feed something to it) you will get a file in "Berkeley DB 1.85 (Hash, version 2, native byte- order)" format. Again, as reported by file(1). Seems this is created by using the Perl DB_File module... -- Ticket URL: <http://trac.macports.org/ticket/16690> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #16201: Upgrading openssh overwrites user-modified config files
by MacPorts 16 Feb '14

16 Feb '14

#16201: Upgrading openssh overwrites user-modified config files ---------------------------------+------------------------------------------ Reporter: vinc17(a)macports.org | Owner: wms(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: | ---------------------------------+------------------------------------------ The openssh port shouldn't overwrite user-modified config files (ssh_config and sshd_config), or should introduce some mechanism to do config file upgrades safely. For instance, contents between some markers could be preserved, e.g. {{{ # BEGIN local configuration ... # END local configuration }}} In such a case, such configuration should be near the beginning of the file. The ssh_config man page says: {{{ For each parameter, the first obtained value will be used. The configu- ration files contain sections separated by ``Host'' specifications, and that section is only applied for hosts that match one of the patterns given in the specification. The matched host name is the one given on the command line. Since the first obtained value for each parameter is used, more host- spe- cific declarations should be given near the beginning of the file, and general defaults at the end. }}} I don't know about sshd_config. I suppose that the same rule is applied. -- Ticket URL: <http://trac.macports.org/ticket/16201> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #15939: port install : in need of a progressbar
by MacPorts 14 Feb '14

14 Feb '14

#15939: port install : in need of a progressbar --------------------------------------+------------------------------------- Reporter: pc(a)anykey.de | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Low | Milestone: Component: base | Version: 1.6.0 Keywords: port install progressbar | --------------------------------------+------------------------------------- Installing bigger Distributions, like texlive_texmf-full (>125MB), I was wondering if everything is allright after some minutes of nothingness. I know that other *nix-packet-managers have a progressbar (some dots or whatever) so that the user is able to track the progress, at least having an idea if everything is allright. Since now I know I just have to wait, everything is fine for me. Thinking of other users - they would sometimes appreciate to have a progressbar when installing using port, I suppose. Thinking of gentoo-users sitting next to me, I would appreciate that anyway ;) -- Ticket URL: <http://trac.macports.org/ticket/15939> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 7

[MacPorts] #15571: request - uniform Portfile standard to handle the different possibilities of Fortran compilers
by MacPorts 29 Jan '14

29 Jan '14

#15571: request - uniform Portfile standard to handle the different possibilities of Fortran compilers -------------------------------------+-------------------------------------- Reporter: davidh(a)ipac.caltech.edu | Owner: markd(a)macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Component: guide | Version: 1.6.0 Keywords: | -------------------------------------+-------------------------------------- I don't write code in Fortran, but some of the ports I use require Fortran. Different Portfiles depend on different Fortran compilers. Contrast fftw-3(g95, gfortran/gcc4.2, gfortan/gcc4.3) pgplot(g77 on PPC, gfortran/gcc4.2 on i386) and cfitsio(gfortran/gcc42). There are at least 4 compilers to choose from. My request: formulate a standard to allow any of the compilers to be selected with a variant. The fftw-3 Portfile comes closest with variants to select any one of 3 compilers. If possible, I'd like to see g77 deprecated. -- Ticket URL: <http://trac.macports.org/ticket/15571> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 7

[MacPorts] #17243: make openmpi compiler wrappers use currenly selected compiler
by MacPorts 28 Jan '14

28 Jan '14

#17243: make openmpi compiler wrappers use currenly selected compiler --------------------------------+------------------------------------------- Reporter: mmoll(a)macports.org | Owner: mww(a)macports.org Type: enhancement | Status: new Priority: Normal | Milestone: Port Enhancements Component: ports | Version: 1.7.0 Keywords: openmpi gcc_select | Port: openmpi --------------------------------+------------------------------------------- It'd be nice if openmpi used gcc_select to select default compilers. Right now, the openmpi compiler wrappers (mpicc, mpicxx, mpif77) always use the C and C++ compilers in /usr/bin, even if /opt/local/bin comes first in the user's path. The changes to accomplish this are trivial: - add a dependency on port:gcc_select - patch the files in ${prefix}/share/openmpi to use /opt/local/bin/gcc instead of /usr/bin/gcc (similarly for C++ and Fortran). -- Ticket URL: <http://trac.macports.org/ticket/17243> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 3

[MacPorts] #15653: std::locale broken in gcc
by MacPorts 27 Nov '13

27 Nov '13

#15653: std::locale broken in gcc --------------------------------+------------------------------------------- Reporter: dirk(a)code-shop.com | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.6.0 Keywords: | --------------------------------+------------------------------------------- When compiling the following code: #include <locale> #include <iostream> #include <exception> #include <clocale> void try_c_locale(const char* locale_name) { if( std::setlocale(LC_ALL, locale_name) == NULL ) printf("Failed to setlocale(LC_ALL, \"%s\")\n", locale_name); else printf("Succeeded in calling setlocale(LC_ALL, \"%s\")\n", locale_name); } void try_cpp_locale(const char* locale_name) { try { std::locale my_locale(locale_name); } catch(std::exception& e) { printf("Failed ctor for std::locale with \"%s\": %s\n", locale_name, e.what()); return; } printf("Succeeded ctor for std::locale with \"%s\"\n", locale_name); } int main(void) { // Some locales from "locale -a" on my OS X system, here is proof // that these locales do exist on my system. Take my word for it // that "locale -a" also shows these locales existing on my linux // system as well. // // rutski@imac:~$ locale -a | tail -n 2 // C // POSIX // rutski@imac:~$ locale -a | grep en_US // en_US // en_US.ISO8859-1 // en_US.ISO8859-15 // en_US.US-ASCII // en_US.UTF-8 // rutski@imac:~$ locale -a | grep pl_PL // pl_PL // pl_PL.ISO8859-2 // pl_PL.UTF-8 // rutski@imac:~$ const char* test_locales[] = { "C", "POSIX", "en_US", "en_US.UTF-8", "pl_PL", "pl_PL.ISO8859-2" }; printf("Trying c locales...\n"); for(size_t x = 0; x < sizeof(test_locales)/sizeof(char*); x++) try_c_locale(test_locales[x]); printf("\n"); printf("Trying C++ locales...\n"); for(size_t x = 0; x < sizeof(test_locales)/sizeof(char*); x++) try_cpp_locale(test_locales[x]); } the output clearly states there is something wrong: Trying c locales... Succeeded in calling setlocale(LC_ALL, "C") Succeeded in calling setlocale(LC_ALL, "POSIX") Succeeded in calling setlocale(LC_ALL, "en_US") Succeeded in calling setlocale(LC_ALL, "en_US.UTF-8") Succeeded in calling setlocale(LC_ALL, "pl_PL") Succeeded in calling setlocale(LC_ALL, "pl_PL.ISO8859-2") Trying C++ locales... Succeeded ctor for std::locale with "C" Succeeded ctor for std::locale with "POSIX" Failed ctor for std::locale with "en_US": locale::facet::_S_create_c_locale name not valid Failed ctor for std::locale with "en_US.UTF-8": locale::facet::_S_create_c_locale name not valid Failed ctor for std::locale with "pl_PL": locale::facet::_S_create_c_locale name not valid Failed ctor for std::locale with "pl_PL.ISO8859-2": locale::facet::_S_create_c_locale name not valid a google serach delivers this: http://groups.google.com/group/gnu.gcc.help/browse_thread/thread/99d874aed6… appearantly, a --enable-clocale to configure might do something however, macport's configure stage does not allow for adding options (or I could not find it) * could this be fixed in gcc? (in libstdc++) * could this be added to macport (adding extra configure options) -- Ticket URL: <http://trac.macports.org/ticket/15653> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #15432: Update mod_security
by MacPorts 23 Nov '13

23 Nov '13

#15432: Update mod_security -----------------------------------+---------------------------------------- Reporter: webmaster(a)lifedit.com | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: High | Milestone: Port Updates Component: ports | Version: 1.6.0 Keywords: mod_security | -----------------------------------+---------------------------------------- Hi ... I would like to see an update to the latest release of mod_security for Apache. Current MacPort version is 1.8.6 (http://trac.macports.org/browser/trunk/dports/www/mod_security/Portfile) and the official project website (http://www.modsecurity.org) currently shows version 2.5.6 to download (http://www.modsecurity.org/download/direct.html) So I think it would be great if this one could be updated soon if possible. Thanks! -- Ticket URL: <http://trac.macports.org/ticket/15432> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 9

[MacPorts] #17155: avr-gdb-6.71 broken / fails to read symbols from elf files
by MacPorts 21 Nov '13

21 Nov '13

#17155: avr-gdb-6.71 broken / fails to read symbols from elf files --------------------------------------------+------------------------------- Reporter: moritz.fischer(a)student.kit.edu | Owner: macports-tickets(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.6.0 Keywords: elf32-avr, symbols, elf, bfd | Port: avr-gdb --------------------------------------------+------------------------------- Although it seems to build perfectly ok, avr-gdb is not able to read debugging symbols from elf files. I tried switching to gdb-6.8 with the same effect. I found out that if built by hand with same ./configure parameters it works just fine, but using the port somehow elfread.o doesn't get linked in. Somehow the configure scripts seem to fail. The Problem is afaik related to bfd's elf support: "checking for ELF support in BFD... no" if compiled by port, whereas ELF support is detected when build by hand. -- Ticket URL: <http://trac.macports.org/ticket/17155> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1