Re: OpenSSL 1.0.0 beta3 release v. VMS

View: New views
13 Messages — Rating Filter:   Alert me  

Re: OpenSSL 1.0.0 beta3 release v. VMS

by Steven M. Schweda-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

From: "Arpadffy Zoltan" <Zoltan.Arpadffy@...>

> As you probably know VMS has a different DIFF output than UNIX diff and
> is not able to produce patch output.
>
> Please advice, how can I share my changes.
>
> May I submit a standard VMS diff output here?

   You might try GNU "diff" for VMS:

      http://antinode.info/dec/sw/diffutils.html

No guarantees, but it has worked for me.  Wake me (directly) if you have
any questions on it or problems with it.

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

[PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Arpadffy Zoltan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Mandatory information:
Request type: PATCH
OS and arch: OpenVMS ALPHA, IA64
OpenSSL version: 1.0.0 beta 3

Hello,

This patch corrects build on OpenVMS systems.

I have tested on ALPHA and IA64 platform with DECC.

As VMS does not have a make clean function yet, it was hard to separate
the really modified files from the copied (poor symlink imitation on
VMS) etc.

I hope that I have not missed anything.

The ALL target has built successfully, tests passed (check the TODO) and
installed the libraries, executables and header files.

TODO:
- test on VAX
- test with other compilers than DECC
- add support for building 32 and 64 bits libraries
- testca and testtsa fails (can not find .rnd file)
- test if everything is there - compare more in detail unix makefiles
with VMS

OPTIONAL TODO
- in order to make life more compatible we could use the same logicals
like HP's SSL product - I mean SSL$ROOT instead of SSLROOT

Have a nice weekend :)

Best regards,
Zoltan Arpadffy


-----Original Message-----
From: Steven M. Schweda [mailto:sms@...]
Sent: den 12 augusti 2009 21:05
To: openssl-dev@...
Subject: Re: OpenSSL 1.0.0 beta3 release v. VMS

From: "Arpadffy Zoltan" <Zoltan.Arpadffy@...>

> As you probably know VMS has a different DIFF output than UNIX diff
and
> is not able to produce patch output.
>
> Please advice, how can I share my changes.
>
> May I submit a standard VMS diff output here?

   You might try GNU "diff" for VMS:

      http://antinode.info/dec/sw/diffutils.html

No guarantees, but it has worked for me.  Wake me (directly) if you have
any questions on it or problems with it.

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547


openssl-1.0.0.beta3-vms.zip (7K) Download Attachment

Parent Message unknown Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Steven M. Schweda-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

From: "Arpadffy Zoltan" <Zoltan.Arpadffy@...>

> This patch corrects build on OpenVMS systems.

   I haven't looked at it yet, but ...

> As VMS does not have a make clean function yet, it was hard to separate
> the really modified files from the copied (poor symlink imitation on
> VMS) etc.

   Copied files?  What's copied?  I thought that I had eliminated all
the file copying (and the need for any symlinks).

> TODO:
> [...]
> - test with other compilers than DECC

   Who uses anything else?

> OPTIONAL TODO
> - in order to make life more compatible we could use the same logicals
> like HP's SSL product - I mean SSL$ROOT instead of SSLROOT

   I changed the library names from xxx to SSL_xxx to look more like
HP's SSL$xxx (and so I could find them), but I don't see a good reason
to go further than that.  I believe that many people and procedures use
these SSL* logical names to determine which SSL package is being used.
Making everything look exactly the same would seem likely to cause more
trouble than leaving them different.  If there _is_ a good reason to
make a change like this, please explain why, how, and so on, and why it
wouldn't break a lot of existing stuff.

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Arpadffy Zoltan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

> Copied files?  What's copied?  
In makevms.com ALL target will do a SOFTLINKS by the way, that will do a
lot of coping around.
I agree that with the right /INCLUDE parameter it would be more
appropriate to build. I'll add this as well to my TODO list.

>> - test with other compilers than DECC
>   Who uses anything else?
The build scripts are prepared for VAXC and for GCC as well. I share
your opinion that these compilers are not used that often nowadays...
but on old vaxes VAXC still rules and GCC might get a wing in the
future. It is worth testing at all, unfortunately I do not have
environment for that.

>> OPTIONAL TODO
>> - in order to make life more compatible we could use the same
logicals
>> like HP's SSL product - I mean SSL$ROOT instead of SSLROOT
>If there _is_ a good reason to make a change like this, please explain
why

In the past almost 10 years nobody used any other SSL on OpenVMS but
HP's.
I know that it is utopist thought - but I would prefer to have one SSL
library on OpenVMS - even better it that would be supported by HP
itself.

