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

Re: [MacPorts] #13026: emacs and emacs-devel won't install on Mac OS X 10.5 Leopard
by MacPorts 30 Nov '07

30 Nov '07

#13026: emacs and emacs-devel won't install on Mac OS X 10.5 Leopard ----------------------------------+----------------------------------------- Reporter: econnally(a)gmail.com | Owner: darren.bane(a)gmail.com Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.5.0 Resolution: | Keywords: emacs ----------------------------------+----------------------------------------- Comment (by darren.bane(a)gmail.com) I tried this patch but it didn't work for me. However, one attached to bug #13294 does work, hopefully the port update will be checked in soon. -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/13026#comment:4> MacPorts </projects/macports> Ports system for Mac OS

1 0

Re: [MacPorts] #13294: emacs 22.1 fails to build on Mac OS X 10.5 Leopard
by MacPorts 30 Nov '07

30 Nov '07

#13294: emacs 22.1 fails to build on Mac OS X 10.5 Leopard ----------------------------------+----------------------------------------- Reporter: queshaw(a)pacbell.net | Owner: macports-dev(a)lists.macosforge.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.5.0 Resolution: | Keywords: emacs ----------------------------------+----------------------------------------- Comment (by darren.bane(a)gmail.com) Sorry for the delay, I was confusing this bug with my #13026, which I had previously rejected as not fixing the problem. I can confirm that the attached patch fixes Emacs for Leopard, at least on PPC. Thanks for helping out guys, I'm more of a UNIX guy, and it looks like maintaining Emacs is a job for a Lisp wizard ;-) -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/13294#comment:4> MacPorts </projects/macports> Ports system for Mac OS

1 0

doxygen "file not found"
by Preben 29 Nov '07

29 Nov '07

I get an error each time I try to install doxygen. It's not available! / Preben

1 0

Re: [MacPorts] #12883: clisp will not build on 10.4.10, Core2 Duo MacBook Pro
by MacPorts 29 Nov '07

29 Nov '07

#12883: clisp will not build on 10.4.10, Core2 Duo MacBook Pro ---------------------------------+------------------------------------------ Reporter: jwiegley(a)gmail.com | Owner: eridius(a)macports.org Type: defect | Status: new Priority: High | Milestone: Port Bugs Component: ports | Version: 1.5.2 Resolution: | Keywords: ---------------------------------+------------------------------------------ Comment (by ebgssth(a)gmail.com) don't build on 10.3.9 either. {{{ cc -O -O -DUNICODE -DNO_SIGSEGV -I. -c spvw.c In file included from spvw.d:24: lispbibl.d:9501:27: libintl.h: No such file or directory In file included from spvw.d:550: spvw_sigwinch.d:24:33: readline/readline.h: No such file or directory spvw.d: In function `getSP': spvw.d:643: warning: function returns address of local variable In file included from spvw.d:667: spvw_language.d: In function `clgettext': spvw_language.d:255: warning: assignment makes pointer from integer without a cast spvw_language.d: In function `clgettextl': spvw_language.d:271: warning: assignment makes pointer from integer without a cast make: *** [spvw.o] Error 1 Warning: the following items did not execute (for clisp): org.macports.activate org.macports.build org.macports.destroot org.macports.install Error: Status 1 encountered during processing. }}} -- Ticket URL: <http://trac.macports.org/projects/macports/ticket/12883#comment:3> MacPorts </projects/macports> Ports system for Mac OS

1 0

Re: [MacPorts] #12130: RFE: .pkg installer should set the MANPATH
by MacPorts 29 Nov '07

29 Nov '07

