Re: [116220] trunk/dports/python
j...@macports.org writes: Revision: 116220 https://trac.macports.org/changeset/116220 Author: snc at macports.org Date: 2014-01-21 13:14:00 -0800 (Tue, 21 Jan 2014) Log Message: --- py-turbogears, py-turbokid: remove python24, maintainer timeout #35623 Instead of deleting a few random py24 subports, why don't you ask the python24 maintainer and the -users list if anyone still needs python 2.4? (They said yes last time we asked.) And if they don't, make a ticket for deleting python24 and either deleting or updating to a newer python for all its dependents. I would like to not get rid of python24 anytime soon because it allows me to test compatibility. I am not opposed, however, to removing all the py24-* ports (maybe all but virtualenv and friends?). ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [116220] trunk/dports/python
Those packages were blocking the removal of python24 subports that I maintain (e.g py-elementtree). 100% agree with removing at least the python24 modules like Sean said. Also, people are quite capable of pulling python24’s modules out of our repository after removal if they need them. While Sean has a use for python24 itself, it has security problems and is not supported. I feel it also should get removed and used in a local repository if possible, but I’m perfectly content with doing just modules for now. Realistically, most modules below python27 should get axed. On Jan 22, 2014, at 10:53, Sean Farley s...@macports.org wrote: j...@macports.org writes: Instead of deleting a few random py24 subports, why don't you ask the python24 maintainer and the -users list if anyone still needs python 2.4? (They said yes last time we asked.) And if they don't, make a ticket for deleting python24 and either deleting or updating to a newer python for all its dependents. I would like to not get rid of python24 anytime soon because it allows me to test compatibility. I am not opposed, however, to removing all the py24-* ports (maybe all but virtualenv and friends?). ___ 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: [116220] trunk/dports/python
I agree. I think all py24-* ports should be removed now. Removing py24-* ports will change the default python to 2.7 for people who (mistakenly) install py-foo. I would not object to everything less than py27-* leaving too but maybe later. Cheers! Frank On Jan 22, 2014, at 9:11 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Those packages were blocking the removal of python24 subports that I maintain (e.g py-elementtree). 100% agree with removing at least the python24 modules like Sean said. Also, people are quite capable of pulling python24’s modules out of our repository after removal if they need them. While Sean has a use for python24 itself, it has security problems and is not supported. I feel it also should get removed and used in a local repository if possible, but I’m perfectly content with doing just modules for now. Realistically, most modules below python27 should get axed. On Jan 22, 2014, at 10:53, Sean Farley s...@macports.org wrote: j...@macports.org writes: Instead of deleting a few random py24 subports, why don't you ask the python24 maintainer and the -users list if anyone still needs python 2.4? (They said yes last time we asked.) And if they don't, make a ticket for deleting python24 and either deleting or updating to a newer python for all its dependents. I would like to not get rid of python24 anytime soon because it allows me to test compatibility. I am not opposed, however, to removing all the py24-* ports (maybe all but virtualenv and friends?). ___ 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 ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: [116220] trunk/dports/python
The one thing I'd caution against is removing any py24* ports that have no newer versions. I cannot think of any off the top of my head, but I guess that would just be something to check for while removing the py24* ports, i.e., making sure that they have a version available for a newer python before removing it. On Wed, Jan 22, 2014 at 12:25 PM, Frank Schima macsforever2...@macports.org wrote: I agree. I think all py24-* ports should be removed now. Removing py24-* ports will change the default python to 2.7 for people who (mistakenly) install py-foo. I would not object to everything less than py27-* leaving too but maybe later. Cheers! Frank On Jan 22, 2014, at 9:11 AM, Jeremy Lavergne jer...@lavergne.gotdns.org wrote: Those packages were blocking the removal of python24 subports that I maintain (e.g py-elementtree). 100% agree with removing at least the python24 modules like Sean said. Also, people are quite capable of pulling python24’s modules out of our repository after removal if they need them. While Sean has a use for python24 itself, it has security problems and is not supported. I feel it also should get removed and used in a local repository if possible, but I’m perfectly content with doing just modules for now. Realistically, most modules below python27 should get axed. On Jan 22, 2014, at 10:53, Sean Farley s...@macports.org wrote: j...@macports.org writes: Instead of deleting a few random py24 subports, why don't you ask the python24 maintainer and the -users list if anyone still needs python 2.4? (They said yes last time we asked.) And if they don't, make a ticket for deleting python24 and either deleting or updating to a newer python for all its dependents. I would like to not get rid of python24 anytime soon because it allows me to test compatibility. I am not opposed, however, to removing all the py24-* ports (maybe all but virtualenv and friends?). ___ 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 ___ 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
Removing old Python versions
(was: [116220] trunk/dports/python) On Wed, Jan 22, 2014 at 5:11 PM, Jeremy Lavergne wrote: Realistically, most modules below python27 should get axed. I don't have anything against removing python 2.4 (or 2.5 for that matter), but there is one specific use case speaking against removing python 2.6 just now (or rather: removing all but one python from the 2.x series). Some ports depend on wxPython 2.8, but wxPython 2.8 and 3.0 conflict with each other. One possible workaround is to install py26-wxpython-2.8 and py27-wxpython-3.0, so that one can still use old ports with Python 2.6 and modern ports with Python 2.7. If all python versions 2.4, 2.5, 2.6 get removed, we suddenly get a conflict we cannot work around. This specific problem should hopefully disappear in a year (or two or three, ... depending on how long we'll tolerate abandonware). That is, unless we'll have to deal with another conflict between wxPython and Phoenix. Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: Compilers and MPI Port Groups
s...@macports.org writes:
ebori...@ieee.org writes:
Haven't had a chance to look into this; have you updated mpich-devel
(betas / etc), as well?
Yep. The two files are almost the same now and could even be merged into
one portfile to de-duplicate logic. Same goes for openmpi{,-devel}.
The noteworthy changesets are:
mpi-doc: new port to abstract docs for mpich and openmpi
https://smf.io/macports/changeset/2d0f20f8414b7b676f0c72079938ff3fc6dccb86
mpich_select: rename to mpi_select so all mpi ports can use it
https://smf.io/macports/changeset/0946ba1629b857a1cc3ca5ae098df616c30dc2a4
mpich: use non-conflicting names for files that mpich-devel also installs
https://smf.io/macports/changeset/718a0fc09fedb2c24a662e833fe286f945d30135
mpich-devel: make non-conflicting with mpich
https://smf.io/macports/changeset/040299c685f3a453987bd7dadefe2882eb52bd9a
openmpi: unify wrapper names as mpi{cc,cxx,fc,f77,f90}
https://smf.io/macports/changeset/e6453dc62852bd9f2b6b902bb018f8bdb75d5970
Just a heads up that I'm planning to push this tomorrow.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