It is rather easy to make few steps towards HP's SSL build that might
motivate and encourage HP to send back their changes to the openssl
community.
Like this the whole OpenVMS community would benefit... as well as HP's
supported SSL product build would be trivial and reduce to regression
tests and repackaging.

I am an optimist and unitarist who still believe in tolerance and free
will's good choices.

Regards,
Z

-----Original Message-----
From: Steven M. Schweda [mailto:sms@...]
Sent: den 15 augusti 2009 18:39
To: openssl-dev@...
Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

From: "Arpadffy Zoltan" <Zoltan.Arpadffy@...>

> This patch corrects build on OpenVMS systems.

   I haven't looked at it yet, but ...

> As VMS does not have a make clean function yet, it was hard to
separate
> the really modified files from the copied (poor symlink imitation on
> VMS) etc.

   Copied files?  What's copied?  I thought that I had eliminated all
the file copying (and the need for any symlinks).

> TODO:
> [...]
> - test with other compilers than DECC

   Who uses anything else?

> OPTIONAL TODO
> - in order to make life more compatible we could use the same logicals
> like HP's SSL product - I mean SSL$ROOT instead of SSLROOT

   I changed the library names from xxx to SSL_xxx to look more like
HP's SSL$xxx (and so I could find them), but I don't see a good reason
to go further than that.  I believe that many people and procedures use
these SSL* logical names to determine which SSL package is being used.
Making everything look exactly the same would seem likely to cause more
trouble than leaving them different.  If there _is_ a good reason to
make a change like this, please explain why, how, and so on, and why it
wouldn't break a lot of existing stuff.

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

Parent Message unknown RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Arpadffy Zoltan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

> No.

OK.

...seems SMS is also against... and I am keen to bow in front of
democracy :)

Regards,
Z

-----Original Message-----
From: Richard Levitte [mailto:richard@...]
Sent: den 17 augusti 2009 10:37
To: openssl-dev@...; Arpadffy Zoltan
Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

In message <839C820B5C926B4B89713B3A6ED68D2AAE493D@...>
on Fri, 14 Aug 2009 19:15:12 +0200, "Arpadffy Zoltan"
<Zoltan.Arpadffy@...> said:

Zoltan.Arpadffy> OPTIONAL TODO
Zoltan.Arpadffy> - in order to make life more compatible we could use
the same logicals
Zoltan.Arpadffy> like HP's SSL product - I mean SSL$ROOT instead of
SSLROOT

No.

$ in logical names and such are not recommended outside of
DEC/Compaq/HP, they have "reserved" that character for their own use
for ages.

Also, if we use the same and we ave a versioning conflict between the
products, there will be trouble.  And I really see no reason why two
products, even though one is based on the other, should compete over
logical names.

Cheers,
Richard

--
Richard Levitte                         richard@...
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

Parent Message unknown RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Arpadffy Zoltan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

You are right...
There were lot of try and fail play around the headers and I wanted to
submit the patch before the sunset - therefore I haven't checked it
over.

1. _XOPEN_SOURCE_EXTENDED issue.
Yes, it would be good to have it defined for all VMS systems, but the
main reason was the struct timeval that is in the time.h ... depending
on that define. But I have found resource.h an include file made to
solve issues around this.