#12130: RFE: .pkg installer should set the MANPATH ------------------------------+--------------------------------------------- Reporter: emix(a)solira.org | Owner: macports-dev(a)lists.macosforge.org Type: enhancement | Status: closed Priority: Normal | Milestone: Component: base | Version: Resolution: invalid | Keywords: installer manpath ------------------------------+--------------------------------------------- Changes (by jmpp(a)macports.org) * milestone: MacPorts 1.5 => Old description: > After the installation of MacPorts via the .pkg, the command "man port" > returns "No manual entry for port". I think that the MANPATH should be > set using the postflight script, adding this in ".profile" file: > > export MANPATH=/opt/local/man:$MANPATH New description: After the installation of MacPorts via the .pkg, the command "man port" returns "No manual entry for port". I think that the MANPATH should be set using the postflight script, adding this in ".profile" file: {{{ export MANPATH=/opt/local/man:$MANPATH }}} -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/12130#comment:7> MacPorts </projects/macports> Ports system for Mac OS

1 0

Re: [MacPorts] #12130: RFE: .pkg installer should set the MANPATH
by MacPorts 29 Nov '07

29 Nov '07

#12130: RFE: .pkg installer should set the MANPATH ------------------------------+--------------------------------------------- Reporter: emix(a)solira.org | Owner: macports-dev(a)lists.macosforge.org Type: enhancement | Status: closed Priority: Normal | Milestone: MacPorts 1.5 Component: base | Version: Resolution: invalid | Keywords: installer manpath ------------------------------+--------------------------------------------- Changes (by jmpp(a)macports.org) * status: new => closed * resolution: => invalid Comment: Both Tiger and Leopard should find man pages under our installation prefix just fine if the `$PATH` variable already contains the path to our binaries, which is something we already take care of in the `base/portmgr/dmg/postflight` script. The only platform in which we would probably have to do something is Panther, but, for one, we don't actively support that platform any longer and, last but not least, it's getting increasingly difficult coming by someone with a Panther box to do some testing. Therefore I'm closing this ticket as invalid. If someone with a Panther box wants to suggest an enhancement to `base/portmgr/dmg/postflight` to easily find our man pages there, then I'd be happy to accept it provided it doesn't break anything for Leopard & Tiger. -jmpp -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/12130#comment:6> MacPorts </projects/macports> Ports system for Mac OS

1 0

Re: [MacPorts] #1068: Pre/Post-install and Post-removal scripts
by MacPorts 29 Nov '07

29 Nov '07

