Hello,
As Ryan said, it is not really the duty of MacPorts developers to keep
ports alive if they are not supported upstream. KDE 3 is long since
dead (unmaintained) and all KDE apps dependent on KDE 3 with it.
So, do not worry about KOffice… :-(
You have a fair point here. I’ll proceed on
On Tue, Sep 30, 2014 at 5:46 AM, Nicolas Pavillon ni...@macports.org
wrote:
Apart from the possibility of announcing calligra as a replacement of
koffice, I am nevertheless hesitating about committing the existing
portfile. It can build, so that it would be a good starting point to
improve
On Mon, Sep 29, 2014 at 5:58 AM, Joshua Root wrote:
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
On Sep 28, 2014, at 2:55 AM, Ryan Schmidt ryandes...@macports.org wrote:
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.
I think we really should move in the
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
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
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
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
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
?
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
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 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
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
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
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
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
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
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
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
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
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
On 2014-9-28 12:15 , Ryan Schmidt 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
On Sat, Sep 27, 2014 at 11:12 PM, Joshua Root j...@macports.org wrote:
It would be better to fix the macros in xorg-cf-files or wherever so
they work with a modern preprocessor.
This probably isn't possible; the issue is that a modern preprocessor
speaks C / C++, not Makefile.
--
brandon s
On 2014-9-28 13:14 , Brandon Allbery wrote:
On Sat, Sep 27, 2014 at 11:12 PM, Joshua Root j...@macports.org
mailto:j...@macports.org wrote:
It would be better to fix the macros in xorg-cf-files or wherever so
they work with a modern preprocessor.
This probably isn't possible;
On Sat, Sep 27, 2014 at 11:47 PM, Joshua Root j...@macports.org wrote:
That isn't the issue AFAICT, it's just doing things with comments that
were probably undefined before and now don't work:
That is in fact closely related to the issue. The old KR preprocessor
allowed that as a hack; ANSI C
On 2014-9-28 13:55 , Brandon Allbery wrote:
On Sat, Sep 27, 2014 at 11:47 PM, Joshua Root j...@macports.org
mailto:j...@macports.org wrote:
That isn't the issue AFAICT, it's just doing things with comments that
were probably undefined before and now don't work:
That is in fact
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?
- Josh
___
macports-dev mailing list
macports-dev
On Sun, Sep 28, 2014 at 12:28 AM, Joshua Root j...@macports.org wrote:
It does, with a little tweaking. But you're still right, it then
proceeds to screw up the indentation in the Makefile.
Yeh. I got to know this stuff all to well trying to deal with Haskell's use
of CPP --- Haskell tokens
28 matches
Mail list logo
