On Sat, Oct 3, 2009 at 20:00, Ryan Schmidt wrote:
> Hi Adam. The only difference to what I have in my config is that I'm using a
> semicolon separator instead of a comma. Try that.
>
> Portfile = svn:eol-style=native;svn:keywords=Id
Thanks Ryan, I've made the change and reading the man page in m
On Oct 3, 2009, at 19:57, Adam Mercer wrote:
As per the guidelines I have
[miscellany]
enable-auto-props = yes
[auto-props]
Portfile = svn:eol-style=native,svn:keywords=Id
in my ~/.subversion/config file, but after committing r58737 I've
noticed that the properties are not being set:
$ svn
Hi
As per the guidelines I have
[miscellany]
enable-auto-props = yes
[auto-props]
Portfile = svn:eol-style=native,svn:keywords=Id
in my ~/.subversion/config file, but after committing r58737 I've
noticed that the properties are not being set:
$ svn proplist Portfile
$
Does anyone know why the
> I'm still not clear how you ended up with a 0-sized file with obviously
> mismatched checksums if no 0-sized file existed on any of the
> master_sites. If you can reproduce that problem, please send the debug
> output.
Ok I'll try, it happened when I updated the file on the n.ethz.ch server
(wi
On Oct 3, 2009, at 18:46, Jann Röder wrote:
Ryan Schmidt schrieb:
On Oct 3, 2009, at 18:27, Jann Röšder wrote:
I have seen an instance where the macports mirror servers were tried
which did not have the file. The server specified in the port file
was
not tried at all. For some reason e
It was the eiffelstudio65 port, I now added another source which does
respond to ping requests - problem "solved". The n.ethz.ch server (which
is not pingable) is still included in the source list.
Ryan Schmidt schrieb:
>
> On Oct 3, 2009, at 18:27, Jann Röšder wrote:
>
>> I have seen an instanc
On Oct 3, 2009, at 18:27, Jann Röder wrote:
I have seen an instance where the macports mirror servers were tried
which did not have the file. The server specified in the port file was
not tried at all. For some reason even though the macports mirror
servers didn't have the file a file with siz
> MacPorts 1.7 changed this to ping all download servers and try them in
> ping order. If a server does not respond to ping or is offline, it
> will be at the bottom of the list and will be tried last.
I have seen an instance where the macports mirror servers were tried
which did not have the file
On Oct 3, 2009, at 11:58, Jann Röder wrote:
I noticed, that at the moment servers which do not respond to Pings
are
not considered as sources. This sounds reasonable, but unfortunately
there are some servers out there that work just fine even though
they do
not respond to Ping messages. S
I believe negative variants are still not stored in the registry, so
default variants can cause issues for people when upgrading a port
(since they'll be automatically selected again).
This was my reasoning for going with the no_* nomenclature.
You'll want these packages to build against
What is the hostname of one of these servers for example?
--
Scott * If you contact me off list replace talklists@ with scott@ *
On Oct 3, 2009, at 10:04 AM, Jann Röder wrote:
Yes, but I still want to download stuff from them.
Daniel J. Luke schrieb:
On Oct 3, 2009, at 12:58 PM, Jann Röšd
On Sat, Oct 03, 2009 at 04:50:51PM -, MacPorts wrote:
> #21341: fixed packaging for gcc44
> --+-
> Reporter: howa...@… | Owner: m...@…
> Type: enhancement | Statu
Yes, but I still want to download stuff from them.
Daniel J. Luke schrieb:
> On Oct 3, 2009, at 12:58 PM, Jann Röšder wrote:
>> I noticed, that at the moment servers which do not respond to Pings are
>> not considered as sources. This sounds reasonable, but unfortunately
>> there are some servers
On Oct 3, 2009, at 12:58 PM, Jann Röder wrote:
I noticed, that at the moment servers which do not respond to Pings
are
not considered as sources. This sounds reasonable, but unfortunately
there are some servers out there that work just fine even though
they do
not respond to Ping messages.
On Oct 3, 2009, at 12:41 PM, Maximilian Nickel wrote:
However i'd like
to propose renaming the no_* variants into gcc43 and atlas and making
them default variants.
This way additional variants like gcc44 could easily be added
I believe negative variants are still not stored in the registry, so
I noticed, that at the moment servers which do not respond to Pings are
not considered as sources. This sounds reasonable, but unfortunately
there are some servers out there that work just fine even though they do
not respond to Ping messages. So I request that sources with a ping
value of 1 ar
On Sat, Oct 3, 2009 at 6:05 PM, Adam Mercer wrote:
> I really like this idea, but the main thing that concerns me is that
> any port that depends on numpy will now also depend on gcc43, or gcc44
> (which seems like a better idea), this is a big change as gcc takes a
> _long_ time to build.
ATLAS
On Sat, Oct 03, 2009 at 11:05:28AM -0500, Adam Mercer wrote:
> On Fri, Oct 2, 2009 at 22:06, James Kyle wrote:
>
> > Both numpy and scipy tests pass 100% after this change.
> >
> >> >>> import numpy
> >> >>> numpy.test()
> >>
> >
> >> >>> import scipy
> >> >>> scipy.test()
> >>
>
> What platfo
On Fri, Oct 2, 2009 at 22:06, James Kyle wrote:
> Both numpy and scipy tests pass 100% after this change.
>
>> >>> import numpy
>> >>> numpy.test()
>>
>
>> >>> import scipy
>> >>> scipy.test()
>>
What platform is this on? Leopard, SL?
I really like this idea, but the main thing that concerns
On Oct 3, 2009, at 00:01, Jack Howarth wrote:
You'll want these packages to build against the gcc44 package
rather than the gcc43 package. Only gcc 4.4.x and later builds
on Snow Leopard.
gcc43 builds fine for me on Snow Leopard as well, but I too would
recommend choosing gcc44, since it i
20 matches
Mail list logo
