Re: imake
On Sep 27, 2014, at 11:37 PM, Joshua Root wrote: On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? It would match how we handle other build systems like xcodebuild and cmake. It is inconsistent that MacPorts base contains special support for imake, and especially since imake is obsolete, it makes sense to me to move it out of base into a portgroup so it doesn't clutter up base. https://trac.macports.org/ticket/42547 is mostly not helpful, but does point out that the hardcoded value of IMAKECPP set by base is a problem here because we need to override it for Xcode 5 and there's currently no way to do so while using use_xmkmf yes because base sets it directly in configure_main. Moving this code to a portgroup would make it possible for us to fix this problem and any other problems that might come up later without having to produce a new MacPorts release. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? Affected platforms is Xcode 5 and later, which we don't have a clean way to model. We can check $xcodeversion, yes, but consider a case where a Mavericks user installs the imake port while using Xcode 4, and therefore doesn't get the gcc dependency because it's not needed, and later upgrades to Xcode 5, and now needs the gcc dependency but won't get it unless they rebuild imake, which they won't know to do. There's a bunch of other stuff needed to build properly with imake, even above and beyond what's currently in base. We're missing all the things that are usually missing when one doesn't autotools -- using the right compiler, using arch flags, having a working universal variant, supporting the requested cxx_stdlib. Code to support all of this can go into the new portgroup, where it's not an inconvenience for the gcc dependency to go so that every time the user builds a port with imake, the gcc dependency can be added if the version of Xcode installed at that moment needs it. If we come up with a better solution later that doesn't involve needing the big gcc dependency, great, we can improve it then. I'm just tired of this problem and want to make *something* that works, rather than what we currently have where all imake-using ports are broken with Xcode 5 or later. Some of those are dependencies of software I maintain so I'm eager to resolve this. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
no space left on buildports-lion-x86_64
Hi, The build initiated by https://trac.macports.org/changeset/125857 caused a disk overflow of the buildbot for Lion. https://build.macports.org/builders/buildports-lion-x86_64/builds/23545 Could someone fix the buildbot? Thanks Takeshi - Takeshi Enomoto take...@macports.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
no space left on buildports-lion-x86_64
Hi, The build initiated by https://trac.macports.org/changeset/125857 caused a disk overflow of the buildbot for Lion. https://build.macports.org/builders/buildports-lion-x86_64/builds/23545 Could someone fix the buildbot? Thanks Takeshi - Takeshi Enomoto take...@macports.org - Takeshi Enomoto take...@macports.org ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: no space left on buildports-lion-x86_64
On Sep 28, 2014, at 2:18 AM, Takeshi Enomoto wrote: The build initiated by https://trac.macports.org/changeset/125857 caused a disk overflow of the buildbot for Lion. https://build.macports.org/builders/buildports-lion-x86_64/builds/23545 Could someone fix the buildbot? Takeshi, only admin at macosforge dot org can do that. I'm Cc'ing them on this email. Shree, this issue has come up a lot lately. Were you ever able to determine if there's something strange taking up space, or is it just that we have so many packages now that we need more disk space on the builders to keep them all installed? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-28 16:55 , Ryan Schmidt wrote: On Sep 27, 2014, at 11:37 PM, Joshua Root wrote: On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? It would match how we handle other build systems like xcodebuild and cmake. It is inconsistent that MacPorts base contains special support for imake, and especially since imake is obsolete, it makes sense to me to move it out of base into a portgroup so it doesn't clutter up base. https://trac.macports.org/ticket/42547 is mostly not helpful, but does point out that the hardcoded value of IMAKECPP set by base is a problem here because we need to override it for Xcode 5 and there's currently no way to do so while using use_xmkmf yes because base sets it directly in configure_main. Moving this code to a portgroup would make it possible for us to fix this problem and any other problems that might come up later without having to produce a new MacPorts release. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? Affected platforms is Xcode 5 and later, which we don't have a clean way to model. We can check $xcodeversion, yes, but consider a case where a Mavericks user installs the imake port while using Xcode 4, and therefore doesn't get the gcc dependency because it's not needed, and later upgrades to Xcode 5, and now needs the gcc dependency but won't get it unless they rebuild imake, which they won't know to do. So you could at least use llvm-gcc42 on 10.8 and 10.9 then, and gcc49 on 10.10+. There's a bunch of other stuff needed to build properly with imake, even above and beyond what's currently in base. We're missing all the things that are usually missing when one doesn't autotools -- using the right compiler, using arch flags, having a working universal variant, supporting the requested cxx_stdlib. Code to support all of this can go into the new portgroup, where it's not an inconvenience for the gcc dependency to go so that every time the user builds a port with imake, the gcc dependency can be added if the version of Xcode installed at that moment needs it. If I were going there, I wouldn't start here. If you want the programs to build right, put your effort into moving them off of imake. Most of them aren't very big. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
Hi, - On 28 Sep, 2014, at 04:15, Ryan Schmidt ryandes...@macports.org wrote: My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. You could try using /usr/bin/clang -E -undef -traditional -Wno-invalid-pp-token -Wno-unicode -Wno-trigraphs -x assembler-with-cpp as preprocessor. That's what GHC uses to preprocess its non-C macros, and it works there. I wouldn't be surprised if it didn't work for you, but I guess it's worth a shot. -- Clemens Lang ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 5:22 AM, Clemens Lang c...@macports.org wrote: as preprocessor. That's what GHC uses to preprocess its non-C macros, and it works there. Mostly works. There are still cases where you can't turn off the implicit dependency on C tokens, as I outlined previously. GHC 7.10 is moving away from relying on a C compiler to provide a usable preprocessor entirely because of this. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
configure.cmd
What are the limitations on the configure.cmd variable? I tried
configure.cmd ./configure ${configure.pre_args} --with-csl ;
./configure --with-psl
but port didn't like that. I ended up with
configure.args-append --with-csl
# Need to run the configure script twice, once with --with-csl and any
# other relevent options and once with --with-psl and any relevant PSL
# options. After that use make and both systems should be made.
post-configure {
configure.args-replace --with-csl --with-psl
system -W ${worksrcpath} ${configure.cmd}\
${configure.pre_args}\
${configure.args}\
CC=${configure.cc}\
CXX=${configure.cxx}
}
This is according to the source documentation. I've tested it and it does work.
Mark
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: configure.cmd
On Sep 28, 2014, at 1:25 PM, Mark Brethen wrote:
What are the limitations on the configure.cmd variable? I tried
configure.cmd ./configure ${configure.pre_args} --with-csl ;
./configure --with-psl
but port didn't like that.
configure.cmd (and, more generally, any *.cmd) is designed to specify the
relative or absolute path to a program to run. Any arguments to that command
are meant to be specified in *.args, *.pre_args and *.post_args. It's not
intended to be used to run more than one command.
I ended up with
configure.args-append --with-csl
# Need to run the configure script twice, once with --with-csl and any
# other relevent options and once with --with-psl and any relevant PSL
# options. After that use make and both systems should be made.
post-configure {
configure.args-replace --with-csl --with-psl
system -W ${worksrcpath} ${configure.cmd}\
${configure.pre_args}\
${configure.args}\
CC=${configure.cc}\
CXX=${configure.cxx}
}
This is according to the source documentation. I've tested it and it does
work.
That looks good. Bear in mind though that the configure phase sets many
environment variables. You're setting CC and CXX here as arguments, which might
be equivalent in this case to having them set in the environment, but there are
other variables which you're not setting and that might adversely affect the
build.
Hopefully the developers can fix their configure script so that in the future
it will only need a single invocation.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 2:41 AM, Joshua Root wrote: On 2014-9-28 16:55 , Ryan Schmidt wrote: On Sep 27, 2014, at 11:37 PM, Joshua Root wrote: On 2014-9-28 12:15 , Ryan Schmidt wrote: In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. Why? It would match how we handle other build systems like xcodebuild and cmake. It is inconsistent that MacPorts base contains special support for imake, and especially since imake is obsolete, it makes sense to me to move it out of base into a portgroup so it doesn't clutter up base. https://trac.macports.org/ticket/42547 is mostly not helpful, but does point out that the hardcoded value of IMAKECPP set by base is a problem here because we need to override it for Xcode 5 and there's currently no way to do so while using use_xmkmf yes because base sets it directly in configure_main. Moving this code to a portgroup would make it possible for us to fix this problem and any other problems that might come up later without having to produce a new MacPorts release. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. What's wrong with adding the dependency to the imake port on the affected platforms? Affected platforms is Xcode 5 and later, which we don't have a clean way to model. We can check $xcodeversion, yes, but consider a case where a Mavericks user installs the imake port while using Xcode 4, and therefore doesn't get the gcc dependency because it's not needed, and later upgrades to Xcode 5, and now needs the gcc dependency but won't get it unless they rebuild imake, which they won't know to do. So you could at least use llvm-gcc42 on 10.8 and 10.9 then, and gcc49 on 10.10+. You mean using the macports llvm-gcc42 port instead of the gcc49 port? Sure, we could that. It is a much smaller package. There's a bunch of other stuff needed to build properly with imake, even above and beyond what's currently in base. We're missing all the things that are usually missing when one doesn't autotools -- using the right compiler, using arch flags, having a working universal variant, supporting the requested cxx_stdlib. Code to support all of this can go into the new portgroup, where it's not an inconvenience for the gcc dependency to go so that every time the user builds a port with imake, the gcc dependency can be added if the version of Xcode installed at that moment needs it. If I were going there, I wouldn't start here. If you want the programs to build right, put your effort into moving them off of imake. Most of them aren't very big. I'm not sure I know how to do that. I have no experience with these packages' build systems or with imake, and although I can write a basic Makefile, I haven't ever written anything using autotools or cmake or similar. If the developers of those programs want to switch to those systems, that would be great, but I don't consider it my job to rewrite their configuration system for them. But I'm hopeful that I'm able to accomplish writing a xmkmf portgroup that would work. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: configure.cmd
On Sep 28, 2014, at 7:07 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Sep 28, 2014, at 1:25 PM, Mark Brethen wrote:
What are the limitations on the configure.cmd variable? I tried
configure.cmd ./configure ${configure.pre_args} --with-csl ;
./configure --with-psl
but port didn't like that.
configure.cmd (and, more generally, any *.cmd) is designed to specify the
relative or absolute path to a program to run. Any arguments to that command
are meant to be specified in *.args, *.pre_args and *.post_args. It's not
intended to be used to run more than one command.
I ended up with
configure.args-append --with-csl
# Need to run the configure script twice, once with --with-csl and any
# other relevent options and once with --with-psl and any relevant PSL
# options. After that use make and both systems should be made.
post-configure {
configure.args-replace --with-csl --with-psl
system -W ${worksrcpath} ${configure.cmd}\
${configure.pre_args}\
${configure.args}\
CC=${configure.cc}\
CXX=${configure.cxx}
}
This is according to the source documentation. I've tested it and it does
work.
That looks good. Bear in mind though that the configure phase sets many
environment variables. You're setting CC and CXX here as arguments, which
might be equivalent in this case to having them set in the environment, but
there are other variables which you're not setting and that might adversely
affect the build.
Hopefully the developers can fix their configure script so that in the future
it will only need a single invocation.
The config log looks like pretty basic stuff; probably why it works.
## --- ##
## Core tests. ##
## --- ##
configure:1779: checking build system type
configure:1793: result: x86_64-apple-darwin13.3.0
configure:1813: checking host system type
configure:1826: result: x86_64-apple-darwin13.3.0
configure:1865: checking for a BSD-compatible install
configure:1933: result: /usr/bin/install -c
configure:1944: checking whether build environment is sane
configure:1999: result: yes
configure:2150: checking for a thread-safe mkdir -p
configure:2189: result:
/opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/psl/../install-sh
-c -d
configure:2196: checking for gawk
configure:2212: found /opt/local/bin/gawk
configure:2223: result: gawk
configure:2234: checking whether make sets $(MAKE)
configure:2256: result: yes
configure:2285: checking whether make supports nested variables
configure:2302: result: yes
configure:2435: checking for cygpath
configure:2465: result: no
configure:2527: Build platform specified as
x86_64-mac_10.9_mavericks-darwin13.3.0
configure:2578: Will build this PSL using the macintel64 initial binaries
configure:2777: checking that generated files are newer than configure
configure:2783: result: done
configure:2799: creating ./config.status
## ##
## Cache variables. ##
## ##
ac_cv_build=x86_64-apple-darwin13.3.0
ac_cv_env_build_alias_set=
ac_cv_env_build_alias_value=
ac_cv_env_host_alias_set=
ac_cv_env_host_alias_value=
ac_cv_env_target_alias_set=
ac_cv_env_target_alias_value=
ac_cv_host=x86_64-apple-darwin13.3.0
ac_cv_path_install='/usr/bin/install -c'
ac_cv_prog_AWK=gawk
ac_cv_prog_make_make_set=yes
am_cv_make_support_nested_variables=yes
## - ##
## Output variables. ##
## - ##
ACLOCAL='${SHELL}
/opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/missing
aclocal-1.14'
AMTAR='$${TAR-tar}'
AM_BACKSLASH='\'
AM_DEFAULT_V='$(AM_DEFAULT_VERBOSITY)'
AM_DEFAULT_VERBOSITY='1'
AM_V='$(V)'
AUTOCONF='${SHELL}
/opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/missing
autoconf'
AUTOHEADER='${SHELL}
/opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/missing
autoheader'
AUTOMAKE='${SHELL}
/opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/missing
automake-1.14'
AWK='gawk'
BUILD='x86_64-mac_10.9_mavericks-darwin13.3.0'
CYGPATH='no'
CYGPATH_W='echo'
DEFS='-DPACKAGE_NAME=\PSL\ -DPACKAGE_TARNAME=\psl\
-DPACKAGE_VERSION=\20080915\ -DPACKAGE_STRING=\PSL\ 20080915\
-DPACKAGE_BUGREPORT=\em...@maintainer.org\ -DPACKAGE_URL=\\
-DPACKAGE=\psl\ -DVERSION=\20080915\'
ECHO_C='\c'
ECHO_N=''
ECHO_T=''
INSTALL_DATA='${INSTALL} -m 644'
INSTALL_PROGRAM='${INSTALL}'
INSTALL_SCRIPT='${INSTALL}'
INSTALL_STRIP_PROGRAM='$(install_sh) -c -s'
LIBOBJS=''
LIBS=''
LTLIBOBJS=''
MAKEINFO='${SHELL}
/opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/missing
makeinfo'
Re: configure.cmd
On Sep 28, 2014, at 7:29 PM, Mark Brethen wrote: The config log looks like pretty basic stuff; probably why it works. I don't doubt that it works for you in the situation you tested; I'm worried that it might not support all the features MacPorts is providing by setting those various environment variables. For example, MacPorts sets CC and CXX as environment variables during the normal configure phase, but during your post-configure block, you're setting CC and CXX as configure.args. Why? Does the configure script forget the values of CC and CXX from the first run and go back to its defaults on the second run? If so, are you sure that only applies to CC and CXX, or might it also apply to CFLAGS, CXXFLAGS, LDFLAGS, and the other variables MacPorts uses? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
Why don't we just remove xorg-cf-files, imake, and all dependent ports? Obviously any project still using imake a decade after the build system was declared dead are themselves not well maintained projects and I argue should not be in our port repository. These are the ports that depend on the archaic build system: spim ivtools magicpoint tgif xfig kdebase3 transfig arb rasmol openvas-server canna emiclock fvwm kinput2 kxterm sunclock tightvnc vtwm wmclock xcb xearth xmove xsnow xspringies xtu --Jeremy On Sep 27, 2014, at 19:15, Ryan Schmidt ryandes...@macports.org wrote: I'm going to try to work on the imake problem, specifically that ports using imake fail with Xcode 5 and up because they require a cpp with traditional cpp support which clang doesn't have. In the process I plan to create an xmkmf portgroup to replace the use_xmkmf keyword in base. My proposal is to have this portgroup depend on the latest stable gcc port (currently gcc49) and have it use its cpp in IMAKECPP when the Xcode version is 5 or greater. I tried this with one port already and was able to build it on Yosemite beta. Let me know if you have any objections to this proposal or if you have other ideas how to solve this problem. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 7:42 PM, Jeremy Huddleston Sequoia wrote: Why don't we just remove xorg-cf-files, imake, and all dependent ports? Obviously any project still using imake a decade after the build system was declared dead are themselves not well maintained projects and I argue should not be in our port repository. These are the ports that depend on the archaic build system: spim ivtools magicpoint tgif xfig kdebase3 transfig arb rasmol openvas-server canna emiclock fvwm kinput2 kxterm sunclock tightvnc vtwm wmclock xcb xearth xmove xsnow xspringies xtu I don't plan to remove these ports. I cannot speak for all of them, but as I said earlier, some of the ports I maintain depend on some of the above ports. In particular, pure-octave depends on octave which depends on transfig. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 17:44, Ryan Schmidt ryandes...@macports.org wrote: On Sep 28, 2014, at 7:42 PM, Jeremy Huddleston Sequoia wrote: Why don't we just remove xorg-cf-files, imake, and all dependent ports? Obviously any project still using imake a decade after the build system was declared dead are themselves not well maintained projects and I argue should not be in our port repository. These are the ports that depend on the archaic build system: I don't plan to remove these ports. I cannot speak for all of them, but as I said earlier, some of the ports I maintain depend on some of the above ports. In particular, pure-octave depends on octave which depends on transfig. Then let's fix transfig (or just remove the imake-dependent portions of it). ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: configure.cmd
On Sep 28, 2014, at 7:39 PM, Ryan Schmidt ryandes...@macports.org wrote: On Sep 28, 2014, at 7:29 PM, Mark Brethen wrote: The config log looks like pretty basic stuff; probably why it works. I don't doubt that it works for you in the situation you tested; I'm worried that it might not support all the features MacPorts is providing by setting those various environment variables. For example, MacPorts sets CC and CXX as environment variables during the normal configure phase, but during your post-configure block, you're setting CC and CXX as configure.args. Why? Does the configure script forget the values of CC and CXX from the first run and go back to its defaults on the second run? If so, are you sure that only applies to CC and CXX, or might it also apply to CFLAGS, CXXFLAGS, LDFLAGS, and the other variables MacPorts uses? The invoked configure for the first run was: $ /opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/configure --prefix=/opt/local --with-csl CPPFLAGS=-I/opt/local/include CFLAGS=-pipe -Os -arch x86_64 CXXFLAGS=-pipe -Os -arch x86_64 -stdlib=libc++ LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -arch x86_64 LIBS= CC=/usr/bin/clang CPP= CXX=/usr/bin/clang++ CXXCPP= --with-build=x86_64-mac_10.9_mavericks-darwin13.3.0 --with-pslbuild= --no-create --no-recursion And for the second run: $ /opt/local/var/macports/build/_Users_marbre_ports_math_reduce-algebra/reduce-algebra/work/trunk/psl/configure --prefix=/opt/local --with-psl CC=/usr/bin/clang CXX=/usr/bin/clang++ --with-build=x86_64-mac_10.9_mavericks-darwin13.3.0 --no-create --no-recursion Initially the prefix was set to /usr/local on the second run, so you are probably correct that it forgets the values. Adding the flag and ld env variables caused it to fail, however it accepts the CC and CXX variables. Mark ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: sunclock - No upstream any more Possibly the site is just down at the moment; I remember looking at it not that long ago. FreeBSD updated to a new upstream release in 2013. They are not using imake to build it, but a Makefile.noimake which is provided in the release. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: xcb - No upstream(?), upstream 505s, port last updated in 2009 The homepage listed in the port redirected to http://oldhome.schmorp.de/marc/xcb.html for a while. - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 11:21 PM, Jeremy Huddleston Sequoia jerem...@apple.com wrote: If I hear no objections in the next few days, I'll remove the ports in that first group. If nobody speaks up, I think we should nuke KDE3 in a few weeks. If I understood other discussions correctly, KDE3 is already being removed. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: tgif - Upstream no longer exists, shipped version was released in 2001 Just need to remove the port number from the homepage URL. http://bourbon.usc.edu/tgif/ Latest release was 2011: http://bourbon.usc.edu/tgif/relnotes/ rasmol - Packaged version released in 2008, latest release was in 2009 This is probably used by some of our scientist users. There does seem to be a 2.7.5.2 release from 2011, and more files added to their sourceforge site in 2013. So certainly not dead. (Probably just developed by academics in their spare time, like many such tools.) - Josh ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com wrote: If I understood other discussions correctly, KDE3 is already being removed. Sorry, not discussions; recent commit messages indicate that it's being obsoleted and slated for removal starting from the leaves. See for example r125868, r125871. -- brandon s allbery kf8nh sine nomine associates allber...@gmail.com ballb...@sinenomine.net unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
On Sep 28, 2014, at 20:58, Joshua Root j...@macports.org wrote: On 2014-9-29 13:21 , Jeremy Huddleston Sequoia wrote: tgif - Upstream no longer exists, shipped version was released in 2001 Just need to remove the port number from the homepage URL. http://bourbon.usc.edu/tgif/ Latest release was 2011: http://bourbon.usc.edu/tgif/relnotes/ Here's a possible patch to latest. tgif.patch Description: Binary data ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [125902] trunk/dports/science/arb/Portfile
On Sep 28, 2014, at 10:32 PM, jerem...@macports.org wrote:
Revision
125902
Author
jerem...@macports.org
Date
2014-09-28 20:32:20 -0700 (Sun, 28 Sep 2014)
Log Message
arb: Take a stab at fixing the SL build on the builder
Modified Paths
• trunk/dports/science/arb/Portfile
Diff
Modified: trunk/dports/science/arb/Portfile (125901 = 125902)
+platform darwin {
+if {${os.major} 11} {
+depends_build-append port:coreutils
+
+configure.env-append INSTALL=${prefix}/bin/ginstall
+}
+}
The error I see on the buildbot is:
install -s dvtditr dndfast7 dndblast sextet5 mafft-distance pairlocalalign
pair2hat3s multi2hat3s rnatest pairash addsingle splittbfast disttbfast tbfast
mafft-profile f2cl mccaskillwrap contrafoldwrap countlen seq2regtable
regtable2seq score getlag dndpre dndpre2 setcore replaceu restoreu setdirection
makedirectionlist version
/opt/local/var/macports/build/_opt_mports_dports_science_arb/arb/work/arbsrc_12565/lib/mafft
strip: object:
/opt/local/var/macports/build/_opt_mports_dports_science_arb/arb/work/arbsrc_12565/lib/mafft/dvtditr
malformed object (unknown load command 13)
So it looks like it's strip, not install, that's having a problem with the
object's load command.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: imake
Hello, On 29/09/2014 13:03, Brandon Allbery wrote: On Sun, Sep 28, 2014 at 11:51 PM, Brandon Allbery allber...@gmail.com mailto:allber...@gmail.com wrote: If I understood other discussions correctly, KDE3 is already being removed. Sorry, not discussions; recent commit messages indicate that it's being obsoleted and slated for removal starting from the leaves. See for example r125868, r125871. I had mentioned the idea of making KDE3 obsolete quite some time ago (months) on the list, but never got to do it. I indeed started (independently from the imake discussion, just a coincidence) some days ago with the dependents ports. I going slightly slowly on this part as I am trying to find replacements for the few remaining kde3-based apps whenever possible. The idea would be to then remove the kde3 suite after all dependents have been taken care of. The biggest remaining issue is koffice. Ideally, it could be replaced by calligra (requested in ticket #https://trac.macports.org/ticket/37579), but it seems plagued with several problems at runtime making it only very partly usable on OS X. Cheers, Nicolas ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