2. It is a copy paste mistake, because of the reason explained above :(
Part:
+ #if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS)
+ #include <sys/timeb.h>
+ #endif
Should not be there - please ignore it.

Regards,
Z

-----Original Message-----
From: Richard Levitte [mailto:richard@...]
Sent: den 17 augusti 2009 11:10
To: openssl-dev@...; Arpadffy Zoltan
Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

In message <839C820B5C926B4B89713B3A6ED68D2AAE493D@...>
on Fri, 14 Aug 2009 19:15:12 +0200, "Arpadffy Zoltan"
<Zoltan.Arpadffy@...> said:

Zoltan.Arpadffy> Mandatory information:
Zoltan.Arpadffy> Request type: PATCH
Zoltan.Arpadffy> OS and arch: OpenVMS ALPHA, IA64
Zoltan.Arpadffy> OpenSSL version: 1.0.0 beta 3

I've looked through it, and applied almost all of it.  There are just
two things I wonder about, and haven't applied yet:

In makevms.com:

*************** $!
*** 342,347 ****
--- 343,349 ----
  $   WRITE H_FILE "#undef OPENSSL_EXPORT_VAR_AS_FUNCTION"
  $   WRITE H_FILE "#define OPENSSL_EXPORT_VAR_AS_FUNCTION"
  $!
+ $   WRITE H_FILE "#define _XOPEN_SOURCE_EXTENDED"
  $!  End
  $!
  $ ENDIF

This would only define that logical for VAX.  Is it really not needed
for Alpha and ia64?
Please understand me, adding that logical there is probably a very
good idea...  I've been conservative and only added it on
file-per-file basis, and that's probably not the wisest.

*** openssl-100-beta3/SSL/DTLS1.H Wed Jun 17 13:38:26 2009
--- openssl-100-beta3-work/SSL/DTLS1.H Fri Aug 14 09:40:39 2009
***************
*** 62,67 ****
--- 62,74 ----
 
  #include <openssl/buffer.h>
  #include <openssl/pqueue.h>
+ #if defined(OPENSSL_SYS_WIN32) || defined(OPENSSL_SYS_VMS)
+ #include <sys/timeb.h>
+ #endif
+ #ifdef OPENSSL_SYS_VMS
+ #include <resource.h>
+ #include <sys/timeb.h>
+ #endif
  #ifdef OPENSSL_SYS_WIN32
  /* Needed for struct timeval */
  #include <winsock.h>

This seems odd to me.  Or rather, the first added conditional.  I
doubt Win32 needs sys/timeb.h, as it uses a different mechanism (as
far as I understand, I'm not the Windows hacker here ;-)), and it
seems redundant to include sys/timeb.h twice for VMS.  So far as I can
see, only the second added conditional makes sense...

Cheers,
Richard

--
Richard Levitte                         richard@...
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

Parent Message unknown Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Steven M. Schweda-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

From: "Arpadffy Zoltan" <Zoltan.Arpadffy@...>

> As VMS does not have a make clean function yet, [...]

   When _all_ the product files get put into architecture-specific
directories, then cleaning gets easy.

> > Copied files?  What's copied? =20
> In makevms.com ALL target will do a SOFTLINKS by the way, that will do a
> lot of coping around.
> I agree that with the right /INCLUDE parameter it would be more
> appropriate to build. I'll add this as well to my TODO list.

   I already added it to my DONE list for 0.9.8k.

      notes_0_9_8k.txt:

            VMS Changes to OpenSSL 0.9.8k   2009-03-29  SMS.
            ================================================
[...]
makevms.com             Added IA64 support.
[...]
                        Changed to stop copying files into "[.apps]".
                        Changed to stop copying files into "[.test]".
[...]


   I haven't done anything with the new (1.0.0 beta X) stuff because
it wasn't not clear that anyone was looking at the changes I made to the
old stuff.  It's still not clear.

> >> - test with other compilers than DECC
> >   Who uses anything else?
> The build scripts are prepared for VAXC and for GCC as well. I share
> your opinion that these compilers are not used that often nowadays...
> but on old vaxes VAXC still rules and GCC might get a wing in the
> future. It is worth testing at all, unfortunately I do not have
> environment for that.

   I have a VAX with V5.5-2 and VAX C on it, but I'd be amazed if this
code could be built using VAX C.  The only GNU C I have is also on that
VAX, and it's even older than the VAX C.  I assumed that the non-DEC-C
code was all fossils, but it seemed harmless to leave it in.  The builds
haven't worked on VAX with _any_ compiler for so long that it's hard to
imagine that anyone is still using VAX C or GNU C there.


From: Richard Levitte [mailto:richard@...]

> I've looked through it, and applied almost all of it. [...]

   If more than one person will be making big changes to these builders,
then it might make some sense to discuss the changes before applying all
of anything to the code.

   I had what I thought was a whole, working 0.9.8k kit, where "working"
means that the builds went through on VAX, Alpha, and IA64.  Some of
those changes seem to have made it to 1.0.0 beta 3, but not all, and I
don't know why.  I've asked, but I hear nothing.  I can't see a good
reason to make the same changes over and over again if they do not get
adopted, and no one says why they do not get adopted.  What am I
missing?  Is there some plan here?

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Richard Levitte - VMS Whacker :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

(resend)

In message <09081709341183_202004B7@...> on Mon, 17 Aug 2009 09:34:11 -0500 (CDT), sms@... (Steven M. Schweda) said:

sms> From: "Arpadffy Zoltan" <Zoltan.Arpadffy@...>
sms>
sms> > As VMS does not have a make clean function yet, [...]
sms>
sms>    When _all_ the product files get put into architecture-specific
sms> directories, then cleaning gets easy.

Agreed, but except for cleaning purposes, is there a reason to put
architecture-independent files in architecture-specific directories?

sms>    I haven't done anything with the new (1.0.0 beta X) stuff
sms> because it wasn't not clear that anyone was looking at the
sms> changes I made to the old stuff.  It's still not clear.

I've looked, as I've said before.  I've also applied the functional
bits.  Not the cosmetic bits, not the non-copying bits, as they really
should make no difference, or?

Also, the SSLfoo to SSL_foo logical name conversion...  hmm, did I
apply that?  If I did, it should be reverted, at least in the 0.9.8
series, as such a change will only confuse the users...

sms>    I have a VAX with V5.5-2 and VAX C on it, but I'd be amazed if
sms> this code could be built using VAX C.  The only GNU C I have is
sms> also on that VAX, and it's even older than the VAX C.  I assumed
sms> that the non-DEC-C code was all fossils, but it seemed harmless
sms> to leave it in.  The builds haven't worked on VAX with _any_
sms> compiler for so long that it's hard to imagine that anyone is
sms> still using VAX C or GNU C there.

I haven't had a VAX account for a long time...  someone give me one
and I'll play...

sms> From: Richard Levitte [mailto:richard@...]
sms>
sms> > I've looked through it, and applied almost all of it. [...]
sms>
sms>    If more than one person will be making big changes to these
sms> builders, then it might make some sense to discuss the changes
sms> before applying all of anything to the code.

If those who do commit to the repository, I believe I'm the only one
dealing with the VMS parts of the kit...  Andy might play, but his
focus is on other things, I think...

sms>    I had what I thought was a whole, working 0.9.8k kit, where
sms> "working" means that the builds went through on VAX, Alpha, and
sms> IA64.  Some of those changes seem to have made it to 1.0.0 beta
sms> 3, but not all, and I don't know why.  I've asked, but I hear
sms> nothing.  I can't see a good reason to make the same changes over
sms> and over again if they do not get adopted, and no one says why
sms> they do not get adopted.  What am I missing?  Is there some plan
sms> here?

The plan I worked with (and thought I said) was to take the functional
bits first, have them work, and take the cosmetics later...  I had to
do quite a lot of reading through your patches to extract what I
judged to be functional.  I may have missed some bits.

Cheers,
Richard

--
Richard Levitte                         richard@...
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Arpadffy Zoltan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

> I haven't had a VAX account for a long time...  someone give me one
and I'll play...

You can create your own account at
http://www.polarhome.com/service/shell/
... and just drop me a mail informing me what is you username.

Regards,
Z

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

Parent Message unknown Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Steven M. Schweda-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

From: Richard Levitte <richard@...>

> sms>    When _all_ the product files get put into architecture-specific
> sms> directories, then cleaning gets easy.
>
> Agreed, but except for cleaning purposes, is there a reason to put
> architecture-independent files in architecture-specific directories?

   No, but it would be good to segregate all the generated files from
the source tree.  For example, copying C source files into [.APPS] and
[.TEST] seems to be an unnecessary waste of time and disk space, with no
obvious benefit.

> sms>    I haven't done anything with the new (1.0.0 beta X) stuff
> sms> because it wasn't not clear that anyone was looking at the
> sms> changes I made to the old stuff.  It's still not clear.
>
> I've looked, as I've said before.  I've also applied the functional
> bits.  Not the cosmetic bits, not the non-copying bits, as they really
> should make no difference, or?

   The file copying stuff makes no sense to me.  Eliminating it also
makes it easier to compare a VMS source tree with a UNIX source tree.
Why do it?  A bad idea does not get better just because it gets older.

   Here's one annoying cosmetic thing.  In install.com:

$ IF (F$GETSYI("CPU").LT.128)
$ THEN
$    ARCH := VAX
$ ELSE
$    ARCH = F$EDIT( F$GETSYI( "ARCH_NAME"), "UPCASE")
$    IF (ARCH .EQS. "") THEN ARCH = "UNK"
$ ENDIF

Ignoring the annoying tab indentation, why mix styles like
      ARCH := VAX
and
      ARCH = "UNK"
???
I prefer to use "=" with a quoted string instead of ":=" with an
unquoted string, because it avoids any unplanned case changes, but why
mix them this way?

   And that tab indentation is pretty annoying, and it's not used
everywhere.  See, for example, makevms.com.  Where, by the way, that
seven-line architecture determination is fluffed up to about 3X that
size.  Using the same code fragment to do the same job everywhere is not
merely a cosmetic change.  I claim that it improves maintainability.  If
I had my way, I'd have a single procedure to do that particular job, and
everyone would use it.  But I suppose that that would be just one more
cosmetic change, so I didn't try to push that one through.

> Also, the SSLfoo to SSL_foo logical name conversion...  hmm, did I
> apply that?  If I did, it should be reverted, at least in the 0.9.8
> series, as such a change will only confuse the users...

   I didn't change any logical names, only the names of the actual
library files.  Yes, without some documentation, it might confuse some
users.  I don't see why SET FILE /ENTER couldn't be used to aid a
transition to what I claim would be _less_ confusing names.  1.0.0
sounds to me like a near-ideal time to make the switch.

> I haven't had a VAX account for a long time...  someone give me one
> and I'll play...

   I'd spend some time looking for a user who would care about VAX C
before I spent any time trying to use it to compile any modern code.
DEC C has been around since about when, mid-1994?  On my fastest VAX
(4000 model 200), building this stuff takes a whole day.  I don't keep a
VAX running continuously, so playing with mine would not be convenient
(especially in summer).

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Arpadffy Zoltan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message



Hello Richard,

>If those who do commit to the repository, I believe I'm the only one
>dealing with the VMS parts of the kit...

I tested OPENSSL-VMS_64BIT-SNAP-20090821 as I was expecting that my
changes would be there.
I was wrong :(

I wonder, where do you apply the patches and patch suggestions?
Is there any source snapshot that is possible to test?

Thank you.
Have a nice weekend.

Regards,
Z
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Richard Levitte - VMS Whacker :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

In message <839C820B5C926B4B89713B3A6ED68D2AAE49C2@...> on Fri, 21 Aug 2009 17:36:08 +0200, "Arpadffy Zoltan" <Zoltan.Arpadffy@...> said:

Zoltan.Arpadffy>
Zoltan.Arpadffy>
Zoltan.Arpadffy> Hello Richard,
Zoltan.Arpadffy>
Zoltan.Arpadffy> >If those who do commit to the repository, I believe I'm the only one
Zoltan.Arpadffy> >dealing with the VMS parts of the kit...
Zoltan.Arpadffy>
Zoltan.Arpadffy> I tested OPENSSL-VMS_64BIT-SNAP-20090821 as I was expecting that my
Zoltan.Arpadffy> changes would be there.
Zoltan.Arpadffy> I was wrong :(

Yes.  I'm committing your changes (as well as sms') directly to the
1.0.0 branch as well as the 0.9.8 branch.

Cheers,
Richard

--
Richard Levitte                         richard@...
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...

RE: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

by Arpadffy Zoltan :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hello,

It has passed few months and it is getting closer to the official
release of v1.0.0.

I have recently checked out the source from the CVS and tested the VMS
build and in order to finalize issues from my TODO lis:
- add support for building 32 and 64 bits libraries
- testca and testtsa fails (can not find .rnd file)

Unfortunately, the build failed.

Wonder:

1. is it right assumption that the last cvs checkout should contain all
recent patches, changes for 1.0.0?
2. Have all VMS related changes that I have sent been merged into the
code? (1.0.0beta3 builds nice with my patches on VMS)
3. How should we proceed? Should I send a new patch that corrects VMS
build against latest code from the cvs?

I would like to see openssl building correctly on OpenVMS before 1.0.0
is released. Hope that this is a common goal.

Thank you in advance.

Regards,
Z

-----Original Message-----
From: Richard Levitte [mailto:richard@...]
Sent: den 25 augusti 2009 10:09
To: openssl-dev@...; Arpadffy Zoltan
Subject: Re: [PATCH] OpenSSL 1.0.0 beta3 release v. VMS

In message <839C820B5C926B4B89713B3A6ED68D2AAE49C2@...>
on Fri, 21 Aug 2009 17:36:08 +0200, "Arpadffy Zoltan"
<Zoltan.Arpadffy@...> said:

Zoltan.Arpadffy>
Zoltan.Arpadffy>
Zoltan.Arpadffy> Hello Richard,
Zoltan.Arpadffy>
Zoltan.Arpadffy> >If those who do commit to the repository, I believe
I'm the only one
Zoltan.Arpadffy> >dealing with the VMS parts of the kit...
Zoltan.Arpadffy>
Zoltan.Arpadffy> I tested OPENSSL-VMS_64BIT-SNAP-20090821 as I was
expecting that my
Zoltan.Arpadffy> changes would be there.
Zoltan.Arpadffy> I was wrong :(

Yes.  I'm committing your changes (as well as sms') directly to the
1.0.0 branch as well as the 0.9.8 branch.

Cheers,
Richard

--
Richard Levitte                         richard@...
                                        http://richard.levitte.org/

"Life is a tremendous celebration - and I'm invited!"
-- from a friend's blog, translated from Swedish
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
Development Mailing List                       openssl-dev@...
Automated List Manager                           majordomo@...