#1068: Pre/Post-install and Post-removal scripts -----------------------------------+---------------------------------------- Reporter: jdputsch(a)comcast.net | Owner: macports-tickets(a)lists.macosforge.org Type: enhancement | Status: new Priority: Normal | Milestone: MacPorts base enhancements Component: base | Version: Resolution: | Keywords: -----------------------------------+---------------------------------------- Old description: > It seems to me that Darwin Ports needs to have a script that runs after > the install action. Let me > explain why: > > Take, for example, a port that installs info files into > /opt/local/share/info using the "install-info" > script. This script copies the info files to destination AND modifies the > info directory file (/opt/ > local/share/info/dir). > Now the normal flow goes something like this: > > port build > port destroot # info files goto > ..../work/destroot/opt/local/share/info > # and the .../work/destroot/opt/local/share/info/dir > file > # is modified to add the entries. > port install > > After the "port install" step the "dir" file containing ONLY entries for > the newly built/installed port > is copied to /opt/local/share/info/dir. This wipes out any entries that > may have previously been > there. I don't think this is the behavior we want. > > In addition if "port package" is run during this process a package is > built that will install a "dir" file > that only knows about the info files for that package. I don't believe > this is proper behavior either. > > I believe in both cases the proper thing to have happen is to have a post > install action take place > that makes sure the proper "dir" file is in place. > If packages were never built this could be taken care of entirely in the > Portfile. Unfortunately, I feel > packages should do the right thing too and only add their info files to > /opt/local/share/info/dir > and not replace that file with their idea of what that file should be. I > don't see any way to > accomplish that without taking advantage of the "postinstall" or > "postflight" scripts that Apple > allows packages to have. See > http://developer.apple.com/documentation/DeveloperTools/Conceptual/Software… > Concepts/sd_pre_post_processing.html > for more information. > > In fact, I'd like to propose two files be added to ports directories: > "files/preinstall" and "files/ > postinstall". These files, if present, are run just before the "port > install" action and just after it > respectively. When building packages, these scripts would be put into the > proper place in the > package so they can achieve the same results as they would if run via the > "port ..." command. > > Basically, the port directory with these files would look like this: > > Portfile > files/postinstall > files/preinstall > > I believe that, when combined with actions such as post-destroot, these > scripts would be allow > ports to be constructed that do the right thing regardless of their > installation order AND build > packages that do the right thing regardless of their installation order. > > I realize I've stressed the "info" files here, they are a concrete > example of why I feel this feature > needs to be added and supported. I'm sure others will be found. > > I also realized that a "postremove" (and maybe) a "preremove" script are > needed to so packages > clean up after themselves when removed. Sticking with the earlier "info" > example ${prefix}/share/ > info/dir is edited by the "postinstall" script. When a package is > removed, those edits need to be > undone. > > It was very easy to add a "postremove" script to the package DarwinPorts > builds and modify the > uninstall.tcl script used by the Uninstaller.app. I don't know how to do > the same thing with the > current receipts system for "port install"/"port remove". I know I can > put tcl code to be executed > post-remove in there, but I think it's better to have one source for > these actions and any package > built by DarwinPorts needs to have scripts since they become decoupled > from the ports system > itself. New description: It seems to me that Darwin Ports needs to have a script that runs after the install action. Let me explain why: Take, for example, a port that installs info files into /opt/local/share/info using the "install-info" script. This script copies the info files to destination AND modifies the info directory file (/opt/ local/share/info/dir). Now the normal flow goes something like this: port build port destroot # info files goto ..../work/destroot/opt/local/share/info # and the .../work/destroot/opt/local/share/info/dir file # is modified to add the entries. port install After the "port install" step the "dir" file containing ONLY entries for the newly built/installed port is copied to /opt/local/share/info/dir. This wipes out any entries that may have previously been there. I don't think this is the behavior we want. In addition if "port package" is run during this process a package is built that will install a "dir" file that only knows about the info files for that package. I don't believe this is proper behavior either. I believe in both cases the proper thing to have happen is to have a post install action take place that makes sure the proper "dir" file is in place. If packages were never built this could be taken care of entirely in the Portfile. Unfortunately, I feel packages should do the right thing too and only add their info files to /opt/local/share/info/dir and not replace that file with their idea of what that file should be. I don't see any way to accomplish that without taking advantage of the "postinstall" or "postflight" scripts that Apple allows packages to have. See http://developer.apple.com/documentation/DeveloperTools/Conceptual/Software… Concepts/sd_pre_post_processing.html for more information. In fact, I'd like to propose two files be added to ports directories: "files/preinstall" and "files/ postinstall". These files, if present, are run just before the "port install" action and just after it respectively. When building packages, these scripts would be put into the proper place in the package so they can achieve the same results as they would if run via the "port ..." command. Basically, the port directory with these files would look like this: Portfile files/postinstall files/preinstall I believe that, when combined with actions such as post-destroot, these scripts would be allow ports to be constructed that do the right thing regardless of their installation order AND build packages that do the right thing regardless of their installation order. I realize I've stressed the "info" files here, they are a concrete example of why I feel this feature needs to be added and supported. I'm sure others will be found. I also realized that a "postremove" (and maybe) a "preremove" script are needed to so packages clean up after themselves when removed. Sticking with the earlier "info" example ${prefix}/share/ info/dir is edited by the "postinstall" script. When a package is removed, those edits need to be undone. It was very easy to add a "postremove" script to the package DarwinPorts builds and modify the uninstall.tcl script used by the Uninstaller.app. I don't know how to do the same thing with the current receipts system for "port install"/"port remove". I know I can put tcl code to be executed post-remove in there, but I think it's better to have one source for these actions and any package built by DarwinPorts needs to have scripts since they become decoupled from the ports system itself. Comment (by jmpp(a)macports.org) This ticket is sorely out of date and many thing have changed since, specially with respect to the info files which we've been pruning from our destroots for a long while already. I'm nevertheless going to leave the ticket open, as it does contain some interesting suggestions for pre/post- installation/uninstallation scripts. -jmpp -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/1068#comment:4> MacPorts </projects/macports> Ports system for Mac OS

