Christopher,
I mentioned the redirect only because you said something about "shouldn't
be using SSL anyway".
My testing script always disables the cert check because it has been needed
often enough to become my preferred default.
phargrov@sparc64:~$ sudo apt-get update
[...]
W: Failed to fetch
I believe that both the addresses and subscription URLs for the mailing
lists are out-of-date in the README as shown in red below.
I don't know if the list addresses might be forwarding, but those
subscription URLs are definitely 404.
-Paul
The best way to report bugs, send comments, or ask quest
On 31/08/16 12:05, Paul Hargrove wrote:
> As Giles mentions the http: redirects to https: before anything is fetched.
> Replacing "-nv" in the wget command with "-v" shows that redirect clearly.
Agreed, but it still just works on Debian Wheezy for me. :-)
What does "apt-cache policy wget" say fo
Giles,
I am not using a proxy at the http level, but am behind a NAT box (which
should not make any difference).
Both http: and https: URLs fail in the same manner with wget, while curl is
fine with either.
Christopher,
As Giles mentions the http: redirects to https: before anything is fetched.
Paul,
http://www.open-mpi.org redirects to https://www.open-mpi.org
(note http vs https)
if you are using a manual proxy, both http_proxy and https_proxy should
be configured in your /etc/wgetrc
if you are behind a transparent proxy, you have to make sure it allows
https to www.open-mpi.o
Thanks Paul,
this is a known issue that is tracked in the pmix project at
https://github.com/pmix/master/issues/136
Cheers,
Gilles
On 8/31/2016 10:00 AM, Paul Hargrove wrote:
Just tried to build last night's master tarball on Solaris-11.3 on
x86-64 hardware (but keep in mind the default
Just tried to build last night's master tarball on Solaris-11.3 on x86-64
hardware (but keep in mind the default ABI is ILP32).
I see the following fatal error
"/shared/OMPI/openmpi-master-solaris11-x86-ib-ss12u5/openmpi-dev-4716-g99b2664/opal/mca/pmix/pmix3x/pmix/src/dstore/pmix_esh.c",
line 305
On 31/08/16 06:22, Paul Hargrove wrote:
> It seems that a stock Debian Wheezy system cannot even *download* Open
> MPI any more:
Works for me, both http (which shouldn't be using SSL anyway) and https.
Are you behind some weird intercepting proxy?
root@db3:/tmp# wget -nv --no-check-certificate
FWIW, I can confirm that 'master' currently works fine on IA64 using
builtin atomic support (which is the default on 'master').
-Paul
On Tue, Aug 30, 2016 at 4:56 PM, Nathan Hjelm wrote:
> This might be the last straw in IA64 support. If we can’t even test it
> anymore it might *finally* be time
This might be the last straw in IA64 support. If we can’t even test it anymore
it might *finally* be time to kill the asm. If someone wants to use IA64 they
can use the builtin atomic support.
-Nathan
> On Aug 30, 2016, at 4:42 PM, Paul Hargrove wrote:
>
> I don't recall the details of the la
I don't recall the details of the last discussion over which CPU
architectures would be dropped effective when.
However, apparently IA64 support is still present in both 2.0.1rc2 and
master
I suspect that I am currently the only member of this community with the
ability to test IA64.
So, I thought
On a recent nightly tarball of 'master' (but not v2.0) I am seeing "-Wall"
among the options passed to the compiler without any configure test to
ensure this options is safe. The root cause seems to be the following
(final) line in opal/mca/pmix/pmix3x/pmix/src/Makefile.am:
AM_CFLAGS = -Wall
On Tue, Aug 30, 2016 at 1:42 PM, Jeff Squyres (jsquyres) wrote:
> On Aug 30, 2016, at 4:22 PM, Paul Hargrove wrote:
> >
> > It seems that a stock Debian Wheezy system cannot even *download* Open
> MPI any more:
> >
> > $ wget -nv --no-check-certificate http://www.open-mpi.org/
> software/ompi/v2
On Aug 30, 2016, at 4:22 PM, Paul Hargrove wrote:
>
> It seems that a stock Debian Wheezy system cannot even *download* Open MPI
> any more:
>
> $ wget -nv --no-check-certificate
> http://www.open-mpi.org/software/ompi/v2.0/downloads/openmpi-2.0.1rc2.tar.bz2
> GnuTLS: A TLS packet with unexpec
On Aug 30, 2016, at 4:06 PM, Paul Hargrove wrote:
>
> I will report my findings as they come in from my testers.
> However, NERSC is down for quarterly maintenance which means I am w/o Intel
> compilers today.
>
> I am proud to have been verb-ified, but could I get some clarification on
> whic
On Tue, Aug 30, 2016 at 10:49 AM, Paul Hargrove wrote:
[...]
>
> I still have systems running Red Hat Linux 8 (that would be something like
> Fedora "negative 3").
> I had to accept that Open MPI moved forward while I did not - I use Open
> MPI 1.6.5 on that system.
> When I reported a build issue
I will report my findings as they come in from my testers.
However, NERSC is down for quarterly maintenance which means I am w/o Intel
compilers today.
I am proud to have been verb-ified, but could I get some clarification on
which "Hargroved" items are fixed?
I *am* expecting that the following
On Wed, Aug 31, 2016 at 1:49 AM, Paul Hargrove wrote:
> Responses inline, below.
>
>
> On Mon, Aug 29, 2016 at 8:42 PM, C Bergström
> wrote:
>>
>> On Tue, Aug 30, 2016 at 5:49 AM, Paul Hargrove wrote:
>> >
>> > On Mon, Aug 29, 2016 at 8:32 AM, C Bergström
>> > wrote:
>> > [...snip...]
>> >>
>>
On Wed, Aug 31, 2016 at 2:25 AM, Paul Hargrove wrote:
>
> On Tue, Aug 30, 2016 at 7:06 AM, C Bergström
> wrote:
>>
>>
>> >
>> > 3. More complete patches for fixing the issues. Specifically, the 3
>> > provided patches fix certain issues in some parts of the code base, but the
>> > same issues oc
Nathan,
Unless I have misunderstood both Chris and the Clang bug report, the
problematic functions are in glibc.
So, addition of the gnu_inline attribute would probably require either
modifying system headers or interposing ahead of them.
-Paul
On Tue, Aug 30, 2016 at 8:30 AM, Nathan Hjelm wrot
On Tue, Aug 30, 2016 at 7:06 AM, C Bergström
wrote:
>
> >
> > 3. More complete patches for fixing the issues. Specifically, the 3
> provided patches fix certain issues in some parts of the code base, but the
> same issues occur in other places in the code base. As such, the provided
> patches a
On Tue, Aug 30, 2016 at 7:06 AM, C Bergström
wrote:
> On Tue, Aug 30, 2016 at 9:20 PM, Jeff Squyres (jsquyres)
> wrote:
> > On Aug 29, 2016, at 11:42 PM, C Bergström
> wrote:
> >>
> >> Paul - Is this your typical post? I can't tell if you're trying to be
> >> rude or it's accidental.
> >
> > I
Responses inline, below.
On Mon, Aug 29, 2016 at 8:42 PM, C Bergström
wrote:
> On Tue, Aug 30, 2016 at 5:49 AM, Paul Hargrove wrote:
> >
> > On Mon, Aug 29, 2016 at 8:32 AM, C Bergström
> > wrote:
> > [...snip...]
> >>
> >> Based on the latest response - it seems that we'll just fork OMPI and
On Tue, Aug 30, 2016 at 11:30 PM, Nathan Hjelm wrote:
> The best way to put this is his compiler defaults to --std=gnu89. That gives
> him about 90% of what we require from C99 but has weirdness like __restrict.
> The real solution is the list of functions that are called out on link and
> spot fi
The best way to put this is his compiler defaults to --std=gnu89. That gives
him about 90% of what we require from C99 but has weirdness like __restrict.
The real solution is the list of functions that are called out on link and spot
fixing with the gnu_inline attribute if -fgnu89-inline does n
Chris
At the risk of being annoying, it would really help me if you could answer my
question: is Gilles correct in his feeling that we are looking at a scenario
where you can support 90% of C99 (e.g., C99-style comments, named structure
fields), and only the things modified in this PR are requi
On Tue, Aug 30, 2016 at 9:20 PM, Jeff Squyres (jsquyres)
wrote:
> On Aug 29, 2016, at 11:42 PM, C Bergström wrote:
>>
>> Paul - Is this your typical post? I can't tell if you're trying to be
>> rude or it's accidental.
>
> I believe that multiple people on this thread are reacting to the
> passi
On Aug 29, 2016, at 11:42 PM, C Bergström wrote:
>
> Paul - Is this your typical post? I can't tell if you're trying to be
> rude or it's accidental.
I believe that multiple people on this thread are reacting to the
passive-aggressive tones and negative connotations in charged replies. So
may
Chris
For me, this is the critical point:
> On Aug 29, 2016, at 9:50 PM, Gilles Gouaillardet wrote:
>
> iirc, we use C99 struct initialisers, so stricly speaking, i do not think
> Open MPI can be built with a pure C89 compiler when configure'd
>
> with the --disable-c99 option. i'd rather im
29 matches
Mail list logo
