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

[MacPorts] #34454: Midnight Commander & corrupted FTP directory listing
by MacPorts 25 Aug '14

25 Aug '14

#34454: Midnight Commander & corrupted FTP directory listing -------------------------------+-------------------------------------------- Reporter: gkmarty@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.4 Keywords: | Port: -------------------------------+-------------------------------------------- Midnight Commander shows damaged FTP directory list since version 4.8.1.3 Most (almost all) of files/directories in listing are not accessible and its name beginning with "?". Listing, browsing and accessing to the files/directories through plain ftp client (or any other ftp client than mc) works. -- Ticket URL: <https://trac.macports.org/ticket/34454> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 6

[MacPorts] #35390: ocaml-batteries Error: Unbound module Toploop
by MacPorts 25 Aug '14

25 Aug '14

#35390: ocaml-batteries Error: Unbound module Toploop ------------------------------------+--------------------------------------- Reporter: maverick.woo@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: ------------------------------------+--------------------------------------- I just upgraded to ocaml 4.0 and everything except batteries was fine. $port installed | grep ocaml ocaml @4.00.0_0+profile (active) ocaml-bin-prot @108.00.02_1 (active) ocaml-camomile @0.8.3_1 (active) ocaml-extlib @1.5.2_3 (active) ocaml-fileutils @0.4.4_1 (active) ocaml-findlib @1.3.3_2 (active) ocaml-menhir @20120123_1 (active) ocaml-ocamlgraph @1.8.2_1 (active) ocaml-ocamlmakefile @6.37.0_1 (active) ocaml-ocamlnet @3.6_1 (active) ocaml-odn @0.0.8_3 (active) ocaml-ounit @1.1.2_1 (active) ocaml-pcre @7.0.2_0 (active) ocaml-sexplib @108.00.02_1 (active) ocaml-sqlite3 @2.0.2_0 (active) ocaml-type-conv @108.00.02_1 (active) ocaml-zip @1.04_1 (active) ocamlify @0.0.1_1 (active) ocamlmod @0.0.3_1 (active) -- Ticket URL: <https://trac.macports.org/ticket/35390> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 4

[MacPorts] #32967: cvsps needs to be UsingTheRightCompiler
by MacPorts 25 Aug '14

25 Aug '14

#32967: cvsps needs to be UsingTheRightCompiler ------------------------------+--------------------------------------------- Reporter: snc@… | Owner: erickt@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: Keywords: | Port: cvsps ------------------------------+--------------------------------------------- {{{ cc -g -O2 -Wall -I. -DVERSION=\"2.1\" -c -o cbtcommon/debug.o cbtcommon/debug.c cc -g -O2 -Wall -I. -DVERSION="2.1" -c -o cbtcommon/debug.o cbtcommon/debug.c cc: Error: You should be using ${configure.cc} See http://trac.macports.org/wiki/UsingTheRightCompiler make: *** [cbtcommon/debug.o] Error 1 }}} -- Ticket URL: <https://trac.macports.org/ticket/32967> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 1

[MacPorts] #24708: p5-libxml-enno and p5-xml-dom conflict
by MacPorts 25 Aug '14

25 Aug '14

#24708: p5-libxml-enno and p5-xml-dom conflict -------------------------------------+-------------------------------------- Reporter: ryandesign@… | Owner: narf_tm@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.8.2 Keywords: | Port: p5-libxml-enno, p5-xml-dom -------------------------------------+-------------------------------------- p5-libxml-enno and p5-xml-dom conflict; indeed the description of p5 -libxml-enno says it provides XML::DOM. We should have only a single port for this software, whichever is the latest. -- Ticket URL: <http://trac.macports.org/ticket/24708> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5

[MacPorts] #35339: Update zorba to 2.5 release
by MacPorts 24 Aug '14

24 Aug '14

#35339: Update zorba to 2.5 release ------------------------------------+--------------------------------------- Reporter: cezar.andrei@… | Owner: macports-tickets@… Type: update | Status: new Priority: Normal | Milestone: MacPorts Future Component: ports | Version: 2.1.1 Keywords: zorba | Port: zorba ------------------------------------+--------------------------------------- This is an update to zorba port to upgrade to release 2.5. Attached are the patch to the Portfile and updated patch files. -- Ticket URL: <https://trac.macports.org/ticket/35339> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 10

[MacPorts] #36807: torsocks should install a sample conf file, not a real conf file
by MacPorts 22 Aug '14

22 Aug '14

