[EMAIL PROTECTED] wrote:
Revision: 35247
http://trac.macosforge.org/projects/macports/changeset/35247
Author: [EMAIL PROTECTED]
Date: 2008-03-21 21:45:53 -0700 (Fri, 21 Mar 2008)
Log Message:
---
Put heimdal in a seperate prefix. No other ports depend on it, it
Michelangelo wrote:
Hello,
Hello Michelangelo,
I've been thinking about this proposal for the whole day; William has
suggested me to write it here, to hear directly from you, to hear your
feedbacks and, most thing important for me, your objections.
Ah! I was about to forget, my name's
Marcus Calhoun-Lopez wrote:
A few days ago, I submitted a ticket outlining situations in which it
takes two runs of the port command for correct installation
(http://trac.macosforge.org/projects/macports/ticket/14687
).
Is this a known behavior?
Don't think so...
I have attempted to
[EMAIL PROTECTED] wrote:
Revision: 35256
http://trac.macosforge.org/projects/macports/changeset/35256
Author: [EMAIL PROTECTED]
Date: 2008-03-22 15:18:17 -0700 (Sat, 22 Mar 2008)
Log Message:
---
added checksum display and an early exit when master_sites is not
Ryan Schmidt wrote:
On Mar 24, 2008, at 09:05, James Berry wrote:
Yes, as Adam says, this is our standard and supported behavior, and
is used for many ports. I'm not sure it's documented anywhere
however, but Adam's explanation is correct; we support two forms of
obfuscation, a
Ryan Schmidt wrote:
-version1.60
-revision1
+version1.7.0
Hmm... users who have 1.60 installed probably won't get informed of
this upgrade, since numerically 7 60, right? :-(
You are right. epoch should be set, too.
Rainer
Bryan Blackburn wrote:
I've just attached a patch to that ticket which should solve the proxy/
root issue. Basically, what it does is query the SystemConfiguration
framework for the proper HTTP, HTTPS, and FTP proxy information (as
well as names which should skip the proxy) and sets the
Guido Soranzio wrote:
We are in serious need of:
1. An open repository where to exchange precompiled archives in
order to avoid the lengthy compilations of the dependencies.
Which requires 2.
2. A buildbot on a central server which automatically builds
and tests the proposed
Guido Soranzio wrote:
I meant a simple hosting infrastructure outside of the subversion
repository where the submitters and the committers could upload and
share their precompiled packages/archives: we already have the
archive mode and the support for RPM.
Sure, but it doesn't integrate with
Guido Soranzio wrote:
On trunk several pieces of Gnome 2.22 have been already committed
sparsely without coordination: almost a nightmare.
Why is this a nightmare? Gnome ports got no maintainer, so others did
what they could.
Let's suppose that someone (me!) is busy building Gnome again from
Guido Soranzio wrote:
On Mar 31, 2008, at 6:53 PM, Rainer Müller wrote:
We have a port for ruby.
No: MacRuby is a new project which is porting Ruby 1.9 directly on the
Objective-C runtime.
Okay, so it is different from the default Ruby and seems to be a
separate project. Make a ruby-mac
Eric Hall wrote:
I've always thought this was an excellent idea, it neatly
solves conflicting version problems (libnet for example) and allows
a new version of $THIS_DEPENDENCY to be installed without breaking
$OTHER_SOFTWARE that's linked against $OLDER_VERSION_OF_THIS_DEPENDENCY,
[EMAIL PROTECTED] wrote:
Revision: 35831
http://trac.macosforge.org/projects/macports/changeset/35831
Author: [EMAIL PROTECTED]
Date: 2008-04-07 14:32:47 -0700 (Mon, 07 Apr 2008)
Log Message:
---
Set svn:keywords to Id on all Portfiles per current guidelines
I may
Hi,
Currently +universal is broken in trunk. I get the following error message:
$ sudo port configure +universal
Error: Error executing universal: can't read
configure.universal_cflags: can't read configure.universal_target:
no such variable
Rainer
Anders F Björklund wrote:
Hopefully fixed in r35970, gave no error here for some strange reason...
Thanks, it works for me now.
Maybe this could be due to a different Tcl version? I am on Leopard
which comes with Tcl 8.4, but tclsh doesn't tell me the exact version
(tried -h and --version,
Rainer Müller wrote:
[EMAIL PROTECTED] wrote:
Revision
34977 http://trac.macosforge.org/projects/macports/changeset/34977
Author
[EMAIL PROTECTED]
Date
2008-03-13 07:13:51 -0700 (Thu, 13 Mar 2008)
Log Message
Add new --recursive option to port uninstall to uninstall
Ryan Schmidt wrote:
post-patch {
-cd ${worksrcpath}
+system cd ${worksrcpath}
foreach item [exec find . -type f -name .cvsignore] {
file delete -force ${item}
}
@@ -99,7 +107,7 @@
set docPath ${prefix}/share/doc/${name}
xinstall -d -m 0755
William Siegrist wrote:
I can see a use for both directions, so I guess having options for
both directions would be nice. But also a name like follow-
dependents or also-dependents would be clearer.
I renamed --recursive to --follow-dependents for port uninstall in r36160.
Rainer
Hi,
What is the current status of registry 2.0? As we are still putting new
features (recursive uninstall) into registry1.0 I was wondering what the
status of registry2.0 is at the moment. It is sitting around in trunk
now for quite some time without active work.
What is missing from
Ryan Schmidt wrote:
Don't forget to commit the actual patchfile too!
Thanks, forgot to svn add it. Added in r36242.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo/macports-dev
William Siegrist wrote:
I'm forwarding on to macports-dev since it seems like the XML
declaration they are using makes that browser treat the site as an XML
doc instead of an XHTML 1.1 doc. What they have is valid XHTML 1.1,
so it might just be that Shiira2 doesnt work well with the latest
Shreevatsa R wrote:
Hi MacPorts developers,
Hi,
I was planning to write some non-trivial code before posting to this
list, but I thought I would first check if I was doing anything
stupid.
[snip]
So deciding that at least knowing all dependencies of a port
beforehand would help, I tried
Anders F Björklund wrote:
There probably needs to be a repackaging of the MacPorts 1.6
installer that includes the correct postflight (whether it is
called 1.6.0p1 or 1.6.1 doesn't mattter much). Either that, or the
Guide/instructions should be changed to include how to set up the
PATH
Ryan Schmidt wrote:
The other problem with parallel builds is that they are not identical
each time you run them. The build may succeed 3 times, then fail the
4th. I personally haven't had the time to try to build each of my
ports several times with parallel build on to see if they
Florian Ebeling wrote:
Wiki modification requires committer privileges.
I think it would benefit the project if we losen this policy. Nobody applies
for commit to correct a small factual error. And it works for other site quite
well. What was the name of this online encyclopedia, gain? ;)
I
Juan Manuel Palacios wrote:
I can see mp-changes hosting these mails, but I'd actually think this
list is a better choice, since these edits will mostly (hopefully) be
about documentation, which is something we've always reviewed here. In
any case, I have no problem with having them on
Blair Zajac wrote:
I'd like to move to Python 2.5 for all our PyQt and GUI apps that require the
Framework build. We have some major apps written on 2.4, so I'd like to be able
to have 2.4 and 2.5 simulatenously installed so developers can check their work
on the same system with a single
Anders F Björklund wrote:
Joshua Root wrote:
I've got a bunch of bugfix patches on Trac which need reviewing. It
would be nice to get as many of them as possible into the upcoming
release.
As jmpp mentioned, there will probably be two releases: one old/
bugfix release of MacPorts 1.6.1
Blair Zajac wrote:
I don't think we can just move the site-packages, can we? There are .so's in
there.
No, especially not because they are recorded in file_map.db to be
installed at the old location. If you just move them, they are not known
to MacPorts at all.
It would be possible to do
Anders F Björklund wrote:
Rainer Müller:
So if someone knows how to link against a framework in a custom
path, please advice.
See the -F flag. You'd still need the standard Current symlink
operational, though.
-F is documented to set the include path (like -I):
Add the framework
[EMAIL PROTECTED] wrote:
+# PATH settings that are used for external tools (configure, make,
etc.) while installing ports. The default
+# paths are given in the example; it need not be uncommented.
Customizing binpath is intended for advanced users only.
+#binpath
[EMAIL PROTECTED] wrote:
Just use @prefix_expended@ and @x11prefix@ which will get expanded on
install. We already use them at other places in this file.
Are you saying that we should move where the binpath setting is set from
wherever it is now to macports.conf? Also, what is
Adam Schenker wrote:
I'd be grateful if someone could commit this for me. Also, I'd like to
go ahead and request commit privileges so I don't have to keep asking
on the list. I am the maintainer of the above port as well as 4 others.
This should go over portmgr's desk for approval. I am
Andrea D'Amore wrote:
Hello,
octave-forge portfile is pretty outdated, I got latest tarball and
structure has changed, main tarball hasn't a configure script
anymore,now it's only a collection of .tar.gz, each of them with its
own configure script.
What's the more convenient way to
Ronald Oussoren wrote:
First of: what are you trying to accomplish? And more to the point:
I'd like to know if there's anything we can change in the python.org
distribution to make that easier to accomplish.
Currently the python24 port is build as framework, while python25 is
installed
Rainer Müller wrote:
See http://trac.macports.org/wiki/PythonFrameworkTransition and the
python-frameworks branch in svn. I tried to make python24 and python25
more similar and build both as frameworks.
Before this can be released we need an easy way for the transition as
described
Thomas Reifferscheid wrote:
I do not understand the ..is absolutely not what we want-part of your
e-mail.
Regarding the symlink you posted, the binary in your example will appear
as $prefix/bin/hg. Why is that considered bad or no go?
According to our plans in the wiki we decided to do the
Anders F Björklund wrote:
Ryan Schmidt wrote:
Should we change MacPorts to only add the -j argument to the make
command in the build phase, and not do so in the destroot phase?
Sounds like a good idea to me.
Yes, this is good. We should also merge it to release_1_6 to get it
included in
Andrea D'Amore wrote:
On 17/mag/08, at 21:26, Alakazam wrote:
If we agree that that is the correct solution for octave-forge, I can
look into this in the next couple of days.
I'm not sure how to cope with portgroups (they have to be builtin into
macports from what I've read).
[...]
I
Joshua Root wrote:
+depends_lib port:XFree86 port:jpeg port:libpng port:freetype \
+port:tiff port:libungif port:gtk2 port:librsvg
Shouldn't the XFree86 dependency stay as lib: rather than port: so that
it will be satisfied by Apple's X11?
The XFree86 port checks for X11 and
Joshua Root wrote:
It also errors out if both Apple X11 and X11SDK are present. (And the
usage of ${prefix} in those checks in the XFree86 portfile seems to be
wrong, BTW. Not to mention quartz-wm is in /usr/bin these days, not
${x11prefix}/bin.) So it's impossible to install AfterStep with
Ryan Schmidt wrote:
On Mar 12, 2008, at 11:41, [EMAIL PROTECTED] wrote:
Log Message:
---
Fix reported destroot error caused by not cd'ing to ${worksrcpath}.
+# This should not be necessary, but it seems to work around a bug
+# that exist at least in MP 1.600.
destroot{
-
Jordan K. Hubbard wrote:
This is why I think that releases should be tags on trunk, with a
convergence period before each release. This project is not big
enough and does not have the manpower or written guidelines and a
release engineer driving the process on a daily basis which are
Simon Ruderich wrote:
On Tue, May 27, 2008 at 12:22:39PM -0400, Charles Darwin wrote:
sudo port -d selfupdate
…
12:20:42 sudo port clean --all mutt
--- Cleaning mutt
12:20:51 sudo port -dsc patch mutt +imap +ssl +buffy +compress
+imap_headercache
Sorry, normally you have to wait 12
Caspar Florian Ebeling wrote:
This is exactly what I have been preaching, but I think it changes
with Git. I know that saying this might well be boring by now, but Git
eases the whole branch handling a lot. And svnmerge.py is really
not a substitute here. I used it for a feature branch of a
Caspar Florian Ebeling wrote:
Yeah, and that's the whole problem. With svn you dump all your new
half-cooked,
half-done features into trunk. With Git it's the reverse situation.
You do the dangerous
things in branches and can assume that mainline is reasonably in shape. That's
only a
Jay Levitt wrote:
I don't know if there's a naming standard on macports, but -dev and
-devel package suffixes on both Red Hat- and Debian-based Linux
distros mean the include files you'll need to compile against this
package/library. So I'd recommend against -devel.
It is the naming
Jordan K. Hubbard wrote:
On May 27, 2008, at 1:38 PM, Rainer Müller wrote:
Jordan brings up the idea not to use branches at all, but to make
releases from the main line. [ ... ] How would we do minor releases
for bugfixes without branches?
Easy. In Subversion, tags and branches
Jordan K. Hubbard wrote:
On May 27, 2008, at 6:28 PM, Rainer Müller wrote:
Hm, this sounds like you propose here to make release branches
without using tags.
No. From the very beginning of my proposal (please go back and read
my first message again) I have suggested making releases
Joshua Root wrote:
I would have no objection to tagging trunk today and calling it an -rc1.
Well, except that there are apparently some bug fixes in the 1.6 branch
that are not in trunk - argh!
But you would definitely tag that 1.7.0-rc1 not 1.6.1-rc1. And where do
you fix a bug found in
Blair Zajac wrote:
Rainer Müller wrote:
So if a release was near, I would do (with some pseudo-shell commands):
svn cp trunk branches/release_1_7
svn cp branches/release_1_7 tags/release_1_7_0-rc1
Bug fixes go to branches/release_1_7. Anything can happen on trunk in
the mean time
Joshua Root wrote:
People can start relying on the mirror and building it into port1.0
Done: http://trac.macports.org/attachment/ticket/15456/d.m.o.diff :-D
Nice implementation. Patch works fine here!
As you use port mirror for this task now, can we revert the addition of
port distfiles?
[EMAIL PROTECTED] wrote:
Revision: 37228
http://trac.macosforge.org/projects/macports/changeset/37228
Author: [EMAIL PROTECTED]
Date: 2008-05-31 07:10:38 -0700 (Sat, 31 May 2008)
Log Message:
---
Switch over remaining teTeX dependencies to texlive. Closes #12913
[EMAIL PROTECTED] wrote:
Revision: 37243
http://trac.macosforge.org/projects/macports/changeset/37243
Author: [EMAIL PROTECTED]
Date: 2008-05-31 14:57:15 -0700 (Sat, 31 May 2008)
Log Message:
---
port/port-help.tcl:
More helpful action desriptions
Modified
Hi,
I consider the work in the branch python-frameworks as finished and it
needs some more testing until I will merge it back into trunk/dports. So
I need your help here.
I would kindly ask volunteers to checkout the python-frameworks branch
[1] and test to install the python ports from
Blair Zajac wrote:
Should we do fresh builds or take an existing tree and update the MacPorts in
it?
Both should work without problems, hopefully.
After potential issues are found and fixed, I will move these Portfiles
back to trunk. Then I am also going to make additions to python_select
Bryan Blackburn wrote:
A few initial notes, nothing major as yet:
- any reason you switched to tgz from the tar.bz2 (since that means
another download of the basic same file)?
I just wanted to use the same file type for all python ports. I could
have switched all to bzip2 as well...
-
Ryan Schmidt wrote:
On Jun 11, 2008, at 03:45, Caspar Florian Ebeling wrote:
Is there documentation of the mp-specific commands
somewhere, that I overlooked? Things like system?
I found the definition in macports/base/src/pextlib1.0/Pextlib.c,
eventually, but it is still a bit
Ryan Schmidt wrote:
Does universal mean it works at full performance on all
architectures? In this case, ports like this that install no
architecture-specific files should be modified to have an empty
universal variant selected by default.
Or does universal mean it has more than one
Ryan Schmidt wrote:
Ok, with that ticket resolved, the build proceeds further, but now
complains about missing X11:
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking whether -R must be followed by a space... neither works
checking for dnet_ntoa in -ldnet...
Ryan Schmidt wrote:
3) Builds always universal (because the build system does that)
I think we should strive not to have this situation... if the port
builds universal by default, an effort should be made to change the
build so that it builds non-universal by default, and universal
[EMAIL PROTECTED] wrote:
Revision
36832 http://trac.macosforge.org/projects/macports/changeset/36832
Author
[EMAIL PROTECTED]
Date
2008-05-16 00:55:27 -0700 (Fri, 16 May 2008)
Log Message
version 1.20 with workaround for broken gcc-4.0 on 10.5: beta gcc 4.2 needs
Markus Weissmann wrote:
[...]
+platform darwin 9 {
+ # gcc 4.0 fails to compile gnutar on 10.5 (probably will get
fixed with XCode 3.1)
+ configure.compiler gcc-4.2
+}
Why not use gcc42 or gcc43 from MacPorts instead of requiring the
Xcode beta? I can confirm it builds fine
Hi,
currently we hardcode gcc-4.0 for Leopard (or Darwin 9) in
port1.0/portconfigure.tcl, but as far as I am informed the next Xcode
release will contain gcc-4.2. But will it also still contain gcc-4.0?
I think we need an additional check for the Xcode version in our default
selecting code
[EMAIL PROTECTED] wrote:
Revision: 37636
http://trac.macosforge.org/projects/macports/changeset/37636
Author: [EMAIL PROTECTED]
Date: 2008-06-16 11:56:38 -0700 (Mon, 16 Jun 2008)
Log Message:
---
Update bdb dependency, now depend on db46
Modified Paths:
Thomas Hagedorn wrote:
Sorry, but I was away for the week. It appears that I did submit a
port that was already already as the port p5-net-ip. I'm not sure how
that happened, but deleting the submitted port p5-net-id would seem to
be the correct action.
Maybe I was too fast with closing
Ryan Schmidt wrote:
I don't want to introduce yet more ways for two users to think they
have installed the same thing but in fact they haven't. You're just
creating more support headaches that way.
It is already possible to choose another compiler from the command line:
$ sudo port
Caspar Florian Ebeling wrote:
Quick question: in macports svn, is doc obsolete and only doc-new in
use anylonger?
I would say yes. As you can see in the repository browser [1] doc hasn't
gotten any commits in 9 months, which is when doc-new was created.
so should we maybe get rid of it?
Boyd Waters wrote:
So if I set configure.compiler in macports.conf, it gets picked up
unless overridden in the Port file?
There is no option yet in macports.conf, that's what I am proposing here.
Currently you can only use it from command line, but this will override
configure.compiler from
Joshua Root wrote:
dist_subdir ${name}/${version}_${revision}
If you want, you could remove this later, once the next version of
the software is released.
Won't this result in one of the distfiles being orphaned, i.e. it won't
be removed by clean --dist?
${distpath}/${name} is
Ryan Schmidt wrote:
But you are right, if you change it from a non-standard location to
another non-standard location (e.g. if you have the definition from
above and increment the Portfile revision), it will leave orphaned
files.
Is there something we could do against it?
Upgrading
Ryan Schmidt wrote:
On Jun 15, 2008, at 12:36 PM, [EMAIL PROTECTED] wrote:
--- branches/gsoc08-privileges/base/configure2008-06-15 17:35:46
UTC (rev 37614)
+++ branches/gsoc08-privileges/base/configure2008-06-15 17:36:41
UTC (rev 37615)
@@ -1,6 +1,6 @@
#! /bin/sh
#
Landon Fuller wrote:
I would like to propose a policy for general consideration. I believe
it could save everyone energy and brain-cycles; let's call it
batteries included:
As a general rule, ports should enable all standard features/
functionality that may be useful to an
[EMAIL PROTECTED] wrote:
Revision: 37766
http://trac.macosforge.org/projects/macports/changeset/37766
Author: [EMAIL PROTECTED]
Date: 2008-06-22 07:54:59 -0700 (Sun, 22 Jun 2008)
Log Message:
---
Don't use parallel build for bind9
[...]
-use_parallel_build yes
[EMAIL PROTECTED] wrote:
Revision: 37344
http://trac.macosforge.org/projects/macports/changeset/37344
Author: [EMAIL PROTECTED]
Date: 2008-06-03 15:20:38 -0700 (Tue, 03 Jun 2008)
Log Message:
---
Updates to Port API.
Modified Paths:
--
[EMAIL PROTECTED] wrote:
Hope this isn't me just being silly but I tried to install MacPorts from
http://svn.macports.org/repository/macports/downloads/MacPorts-1.6.0/MacPorts-1.6.0.tar.bz2
and it didn't work. It looks like there is a missing l from the ar flags
when making cregistry.a.
Daniel J. Luke wrote:
On Jun 23, 2008, at 2:58 PM, [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] 11:58:48
-0700 (Mon, 23 Jun 2008)Log Message
Most actions are now performed using user privileges, up to and
including the destroot stage. For install, the original root
privileges are
[EMAIL PROTECTED] wrote:
Revision: 37615
http://trac.macosforge.org/projects/macports/changeset/37615
Author: [EMAIL PROTECTED]
Date: 2008-06-15 10:36:41 -0700 (Sun, 15 Jun 2008)
Log Message:
---
Add --with-no-root-privileges switch to ./configure.
[...]
+
Paul Magrath wrote:
On 23 Jun 2008, at 21:29, Rainer Müller wrote:
Please use an appropriate way to find the home directory of the user
here, not an hardcoded /Users.
There must be a better way to find the current user than an external
whoami. If you really need whoami, run it only once
[EMAIL PROTECTED] wrote:
Revision: 37786
http://trac.macosforge.org/projects/macports/changeset/37786
Author: [EMAIL PROTECTED]
Date: 2008-06-23 04:44:41 -0700 (Mon, 23 Jun 2008)
Log Message:
---
port.tcl: fix bug from r37756: allow 'port ed --editor' to work
Ryan Schmidt wrote:
[...]
Not sure what else in the modeline needs verification. The modeline
can/should specify the file's character encoding, but port lint
always checks to make sure the file is UTF-8; it does not use the
encoding listed in the modeline. Then again, neither does
Ryan Schmidt wrote:
So then lint could warn if the modeline specifies a character
encoding other than UTF-8. In fact it could warn if the modeline
differs at all from the one shown in the Guide.
Hm, I would say this modeline is just a recommendation, and not
mandatory. Port maintainers
Ryan Schmidt wrote:
The page says MPAB is to be downloaded from the attachment on that
wiki page. Why not put it in the repository somewhere, like in /users/
blb?
Maybe we should create a 'contrib area' in our repository? That would be
another directory like /trunk/contrib or /trunk/tools
kimura wataru wrote:
Hi, I'm a maintainer of lang/ruby.
Hi Kimuraw!
Welcome aboard :-)
I'm planning to change the Portfile of lang/ruby to ignore minor
system version for archdir, like Apple's Ruby.
Ruby uses archdir to define install destination of extension
modules, such as
Hi Bill,
There haven't been any wiki change notification mails to
macports-changes recently. I assume they got lost as you switched
servers. Could you please re-enable them?
Thanks in advance,
Rainer
___
macports-dev mailing list
Adam Mercer wrote:
--- Fetching py25-scipy
Error: Target org.macports.fetch returned: invalid command name llen
Error: Status 1 encountered during processing.
It should be [llength ...]
Rainer
___
macports-dev mailing list
Ryan Schmidt wrote:
On Jul 3, 2008, at 23:30, [EMAIL PROTECTED] wrote:
Revision: 38038
http://trac.macosforge.org/projects/macports/changeset/38038
Author: [EMAIL PROTECTED]
Date: 2008-07-03 21:30:56 -0700 (Thu, 03 Jul 2008)
Log Message:
---
Ryan Schmidt wrote:
+ln -s ${prefix}/bin/perl${version} ${destroot}${prefix}/bin/$name
Wouldn't a relative link have sufficed or is an absolute reference
necessary? Just curious.
ln -s perl${version} ${destroot}${prefix}/bin/$name
Right, that should have been sufficient as well. But
Randall Wood wrote:
In Leopard, do we really want to set the display? Won't that screw
with the new Apple mechanism for handling X display requests?
This script only exports DISPLAY if it is not set yet. On Leopard
DISPLAY is already exported from the LaunchAgent in launchd, so the
mechanism
Randall Wood wrote:
But if you are going to source some script we provide, why not let
ports set certain expected environment variables that make
correct-in-most-cases-but-not-ours assumptions that can be overridden
by setting the environment. Its better than patching the upstream code
if the
[EMAIL PROTECTED] wrote:
Revision: 38144
http://trac.macosforge.org/projects/macports/changeset/38144
Author: [EMAIL PROTECTED]
Date: 2008-07-08 13:35:34 -0700 (Tue, 08 Jul 2008)
Log Message:
---
Added a new procedure for recursive chowning of directories. Inserted
Ryan Schmidt wrote:
If I had to define these I guess I would say:
fixed - there was a problem in MacPorts and it was fixed in MacPorts
Or: there was a problem somewhere and this fix is available through MacPorts
Some problems are directed to upstream and fixed there, and then an
updated
Caspar Florian Ebeling wrote:
I have other issues myself. It is not entirely convincing to install
ruby libraries
via a generic package manager like mp, given that ruby has it's own in the
form of Rubygems, which even comes builtin with 1.9.
The same thing applies to Perl. There is CPAN which
Ryan Schmidt wrote:
We need to add a keyword to the portfile syntax for this.
What should it be?
fetch.mirror, default yes, can be set to no by portfile authors?
Or should it not be linked with the fetch phase?
mirror_distfile default yes?
allow_distfile_mirror
allow_mirroring
There was
Marcus Calhoun-Lopez wrote:
I am experimenting with a local version of graphviz.
During the activation phase, I get the error:
Error: Target org.macports.activate returned: Not a directory
Does anyone know the meaning of this error?
This happens when 'port activate' finds something
Caspar Florian Ebeling wrote:
Ok. Maybe a deprecation period would have smoothed things over a bit
more garcefully, but just turning it off makes for a quicker migration ;)
We will see when 1.7 comes out. (Which hopefully it does some day!)
Actually there was a deprecation period. MacPorts 1.6
Rainer Müller wrote:
I think there is some problem with the python25 framework port. I can
reproduce the message here and will see if I can find a solution.
I am still trying to figure out where graphviz or swig pick up the path
to the framework directory, but I can't find it. It needs
Ryan Schmidt wrote:
Would be great if it did print a message when cd is used, but I
don't think it does.
Damn, I was mistaken. So I stand corrected and it seems like I have only
dreamed about this warning :-/
Sorry, I thought there had been a deprecation warning in 1.6.0, but
actually the
Adam Mercer wrote:
Just tried to install base from the trunk and install fails with the
following error:
/usr/bin/install -c -o root -g admin -m 444 setupenv.bash
/opt/local/share/macports/
install: /opt/local/share/macports/: No such file or directory
manually creating this directory
Uwe Schwartz wrote:
are there any conventions about tabs and whitespaces in Portfile?
I couldn't find any hints in the wiki or in the guide.
http://guide.macports.org/#development.practices.portstyle
Additionally, watch out for trailing whitespace - especially when the
line should end with a
101 - 200 of 1310 matches
Mail list logo
