On Apr 24, 2009, at 11:12 PM, Perry Lee wrote:
I think the problematic line in port1.0/portlivecheck.tcl is:
set livecheck.regex [list "http://[quotemeta $
{livecheck.name}].googlecode.com/files/[quotemeta $
{livecheck.distname}]\""]
In particular: [quotemeta ${livecheck.distname}]
quotemet
On Apr 24, 2009, at 10:33 PM, Jeremy Lavergne wrote:
Has anyone else witnessed the default livecheck.regex failing when
using master_sites googlecode?
For me, it looks like there is style info and whitespace breaking
the pattern.
I've witnessed this problem in distcc and libofa, both of w
Has anyone else witnessed the default livecheck.regex failing when
using master_sites googlecode?
For me, it looks like there is style info and whitespace breaking the
pattern.
smime.p7s
Description: S/MIME cryptographic signature
___
macports-d
On Apr 24, 2009, at 21:02, ma...@macports.org wrote:
Similarly, I've almost never looked at the chunked Guide. I load the
single-page Guide, so that I can press Command-F, type my search
string, press return, and find what I'm looking for. Which isn't to
say we shouldn't have the chunked Guide;
>> This is also the reason why I am splitting this into multiple smaller
>> man pages describing one command only. This makes it much easier to
>> find
>> what you are after than searching a long port(1).
>
>Just to talk about this one point for a moment, perl has its manpages
>split up into seve
>First I want to apologize for being inactive in the last months.
>I only have sporadic access to a Mac at the moment (I switched to
>Linux with my main machine) so my activity was very low. But I
>like the MacPorts project and will continue to update my ports
>when I have time and access to my Mac
On Fri, Apr 24, 2009 at 01:37:48PM -0700, Darren Weber said:
> I'm working on vtk-devel Portfile and I have:
> a) completed a lengthy build of VTK
> b) edited parts of the Portfile that affect downstream stages from the build
> (ie, destroot command)
>
> How can I continue with the downstream stag
Hi,
On Thu, 23 Apr 2009 00:02:30 +0200, Rainer Müller wrote:
> kimura wataru wrote:
>> I write experimental ruby_select for ruby186 and ruby18.
>>
>> http://trac.macports.org/browser/users/kimuraw/ruby_select
>
> Will ruby19 be moved to ruby? Or what will happen to the existing ruby
> port at
Hi Florian,
On Fri, 24 Apr 2009 08:52:48 +0200, C. Florian Ebeling wrote:
> On Wed, Apr 22, 2009 at 3:00 PM, kimura wataru wrote:
>> I write experimental ruby_select for ruby186 and ruby18.
>>
>> http://trac.macports.org/browser/users/kimuraw/ruby_select
>
> I will test it shortly and try to a
I'm working on vtk-devel Portfile and I have:
a) completed a lengthy build of VTK
b) edited parts of the Portfile that affect downstream stages from the build
(ie, destroot command)
How can I continue with the downstream stages without losing the build?
The default behavior is to clean everything
Why was this "universal_variant no"? It builds universal here, and
making this not universal breaks building libsoup which is a headache
for gnome... so unless you want to !universal all of gnome, I suggest
the following:
Index: Portfile
If here is someone who has access to OS X 10.4, could you please check
if the patch attached to ticket [1] solves the compilation problem
reported?
Thanks,
Uldis
On Wed, Apr 22, 2009 at 12:35 AM, MacPorts wrote:
> #19386: rtmpdump: libkern/_OSByteOrder.h: No such file or directory
>
There is a follow-up report on SF.net saying that an additional patch
patch may also be needed:
https://sourceforge.net/forum/message.php?msg_id=7267196
But, again, I can not verify if that is so.
[1] http://trac.macports.org/ticket/19386
On Fri, Apr 24, 2009 at 7:57 PM, Uldis Bojars wrote:
> I
Ryan Schmidt wrote:
> On Apr 22, 2009, at 16:38, Rainer Müller wrote:
>> But we check the primary category against a hardcoded list of valid
>> categories and we also check the parent directory of the port
>> directory.
>> To pass both tests, this list will always have to reflect the current
>> e
Ryan Schmidt wrote:
build.env isn't broken, but it isn't used if you override the
build phase, right?
Why not use the default build phase? Untested:
build.env ${configure.env}
build.cmd ./ROX-Filer/AppRun
build.args --compile ${configure.args}
If I use ${configure.env}, I get:
DEBUG: En
On Apr 24, 2009, at 02:26, a...@macports.org wrote:
Revision: 50072
http://trac.macports.org/changeset/50072
Author: a...@macports.org
Date: 2009-04-24 00:26:05 -0700 (Fri, 24 Apr 2009)
Log Message:
---
build.env is broken, work around it
Modified Paths:
--
On Apr 24, 2009, at 02:45, Rainer Müller wrote:
Bryan Blackburn wrote:
Ports which use 'fetch.type svn' and have an https URL (eg,
tickets #17419,
#18429, and possibly #18583) will quite likely fail for people in
the fetch
stage. svn from the current subversion port (version 1.6.1) has th
Bryan Blackburn wrote:
> Ports which use 'fetch.type svn' and have an https URL (eg, tickets #17419,
> #18429, and possibly #18583) will quite likely fail for people in the fetch
> stage. svn from the current subversion port (version 1.6.1) has the
> --trust-server-cert option to avoid this, but /
Jeremy Huddleston wrote:
In order to use a non-system X11, the port needed the usual
workaround:
configure.args-append --x-include=${prefix}/include --x-lib=$
{prefix}/lib
Just wasn't obvious where to add them, when using Zero Install's --
compile.
It should "just work".
Not with "use_con
19 matches
Mail list logo