#36807: torsocks should install a sample conf file, not a real conf file --------------------------+-------------------------- Reporter: ryandesign@… | Owner: sami.laine@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: torsocks --------------------------+-------------------------- torsocks installs ${prefix}/etc/torsocks.conf, but ports should not install files users are expected to modify. Instead it [wiki:PortfileRecipes#configfiles should install a sample conf file]. -- Ticket URL: <https://trac.macports.org/ticket/36807> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #36806: torsocks installs documentation in the wrong directory
by MacPorts 22 Aug '14

22 Aug '14

#36806: torsocks installs documentation in the wrong directory --------------------------+-------------------------- Reporter: ryandesign@… | Owner: sami.laine@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.2 Keywords: | Port: torsocks --------------------------+-------------------------- torsocks installs documentation files directly in ${prefix}/share but it [wiki:PortfileRecipes#doc should install them in] ${prefix}/share/doc/${name} -- Ticket URL: <https://trac.macports.org/ticket/36806> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 2

[MacPorts] #33719: keep machines from sleep during port building
by MacPorts 21 Aug '14

21 Aug '14

#33719: keep machines from sleep during port building ------------------------------------------+--------------------------------- Reporter: drechsel@… | Owner: macports-tickets@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.0.4 Keywords: | Port: all ------------------------------------------+--------------------------------- Frequently I noticed that my iMac G5 will go to sleep during a time extensive build (gcc45 at the moment). I googled and found some other people with that problem - and an easy solution: {{{ #!/bin/bash pmset noidle & <<<... do the work here ...>>> kill %pmset }}} Wouldnt it be smart to put the "noidle" command at the very beginning of any build script - and the "kill %pmset" at the very ending? I'd like the iMac to do the building - and then go to sleep after it's finished if nothing else is to do. -- Ticket URL: <https://trac.macports.org/ticket/33719> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 9

[MacPorts] #16373: svn fetch type should maintain a persistent working copy
by MacPorts 20 Aug '14

20 Aug '14

#16373: svn fetch type should maintain a persistent working copy -------------------------------------+-------------------------------------- Reporter: ryandesign(a)macports.org | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: 1.7.0 Keywords: | -------------------------------------+-------------------------------------- "`fetch.type svn`" is inefficient in that it checks out a new working copy every time, directly to the work area. That would be like a normal port downloading the distfile every time. Instead, we should check out a working copy to that port's distpath, and then in the extract phase we should `svn export` it to the work area. Some checks will be needed in the fetch phase to ensure that an existing working copy: * has no modifications: check `svn status`. Ideally we would try to clean up the working copy, for example by `svn revert`ing modified or added or deleted files, and then in a second `svn status` run, delete any unversioned files. But it's already an improvement if we just discard the working copy if `svn status --ignore-externals` produces any output. * is from the right URL: check `svn info`: check if the "URL" is the one we want. If not, check that the "Repository Root" is a substring of the repository we want. If yes, try to `svn switch` to the URL and revision we want; if not, discard the working copy. So the fetch phase would go something like... {{{ if {working copy exists} { if {working copy has modifications} { delete working copy } } if {working copy exists} { if {working copy url is the one we want} { svn update to the desired revision } else { if {working copy repository root matches beginning of desired url} { try to svn switch to the desired url and revision if {an error occurred} { delete working copy } } else { delete working copy } } } if {working copy doesn't exist} { check out working copy } }}} And the extract phase is simply to `svn export` the working copy from the distpath to the worksrcpath. (There is [http://subversion.tigris.org/issues/show_bug.cgi?id=2429 one problem] if the working copy has externals and the user is using Subversion earlier than 1.5, for example Subversion 1.4.whatever which is included with Leopard. But rather than spend time working around this in base, I think this is a case where the port should depend on MacPorts subversion.) -- Ticket URL: <http://trac.macports.org/ticket/16373> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 21

[MacPorts] #26743: googlecl @0.9.10_0, osxutils @1.7_1 attempt to install conflicting bin/google
by MacPorts 20 Aug '14

20 Aug '14

#26743: googlecl @0.9.10_0, osxutils @1.7_1 attempt to install conflicting bin/google -----------------------------------+---------------------------------------- Reporter: jpenney@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Keywords: | Port: googlecl osxutils -----------------------------------+---------------------------------------- googlecl and osxutils both install attempt to install bin/google, causing whichever port is activated second to fail. I'd like to have both of these packages installed. Could a +no_google variant be added to osxutils perhaps? -- Ticket URL: <https://trac.macports.org/ticket/26743> MacPorts <http://www.macports.org/> Ports system for Mac OS

1 5