Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 16 Jun 2010 21:43:21 -0600
From: RB <aoz.syn@...il.com>
To: john-users@...ts.openwall.com
Subject: Re: 1.7.6-jumbo-2

On Wed, Jun 16, 2010 at 18:31, Solar Designer <solar@...nwall.com> wrote:
> I think it'd be helpful to have
> john-1.7.5-fullmpi-8-after-jumbo2.diff.gz updated to apply after
> 1.7.6-jumbo-3.  In fact, I'd like to see it in a form suitable for
> merging into the jumbo patch

Interesting, I thought you would have preferred to see it go.  The
reason I'd originally re-designed it to apply before the jumbo patch
was that the jumbo patch is a moving target and it was easier to get
one MPI patch that applied to a clean tree and avoided conflicts with
anything the jumbo was doing.  Combining it into the jumbo patch
should be relatively trivial.

Heck, I personally would love to see the jumbo itself broken out into
a series of non-conflicting, bisectable patches instead of the
snowball it's become, but don't know enough about the individual
contributons to disentangle them without spending serious time.  I
also have my suspicions that there are going to be guaranteed
conflicts since the core code wasn't necessarily designed with
patching in mind.  Of course, there are those on the other end of the
spectrum that would rather see the whole patching business go away,
not made even more "complex".

> that is, with proper #ifdef's to allow
> for both non-MPI and MPI-enabled builds from the same source tree.

I think that can be done, but the build process will have to be hooked
as well, since the MPI patch uses mpicc instead of gcc.


RB

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.