[OMPI devel] Build failure on FreeBSD 7

[Karol Mroz]

After digging a little deeper, it turns out that the kevent() call in
opal/event/kquene.c:
if (kevent(kq,
   kqueueop->changes, 1, kqueueop->events, NEVENT, NULL) != 1 ||
   (int)kqueueop->events[0].ident != master ||
   kqueueop->events[0].flags != EV_ERROR) {

seems to hang in freebsd 7. Changing the NULL parameter to, lets say
1000, causes the function to return and print out the error message:

	event_warn("%s: detected broken kqueue (failed delete); not 		 	using 
error %d (%s)", __func__, errno, strerror(errno));


The simple non-blocking send/recv app used to test this then runs to
completion. Compiling OpenMPI on linux and running this same app
produces no errors.

Any ideas?

Thanks.
--
Karol

Re: [OMPI devel] Switching away from SVN?

[Manuel Prinz]

Am Mittwoch, 19. März 2008 00:02:47 schrieb Roland Dreier:
> As an ompi bystander, I would strongly endorse a switch away from svn.
> I think that git, hg and bzr are all roughly equivalent -- they each
> have their enthusiastic partisans, but in reality they're all probably
> fine.  And the difference between svn and any of the newer distributed
> systems, especially for a big codebase like ompi, is pretty huge.

Speaking as an Debian OpenMPI maintainer, I as well endorse a switch away from 
SVN since it will make package maintainance more easy for us. Most Debian 
maintainers tend to use git (if they use a DVCS), Ubuntu seems to prefer bzr, 
but I can't say about others. Of course, you should use the systems you 
prefer but it may be worth to consider the preferences of distributors. 
Debian has quite sophisticated tools for packaging for almost all DVCS, so it 
is not really an issue which one you'll choose from Debian's point of view. 
(I personally prefer git over all others. I'm a git fan-boy. Don't know 
Dirk's opinion on that.) I use git for my packaging work on OpenMPI, although 
we have a SVN repo. ;)

Anyway, switching away from SVN would ease the work on both sides, since 
patches/commits can easily merged between our repositories. Features like 
cherry-picking can be very useful here. Also, git's feature to export/import 
commits via email helps a lot, as I can tell from experience. Reducing the 
time to integrate changes/patches is definately worth switching to an DVCS.

Best regards
Manuel