On 2013-11-12 17:25 , David Strubbe wrote:
> Thanks. This isn't in the guide. Would be helpful to list
> in http://guide.macports.org/#reference.phases.configure.
Yep.
> I think I should do "configure.ld_archflags " (i.e. set to blank) if the
> compiler is gfortran. When you say "simply clearing
If they're not uninstalling that would be a bug in base. The files are
meant to be uninstalled and the registry entry removed regardless of
whether executing the portfile succeeds.
- Josh
On 2013-11-12 17:16 , David Strubbe wrote:
> I see. As it stands, I am not sure how to actually uninstall the
Thanks. This isn't in the guide. Would be helpful to list in
http://guide.macports.org/#reference.phases.configure.
I think I should do "configure.ld_archflags " (i.e. set to blank) if the
compiler is gfortran. When you say "simply clearing it may break the port's
ability to build for the selected
I see. As it stands, I am not sure how to actually uninstall the ports I
installed with the test portgroup -- they are still there after the failed
uninstall. Any tip?
David
On Tue, Nov 12, 2013 at 12:44 AM, Sean Farley wrote:
>
> dstru...@mit.edu writes:
>
> > I tried it out, and it works par
On 2013-11-12 16:32 , David Strubbe wrote:
> Hi all,
>
> Is there a way to remove the -arch option from LDFLAGS, as for gfortran?
> Using configure.compiler macports-gcc-XX removes it, but that is not
> compatible with the Fortran recipe which only sets configure.f90 etc. On
> my machine, the defa
dstru...@mit.edu writes:
> I tried it out, and it works partially. The PortGroup file I made in
> _resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but
> not when uninstalling.
Yep. I filed a bug long ago and tried to fix it:
https://trac.macports.org/ticket/34933
_
I tried it out, and it works partially. The PortGroup file I made in
_resources/port1.0/group/fortran-1.0.tcl is recognized when installing, but
not when uninstalling. For example:
$ sudo port uninstall libxc @2.0.2_0+gcc47
Warning: PortGroup fortran 1.0 could not be located. fortran-1.0.tcl does
Hi all,
Is there a way to remove the -arch option from LDFLAGS, as for gfortran?
Using configure.compiler macports-gcc-XX removes it, but that is not
compatible with the Fortran recipe which only sets configure.f90 etc. On my
machine, the default value is
LDFLAGS='-L/opt/local/lib -Wl,-headerpad_
I wasn't even trying to log in, I was just refreshing the page, and got a
similar error:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/trac/web/api.py", line 441,
in send_error
data, 'text/html')
File "/usr/lib/python2.6/site-packages/trac/web/chrome.py", line
8
Is there a better alternative to eval for setting conflicts to a list variable?
set mp.conflicts {c1 c2 c3 c4}
conflicts${mp.conflicts}
foreach mp.conflict $conflicts {
puts ${mp.conflict}
}
/* returns:
c1 c2 c3 c4
*/
eval conflicts ${mp.conflicts}
foreach mp.co
please could someone commit this?
thanks,
Daniel
On 11 Nov 2013, at 19:53, MacPorts wrote:
> #41303: splash @2.3.1 new release
> -+-
> Reporter: daniel.price@… | Owner: macports-tickets@…
> Type: update | S
Hi,
I am unable to log in to Trac right now. Upon logging in, I get the following
Python traceback:
Traceback (most recent call last):
File "/usr/lib/python2.6/site-packages/trac/web/api.py", line 441, in
send_error
data, 'text/html')
File "/usr/lib/python2.6/site-packages/trac/web/chro
On Sun, Nov 10, 2013 at 12:04 PM, Titus von Boxberg wrote:
> Hi Mojca,
>
> since this beautiful example of Bad Code (TM) is inside (system) library
> headers there's not much you can do without reporting upstream
http://bugzilla.maptools.org/show_bug.cgi?id=2464
> or resorting
> to very rude meas
On Nov 11, 2013, at 7:29, Ryan Schmidt wrote:
> Jeremy (and dev list),
>
> The last comment in https://trac.macports.org/ticket/31504 says you were
> looking into the issue “fatal error: ' X11 .rules' file not found” which was
> seen when clang first started being used. Now we’re seeing it ag
On Nov 11, 2013, at 10:31, Daniel J. Luke wrote:
> On Nov 11, 2013, at 11:26 AM, Ryan Schmidt wrote:
>>
>> On Nov 11, 2013, at 10:14, Daniel J. Luke wrote:
> platform variants get recorded in the registry.
Is that still true?
>>>
>>> yes (at least, I have one example of a port wit
On Nov 11, 2013, at 11:35 AM, Ryan Schmidt wrote:
>
> platform blocks were changed from variants into “if” statements in MacPorts
> 1.9.0. If you installed mutt before MacPorts 1.9.0 and haven’t rebuilt it
> since then, then it would still be recorded in the registry with a darwin
> variant.
On Nov 11, 2013, at 11:26 AM, Ryan Schmidt wrote:
>
> On Nov 11, 2013, at 10:14, Daniel J. Luke wrote:
platform variants get recorded in the registry.
>>>
>>> Is that still true?
>>
>> yes (at least, I have one example of a port with a platform darwin that port
>> installed has listed wit
On Nov 11, 2013, at 10:14, Daniel J. Luke wrote:
>>> platform variants get recorded in the registry.
>>
>> Is that still true?
>
> yes (at least, I have one example of a port with a platform darwin that port
> installed has listed with +darwin and port variants doesn't list a +darwin
> varian
On Nov 11, 2013, at 11:02 AM, Ryan Schmidt wrote:
>
> On Nov 11, 2013, at 09:58, Daniel J. Luke wrote:
>> On Nov 11, 2013, at 10:48 AM, Ryan Schmidt wrote:
>>>
[aside: didn't we have a proposal for more flexible platform descriptions
at some point so you could just write this in a nor
On Nov 11, 2013, at 09:58, Daniel J. Luke wrote:
> On Nov 11, 2013, at 10:48 AM, Ryan Schmidt wrote:
>>
>>> [aside: didn't we have a proposal for more flexible platform descriptions
>>> at some point so you could just write this in a normal platform block?]
>>
>> Yes but it doesn’t seem that i
On Nov 11, 2013, at 10:48 AM, Ryan Schmidt wrote:
>
>> [aside: didn't we have a proposal for more flexible platform descriptions at
>> some point so you could just write this in a normal platform block?]
>
> Yes but it doesn’t seem that important to me since it’s exactly equivalent to
> an “if
On Nov 11, 2013, at 09:45, Daniel J. Luke wrote:
> On Nov 11, 2013, at 9:26 AM, Ryan Schmidt wrote:
>>
>> On Nov 11, 2013, at 08:20, Mark Evenson wrote:
>>> Sure: my TCL fu is not that great, so I always a little to hesitant to move
>>> outside the patterns that I know work in Portfiles, but ge
On Nov 11, 2013, at 9:26 AM, Ryan Schmidt wrote:
>
> On Nov 11, 2013, at 08:20, Mark Evenson wrote:
>> Sure: my TCL fu is not that great, so I always a little to hesitant to move
>> outside the patterns that I know work in Portfiles, but getting the right
>> conditionalized stanza that is somew
Jeremy (and dev list),
The last comment in https://trac.macports.org/ticket/31504 says you were
looking into the issue “fatal error: ' X11 .rules' file not found” which was
seen when clang first started being used. Now we’re seeing it again in
Mavericks, e.g.:
https://trac.macports.org/ticket/
On Nov 11, 2013, at 08:20, Mark Evenson wrote:
> Sure: my TCL fu is not that great, so I always a little to hesitant to move
> outside the patterns that I know work in Portfiles, but getting the right
> conditionalized stanza that is somewhat future proof is certainly the right
> thing to do
Sure: my TCL fu is not that great, so I always a little to hesitant to move
outside the patterns that I know work in Portfiles, but getting the right
conditionalized stanza that is somewhat future proof is certainly the right
thing to do
Ryan Schmidt wrote:
>
>On Oct 31, 2013, at 12:17, easi
On Oct 31, 2013, at 12:17, easie...@macports.org wrote:
> Revision
> 112776
> Author
> easie...@macports.org
> Date
> 2013-10-31 10:17:12 -0700 (Thu, 31 Oct 2013)
> Log Message
>
> Fix #41026 for darwin 13 (aka OS X 10.9 Mavericks).
> Modified Paths
>
> • trunk/dports/lang/clisp/Portfile
On 2013-11-11 05:43, Jeremy Huddleston Sequoia wrote:
> What was the reason for moving it from pre_args to args? I don't really see
> that in the commit message.
Most ports were either setting autoconf.args to -fvi (or in the long
form "--force --install --verbose") or clearing autoconf.pre_args
28 matches
Mail list logo
