On 2011-9-1 06:06 , Ryan Schmidt wrote:
>
> On Aug 31, 2011, at 14:03, Jeremy Lavergne wrote:
>
>> Do we consider ports that create and use a shared memory file in $HOME an
>> mtree violation? This would be during the build and/or test phases [1].
>>
>> How would we "properly" get around such a s
On Aug 31, 2011, at 15:25, Ryan Schmidt wrote:
> On Aug 31, 2011, at 10:37, Bradley Giesbrecht wrote:
>
>> My understanding for the use of sbin was mistaken. My reason for putting
>> this script in sbin was to avoid a conflict with port svg2pdf; evidently a
>> bad idea.
>>
>> I believe the po
On Aug 31, 2011, at 10:37, Bradley Giesbrecht wrote:
> My understanding for the use of sbin was mistaken. My reason for putting this
> script in sbin was to avoid a conflict with port svg2pdf; evidently a bad
> idea.
>
> I believe the port sources for svg2pdf are unmaintained and obsolete. In m
> Well, an mtree violation is by definition a port that installs files to
> locations that are not specified in the mtree. But here we're talking
> about a port that merely creates a temporary file during the build, not
> something the port ultimately installs. So it's not an mtree violation.
> But
On Aug 31, 2011, at 14:03, Jeremy Lavergne wrote:
> Do we consider ports that create and use a shared memory file in $HOME an
> mtree violation? This would be during the build and/or test phases [1].
>
> How would we "properly" get around such a situation? Will that also
> account for a working
On Wed, Aug 31, 2011 at 02:14:39PM -0400, Jeremy Lavergne wrote:
> On Wed, August 31, 2011 2:05 pm, Daniel wrote:
> > Hey, I just tried compiling macports after installing Xcode on Lion. I get
> > this:
> >
> > checking Mac OS X version... 10.7.1
> > checking Xcode version... 3.2.4
>
> I guess you
Do we consider ports that create and use a shared memory file in $HOME an
mtree violation? This would be during the build and/or test phases [1].
How would we "properly" get around such a situation? Will that also
account for a working mpab chroot (hopefully it'll work again, someday).
1. https:
On 08/31/2011 08:05 PM, Daniel wrote:
checking Mac OS X version... 10.7.1
checking Xcode version... 3.2.4
On Lion you need at least Xcode 4.1.
A common mistake is to "install" Xcode using the App Store, but you
still need to manually run the installer it downloads to
/Applications/Install Xc
On Wed, August 31, 2011 2:05 pm, Daniel wrote:
> Hey, I just tried compiling macports after installing Xcode on Lion. I get
> this:
>
> checking Mac OS X version... 10.7.1
> checking Xcode version... 3.2.4
I guess you need Xcode 4, which I believe is free now.
___
Hey, I just tried compiling macports after installing Xcode on Lion. I get
this:
[~/tmp/MacPorts-2.0.1]$ ./configure --prefix=/Users/daniel/local/macports
--with-no-root-privileges
checking build system type... x86_64-apple-darwin11.1.0
checking host system type... x86_64-apple-darwin11.1.0
checki
On Aug 30, 2011, at 9:56 PM, Joshua Root wrote:
> On 2011-8-31 07:21 , Ryan Schmidt wrote:
>>
>> On Aug 30, 2011, at 05:17, Joshua Root wrote:
>>
>>> On 2011-8-30 14:56 , Ryan Schmidt wrote:
> +xinstall -m 755 -W ${buildpath} svg2pdf \
> +${destroot}${prefix}/sbin
On Aug 30, 2011, at 9:39 PM, MacPorts wrote:
> #30978: can't install logrotate as non-root
> -+--
> Reporter: nefar@… | Owner: pixilla@…
> Type: defect | Status: new
Are there any more patches that should go into this release?
- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
Anders F Björklund wrote:
> Unless somebody completes Pallet, the only working GUI would be Port
> Authority.
I think we need a completely redesigned GUI leveraging Core Data, Grand Central
Dispatch and the Scripting Bridge.
MacRuby could be the right tool to use since it supports all these ne
On Wed, Aug 31, 2011 at 01:59:22AM -0500, Ryan Schmidt wrote:
> On Aug 30, 2011, at 19:03, Jeremy Lavergne wrote:
>
> >> emacs-snapshot: drop lzmautils dependency (use_xz has that covered)
> >
> > use_xz is only for depends_extract though, right?
>
> Correct.
>
> > Someone can for any number of
Ryan Schmidt wrote:
But using port: dependencies seem like a step back,
since it's losing dependency information (i.e. "5") ?
>>>
>>> I'm not aware of this additional information ever having been helpful.
>>>
>>> lib:- and bin:-style dependencies would allow a file (in this case
>>> l
Ryan Schmidt wrote:
+build.env CC=${configure.cc} CFLAGS=${configure.cflags}
build.args CFLAGS+=-I${prefix}/include LDFLAGS+=-L${prefix}/lib
-DMK_OPENSSL
>>>
>>> Why set CFLAGS in build.env, then append to CFLAGS in build.args?
>>
>> Why not ?
>
> It looked like an oversight. I
On Aug 31, 2011, at 02:13, j...@macports.org wrote:
> Revision: 83390
> http://trac.macports.org/changeset/83390
> Author: j...@macports.org
> Date: 2011-08-31 00:13:22 -0700 (Wed, 31 Aug 2011)
> Log Message:
> ---
> glew: update to 1.7.0, rev bump dependents
> variant univ
On Aug 31, 2011, at 02:07, Anders F Björklund wrote:
> Ryan Schmidt wrote:
>
>>> There's a sover bump around the corner, so it wanted
>>> to make sure that the dependency is also upgraded...
>>> I know that MacPorts now auto-upgrades everything,
>>> and that it doesn't yet have versioned depende
Ryan Schmidt wrote:
>> There's a sover bump around the corner, so it wanted
>> to make sure that the dependency is also upgraded...
>> I know that MacPorts now auto-upgrades everything,
>> and that it doesn't yet have versioned dependencies.
>>
>> But using port: dependencies seem like a step bac
20 matches
Mail list logo
