On Aug 16, 2011, at 8:30 PM, Dan Ports wrote:
On Tue, Aug 16, 2011 at 09:00:45PM -0700, M.E. O'Neill wrote:
The errors I discovered were:
biblatex-biber -> piblatex-module-build
p5-list-uniq -> p5.12-list-uniq
pemail -> p5.12--mail-pop3client
pemail -> p5.12--m
On Tue, Aug 16, 2011 at 09:00:45PM -0700, M.E. O'Neill wrote:
> The errors I discovered were:
>
> biblatex-biber -> piblatex-module-build
> p5-list-uniq -> p5.12-list-uniq
> pemail -> p5.12--mail-pop3client
> pemail -> p5.12--mime-lite
> pemail -> p5.12--term-readkey
When is the depends_build keyword necessary? For example, the reduce-algebra
build doc has this:
GNU make (other versions of "make" are not liable to work), autoconf
and automake. Well you can probably survive without having autoconf
and automake, but if you have them you should use a
In the course of plotting the MacPorts dependency graph for my own edification,
I discovered that there are some ports that have incorrect dependencies (i.e.,
they depend on ports that don't exist). For the most part, these appear to be
typos or name changes that were not updated everywhere.
T
Joshua Root wrote:
> I agree the FAQ entry could do with a rewrite to use less dismissive
> language. Patches welcome. ;-)
I don't think you want a patch from me. I'd replace it with the following
attempt at humor:
;-)
MacPorts is a bit like a cult. You need to really commit it it. One day,
On Aug 16, 2011, at 18:55, M.E. O'Neill wrote:
> I suspect it'll be much the way it is with Flash now -- Apple used to provide
> it, now you have to go to Adobe to download it. (Or maybe MacPorts has
> ambitions to provide GNU Gnash as the system flash player too.)
I actually started looking
Some recent MacPorts changes (using a different compiler based on the Xcode
version, and distributing binaries) are causing problems for ports that use
libtool (and other ports).
At build time, libtool records into itself the contents of the $CC variable.
And the value of the $CC variable at li
Jonathan Stickel wrote:
> I think what you are asking for is the intent of "Homewbrew":
>
> http://mxcl.github.com/homebrew/
>
> Now, I have only read about Homebrew and haven't tried to use it, but I can
> imagine all kinds of gotchas that might arise.
Because what the Mac really needed
On Aug 16, 2011, at 17:52, M.E. O'Neill wrote:
> Jeremy Lavergne wrote:
>>> If MacPorts didn't have a propensity to compile everything from source
>>
>> It doesn't do that by default anymore.
>
> Strange, because when I look at
>
> http://packages.macports.org/pcre/
>
> I find no packag
Joshua Root wrote:
> You might just have 'macportsuser root' in your macports.conf.
Here's what I have:
% grep macportsuser /opt/local/etc/macports/*
/opt/local/etc/macports/macports.conf.default:#macportsuser macports
% grep macportsuser ~/.macports/*
(nothing)
Also, according to D
On 2011-8-17 09:46 , M.E. O'Neill wrote:
> Joshua Root wrote:
>> The buildslave uses a MacPorts install with mostly default settings, which
>> means the build phase is run as the 'macports' user.
>
> I suppose I should junk my much-upgraded MacPorts install and start over if
> that's the way it'
On Aug 16, 2011, at 4:09 PM, Joshua Root wrote:
> On 2011-8-17 06:27 , Dan Ports wrote:
>> In this case, it isn't nearly as bad as that graph suggests. Nearly all
>> of those dependencies are needed only for kaffe, which is only installed
>> on systems where Java isn't already available.
>>
>> [
On Aug 16, 2011, at 15:27, Dan Ports wrote:
>>> [Speaking of which, I would think we should stop doing that; Java has been
>>> part of the base OS for years and I would be surprised if all of our Java
>>> ports really work with Kaffe instead. Does Kaffe itself even work nowadays?]
and Ryan Schmi
On Wed, Aug 17, 2011 at 09:09:25AM +1000, Joshua Root wrote:
> Lion is the beginning of the end for Apple-supplied Java. So maybe we'll
> need our own again soon.
...but hopefully it won't be Kaffe, which hasn't been updated in
years.
Dan
--
Dan R. K. Ports MIT CSAIL
Joshua Root wrote:
> The archives are accompanied by a signed hash; that's the .rmd160 file you
> might have noticed. Port won't install a downloaded archive if the signature
> can't be verified.
I did see the rmd160 files, but assumed from the name that they were merely
hashes (and as 512-byte
Ryan wrote:
> FYI, in case you made that diagram by hand, we also have the port-depgraph
> script to generate things:
>
> https://trac.macports.org/browser/contrib/port-depgraph
>
> And also the depTree.py script which works similarly:
>
> https://trac.macports.org/browser/users/ebo
On 2011-8-17 06:27 , Dan Ports wrote:
> In this case, it isn't nearly as bad as that graph suggests. Nearly all
> of those dependencies are needed only for kaffe, which is only installed
> on systems where Java isn't already available.
>
> [Speaking of which, I would think we should stop doing tha
On 2011-8-17 08:52 , M.E. O'Neill wrote:
> Jeremy Lavergne wrote:
>>> If MacPorts didn't have a propensity to compile everything from source
>>
>> It doesn't do that by default anymore.
>
> Strange, because when I look at
>
> http://packages.macports.org/pcre/
>
> I find no packages for da
On Aug 16, 2011, at 17:37, Mike O'Brien wrote:
> The problem is that in our case, it's very unlikely that the user will have
> any variant of the subject port installed at the time he installs the
> metaport. However, if you install the subject port via lib_depend, the
> "wrong" variant gets
On Aug 16, 2011, at 15:27, Dan Ports wrote:
> [Speaking of which, I would think we should stop doing that; Java has
> been part of the base OS for years and I would be surprised if all of
> our Java ports really work with Kaffe instead. Does Kaffe itself even
> work nowadays?]
The ability to run
> I find no packages for darwin11
>
> And those binary packages, who builds them? Are they signed? Are we still
> building packages as root?
So really the complaint is that nothing is yet pre-built for Lion--we have a
GSoC project that will give us a very good picture of what the majority of
On 2011-8-17 08:51 , Ryan Schmidt wrote:
>
> MacPorts 2.0.0 introduced our buildbot and installing from binaries. We
> (primarily Joshua!) are still sorting through the ports that the builtbot is
> failing to build, and fixing them, so over time, more and more ports should
> be available as qui
On Tue, Aug 16, 2011 at 03:08:31PM -0700, M.E. O'Neill wrote:
> I summarized my feelings about swig's dependencies with this diagram:
>
> http://i.imgur.com/S6vyf.png
I certainly take your point re: dependencies; I think it's a problem in
general.
It's easy for ports to accumulate depende
Jeremy Lavergne wrote:
>> If MacPorts didn't have a propensity to compile everything from source
>
> It doesn't do that by default anymore.
Strange, because when I look at
http://packages.macports.org/pcre/
I find no packages for darwin11 (and no ppc packages either), and when I look at
On Aug 16, 2011, at 17:08, M.E. O'Neill wrote:
> I summarized my feelings about swig's dependencies with this diagram:
>
> http://i.imgur.com/S6vyf.png
FYI, in case you made that diagram by hand, we also have the port-depgraph
script to generate things:
https://trac.macports.org/browser
On 2011-8-17 08:08 , M.E. O'Neill wrote:
> Daniel J. Luke wrote:
>>> see https://trac.macports.org/wiki/FAQ#ownlibs
>
> ... and Dan Ports replied:
>> FWIW, I find that FAQ answer really unsatisfying. I agree that there are
>> good reasons why MacPorts uses its own libraries, but the claim that "t
On Aug 16, 2011, at 3:22 PM, Ryan Schmidt wrote:
> On Aug 16, 2011, at 16:54, Mike O'Brien wrote:
>
>> We are building a virtual port, which install some 40 (!) ports via
>> depends_lib "port:" entries. Now we find that we must install one
>> particular variant of one of the ports. Is t
On 2011-8-17 08:22 , Ryan Schmidt wrote:
> On Aug 16, 2011, at 16:54, Mike O'Brien wrote:
>
>> We are building a virtual port, which install some 40 (!) ports via
>> depends_lib "port:" entries. Now we find that we must install one
>> particular variant of one of the ports. Is there a way
> If MacPorts didn't have a propensity to compile everything from source
It doesn't do that by default anymore.
> megabytes do matter when some people need to pay for bandwidth (e.g., over a
> 3G connection).
Your development machine lives on a 3G connection?
smime.p7s
Description: S/MIME cr
On Aug 16, 2011, at 16:54, Mike O'Brien wrote:
> We are building a virtual port, which install some 40 (!) ports via
> depends_lib "port:" entries. Now we find that we must install one particular
> variant of one of the ports. Is there a way to specify that in a depends-lib
> entry?
No
> We are building a virtual port, which install some 40 (!) ports via
> depends_lib "port:" entries. Now we find that we must install one particular
> variant of one of the ports. Is there a way to specify that in a depends-lib
> entry? Or is there some other way to accomplish the same
Daniel J. Luke wrote:
>> see https://trac.macports.org/wiki/FAQ#ownlibs
... and Dan Ports replied:
> FWIW, I find that FAQ answer really unsatisfying. I agree that there are good
> reasons why MacPorts uses its own libraries, but the claim that "the
> drawbacks of this policy are minimal" just s
We are building a virtual port, which install some 40 (!) ports via
depends_lib "port:" entries. Now we find that we must install one particular
variant of one of the ports. Is there a way to specify that in a depends-lib
entry? Or is there some other way to accomplish the same effect
On Tue, Aug 16, 2011 at 03:29:38PM -0400, Daniel J. Luke wrote:
> see https://trac.macports.org/wiki/FAQ#ownlibs
FWIW, I find that FAQ answer really unsatisfying. I agree that there
are good reasons why MacPorts uses its own libraries, but the claim
that "the drawbacks of this policy are minimal"
On 2011-8-17 06:33 , Daniel J. Luke wrote:
> On Aug 16, 2011, at 4:28 PM, Joshua Root wrote:
>>
>> Ah. It's calling perl5.setup but not using a p5-* name. I didn't think
>> anything did that.
>>
>> I guess either it needs to become p5-svk, or the portgroup needs to work
>> like the python one and n
Daniel J. Luke wrote:
> Few people probably remember this, but back when I started using MacPorts,
> one of the selling points was that it used the built-in MacOS X software (as
> opposed to fink, which installed its own versions of everything).
As I remember it, it was quite the other way arou
On Aug 16, 2011, at 4:44 PM, Jonathan Stickel wrote:
>
> On 8/16/11 13:23 , M.E. O'Neill wrote:
>> By default, swig has build dependences on bison and gsed. Yet swig
>> builds fine on stock OS X, so special versions of bison and gsed
>> are*NOT* required. If I remove these build dependences by
On 8/16/11 13:23 , M.E. O'Neill wrote:
By default, swig has build dependences on bison and gsed. Yet swig
builds fine on stock OS X, so special versions of bison and gsed
are*NOT* required. If I remove these build dependences by hand (and
remove the line that edits the configure script to use
On 2011-8-17 06:33 , Daniel J. Luke wrote:
> On Aug 16, 2011, at 4:28 PM, Joshua Root wrote:
>>
>> Ah. It's calling perl5.setup but not using a p5-* name. I didn't think
>> anything did that.
>>
>> I guess either it needs to become p5-svk, or the portgroup needs to work
>> like the python one and n
On Aug 16, 2011, at 4:28 PM, Joshua Root wrote:
>
> Ah. It's calling perl5.setup but not using a p5-* name. I didn't think
> anything did that.
>
> I guess either it needs to become p5-svk, or the portgroup needs to work
> like the python one and not declare subports when the name doesn't have
>
On 2011-8-17 06:10 , Daniel J. Luke wrote:
> I was looking at fixing svk (which is nomaintainer now), but I ran into a
> little issue that I'm not sure how to fix.
>
> The port name is 'svk', but it uses the perl portgroup.
>
> I can update the dependencies to use ${perl5.major} like I've seen e
On 2011-8-17 05:23 , M.E. O'Neill wrote:
> By default, swig has build dependences on bison and gsed. Yet swig builds
> fine on stock OS X, so special versions of bison and gsed are *NOT* required.
> If I remove these build dependences by hand (and remove the line that edits
> the configure scr
I was looking at fixing svk (which is nomaintainer now), but I ran into a
little issue that I'm not sure how to fix.
The port name is 'svk', but it uses the perl portgroup.
I can update the dependencies to use ${perl5.major} like I've seen elsewhere,
but since it sets name (to svk), things stil
> So, please consider this a plea to give users like me a way to just
> install the software we actually want and rely as much as possible on what
> is already there and working quite-well-enough-thank-you on the system.
If the packages available on the system aren't all the same architecture
(and
On Aug 16, 2011, at 3:23 PM, M.E. O'Neill wrote:
>
> Many MacPorts packages depend on other MacPorts packages of software that
> already exists on a Mac OS X system,
yep.
see https://trac.macports.org/wiki/FAQ#ownlibs
--
Daniel J. Luke
Many MacPorts packages depend on other MacPorts packages of software that
already exists on a Mac OS X system, such as
perl5
bison
m4
openssl
bzip2
zip
ncurses
and so on. I realize that some users may want to run the latest and greatest
ve
Livecheck is also throwing fits:
p5-autodia seems to have been updated (port version: 2.30.0, new version: 2.03)
p5-crypt-gcrypt seems to have been updated (port version: 1.250.0, new version:
1.25)
p5.8-autodia seems to have been updated (port version: 2.30.0, new version:
2.03)
p5.8-crypt-gcryp
47 matches
Mail list logo
