Re: [OMPI devel] RFC: add support for large counts using derived datatypes
On Jul 16, 2013, at 3:22 PM, George Bosilca wrote: > I read your code and it's definitively looking good. I have however few minor > issues with your patch. > > 1. MPI_Aint is unsigned as it must represent the difference between two > memory arbitrary locations. In your MPI_Type_get_[true_]extent_x you go > through size_t possibly reducing it's extent. I would suggest you used > ssize_t instead. MPI_Aint must be signed for Fortran compatibility (among other reasons). If OMPI's MPI_Aint is unsigned then that's a bug in OMPI. -Dave
Re: [OMPI devel] RFC: add support for large counts using derived datatypes
On Jul 16, 2013, at 4:03 PM, George Bosilca wrote: > On Jul 16, 2013, at 22:29 , Jeff Squyres (jsquyres) > wrote: > >> On Jul 16, 2013, at 4:22 PM, George Bosilca wrote: >> >>> Btw, I have a question to you fellow MPI Forum attendees. I just can't >>> remember why the MPI forum felt there was a need for the >>> MPI_Type_get[_true]_extent_x? MPI_Count can't be bigger than MPI_Aint, >> >> Yes, it can -- it has to be the largest integer type (i.e., it even has to >> be able to handle an MPI_Offset). > > Technicalities! In the entire standard MPI_Offset is only used to access > files, not to build datatypes. As such there is no way to have the extent of > an datatype bigger than MPI_Aint. That's not true. You can obtain a datatype with an extent outside the range of an MPI_Aint by nesting types. Just create a contig of size 1, then create a type a very large extent from your contig with MPI_Type_create_resized, then create a second contig of that resized with a count >1. > Thus, these accessors returning MPI_Count are a useless overkill, as they > cannot offer more precision that what the version returning MPI_Aint is > already offering. > > George. > > PS: I hope nobody has the idea to define the MPI_Offset as a signed type … Not sure if you're joking here... MPI_Offset must also be signed, again, for Fortran interoperability. -Dave
Re: [OMPI devel] ompi_info
On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: > That's a good point, and a bad behavior. IIRC, it results from the MPI > Forum's adoption of the MPI-T requirement that stipulates we must allow > access to all control and performance variables at startup so they can be > externally seen/manipulated. Minor nit: MPI_T does not require this. However, it does recommend that you offer users access to as many variables as possible as early as reasonably possible for the convenience and control of the user. If an implementation chooses to offer 5% of the possible control/performance variables to the user just before MPI_Finalize, that's still a valid MPI_T implementation. But it may not be a very useful one... -Dave
Re: [OMPI devel] ompi_info
On Jul 18, 2013, at 9:53 AM, Ralph Castain wrote: > On Jul 18, 2013, at 7:05 AM, David Goodell (dgoodell) > wrote: > >> On Jul 18, 2013, at 8:06 AM, Ralph Castain wrote: >> >>> That's a good point, and a bad behavior. IIRC, it results from the MPI >>> Forum's adoption of the MPI-T requirement that stipulates we must allow >>> access to all control and performance variables at startup so they can be >>> externally seen/manipulated. >> >> Minor nit: MPI_T does not require this. However, it does recommend that you >> offer users access to as many variables as possible as early as reasonably >> possible for the convenience and control of the user. >> >> If an implementation chooses to offer 5% of the possible control/performance >> variables to the user just before MPI_Finalize, that's still a valid MPI_T >> implementation. But it may not be a very useful one... > > The problem here is one of use vs startup performance. George is quite > correct with his concerns - this behavior would have been a serious problem > for RoadRunner, for example, where we had a small IO channel feeding a lot of > nodes. It will definitely become an issue at exascale where IO bandwidth and > memory will be at a premium. My point was not that the performance concerns were unfounded. Rather, I wanted to point out that the "load everything" behavior is not a hard requirement from the MPI standard, so we have room for different implementation choices/tradeoffs. -Dave
Re: [OMPI devel] [EXTERNAL] Re: RFC: Change ompi_proc_t endpoint data lookup
On Jul 20, 2013, at 4:42 PM, "Barrett, Brian W" wrote: > On 7/20/13 3:33 PM, "George Bosilca" wrote: > >> - In terms of memory this solution provide an approach where there will >> never be an extra overhead. The ompi_proc_t is not changed, and the extra >> array of endpoints is only created if the components that share it, are all >> loaded and enabled. > > I agree. Jeff and I talked about a similar concept, but the dependent load > was an idea crusher to me. I'm not really familiar with the code being discussed here, but could you insert a small fixed-size cache in front of this in order to mitigate this second load in the most common cases? -Dave
Re: [OMPI devel] OpenSHMEM round 2
The ".git" URL works for me when "git clone"ing it, but I get a 404 in my browser. Drop the ".git" and it will function as both a browser URL and a proper git clone URL: https://bitbucket.org/jladd_math/mlnx-oshmem -Dave On Aug 6, 2013, at 3:36 PM, Joshua Ladd wrote: > It’s a public repo. What if you do: > > git clone https://jladd_m...@bitbucket.org/jladd_math/mlnx-oshmem.git > > Obviously, everything works for me J > > Josh > > From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On > Behalf Of Shamis, Pavel > Sent: Tuesday, August 06, 2013 5:59 PM > To: Open MPI Developers (de...@open-mpi.org) > Subject: Re: [OMPI devel] OpenSHMEM round 2 > > Josh, > I get 404 error. Probably you have to unlock it. > Best, > -P > > > From: devel-boun...@open-mpi.org [mailto:devel-boun...@open-mpi.org] On > Behalf Of Joshua Ladd > Sent: Tuesday, August 06, 2013 12:30 PM > To: Open MPI Developers (de...@open-mpi.org) > Subject: [OMPI devel] OpenSHMEM round 2 > > Dear OMPI Community, > > Please find on Bitbucket the latest round of OSHMEM changes based on > community feedback. Please git and test at your leisure. > > https://bitbucket.org/jladd_math/mlnx-oshmem.git > > Best regards, > > Josh > > Joshua S. Ladd, PhD > HPC Algorithms Engineer > Mellanox Technologies > > Email: josh...@mellanox.com > Cell: +1 (865) 258 - 8898 > > > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
[OMPI devel] OMPI Git mirror history: incorrect history & rewinding
Short Version: The OMPI GitHub mirror of the OMPI SVN history currently contains some bad history, specifically related to the version tags. Prior to roughly September 16th, this repository also contained several other bits of bad information/history. The git history was *rewound* some time around the 16th, which could cause problems for developers who are using it to construct patches for our SVN repository. We expect the history to be rewound again once at some point in the (hopefully) near future, which will have a similar effect. Users of the git mirror may need to perform some unconventional steps to recover from the upstream rewind in some cases. If you are not currently experiencing any trouble with the mirror you may wish to wait until the second rewind occurs in the near future. More Detail: Though OMPI uses SVN as the canonical version control system (VCS), many developers use Mercurial (hg) or Git repositories for feature development and collaboration before bringing those changes back to SVN. To this end, there are two helpful mirrors hosted on bitbucket and GitHub respectively: https://bitbucket.org/ompiteam/ompi-svn-mirror https://github.com/open-mpi/ompi-svn-mirror The Git mirror is maintained by Mellanox and has been extremely helpful so far. However, in July it became clear that some of the history in the mirror was incorrect. Specifically: 1) Several commits had been squashed into a single commit, losing some history (eb0b490+7fc1da3+36d7b2c+482041f --> 616629d). However, the tree (Git-speak for file contents) at each commit always matched the corresponding commit message. 2) Some author names and user IDs were incorrect in the history. The severity of this is low, since they were all typo-level inaccuracies, not arbitrarily swapped names. 3) Most of the release tags are incorrect. The mirror has tags of the form "v1.X-series" (where "X" is a valid number) instead of "v1.6.2". These "-series" tags then contain directories for each release within that series instead of the expected source tree. Eugene V. at Mellanox recently (~2013-09-16) updated the mirror to address issues (1) and (2). Issue (3) remains outstanding, necessitating a future update at some as-yet unspecified time. Unfortunately, the act of updating the repository to resolve these issues causes entirely new commit ID hashes to be created, resulting in a "rewind" of all of the Git branches and tags in the mirror. Most git users have not encountered this case and may experience difficulty coping with it. If you encounter trouble with these recent repository updates, you might be able to fix your situation by following some of the advice from the "RECOVERING FROM UPSTREAM REBASE" section of the "git rebase" manual (https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html). If that doesn't make any sense to you or you encounter too much trouble with it then you have a couple of options: A) Assuming you only use your cloned version of the repository to generate small patch sets, you can always clone another copy of the repository and move your patches over by hand. B) You may contact me with a clear explanation of your situation and I will attempt to point you in the right direction and clear up any confusion about the recent repository changes. I won't do any work for you, but I'm happy to help with explanation in any reasonable capacity. If you aren't experiencing any problems right now, you might want to wait to address the rewound history until the second (and hopefully final) rewind occurs. I don't have an ETA on this, as Eugene at Mellanox is handling the actual import/update and I believe there are a number of Israeli holidays on the calendar this week. -Dave
Re: [OMPI devel] [OMPI users] Error in openmpi-1.9a1r29179
"bzero" should be avoided for maximum portability. Just use "memset" instead. Even older versions of GCC know how to spot the 0 constant and substitute the right compiler intrinsic(s), assuming they are available for the target platform. http://pubs.opengroup.org/onlinepubs/009695399/functions/bzero.html -Dave On Sep 19, 2013, at 8:44 AM, Ralph Castain wrote: > Can you please do a "man bzero" and tell us what include file it says we need? > > > On Sep 19, 2013, at 3:33 AM, Siegmar Gross > wrote: > >> Hello Josh, >> >> I just tried to compile openmpi-1.9a1r29209 with gcc-4.8.0 and get the >> following error on Solaris sparc and Solars x86_64. >> >> sunpc1 openmpi-1.9a1r29209-SunOS.x86_64.64_gcc 24 tail -14 >> log.make.SunOS.x86_64.64_gcc >> make[2]: Entering directory >> `/export2/src/openmpi-1.9/openmpi-1.9a1r29209-SunOS.x86_64.64_gcc/oshmem' >> CC op/op.lo >> CC proc/proc.lo >> ../../openmpi-1.9a1r29209/oshmem/proc/proc.c: In function >> 'oshmem_proc_construct': >> ../../openmpi-1.9a1r29209/oshmem/proc/proc.c:48:5: error: implicit >> declaration of function 'bzero' [-Werror=implicit-function-declaration] >>bzero(proc->proc_endpoints, sizeof(proc->proc_endpoints)); >>^ >> ../../openmpi-1.9a1r29209/oshmem/proc/proc.c:48:5: error: incompatible >> implicit >> declaration of built-in function 'bzero' [-Werror] >> cc1: all warnings being treated as errors >> make[2]: *** [proc/proc.lo] Error 1 >> make[2]: Leaving directory >> `/export2/src/openmpi-1.9/openmpi-1.9a1r29209-SunOS.x86_64.64_gcc/oshmem' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory >> `/export2/src/openmpi-1.9/openmpi-1.9a1r29209-SunOS.x86_64.64_gcc/oshmem' >> make: *** [all-recursive] Error 1 >> >> >> Kind regards >> >> Siegmar >> >> >> >> Try now, please. >>> >>> I can build openmpi-1.9a1r29209 with my Sun C compiler on my platforms. >>> Thank you very much for your help! I can even use it on Linux and >>> I still get a Bus Error on Solaris, but that is a different problem. >>> I'm happy that I have at least one working platform again. >>> >>> Kind regards and thank you very much once more >>> >>> Siegmar >>> >>> >>> -Original Message- From: Siegmar Gross [mailto:siegmar.gr...@informatik.hs-fulda.de] Sent: Wednesday, September 18, 2013 6:32 AM To: de...@open-mpi.org Cc: siegmar.gr...@informatik.hs-fulda.de; Joshua Ladd Subject: RE: [OMPI users] Error in openmpi-1.9a1r29179 Hello Josh, thank you very much for your help. Unfortunately I have still a problem to >>> build Open MPI. > I pushed a bunch of fixes, can you please try now. I tried to build /openmpi-1.9a1r29197 on my platforms and now I get on all >>> platforms the following error. linpc1 openmpi-1.9a1r29197-Linux.x86_64.64_cc 117 tail -22 >>> log.make.Linux.x86_64.64_cc CC base/memheap_base_alloc.lo "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/amd64/atomic.h", line >>> 136: warning: parameter in inline asm statement unused: %3 >>> "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/amd64/atomic.h", >>> line >>> 182: warning: parameter in inline asm statement unused: %2 >>> "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/amd64/atomic.h", >>> line >>> 203: warning: parameter in inline asm statement unused: %2 >>> "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/amd64/atomic.h", >>> line >>> 224: warning: parameter in inline asm statement unused: %2 >>> "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/amd64/atomic.h", >>> line >>> 245: warning: parameter in inline asm statement unused: %2 >>> "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/atomic_impl.h", line >>> 167: >>> warning: statement not reached >>> "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/atomic_impl.h", line >>> 192: >>> warning: statement not reached >>> "../../../../openmpi-1.9a1r29197/opal/include/opal/sys/atomic_impl.h", line >>> 217: >>> warning: statement not reached >>> "../../../../openmpi-1.9a1r29197/oshmem/mca/spml/spml.h", line 76: warning: >>> anonymous union declaration >>> "../../../../openmpi-1.9a1r29197/oshmem/mca/memheap/base/memheap_base_alloc.c", >>> >>> line 112: warning: argument mismatch >>> "../../../../openmpi-1.9a1r29197/oshmem/mca/memheap/base/memheap_base_alloc.c", >>> >>> line 119: warning: argument mismatch >>> "../../../../openmpi-1.9a1r29197/oshmem/mca/memheap/base/memheap_base_alloc.c", >>> >>> line 124: warning: argument mismatch >>> "../../../../openmpi-1.9a1r29197/oshmem/mca/memheap/base/memheap_base_alloc.c", >>> >>> line 248: warning: pointer to void or function used in arithmetic >>> "../../../../openmpi-1.9a1r29197/oshmem/mca/memheap/base/memheap_base_alloc.c", >>> >>> line 286: syntax error before or at: | >>> "../../../../openmpi-1.9a1r29197/oshmem/mca/memheap/base/memheap_base_alloc.c", >>> >>> li
Re: [OMPI devel] RFC: Neighborhood collective support
On Sep 19, 2013, at 3:07 PM, "Hjelm, Nathan T" wrote: > I have implemented simple tests for cartesian, graph, and dist graph > topologies for the Open MPI/IBM test suite and all tests pass. I will push > those tests to MTT tomorrow. Consider also grabbing the dist graph and neighborhood collective tests from MPICH and running them against your proposed patch. I recall catching a lot of subtle cases with these tests when I implemented this functionality in MPICH. Specifically, I'm thinking of these tests: http://git.mpich.org/mpich.git/blob/HEAD:/test/mpi/topo/dgraph_unwgt.c http://git.mpich.org/mpich.git/blob/HEAD:/test/mpi/topo/neighb_coll.c http://git.mpich.org/mpich.git/blob/HEAD:/test/mpi/topo/distgraph1.c http://git.mpich.org/mpich.git/blob/HEAD:/test/mpi/f77/topo/dgraph_unwgtf.f http://git.mpich.org/mpich.git/blob/HEAD:/test/mpi/f77/topo/dgraph_wgtf.f Some of them might be annoying to run, since they depend on the "MTest" utility code. But they wouldn't be too hard to tweak to use plain MPI instead. Let me know if you run into trouble, I'm happy to point you in the right direction. -Dave
Re: [OMPI devel] OMPI Git mirror history: incorrect history & rewinding
A clarification for those on the devel@ list who were not on our private email thread about these issues: "issue (F)" is the "v1.X-series" tag issue. That is, the second rewind has not yet happened. -Dave On Sep 22, 2013, at 3:33 AM, Eugene Voronov wrote: > Hi All, > I've finished with dynamic generation of authors list direct from SVN, thus > feature provide solution resolve issues of mirroring from svn2git. > > Last issue (F) I'll try solve in next few days. > > > > > -Original Message- > From: David Goodell (dgoodell) [mailto:dgood...@cisco.com] > Sent: Friday, September 20, 2013 7:27 PM > To: Open MPI Developers > Cc: Eugene Voronov; Mike Dubman > Subject: OMPI Git mirror history: incorrect history & rewinding > > Short Version: > > The OMPI GitHub mirror of the OMPI SVN history currently contains some bad > history, specifically related to the version tags. Prior to roughly > September 16th, this repository also contained several other bits of bad > information/history. The git history was *rewound* some time around the > 16th, which could cause problems for developers who are using it to construct > patches for our SVN repository. We expect the history to be rewound again > once at some point in the (hopefully) near future, which will have a similar > effect. > > Users of the git mirror may need to perform some unconventional steps to > recover from the upstream rewind in some cases. If you are not currently > experiencing any trouble with the mirror you may wish to wait until the > second rewind occurs in the near future. > > > More Detail: > > Though OMPI uses SVN as the canonical version control system (VCS), many > developers use Mercurial (hg) or Git repositories for feature development and > collaboration before bringing those changes back to SVN. To this end, there > are two helpful mirrors hosted on bitbucket and GitHub respectively: > > https://bitbucket.org/ompiteam/ompi-svn-mirror > https://github.com/open-mpi/ompi-svn-mirror > > The Git mirror is maintained by Mellanox and has been extremely helpful so > far. However, in July it became clear that some of the history in the mirror > was incorrect. Specifically: > > 1) Several commits had been squashed into a single commit, losing some > history (eb0b490+7fc1da3+36d7b2c+482041f --> 616629d). However, the tree > (Git-speak for file contents) at each commit always matched the corresponding > commit message. > > 2) Some author names and user IDs were incorrect in the history. The > severity of this is low, since they were all typo-level inaccuracies, not > arbitrarily swapped names. > > 3) Most of the release tags are incorrect. The mirror has tags of the form > "v1.X-series" (where "X" is a valid number) instead of "v1.6.2". These > "-series" tags then contain directories for each release within that series > instead of the expected source tree. > > Eugene V. at Mellanox recently (~2013-09-16) updated the mirror to address > issues (1) and (2). Issue (3) remains outstanding, necessitating a future > update at some as-yet unspecified time. Unfortunately, the act of updating > the repository to resolve these issues causes entirely new commit ID hashes > to be created, resulting in a "rewind" of all of the Git branches and tags in > the mirror. Most git users have not encountered this case and may experience > difficulty coping with it. > > If you encounter trouble with these recent repository updates, you might be > able to fix your situation by following some of the advice from the > "RECOVERING FROM UPSTREAM REBASE" section of the "git rebase" manual > (https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html). If that > doesn't make any sense to you or you encounter too much trouble with it then > you have a couple of options: > > A) Assuming you only use your cloned version of the repository to generate > small patch sets, you can always clone another copy of the repository and > move your patches over by hand. > > B) You may contact me with a clear explanation of your situation and I will > attempt to point you in the right direction and clear up any confusion about > the recent repository changes. I won't do any work for you, but I'm happy to > help with explanation in any reasonable capacity. > > If you aren't experiencing any problems right now, you might want to wait to > address the rewound history until the second (and hopefully final) rewind > occurs. I don't have an ETA on this, as Eugene at Mellanox is handling the > actual import/update and I believe there are a number of Israeli holidays on > the calendar this week. > > -Dave >
Re: [OMPI devel] [EXTERNAL] Re: OMPI dev meeting: December?
On Oct 1, 2013, at 11:08 AM, "Jeff Squyres (jsquyres)" wrote: > On Oct 1, 2013, at 11:56 AM, "Barrett, Brian W" wrote: > >> I could catch a flight out of ORD instead of MDW if required, but would >> prefer not to have to get a rental car; is there a taxiable option to the >> Rosemont facility? > > Yes. You can taxi or train to the Cisco office from ORD. > > We have had OMPI dev meetings there before -- do you remember the facility? > It's a walkable distance from where we used to have the MPI Forum meetings in > Rosemont. This might help: http://goo.gl/maps/RyBqV -Dave
Re: [OMPI devel] [EXTERNAL] Re: OMPI dev meeting: December?
A taxi or shuttle would be faster and is probably not unreasonably expensive: http://www.flychicago.com/OHare/EN/GettingToFrom/Transport_Between_Airports/Transport-Between-Airports.aspx -Dave On Oct 1, 2013, at 11:30 AM, Nathan Hjelm wrote: > Ok, that should be fine. Its a long way to MDW on the L (> 1 hr) but it can't > be helped. > > -Nathan > > On Tue, Oct 01, 2013 at 04:09:43PM +0000, David Goodell (dgoodell) wrote: >> On Oct 1, 2013, at 11:08 AM, "Jeff Squyres (jsquyres)" >> wrote: >> >>> On Oct 1, 2013, at 11:56 AM, "Barrett, Brian W" wrote: >>> >>>> I could catch a flight out of ORD instead of MDW if required, but would >>>> prefer not to have to get a rental car; is there a taxiable option to the >>>> Rosemont facility? >>> >>> Yes. You can taxi or train to the Cisco office from ORD. >>> >>> We have had OMPI dev meetings there before -- do you remember the facility? >>> It's a walkable distance from where we used to have the MPI Forum meetings >>> in Rosemont. >> >> This might help: >> >> http://goo.gl/maps/RyBqV >> >> -Dave >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > ___ > devel mailing list > de...@open-mpi.org > http://www.open-mpi.org/mailman/listinfo.cgi/devel
Re: [OMPI devel] oshmem build failures
It's probably missing from a variable which has "dist" effects. In ompi/include/ompi/Makefile.am this is "$(headers)". -Dave On Oct 16, 2013, at 9:25 AM, Ralph Castain wrote: > Weird - that file definitely exists - generated by autogen. > > On Oct 16, 2013, at 7:23 AM, "Jeff Squyres (jsquyres)" > wrote: > >> Begin forwarded message: >> >>> From: MPI Team >>> Subject: === CREATE FAILURE (trunk) === >>> Date: October 16, 2013 10:18:14 AM EDT >>> To: >>> Reply-To: >>> >>> >>> ERROR: Command returned a non-zero exist status (trunk): >>> make distcheck >>> >>> Start time: Wed Oct 16 09:59:02 EDT 2013 >>> End time: Wed Oct 16 10:18:13 EDT 2013 >>> >>> === >>> [... previous lines snipped ...] >>> CC base/memheap_base_register.lo >>> CC base/memheap_base_mkey.lo >>> CCLD libmca_memheap.la >>> make[3]: Leaving directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem/mca/memheap' >>> Making all in mca/scoll >>> make[3]: Entering directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem/mca/scoll' >>> CC base/scoll_base_frame.lo >>> CC base/scoll_base_available.lo >>> CC base/scoll_base_select.lo >>> CCLD libmca_scoll.la >>> make[3]: Leaving directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem/mca/scoll' >>> Making all in mca/spml >>> make[3]: Entering directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem/mca/spml' >>> CC base/spml_base_frame.lo >>> CC base/spml_base_select.lo >>> CC base/spml_base_request.lo >>> CC base/spml_base_atomicreq.lo >>> CC base/spml_base_getreq.lo >>> CC base/spml_base_putreq.lo >>> CC base/spml_base.lo >>> CCLD libmca_spml.la >>> make[3]: Leaving directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem/mca/spml' >>> Making all in . >>> make[3]: Entering directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem' >>> CC op/op.lo >>> CC proc/proc.lo >>> CC proc/proc_group_cache.lo >>> CC request/request.lo >>> CC runtime/oshmem_shmem_init.lo >>> CC runtime/oshmem_shmem_finalize.lo >>> CC runtime/oshmem_shmem_abort.lo >>> CC runtime/oshmem_shmem_params.lo >>> CC runtime/oshmem_shmem_exchange.lo >>> CC runtime/oshmem_info_support.lo >>> ../../oshmem/runtime/oshmem_info_support.c:14:46: error: >>> oshmem/include/oshmem/frameworks.h: No such file or directory >>> ../../oshmem/runtime/oshmem_info_support.c: In function >>> 'oshmem_info_register_types': >>> ../../oshmem/runtime/oshmem_info_support.c:36: error: 'oshmem_frameworks' >>> undeclared (first use in this function) >>> ../../oshmem/runtime/oshmem_info_support.c:36: error: (Each undeclared >>> identifier is reported only once >>> ../../oshmem/runtime/oshmem_info_support.c:36: error: for each function it >>> appears in.) >>> ../../oshmem/runtime/oshmem_info_support.c: In function >>> 'oshmem_info_register_framework_params': >>> ../../oshmem/runtime/oshmem_info_support.c:63: error: 'oshmem_frameworks' >>> undeclared (first use in this function) >>> ../../oshmem/runtime/oshmem_info_support.c: In function >>> 'oshmem_info_close_components': >>> ../../oshmem/runtime/oshmem_info_support.c:70: error: 'oshmem_frameworks' >>> undeclared (first use in this function) >>> make[3]: *** [runtime/oshmem_info_support.lo] Error 1 >>> make[3]: Leaving directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem' >>> make[2]: *** [all-recursive] Error 1 >>> make[2]: Leaving directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build/oshmem' >>> make[1]: *** [all-recursive] Error 1 >>> make[1]: Leaving directory >>> `/home/mpiteam/openmpi/nightly-tarball-build-root/trunk/create-r29441/ompi/openmpi-1.9a1r29441/_build' >>> make: *** [distcheck] Error 1 >>> === >>> >>> Your friendly daemon, >>> Cyrador >>> ___ >>> testing mailing list >>> test...@open-mpi.org >>> http://www.open-mpi.org/mailman/listinfo.cgi/testing >> >> >> -- >> Jeff Squyres >> jsquy...@cisco.com >> For corporate legal information go to: >> http://www.cisco.com/web/about/doing_business/legal/cri/ >> >> ___ >> devel mailing list >> de...@open-mpi.org >> http://www.open-mpi.org/mailman/listinfo.cgi/devel > > ___ > devel mailing list > d
Re: [OMPI devel] OMPI Git mirror history: incorrect history & rewinding
FYI, all subsequent expected rewinds have occurred. The mirroring process has been modified to reduce the risk of an accidental rewind in the future. Several (correct) tags have been added and several (incorrect) tags have been deleted. Going forward, we will also add a .mailmap file to the repository to perform a few minor name corrections and add proper emails to the commit history. This should allow us to avoid name-related rewinds. I'll send a separate email/RFC about the email addresses. -Dave On Sep 23, 2013, at 8:31 AM, David Goodell (dgoodell) wrote: > A clarification for those on the devel@ list who were not on our private > email thread about these issues: "issue (F)" is the "v1.X-series" tag issue. > That is, the second rewind has not yet happened. > > -Dave > > On Sep 22, 2013, at 3:33 AM, Eugene Voronov wrote: > >> Hi All, >> I've finished with dynamic generation of authors list direct from SVN, thus >> feature provide solution resolve issues of mirroring from svn2git. >> >> Last issue (F) I'll try solve in next few days. >> >> >> >> >> -Original Message- >> From: David Goodell (dgoodell) [mailto:dgood...@cisco.com] >> Sent: Friday, September 20, 2013 7:27 PM >> To: Open MPI Developers >> Cc: Eugene Voronov; Mike Dubman >> Subject: OMPI Git mirror history: incorrect history & rewinding >> >> Short Version: >> >> The OMPI GitHub mirror of the OMPI SVN history currently contains some bad >> history, specifically related to the version tags. Prior to roughly >> September 16th, this repository also contained several other bits of bad >> information/history. The git history was *rewound* some time around the >> 16th, which could cause problems for developers who are using it to >> construct patches for our SVN repository. We expect the history to be >> rewound again once at some point in the (hopefully) near future, which will >> have a similar effect. >> >> Users of the git mirror may need to perform some unconventional steps to >> recover from the upstream rewind in some cases. If you are not currently >> experiencing any trouble with the mirror you may wish to wait until the >> second rewind occurs in the near future. >> >> >> More Detail: >> >> Though OMPI uses SVN as the canonical version control system (VCS), many >> developers use Mercurial (hg) or Git repositories for feature development >> and collaboration before bringing those changes back to SVN. To this end, >> there are two helpful mirrors hosted on bitbucket and GitHub respectively: >> >> https://bitbucket.org/ompiteam/ompi-svn-mirror >> https://github.com/open-mpi/ompi-svn-mirror >> >> The Git mirror is maintained by Mellanox and has been extremely helpful so >> far. However, in July it became clear that some of the history in the >> mirror was incorrect. Specifically: >> >> 1) Several commits had been squashed into a single commit, losing some >> history (eb0b490+7fc1da3+36d7b2c+482041f --> 616629d). However, the tree >> (Git-speak for file contents) at each commit always matched the >> corresponding commit message. >> >> 2) Some author names and user IDs were incorrect in the history. The >> severity of this is low, since they were all typo-level inaccuracies, not >> arbitrarily swapped names. >> >> 3) Most of the release tags are incorrect. The mirror has tags of the form >> "v1.X-series" (where "X" is a valid number) instead of "v1.6.2". These >> "-series" tags then contain directories for each release within that series >> instead of the expected source tree. >> >> Eugene V. at Mellanox recently (~2013-09-16) updated the mirror to address >> issues (1) and (2). Issue (3) remains outstanding, necessitating a future >> update at some as-yet unspecified time. Unfortunately, the act of updating >> the repository to resolve these issues causes entirely new commit ID hashes >> to be created, resulting in a "rewind" of all of the Git branches and tags >> in the mirror. Most git users have not encountered this case and may >> experience difficulty coping with it. >> >> If you encounter trouble with these recent repository updates, you might be >> able to fix your situation by following some of the advice from the >> "RECOVERING FROM UPSTREAM REBASE" section of the "git rebase" manual >> (https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html). If that >> d
