On Nov 14, 2008, at 6:30 PM, Vincent Lefevre wrote:
Here (10.4.11) "open" doesn't take arguments:
prunille:~> open -a /Applications/MacPorts/Emacs.app -nw foo
2008-11-15 03:22:26.754 open[4228] No such file: /Users/vinc17/-nw
Well, I have not run 10.4 for a number of years now, but it certai
[Adjusting topic to be a bit more descriptive of the current discussion]
On Nov 8, 2008, at 2:53 PM, Ryan Schmidt wrote:
There is a function fs-traverse in MacPorts designed for this. Grep
through the existing portfiles to see how this can be used.
As one of the authors of that function, I'd
On Nov 5, 2008, at 10:27 PM, Ryan Schmidt wrote:
Hypothetical additional phases before the fetch phase would not
cause problems for the existing strategy. The point of checking and
bailing before the fetch phase is that we don't want someone
downloading a large file if we already know they
On Nov 5, 2008, at 9:59 PM, Ryan Schmidt wrote:
Yes, using pre-fetch to print out fatal error messages has been the
recommendation until this point, and it works fine.
Sure, it works fine, right up until the point where someone invents a
"sniff" target stage (for security, of course) and sa
On Nov 5, 2008, at 9:38 PM, Ryan Schmidt wrote:
You can do something like
platform darwin 7 {
pre-fetch {
return -code error "${name} requires Mac OS X 10.4 or later"
}
}
Ooh. People are using pre-fetch as an "initializer" for the
Portfile? Ugh. I never
On Oct 21, 2008, at 1:33 AM, Ryan Schmidt wrote:
> The feature uses launchctl, not apachectl, pcastctl or any other.
> The arguments to launchctl that we use are load and unload, so
> that's what the arguments to the port command were called as well.
>
> We could discuss changing load/unload
On Oct 21, 2008, at 12:36 AM, Ryan Schmidt wrote:
> One often has the need to load and unload services at times other
> than activating and deactivating a port. For example, ports are not
> loaded when they are initially installed, because some initial setup
> might need to be done manually
On Oct 20, 2008, at 3:15 PM, Ryan Schmidt wrote:
> We added "port load" and "port unload" to 1.7. What I think we should
> still do is call "port unload" automatically before we call "port
> deactivate" (if the port was loaded), and then after "port activate",
> we should automatically call "port
Awesome! I would like to suggest to the new PortMgr team that, as
their first official act, they quickly appoint some folks to do
Release Engineering duties before those someones change their minds. :-)
- Jordan
On Oct 14, 2008, at 6:39 AM, James Berry wrote:
> The (current) PortMgr team is
(http://en.wikipedia.org/wiki/Gordian_knot)
Having just read jmpp's request for "a bit more time" to sort out a
voting process, I must confess to feeling more trepidation than
assurance. To be completely fair, he does note several times that he
and the rest of the moribund portmgr team wou
On Oct 7, 2008, at 9:35 PM, Ryan Schmidt wrote:
> For the next release, I think we need version 1.7.0, not 1.6.1,
> because there are countless new features and a year's worth of bug
> fixes. That much work deserves more than just a bugfix version number
> increase. That means we release from tru
On Oct 7, 2008, at 7:36 PM, paul beard wrote:
FAIL.
There has been a release manager and portmgr@ team for quite some
time and this bug lingers, festers even.
I don't know which reality you have been living in, but I think the
weight of evidence points to exactly the opposite conclusion:
On Oct 6, 2008, at 11:13 AM, Daniel J. Luke wrote:
> On Oct 6, 2008, at 1:41 PM, William Davis wrote:
>> Pardon me for speaking frankly but! "to solve this problem
>> permanently" will take an updated version of port with the bug fix in
>> place. This situation has gone on for many months now and
On Sep 30, 2008, at 9:18 AM, James Berry wrote:
> We have asked Jordan Hubbard, the father of MacPorts, to join us on
> the Elder Council, and he has given his tentative acceptance.
First, let me thank James, Markus and Juan for having both the insight
and the courage to recognize their own
On Jul 11, 2008, at 9:04 PM, Tabitha McNerney wrote:
> So does this mean that Apple has modified the standard Kerberos open
> source code with something proprietary that is non-discoverable (the
> Kerberos open [ ... ]
http://www.opensource.apple.com/darwinsource/10.5.3/Kerberos-75.10.3/
MI
On Jun 11, 2008, at 11:51 PM, [EMAIL PROTECTED] wrote:
> So are you saying that you think "MacPort" is a valid term? I was
> thinking it wasn't an accepted and/or used term. If folks think it
> is, I
> can stop flipping between using "MacPorts port" (mostly in intro
> parts)
> and "port" in
On Jun 11, 2008, at 3:49 PM, Ryan Schmidt wrote:
> That can be our new verb. "I need to emport that new software."
>
> A noble spirit embiggens the smallest man...
OK, consider my mind changed in just 2 lines. :-)
- Jordan
___
macports-users mailing
On Jun 11, 2008, at 10:33 AM, Rainer Müller wrote:
> I dislike 'MacPort', but I like the term 'mport'.
I dunno, that just doesn't seem to roll off the tongue and also
suffers from excessive contraction at the wrong place. If, for
example, you were trying to come up with a more convenient wa
On Jun 11, 2008, at 1:18 AM, Martin Krischik wrote:
> From my quick check I also noted that MacPorts clearly is the largest
> Project on MacOS Forge ao we might as well take the lead.
Actually, I believe that honor goes to WebKit. :-)
It would be nice to have some pageview stats to back that up
On Jun 10, 2008, at 11:32 PM, Ryan Schmidt wrote:
> The proposed new wiki was to be a global Mac OS Forge documentation
> wiki, not a MacPorts-specific wiki. I'm still not a fan of the idea.
> Do we really want to spend the time and energy converting content
> from the MacPorts Trac wiki to a Mac
On Jun 10, 2008, at 11:23 PM, Martin Krischik wrote:
Note that MediaWiki supports up to 256 name spaces. For example on
wikibooks the cookbook runs in it's own name space:
http://en.wikibooks.org/wiki/Cookbook
I think it would be a good idea to have one wiki for - including the
homepage. It j
On Jun 10, 2008, at 9:27 AM, Lorin Rivers wrote:
Leaving aside the issue of what the best platform for sharing the
info might be. If nobody knows it's there, the kick-assingest wiki
server the world has or will ever see is not going to address my
suggestion in the slightest.
Well, to be
On Jun 5, 2008, at 4:58 PM, Rainer Müller wrote:
We already have spread our website over enough different places.
There is macports.org, trac.macports.org and guide.macports.org (and
the upcoming MPWA at db.macports.org). It is already hard enough to
find the relevant information one is lo
o do and then do them are VERY
> GOOD.
>
> I like simple and straightforwards.
>
> Also, how to recover from errors are very good. I plan on having
> virgin OS X installs set up to make sure these HowTos work from a
> new install.
>
> - Zav
>
> On Jun 5,
On Jun 5, 2008, at 8:42 AM, Lorin Rivers wrote:
> Awesome! I did not even know about these How To's.
>
> You know, it's actually kind of hard to find them, if you don't know
> about where they are in the first place. I think they deserve more
> prominence. There should be a link from the docu
Never mind on this - I just read the follow-ups. I still think this
is a really dangerous thing to do, but since the original poster
realizes this also, I'll not belabor the point.
- Jordan
On May 29, 2008, at 7:35 PM, Jordan K. Hubbard wrote:
> I'm not sure I understand what
I'm not sure I understand what point you're trying to make. If you
put anything in /usr outside of /usr/local, since the very first
release of MacOSX the rule has always been "you're living on borrowed
time and at your own risk" since Apple, like every other OS vendor on
the planet, reser
On Mar 29, 2008, at 3:36 PM, Emil Lundberg wrote:
Still failing to get 64-bit MacPorts to work properly, I though I'd
relay my progress so far. The short story is some ports do not
compile properly as ppc64. Others do, but don't compile properly on
x86_64. I'm prepared, of course, to notif
On Mar 8, 2008, at 7:48 PM, Bill Hernandez wrote:
> There were a few of things I did not like about Leopard :
>
> ( 2 ) Translucent Menu Bar (fixed in script finder_utility.scpt)
You don't need a script. You just need to update to 10.5.2 and use
the Desktop preference pane.
Since emacs is al
On Feb 24, 2008, at 9:29 PM, Rainer Müller wrote:
> Jordan K. Hubbard wrote:
>>> All distfiles in one single directory? I am against that at all!
>> Why? Collisions? If so, please name the collisions in question,
>> because I cannot find any.
>
> Maybe not ye
On Feb 24, 2008, at 7:46 PM, Rainer Müller wrote:
> Jordan K. Hubbard wrote:
>> On Feb 23, 2008, at 8:05 AM, William Siegrist wrote:
>>> So whats left? I think you'll want a special hostname for these?
>>> Maybe http://distfiles.macports.org///?
>> I'
On Feb 23, 2008, at 8:05 AM, William Siegrist wrote:
So whats left? I think you'll want a special hostname for these?
Maybe http://distfiles.macports.org///?
I'm not sure what value adds. / would seem more
than reasonable, and a completely flat namespace even more so since it
then beco
On Feb 22, 2008, at 11:51 PM, Anders F Björklund wrote:
> Before fetching all the files, it would probably nice to fix the
> timestamps so that they correctly reflect the upstream distfile ?
I guess I'm missing something. Why is this important? Distfiles are
essentially opaque to the MacPor
On Feb 22, 2008, at 9:34 PM, William Siegrist wrote:
> We dont really see any dips in server load, so waiting until night
> (or any time in particular) doesnt buy us anything. I'm assuming
> you still agree with only fetching distfiles when they change, and
> we already have all the work d
On Feb 22, 2008, at 8:08 PM, William Siegrist wrote:
> The server would grab distfiles during post-commit I imagine
> (assuming the checksums get changed, patchfiles added, etc). So
> similar to the way we handle linting of Portfiles during post-
> commit, we would check for these changes.
On Feb 22, 2008, at 7:11 PM, Rainer Müller wrote:
> One of these things would be how we would push files on the mirror?
> If we keep master_sites we could use something like `port fetch all'
> in a cronjob or in a post-commit hook. But that will have the
> problem that it currently port fetc
On Feb 22, 2008, at 11:35 AM, Ryan Schmidt wrote:
>> The macports repository is the only place macports is looking for it,
>> so it must have been there at some point or the port would never have
>> passed even the most rudimentary QA.
>
> No, the first place it's looking for it is the ntfs-3g we
On Feb 17, 2008, at 7:40 PM, Esteban Barahona wrote:
> That may be the main objective, but why not also support darwin
> without the propietary parts of Mac OS X? As I understand it, if it
> runs on Darwin it must run on Mac OS X... but I guess it's CLI-only
> apps...
Because it's more w
On Feb 17, 2008, at 2:42 PM, Anders F Björklund wrote:
> The project doesn't seem to have decided yet whether it wants to
> provide the best possible Mac OS X experience, or whether it wants
> to e.g. provide its own bootstrap versions of all the required
> system libraries and binaries ?
Given that they haven't posted any updates to their site in over a
year, it's probably fair to say that it's mostly just a domain name at
this point.
This topic was, in any case, hashed out rather thoroughly back when
the project changed its name from DarwinPorts to MacPorts. GIven the
I don't see any point in supporting Pure Darwin for any reason at this
point. You're talking about an installed base of what - 20 people?
50? 100 tops? I can think of more Amiga Unix users than that.
- Jordan
On Feb 17, 2008, at 12:25 AM, Ryan Schmidt wrote:
> On Feb 17, 2008, at 01:40,
On Feb 7, 2008, at 2:45 AM, Jochem Huhmann wrote:
There's no way to take that further (in the file system) by
integrating even more useful fuzziness like recognizing "f" for
"ph", or ignoring accents or whatever. If you're dealing with
international users a case insensitive file system may
ystem was case insensitive when I got my first Mac (a
PowerBook three years ago).
On Feb 6, 2008 2:31 PM, Jordan K. Hubbard <[EMAIL PROTECTED]> wrote:
That's a fair point. Perhaps better to format a "work" partition
as HFSX
then and keep the system partition as HFS. That wa
al Interactive - XIII - Game can't run when installed on case-
sensitive filesystem.
And I keep finding more and more of them. :(
Scott
PS> Anyone else find any issues with Applications or Games?
Jordan K. Hubbard wrote:
On Feb 6, 2008, at 6:28 AM, Jeffrey Goldberg wrote:
The only p
On Feb 6, 2008, at 6:28 AM, Jeffrey Goldberg wrote:
The only problem that I've ever had (and I'm no expert either) is
when I'd installed
the perl script for fetching HTTP headers in
/usr/local/bin/HEAD
That's easily remedied by using the new[er] case-sensitive variant of
HFS (also known
*sigh*
If Linus Torvalds had said that HFS ate babies and eroded the moral
fiber of the nation's youth, would you still be asking this question?
Probably not, since that would be clearly recognizable hyperbole.
Him saying it's "complete and utter crap" without any supporting
evidence o
I don't know where your /Applications/Emacs.app came from, but it
wasn't Apple. You must have installed it at some point in the past
and then nuked its support files or something. I would, in any case,
delete it since you don't know how it got there. :)
- Jordan
On Feb 5, 2008, at 9:46 A
On Feb 5, 2008, at 12:32 AM, Jochen Küpper wrote:
The leopard shipped emacs is linked with Carbon. You don't NEED X
for that version if you use the app wrapper I sent out - it
supports the NATIVE window system.
How is one supposed to find that out?
Run emacs. :-)
If you look at the sta
am I being paid to support anything but the most
MacOSX-centric configuration, which does not mean emacs/x11).
- Jordan
On Feb 4, 2008, at 4:23 PM, Rob MacLeod wrote:
Huh? Because I like X11 for certain apps, I am supposed to run
Linux? Is this supposed to be a joke or a snide remark?
On Feb
2008, at 6:19 AM, Mark Evenson wrote:
Jordan K. Hubbard wrote:
OK, I'll bite. What specifically is wrong with the system emacs
that requires folks to struggle so hard to build another copy?
It even supports carbon if you add an app wrapper (like the one I
just attached - a mere 55k, a
On Jan 20, 2008, at 6:34 AM, Michael Franz wrote:
While trying to configure IcedTea, I found that although lesstif is
a dependency, I was not able to get configure to be happy until I
installed openMotif.
You might want to file a bug report on that - looks like the IcedTea
maintainer sim
unnecessary complexity? We
have too many rules we have to remember. Where oh where is my
missing friend in Leopard's local directory domain named, "_ldap"?
Thus as a result, the openldap MacPort created a separate user
account named "ldap". Ugh!
Thanks,
T.M.
On 1
On Jan 6, 2008, at 1:47 PM, Tabitha McNerney wrote:
Guido, this is fascinating! I was not aware of the command-line tool
named "extract". I don't see it in my PATH on either my Tiger Server
or Leopard Server system. I also don't see "extract" as a MacPort as
in:
"port help" is the comman
This is because the original designers of Unix neglected to take into
account the notion of user namespaces - the namespace is flat. That
means that system or role specific names can conflict with names that
users would like to use for themselves (c.f. "admin" or "operator")
unless you ado
On Jan 3, 2008, at 3:01 AM, Tabitha McNerney wrote:
Thank you for providing a reality check (and thanks to Apple for
modifying Leopard's Tcl to speed things up). I wonder then, will
having a 64-bit operating system with 64-bit tools ( e.g., Xcode)
assist anywhere in the process of compilin
[ Resent from correct account, so MacPorts won't bounce it back again ]
On Jan 2, 2008, at 12:22 PM, Tabitha McNerney wrote:
Has anyone else noticed incredible MacPorts speed up improvements
when installing various ports?
Here's an example: The same hardware (Xserve Intel 2 x 2 GhZ Dual
Co
On Jan 1, 2008, at 8:01 PM, Tabitha McNerney wrote:
Jordan, appreciate the further clarity. Quick question then (just to
make sure I'm ultra clear) -- even if a MacPort installs a new entry
in the local directory domain with a "Crypt Password" type, what
you're saying is that in reality, u
On Jan 1, 2008, at 4:14 PM, Ryan Schmidt wrote:
As I explained, "Ports that depend on XFree86 only do so in the
event that you have not installed Apple X11." To take your example
of pango, look at how the dependency is defined in the pango portfile:
I think Tabitha's question suggests anot
n
On Jan 1, 2008, at 3:09 PM, Tabitha McNerney wrote:
On 1/1/08, Jordan K. Hubbard <[EMAIL PROTECTED]> wrote:
Let's ask a different question: What are you trying to achieve?
- Jordan
Hi Jordan,
You raise a good question, about what I am trying to achieve. My
concern is that, after
Let's ask a different question: What are you trying to achieve?
- Jordan
On Jan 1, 2008, at 2:04 AM, Tabitha McNerney wrote:
Hello all --
I am happily running Leopard Server and installing MacPorts 1.6.0.
Some of the ports install users in the local directory domain (with
Leopard Apple h
On Dec 15, 2007, at 11:25 AM, Charlse Darwin wrote:
Why isn't darwinbuild available as a port? and if I run
No one has written one yet. The ports don't write themselves. :)
svn co http://svn.macosforge.org/repository/darwinbuild/trunk
darwinbuild
how do I go about building and running d
On Nov 16, 2007, at 1:22 PM, Randall Wood wrote:
Note that Mac OS X 10.4 ships with python 2.3. Don't know what
version 10.5 ships with.
2.5.1
___
macports-users mailing list
macports-users@lists.macosforge.org
http://lists.macosforge.org/mailman/
On Oct 8, 2007, at 3:04 PM, Charlie Kester wrote:
If Ryan's advice above is really what the MacPorts community
recommends, then I'm going to start ripping out every MacPorts
package from my machines and download the tarfiles to build and
install manually. It sounds like you have a serious
On Aug 20, 2007, at 7:01 AM, N_Ox wrote:
Maybe we could use ProcFS with MacFuse, and then install htop.
That would be an almost heroic exercise in impedance matching.
Still, I wish you luck with that. :)
- Jordan
___
macports-users mailing li
On Aug 20, 2007, at 5:38 AM, Richard Bronosky wrote:
Thanks for going through the effort to try it out! I figured that a
proc monitor was doing some kernel leve stuff and wouldn't compile
on a foreign kernel, so I didn't even try. By "port... foe the Mac"
I meant simply port, not MacPort
On May 30, 2007, at 9:40 AM, paul beard wrote:
I'm getting a sense that people who use double-clickable installers
are somehow not "our sort of people." Goodness knows we can always
use more snobbery ;-)
I wouldn't argue that at all. I would instead argue that MacPorts is
simply not REA
[ Ah, I love nothing better than a lengthy rant! Here's a lengthy
reply to go with it... ]
On May 18, 2007, at 10:57 AM, Bill Hernandez wrote:
Over time I've installed so many different versions software
(mostly Apache, php, pgsql, and a myriad of dependencies) in the
form of binaries &
On May 14, 2007, at 2:07 PM, Rick Gigger wrote:
So it is possible to create packages with macports but right now
there is a bug that is preventing it from correctly tracking
dependencies. Is that correct?
But once that is fixed I should be able to specify all of the ports
that I want in
On May 8, 2007, at 5:48 AM, Marc André Selig wrote:
I just tried that. It seems not to work quite as anticipated.
$ sudo port mpkg gnucash +guile16
... results in port packaging guile instead of guile16, which makes
the resulting package useless.
It seems as if port mpkg follows the origina
On May 7, 2007, at 7:23 PM, Ryan Schmidt wrote:
Such a format does exist: It's called a .pkg file and you interact
with them every time you install an Apple software update. However,
I don't think there's any functionality in MacPorts to create or
use package files.
Oh really?
[EMAIL PR
On May 7, 2007, at 1:27 AM, Ryan Schmidt wrote:
Perhaps. But note that Apple used to specifically tell you not to
use case-sensitive HFS+ for your boot volume in the 10.3 days. See
the first paragraph:
http://docs.info.apple.com/article.html?artnum=107863
While this is true, "Apple" also
My bigger question is how people are managing to use anything
depending on fuse at all, at the moment. On 10.4.9, I get the
following build error for libfuse:
/opt/local/var/db/dports/build/
_User_jkh_Src_macports_dports_fuse_fusefs/work/fusefs/fuse_knote.h:
17: error: redefinition of 'str
I think all we know by the evidence so far is that puredarwin.org is
a web site. I've spoken to the people behind it and said I'd check
back with them in a year since, by all indications, it appears to me
that they are at least a year off from becoming anything
substantially more than a w
On Apr 26, 2007, at 4:00 PM, Ben Byer wrote:
Right. I do have some simple portfiles up at http://
gitweb.freedesktop.org/?p=users/bbyer/dports.git;a=tree;f=x11 .
My question might better have been phrased "How do I make portfiles
with multiple configure steps?" Even pointing me at some ot
On Apr 25, 2007, at 5:08 PM, Yves de Champlain wrote:
*delurk*
Being curious by nature, what does this mean ?
It means he's no longer lurking.
I'd like to eventually submit these for inclusion in MacPorts to
replace the broken xorg port that currently exists. As it stands,
I wasn't ab
Known problem, I'm afraid. Fixed in next release. :)
- Jordan
On Apr 22, 2007, at 6:03 PM, Fred Dushin wrote:
I am finding that sniffing packets (promiscuous mode) in wireshark
kills my wireless connection.
I can bring wireless back up, but I get an initial failure,
whereupon "Try Again"
ses. :-)
- Jordan
On Apr 18, 2007, at 1:07 PM, Jordan K. Hubbard wrote:
On Apr 17, 2007, at 10:38 PM, David Liontooth wrote:
There are several versions of X11 for OSX -- the one Apple
distributes,
and in macports, xfree86 and xorg, both in several variants. Could
someone give us a summ
On Apr 17, 2007, at 10:38 PM, David Liontooth wrote:
There are several versions of X11 for OSX -- the one Apple
distributes,
and in macports, xfree86 and xorg, both in several variants. Could
someone give us a summary of the state of X11 on OSX? What should be
used when? Where are we headed?
(ref: http://www.bikeshed.com/)
I love little discussions like this because:
A) The people involved generally feel very strongly about the issue
in question and get offended when you point out that, in the greater
scheme of things, 6 billion other people could genuinely give a damn
about
On Mar 12, 2007, at 1:47 PM, Ryan Schmidt wrote:
Seems to me that it would be ideal if I could have version A of a
library installed, then install a whole bunch of software that
depends on that library. Then install a new version B of the
library which breaks backward compatibility. Keep bo
On Mar 10, 2007, at 8:04 AM, Daniel J. Luke wrote:
You'd prefer that burden be foisted on the users, eh? Those who
are perhaps least qualified to diagnose and fix the problem? :-)
Or who are perhaps most qualified to make intelligent choices of
what should be installed and upgraded at w
On Mar 10, 2007, at 8:03 AM, Daniel J. Luke wrote:
I'm sure you meant that in jest, but actually, that assertion is
completely correct. In order to install all at the same time, we
require the user to take the hit of figuring out how to invoke the
others.
And any other method of choos
On Mar 9, 2007, at 10:58 AM, Daniel J. Luke wrote:
That's not how image mode works now - and I'm not sure that we want
to impose the burden of verifying abi/api compatibility between
releases on every portfile author (if we were to add hooks to make
things work that way).
You'd prefer tha
On Mar 9, 2007, at 6:53 AM, Daniel J. Luke wrote:
Here's another variant of that:
1 - libfoo.dylib v. 1.0 comes out and it is so good that everyone
starts writing apps that use it.
2 - a serious security flaw is found in libfoo and is fixed in
libfoo v. 1.1 with no api/abi changes
3 - oh n
On Mar 8, 2007, at 4:21 PM, Yves de Champlain wrote:
Sorry, but I really have a hard time following you here and reading
this leaves me with a deep feeling of deeply missing the whole point.
I understand that the current image implementation is a step in
walk to something else that will so
P.S. Remember the very recent thread about python 2.4 vs python
2.5? Same issue we're talking about.
On Mar 8, 2007, at 10:05 AM, Daniel J. Luke wrote:
On Mar 8, 2007, at 10:30 AM, Yves de Champlain wrote:
Are there people out there who really use the image installations ?
I mean, who are
On Mar 8, 2007, at 10:05 AM, Daniel J. Luke wrote:
The one thing we would loose is the potential for ports to depend
on a specific version of another port that was installed but not
'active' (ie, you could have multiple versions of some library port
installed with ports that needed each ve
On Feb 23, 2007, at 5:21 PM, Altoine Barker wrote:
Jordan, I did not intend for it to be viewed as a optional frill, but
more an option in the sense that the "no-option choice is for the
single
user" and the "optional" choice is for people with either both
architectures or developers of prod
On Feb 23, 2007, at 11:36 AM, Ryan Schmidt wrote:
Now, what we could think about doing is providing some kind of
default, where +universal would use the standard CFLAGS, LDFLAGS
and --disable-dependency-tracking, unless the port itself defines a
+universal variant. This would allow many po
n
available to
test but I can not start or join such an endeavor until I finish a few
that I have now.
Jordan K. Hubbard wrote:
Is that one of them-there rhetorical questions? :-)
There are lots of good reasons to want universal binaries. For
one, it
allows you to NFS/AFP/... share a singl
There is a corollary to this, which is even if you do bundle up the
appropriate MacPorts bits, you're now polluting a namespace that's
not really under your control. A commercial company who shall remain
nameless found this out to their displeasure when they shipped
software which installe
Is that one of them-there rhetorical questions? :-)
There are lots of good reasons to want universal binaries. For one,
it allows you to NFS/AFP/... share a single /opt/local among machines
(who says that directory always has to be local?) without having to
worry about which architecture
dence of bugs you've already reported not being
fixed, I need radar #s so that I can track them down. Thanks.
- Jordan
On Jan 29, 2007, at 4:48 PM, Vincent Lefevre wrote:
On 2007-01-29 12:22:47 -0800, Jordan K. Hubbard wrote:
I haven't seen any radars on it... If you want Apple to u
I haven't seen any radars on it... If you want Apple to update its
ncurses, you need to tell us where and when it's broken. We don't
just update stuff for fun - that only annoys people and increases the
likelyhood that we'll break something. If, on the other hand, we
have compelling reas
On Jan 2, 2007, at 2:08 PM, Kevin Ballard wrote:
If you're going to distribute software, you don't want to build it
with macports (because all the linker paths will be absolute and
pointing at /opt/local, which is not how you want to distribute
anything). Because of this, I don't think cro
I also see the hang (both Tiger and Leopard) . It's hanging here:
#0 0x90020d71 in __findenv ()
#1 0x900023dc in getenv ()
#2 0x900a4c24 in _st_tzset_basic ()
#3 0x90013723 in tzset ()
#4 0x9008c61c in strftime_l ()
#5 0x9008c875 in strftime ()
#6 0x0026c77a in Perl_my_strftime ()
#7 0x
96 matches
Mail list logo
