On Jul 20, 2011, at 19:50, Jeremy Lavergne wrote:
> We're inconsistent in how we handle the -p# flag for patch.
>
> audio/id3lib/Portfile:patch.pre_args -p1
> comms/gnokii/Portfile:patch.args -p1
>
> Documentation says patch.pre_args: shall we go through and tweak these to
> reflect t
We're inconsistent in how we handle the -p# flag for patch.
audio/id3lib/Portfile:patch.pre_args -p1
comms/gnokii/Portfile:patch.args -p1
Documentation says patch.pre_args: shall we go through and tweak these to
reflect the desired behavior to better serve as examples to new maintainers
Yes, that is what I was eventually going to do, but it requires a lot of
synchronous changes and revbumps. If you have the time to do that, it's
certainly a good solution.
--Jeremy
On Jul 20, 2011, at 12:43, Peter O'Gorman wrote:
> On 07/20/2011 11:26 AM, Jeremy Huddleston wrote:
>
>> 6) lib
> What does everyone think, should we consider this a blocker and do
> another RC, or just release as-is and fix this in 2.0.1?
Echoing Jeremy H:
Blocker, then release once fixed.
smime.p7s
Description: S/MIME cryptographic signature
___
macports-dev
Why not just release 2.0.0 *with* the fix?
On Jul 20, 2011, at 13:49, Joshua Root wrote:
> So as you may have seen on -users, Lion's packagemaker seems to be more
> picky about privileges than previous versions. The fix is in svn (I had
> to make it to build the 2.0.0-rc1 dmg.)
>
> What does eve
The problem is resolution at link time.
-L/opt/local/lib caues /opt/local/lib/libnotify.dylib to be used to satisfy
/usr/lib/libSystem.B.dylib's dependency of /usr/lib/system/libnotify.dylib
The -L options on the command line are the link-time equivalent of
DYLD_LIBRARY_PATH at runtime.
On Jul
So as you may have seen on -users, Lion's packagemaker seems to be more
picky about privileges than previous versions. The fix is in svn (I had
to make it to build the 2.0.0-rc1 dmg.)
What does everyone think, should we consider this a blocker and do
another RC, or just release as-is and fix this
On 2011-07-20 18:26 , Jeremy Huddleston wrote:
> 6) libnotify
>
> The libnotify port is disabled on Lion. This blocks gnome,
> firefox-x11, and other ports. There is a hacky workaround discussed
> in the Portfile, but it is recommended for *experts only* ... I
> really can't stress that enough.
On 07/20/2011 11:26 AM, Jeremy Huddleston wrote:
6) libnotify
The libnotify port is disabled on Lion. This blocks gnome,
firefox-x11, and other ports. There is a hacky workaround discussed
in the Portfile, but it is recommended for *experts only* ... I
really can't stress that enough.
Hi,
On Jul 20, 2011, at 1:12 PM, Ryan Schmidt wrote:
>
>> I'd like this to work so I can use both ext2fuse and Krusader.
>
> Since these ports have no maintainer, you may want to bring the issue to the
> attention of the developers of these two programs. Perhaps they can work
> together to resolve
> Comment: add --follow-dependents to uninstall command, so ports with
> deactivate hooks have the best chance to run them cleanly
Ah, good point. Also not obvious based on the command to run.
Anything we can do to make the semantics clear?
___
macport
On Wed, Jul 20, 2011 at 09:26:46AM -0700, Jeremy Huddleston wrote:
>
> 4) compiler codegen issues
>
> As discussed on this list over the past month or so, we've run into some
> codegen issues when using llvm-gcc-4.2. This will appear as a segfault,
> timeout, bad visual artifacts, or just plai
On Jul 20, 2011, at 10:24 AM, Jeremy Lavergne wrote:
>> Clang is LLVM. You probably mean "llvm-gcc" rather than "llvm"?
>
> Yup, llvm-gcc is what I meant, not clang.
>
> Is it correct to say?
> * llvm-gcc is llvm 2
> * clang is llvm 3
There are too many differnet versions floating around for
> Clang is LLVM. You probably mean "llvm-gcc" rather than "llvm"?
Yup, llvm-gcc is what I meant, not clang.
Is it correct to say?
* llvm-gcc is llvm 2
* clang is llvm 3
> Do you know if it is specifically cairo or pango that has the issue (or
> both)? I'd suggest just having cairo and pango
On Jul 20, 2011, at 10:12 AM, Jeremy Lavergne wrote:
> With regards to the upcoming use of LLVM: has anyone had issues with any
> programs that use Cairo to print, which would involve output to PDF or PS?
> I don't think it's a match with the ticket already open [1].
>
> PSPP is having issues wh
On Jul 20, 2011, at 04:49, Russell Jones wrote:
> These two packages conflict, but as far as I can see it's because they have a
> same-named file.
Yes, that's pretty much exclusively what it means in MacPorts when two ports
conflict.
> It looks like they both have the same subsidiary build. C
With regards to the upcoming use of LLVM: has anyone had issues with any
programs that use Cairo to print, which would involve output to PDF or PS?
I don't think it's a match with the ticket already open [1].
PSPP is having issues whenever pango/cairo are built with LLVM 2: the
problem goes away w
MacPorts on Lion works fairly well out of the box with a few exceptions. I've
fixed a number of build issues already, so I'd like to share the common cases
for other developers to benefit from:
1) Reinventing functionality added to Libc
Lion's Libc pulled in some new functionality from POSIX 20
Forgot to say: c.f. https://trac.macports.org/ticket/26869
Russell
From: macports-dev-boun...@lists.macosforge.org
[macports-dev-boun...@lists.macosforge.org] on behalf of Russell Jones
[russell.jo...@physics.ox.ac.uk]
Sent: 20 July 2011 10:49
To: macports-dev@li
Hello all,
These two packages conflict, but as far as I can see it's because they have a
same-named file. It looks like they both have the same subsidiary build. Could
something be renamed, or the build be moved out to another port? Neither has a
maintainer, otherwise I'd ask them this... is th
20 matches
Mail list logo
