On Jun 6, 2015, at 2:53, René J.V. Bertin rjvber...@gmail.com wrote:
On Friday June 05 2015 17:45:22 Landon Fuller wrote:
but if that does work in Yosemite, it seems very likely to break in
Yosemite+1 of OS X when they start applying additional iOS-style
restrictions based on code
On Jun 3, 2015, at 4:46, René J.V. Bertin rjvber...@gmail.com wrote:
On Wednesday June 03 2015 16:47:39 Joshua Root wrote:
Finally got around to trying an unsigned kext, and the answer is no,
neither kextload nor kextutil will load unsigned kexts at all (without
kext-dev-mode=1 in the
On Mar 21, 2014, at 4:17 PM, Landon Fuller land...@macports.org wrote:
On Mar 20, 2014, at 8:39 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Mar 20, 2014, at 19:21, Eric Gallager wrote:
That said, a git/hg mirror on GitHub/ButBucket would definitely be nice.
Why would
On Mar 20, 2014, at 8:39 PM, Ryan Schmidt ryandes...@macports.org wrote:
On Mar 20, 2014, at 19:21, Eric Gallager wrote:
That said, a git/hg mirror on GitHub/ButBucket would definitely be nice.
Why would that be nicer than the read-only git mirror that Mac OS Forge
already provides
On Mar 16, 2014, at 11:40 PM, Joshua Root j...@macports.org wrote:
However I would also agree with what Landon said here:
https://lists.macosforge.org/pipermail/macports-dev/2013-September/024252.html
I’m glad I read the full thread, as otherwise I might have reiterated this
point without
On Dec 28, 2013, at 0:36 , Ryan Schmidt ryandes...@macports.org wrote:
If you have reason to believe that *only* llvm-gcc — not clang, not gcc —
will work, then ok, whitelist only llvm-gcc. That would be unusual, but maybe
openjdk is unusual in its compiler needs; I don’t know.
With a
On Dec 22, 2013, at 3:11 , Ryan Schmidt ryandes...@macports.org wrote:
Hey Ryan --
Thanks for looking into this.
This will unnecessarily make users of Xcode 5 install the llvm-gcc42 port,
when they have a perfectly good version of llvm-gcc42 provided by Xcode.
Rather than this, you should
Howdy all --
I think certsync is now ready to be relied on by default. Here's a brief status
update:
- On-demand Launching:
I've updated certsync to launch via launchd on-demand when relevant files
change, rather than staying memory-resident. This eliminates any sort of
potential runtime
[sorry for the delay, picking this up again post-holidays]
On Nov 29, 2013, at 3:38 , Ryan Schmidt ryandes...@macports.org wrote:
I’ve switched many of my MacPorts installs to certsync, including on Leopard,
but I don’t know if it’s working correctly (how would I test that?).
As long as
On Nov 28, 2013, at 10:32 , Rainer Müller rai...@macports.org wrote:
The only catch is that custom added certificates or trust anchors need
to be in the system keychain to be picked up by certsync by default.
Yeah, this was an unfortunate trade-off; since certsync is a system-wide
daemon,
that the user has added. This is the
case for many people who use internal CAs to sign certificates for their
corporate (or personal) services.
- Automatically updates when the System Keychain(s) or trust settings
are modified.
Thoughts?
-landonf
On May 13, 2013, at 21:39 , Landon Fuller land
On Nov 4, 2013, at 20:06 , Ryan Schmidt ryandes...@macports.org wrote:
... we’d really prefer them to uninstall and reinstall all ports.
Users *really* (and rightfully) hate this, especially when there aren't binary
packages available. For our local machines, we simply upgraded MacPorts base,
On Nov 17, 2013, at 14:02 , Chris Jones jon...@hep.phy.cam.ac.uk wrote:
Yes, there are. For instance the change in the default c++ runtime from
libstdc++ to libc++ with OSX 10.9. These two runtimes cannot reliably be
mixed, so rebuilding all ports is the only safe option. Yes, you might get
On Aug 28, 2013, at 19:47 , Ryan Schmidt ryandes...@macports.org wrote:
On Aug 28, 2013, at 15:48, Marius Coțofană wrote:
I have stumbled upon this [0]. It seems like the Homebrew guys
are using MacPorts' name in a bad way, thus generating negative
advertising for us.
I believe we can
On Aug 27, 2013, at 19:47 , Ryan Schmidt ryandes...@macports.org wrote:
On Aug 27, 2013, at 14:49, dev...@macports.org wrote:
Revision: 110171
https://trac.macports.org/changeset/110171
Author: dev...@macports.org
Date: 2013-08-27 12:49:23 -0700 (Tue, 27 Aug 2013)
Log
On May 23, 2013, at 5:00 AM, Ryan Schmidt ryandes...@macports.org wrote:
On May 23, 2013, at 05:54, Rainer Müller wrote:
I ran into this problem with the recent mercurial upgrade. I guess we
should rewrite this dependency such that it's satisfied by both ports:
depends_run
On Jul 30, 2013, at 14:31, Ryan Schmidt ryandes...@macports.org wrote:
On Jul 30, 2013, at 09:49, Landon J Fuller wrote:
Without actually measuring the gains, there's no guarantee that these
changes will actually improve performance, and in moving away from the
optimization flags et al
Howdy,
Over the weekend I whipped up (and added a port for) 'certsync'; it's a small
tool that fetches all trusted certificates from the Mac OS X system keychain,
and then spits them out as OpenSSL-readable pem-encode certificate bundle.
The goal was to provide a replacement for curl-ca-bundle
On Apr 8, 2012, at 8:42 AM, Rainer Müller wrote:
On 2012-04-08 13:57 , Clemens Lang wrote:
Not running rev-upgrade automatically will probably cause it never to be
run at all by the average user. We could run the analysis phase
automatically and instruct the user to issue port rev-upgrade to
On Oct 24, 2009, at 7:02 PM, Ryan Schmidt wrote:
On Oct 24, 2009, at 20:32, land...@macports.org wrote:
Revision: 59862
http://trac.macports.org/changeset/59862
Author: land...@macports.org
Date: 2009-10-24 18:32:20 -0700 (Sat, 24 Oct 2009)
Log Message:
---
Fix
On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote:
On Sep 17, 2009, at 10:36, alaka...@macports.org wrote:
If you need to create files (like config files) outside of the
destroot, you should do so in the post-activate phase, not in the
destroot phase.
I believe the (documented? defacto?)
On Sep 17, 2009, at 12:08 PM, Ryan Schmidt wrote:
On Sep 17, 2009, at 13:43, Landon Fuller wrote:
On Sep 17, 2009, at 8:44 AM, Ryan Schmidt wrote:
On Sep 17, 2009, at 10:36, alaka...@macports.org wrote:
If you need to create files (like config files) outside of the
destroot, you
On Jul 31, 2008, at 9:38 PM, Adam Mercer wrote:
On Thu, Jul 31, 2008 at 11:23 PM, Landon Fuller
[EMAIL PROTECTED] wrote:
On Jul 31, 2008, at 9:05 PM, Adam Mercer wrote:
On Thu, Jul 31, 2008 at 7:07 PM, [EMAIL PROTECTED] wrote:
3.0 's C-API is both API and binary compatible with the 2.x
On Aug 1, 2008, at 3:33 AM, Caspar Florian Ebeling wrote:
it just strikes me that there was this undocumented curl command in
Pextlib. I'll check it later, but
it sounds exactly like what I need...
Except then your fetch would be imperative instead of declarative, and
you'll skip some
On Jul 25, 2008, at 11:52 AM, Uwe Schwartz wrote:
Hi,
I would like to add a variant to a port which should create a
StartupItem.
In the MacPort Guide the example uses server as name for the
variant.
Is this common practice? Or are there any other suggestions?
I would suggest either
On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:
On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt
[EMAIL PROTECTED] wrote:
Do you mean to change the user's shell for them? It should be
possible with
NetInfo. But I don't think MacPorts should be the one to tell the
user what
shell to use.
On Jul 7, 2008, at 9:41 AM, Randall Wood wrote:
On Mon, Jul 7, 2008 at 12:02 PM, Landon Fuller
[EMAIL PROTECTED] wrote:
On Jul 7, 2008, at 3:18 AM, Randall Wood wrote:
On Mon, Jul 7, 2008 at 5:00 AM, Ryan Schmidt [EMAIL PROTECTED]
wrote:
Do you mean to change the user's shell
On Jul 3, 2008, at 11:25 PM, Adam Mercer wrote:
The recent changes to the swig port have broken the scipy build on
Tiger, essentially the problem is that scipy requires the python
variant of swig to be installed.
Swig's variants:
swig 1.3.36, devel/swig (Variants: universal, doc, python,
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 end-user.
With this:
- You never
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute.
It's not broken. It's just like a spell checker that gets annoyed when
you type colour instead of color.
-landonf
___
macports-dev mailing list
On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute.
It's not broken. It's just like a spell checker that gets annoyed
when you type colour instead of color.
Teams have style
On Mar 25, 2008, at 11:40 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:31 AM, Blair Zajac wrote:
Landon Fuller wrote:
On Mar 25, 2008, at 11:25 AM, Blair Zajac wrote:
How long does it take to fix it? One minute.
It's not broken. It's just like a spell checker
Any votes for/against creating an Erlang category, to match the Python/
Ruby/etc categories? First port I'd like to add is eunit 2.0 (erlang
unit test library).
-landonf
___
macports-dev mailing list
macports-dev@lists.macosforge.org
On Feb 6, 2008, at 13:23, Ryan Schmidt wrote:
There is no detriment that I can discern by naming patchfiles
patch-*.diff as port lint recommends. There is a detriment by not
following this convention which has been discussed at length before
on the list.
There is a detriment. The
On Jan 8, 2008, at 00:54, Markus Weissmann wrote:
This should definitely be made user-configurable. Most people will
actually be interested in building 32 and 64 bit for their machine,
that is either ppc+ppc64 or i386+x86_64.
Yes, please! 64-bit Intel is the only thing I need 'universal'
On Jan 5, 2008, at 1:42 PM, Ryan Schmidt wrote:
On Jan 3, 2008, at 05:11, Anders F Björklund wrote:
Ryan Schmidt wrote:
Perhaps, but these -devel ports usally build from tip of trunk so
they all had revision 0...
Ports should never build from tip of trunk or HEAD or similar
On Jan 2, 2008, at 10:40, Kevin Van Vechten wrote:
On Dec 31, 2007, at 3:26 PM, Landon Fuller wrote:
But HTTP digest doesn't solve any of the problems that SSL solves:
- It is still vulnerable to a MITM attack. Your password is
hashed, but the hash is password-equivalent -- an attacker
On Nov 8, 2007, at 08:58, Emmanuel Hainry wrote:
Dear list,
For a port I maintain (namely rubber), there are some patches
that upstream has not yet included and are provided by the
maintainer of
the port for pkgsrc. They are now in macports repository and I wonder
which
On Nov 9, 2007, at 15:16, Landon Fuller wrote:
On Nov 8, 2007, at 08:58, Emmanuel Hainry wrote:
Dear list,
For a port I maintain (namely rubber), there are some patches
that upstream has not yet included and are provided by the
maintainer of
the port for pkgsrc
On Sep 10, 2007, at 1:28 AM, Ryan Schmidt wrote:
On Sep 9, 2007, at 00:29, [EMAIL PROTECTED] wrote:
Revision: 28796
http://trac.macosforge.org/projects/macports/changeset/
28796
Author: [EMAIL PROTECTED]
Date: 2007-09-08 22:29:36 -0700 (Sat, 08 Sep 2007)
Log Message:
On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:
Very sorry! That was my fault. I've now fixed the svn:date
property of revision 2 so the log should work again. The timestamp
of revision 1 and revision 3 are identical, so I set revision 2 to
that same timestamp.
(I issued a bad svn
On Sep 7, 2007, at 09:43, Rainer Müller wrote:
Landon Fuller wrote:
On Sep 4, 2007, at 12:03 PM, Ryan Schmidt wrote:
Very sorry! That was my fault. I've now fixed the svn:date property
of revision 2 so the log should work again. The timestamp of
revision
1 and revision 3 are identical
On Sep 7, 2007, at 14:29, Blair Zajac wrote:
Landon Fuller wrote:
On Sep 7, 2007, at 09:43, Rainer Müller wrote:
It's nice to fix typos in log messages. But it could be limited to
svn:log for that purpose with a pre-revprop-change like this:
The log being unversioned, that still seems
On Sep 1, 2007, at 6:07 AM, Weissmann Markus wrote:
'portconfigure.tcl' from trunk will chose a default for darwin
7/8/9 (gcc3.3/4.0/4.0). Please test it! Just replacing /opt/local/
share/macports/Tcl/port1.0/portconfigure.tcl with http://
On Aug 30, 2007, at 11:09 AM, Anders F Björklund wrote:
I should have mentioned that the most annoying bug for all binary
targets (archive or package) must be: http://trac.macports.org/
projects/macports/ticket/10881
As noted in the bug, it requires you to -force the destroot
(usually
On Aug 28, 2007, at 1:58 PM, N_Ox wrote:
Le 28 août 07 à 04:00, [EMAIL PROTECTED] a écrit :
Revision 28311
Author [EMAIL PROTECTED]
snip/
+ system cd ${destroot}${prefix}/bin ln -sf ${nprefix}/bin/gcc-
apple-4.0 ln -sf ${nprefix}/bin/cpp-apple-4.0
snip/
Why don't you use cd and ln
On Aug 22, 2007, at 07:13, Daniel J. Luke wrote:
On Aug 22, 2007, at 5:34 AM, Randall Wood wrote:
Well, no, not really. Its just that I think that they are a really
bad way to physically organize the ports collection.
why?
I understand that categories are an important and useful tool for
On Aug 22, 2007, at 13:29, Ryan Schmidt wrote:
Since we're already on the topic of changes to the dports dir (see
Categories are evil), I'd like to propose that having 4000+ files
named Portfile is evil, too.
In Mac OS X, I can associate files with applications based on the
filename's
On Aug 20, 2007, at 8:17 AM, Rainer Müller wrote:
Daniel J. Luke wrote:
It makes sense to include NLS support by default in most ports.
I would like +nls variants, so people who want localized software
could
enable this in variants.conf.
I don't see any advantage to adding complexity
On Aug 16, 2007, at 10:55, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving
macports1.0 from the current @TCL_PACKAGE_DIR@ directory to the
@prefix_expanded@/share/macports/Tcl
On Aug 16, 2007, at 11:10, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 10:55, Blair Zajac wrote:
Landon Fuller wrote:
On Aug 16, 2007, at 02:15, Anders F Björklund wrote:
For MacPorts 1.6, it might be a good idea to consider moving
macports1.0 from the current
On Aug 16, 2007, at 12:10, Blair Zajac wrote:
I'm just trying to get a sense of what we're talking about here,
as we're discussing trade offs between competing concerns.
OK, then I'll simplify.
Arguments For Moving:
Developers can install multiple versions without passing --
On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:
I'm trying to figure out why you don't just fetch from CVS all the
time
Why do we allow fetching from CVS in the standard ports tree? There's
no way to validate the downloaded files (ie, checksums), and it's
completely non-deterministic.
On Aug 13, 2007, at 17:05, N_Ox wrote:
Le 14 août 07 à 01:49, Landon Fuller a écrit :
On Aug 10, 2007, at 18:17, Ryan Schmidt wrote:
I'm trying to figure out why you don't just fetch from CVS all
the time
Why do we allow fetching from CVS in the standard ports tree?
There's no way
On Jul 29, 2007, at 17:21, Blair Zajac wrote:
On Jul 29, 2007, at 4:11 PM, Ryan Schmidt wrote:
Here's a message from the -users list just now:
On Jul 28, 2007, at 18:39, Chris Waterson wrote:
Hey, I had the same problem. It turns out I was using an older
version of Xtools
On Jul 23, 2007, at 02:09, Elias Pipping wrote:
I chose a separate repository (and wiki) for a number of reasons:
* I do not like working with Trac (contrary to ViewVC and DokuWiki -
If I had needed a bug tracker I would have set up BugZilla, too)
* I did not want to spam
[from the correct e-mail address, this time]
On Jul 22, 2007, at 1:10 PM, Rainer Müller wrote:
Ryan Schmidt wrote:
You may also wish to check for compatible architecture in a different
way. Your way currently handles only on Intel Mac OS X, but
according to
the project's web site, it works
On Jul 16, 2007, at 20:03, Chris Pickel wrote:
Hi all,
12309 [1] - Currently we use sed to do some replacement in port,
portindex, and portmirror. I think autoconf is better suited to this.
Using make for this purpose ensures that the scripts are re-built
when their source is updated.
On Jul 4, 2007, at 03:00, Anders F Björklund wrote:
http://trac.macports.org/projects/macports/ticket/12168
Patch committed to trunk
http://trac.macports.org/projects/macports/ticket/12173
Outside of my immediate jurisdiction.
http://trac.macports.org/projects/macports/ticket/12212
I
On Jun 29, 2007, at 11:22 PM, Ryan Schmidt wrote:
On Jun 29, 2007, at 13:33, Landon Fuller wrote:
On Jun 26, 2007, at 11:39 PM, Ryan Schmidt wrote:
On Jun 25, 2007, at 09:46, Taylor R Campbell wrote:
There was some recent
discussion about a `ui_fatal' command by which to fail, although
On Jun 26, 2007, at 11:39 PM, Ryan Schmidt wrote:
On Jun 25, 2007, at 09:46, Taylor R Campbell wrote:
Actually, it occurs to me that it's not really necessary to declare a
dependency -- that it would suffice for the variant to have a command
that checks for the existence of an executable by
On Jun 21, 2007, at 02:45, Ryan Schmidt wrote:
On Jun 21, 2007, at 04:31, Ryan Schmidt wrote:
But could you please not output messages and exit merely in a
platform statement? Please do so only within a stage such as pre-
fetch, e.g.:
platfrom darwin 7 {
pre-fetch {
On Apr 16, 2007, at 10:30 PM, Kevin Ballard wrote:
Yeah, I know, but the fact of the matter was nobody used find, and
I mean nobody. And the other part is that, in general, it's far
more conducive to stop thinking of code as my code or his code
and to think of it simply as project code.
On Apr 17, 2007, at 03:48, Ryan Schmidt wrote:
Portfile = svn:eol-style=native;svn:keywords=Id
For consistency and conformance with the Subversion documentation
let's please use Id, not id, for the keyword name.
This recommendation should probably be in the documentation
somewhere but
On Apr 17, 2007, at 14:33, Ryan Schmidt wrote:
On Apr 17, 2007, at 16:19, Landon Fuller wrote:
I once said I would work on a pre-commit hook script we could
install which would reject any commit that did not conform with
these requirements. I haven't gotten around to that yet, but I
On Apr 7, 2007, at 5:10 PM, Jordan K. Hubbard wrote:
Actually, Apple has always traditionally reserved uids 500 for
its own use. We simply haven't passed 100 yet. :-)
- Jordan
On Apr 7, 2007, at 11:52 AM, [EMAIL PROTECTED] wrote:
nextuid and nextgid now return the first uid/gid 100
On Apr 9, 2007, at 12:46 AM, Ryan Schmidt wrote:
My preliminary patch for php5 is attached to this ticket:
https://trac.macosforge.org/projects/macports/ticket/8599
However I still need a fix that will let it work with either MP
1.4.0 or trunk.
Also would like advice regarding any ways
On Apr 9, 2007, at 10:17, [EMAIL PROTECTED] wrote:
But the disadvantage, as opposed to a Wiki, is that joe user can't
make
changes to the docs. And that is what people want. Although I
wonder if
we have Joe user contributing to the docs if it will really be
better. It
may be, I just
On Apr 9, 2007, at 02:22, Ryan Schmidt wrote:
$ cd doc/guide
$ make
xmllint --xinclude --noout xml/guide.xml
http://www.oasis-open.org/docbook/xml/4.2/dbpoolx.mod:99: parser
error : Content error in the external subset
!ENTIT
make xhtml
or make html
Try adding --nonet to the xsltproc
On Apr 4, 2007, at 01:49, Randall Wood wrote:
Are there any mechanisms in place to take advantage of the
portindex -a option?
Or if I have a collection of the archives created with that option
how would I use them?
I implemented the -a option and HTTP port archive fetching in 2002,
On Apr 4, 2007, at 04:21, Yves de Champlain wrote:
Le 07-04-04 à 04:30, Randall Wood a écrit :
What's the best way to do this?
I have seen calls in ports doing this in the past like:
pre-install {
system port -f uninstall xxx
}
Which is not really the way to do it. Clearly the
On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:
zlib +universal worked fine in MP 1.3.2 until the portfile was
declared to be too ugly and got totally rewritten... I'll have more
to say about that in a moment.
No, it did not.
The port broke because the 'command' private API was used.
On Apr 1, 2007, at 11:34 AM, Landon Fuller wrote:
On Apr 1, 2007, at 10:43 AM, Ryan Schmidt wrote:
zlib +universal worked fine in MP 1.3.2 until the portfile was
declared to be too ugly and got totally rewritten... I'll have
more to say about that in a moment.
No, it did
I received a bug report about the zlib port not working -- it was
modified to use private API in an attempt to hack in Universal support.
The port, which I originally wrote in 2003, went from this:
http://trac.macports.org/projects/macports/browser/trunk/dports/
On Mar 31, 2007, at 11:20 AM, Mark Duling wrote:
macports-dev@lists.macosforge.org on Saturday, March 31, 2007 at
10:25 AM
-0800 wrote:
Revision
[ http://trac.macosforge.org/projects/macports/changeset/23415 ]23415
Author
[EMAIL PROTECTED]
Date
2007-03-31 10:25:27 -0700 (Sat, 31 Mar 2007)
On Mar 31, 2007, at 2:38 PM, Jordan K. Hubbard wrote:
Which private API are you referring to?
I know that the port was *broken* until I changed it to use the
right command API, but that had nothing to do with building
universal, that was a very hacky way of building the static archive.
On Mar 27, 2007, at 14:37, Ryan Schmidt wrote:
No... MacPorts just needs to write some things in /Library/Tcl/
darwinports1.0, that's all. But I don't know why it thinks it needs
to do that.
MacPorts uses the system-supplied Tcl interpreter, and /Library/Tcl
is the standard location for
On Mar 3, 2007, at 12:49 PM, James Berry wrote:
I'm quite distressed by the concept of too much work (and too much
ugly code) going into building +universal variants of ports.
I'd like to see people refrain from completely bastardizing
portfiles in order to support universal builds. Let's
On Feb 22, 2007, at 3:15 AM, Weissmann Markus wrote:
On 22.02.2007, at 03:54, Randall Wood wrote:
On 21 Feb 2007, at 20:43, Landon Fuller wrote:
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a
python 2.5 port
On Feb 21, 2007, at 15:43, Weissmann Markus wrote:
Hi Douglas,
the soon-to-be-released version 1.4 of port will come with a python
2.5 port group. This will allow us to quickly produce all the
python vastness for python 2.5, too.
This might be a chance for newcomers to start coding
On Feb 13, 2007, at 12:20, Kevin Ballard wrote:
I'm just going to point out that all of the base/ files I've looked
at have the following at the top of the file:
# et:ts=4
What that does is, in vim, sets 4-width soft tabs. Sounds like
whomever created these files in the first place
On Feb 4, 2007, at 02:15, Juan Manuel Palacios wrote:
On Jan 30, 2007, at 8:07 PM, Blair Zajac wrote:
If you don't specify --tclpackage, then it may end up being /
Library/Tcl or /System/Library/Tcl.
I sometimes do multiple installs of MacPorts on the same box and
it would be nice to
On Feb 3, 2007, at 8:00 AM, Randall Wood wrote:
ALCON:
Recently a number of ports required for GNOME programs were broken
for PowerPC (G3/4/5) platforms (for about half these ports, this
break was from fixing problems on the Intel platform). I am
attempting to track down working fixes
On Feb 1, 2007, at 10:04 PM, Paul Beard wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Feb 1, 2007, at 9:59 PM, Landon Fuller wrote:
What version of gcc / Xcode?
I was all prepared for an aha moment, but I have the same version
on both systems:
Component versions
On Jan 24, 2007, at 15:48, Paul Guyot wrote:
I don't know why, but I thought there was a good reason for the
presence and use of a native replacement. Maybe when the readdir
command was developed, it was in the Tcl 8.2.x area and glob didn't
take the -directory option.
As I recall, that
85 matches
Mail list logo