1 0

[MacPorts] #13417: BUG: gcc42 @4.2.2_0: fails to install on leopard/ppc
by MacPorts 29 Nov '07

29 Nov '07

#13417: BUG: gcc42 @4.2.2_0: fails to install on leopard/ppc -----------------------------------+---------------------------------------- Reporter: takanori(a)macports.org | Owner: mww(a)macports.org Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: Keywords: | -----------------------------------+---------------------------------------- {{{ ---> Fetching gcc42 ---> Attempting to fetch gcc-core-4.2.2.tar.bz2 from ftp://ftp.funet.fi/pub/mirrors/sources.redhat.com/pub/gcc/releases/gcc-4.2.… ---> Attempting to fetch gcc-fortran-4.2.2.tar.bz2 from ftp://ftp.funet.fi/pub/mirrors/sources.redhat.com/pub/gcc/releases/gcc-4.2.… ---> Attempting to fetch gcc-g++-4.2.2.tar.bz2 from ftp://ftp.funet.fi/pub/mirrors/sources.redhat.com/pub/gcc/releases/gcc-4.2.… ---> Attempting to fetch gcc-java-4.2.2.tar.bz2 from ftp://ftp.funet.fi/pub/mirrors/sources.redhat.com/pub/gcc/releases/gcc-4.2.… ---> Attempting to fetch gcc-objc-4.2.2.tar.bz2 from ftp://ftp.funet.fi/pub/mirrors/sources.redhat.com/pub/gcc/releases/gcc-4.2.… ---> Verifying checksum(s) for gcc42 ---> Extracting gcc42 ---> Configuring gcc42 ---> Building gcc42 with target bootstrap ---> Staging gcc42 into destroot Error: Target org.macports.destroot returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_gcc42/work/destroot/opt/local/include/gcc42 && cp ../../lib/gcc42/gcc/*/4.2.2/include/ffitarget.h ." returned error 1 Command output: cp: ../../lib/gcc42/gcc/*/4.2.2/include/ffitarget.h: No such file or directory }}} That's because if gcj is not installed, libffi is also not installed. -- Ticket URL: <https://trac.macports.org/projects/macports/ticket/13417> MacPorts </projects/macports> Ports system for Mac OS

1 1

Re: [MacPorts] #13042: bazaar don't build on Leopard
by MacPorts 28 Nov '07

28 Nov '07

#13042: bazaar don't build on Leopard ----------------------------------+----------------------------------------- Reporter: saispo(a)mandriva.org | Owner: josh-macports(a)root.id.au Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.5.2 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by josh-macports(a)root.id.au) All of those archive-pfs.c warnings happen during a working build. Please either find and post the actual error message from the compiler, or just attach a full build log. (sudo port -v build bazaar > build.log) -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/13042#comment:4> MacPorts </projects/macports> Ports system for Mac OS

1 0

Re: [MacPorts] #13042: bazaar don't build on Leopard
by MacPorts 28 Nov '07

28 Nov '07

#13042: bazaar don't build on Leopard ----------------------------------+----------------------------------------- Reporter: saispo(a)mandriva.org | Owner: josh-macports(a)root.id.au Type: defect | Status: new Priority: Normal | Milestone: Port Bugs Component: ports | Version: 1.5.2 Resolution: | Keywords: ----------------------------------+----------------------------------------- Comment (by saispo(a)macports.org) Yep i have Xcode 3.0 and i build it on a x86 macbook... i try after a fresh reinstall and have the same error... maybe a dependancy is missing ? -- Ticket URL: <http://trac.macosforge.org/projects/macports/ticket/13042#comment:3> MacPorts </projects/macports> Ports system for Mac OS

1 0