[Vm-dev] Re: [squeak-dev] Crypto plugins for ubuntu 32-bits

[Robert Withers]

Hi Dave,

It looks like those 2 methods are now in version 9, are you able to have 
success with this version building? I have but only in one specific 
configuration...here are the steps I have taken:

1) load CryptographyPlugins into a VMMaker image
2) delete files out of these plugin directories under src
3) VMMakerTool openInWorld.
4) make these changes:
4-a) change Interpreter to CoInterpreterPrimitives
4-b) set platform directory to platform directory path
4-c) set path to generated to the src directory
4-d) move 4 crypto plugins to external list
5) Click the External Plugins generate button
6) terminal work:
6-a) goto build.linux32x64/squeak.cog.spur
6-b) add 4 plugins to plugins.ext
6-c) cd into build directory
6-d) ./mvm &> build.out
6-e) sudo make install
6-f) run squeak on Cryptography image
6-g) run Cryptography tests

Best,
Robert

On 12/06/2015 07:30 PM, David T. Lewis wrote:
>   
> Hi Robert,
>
> I think I have overcome my confusion with build problems for the
> plugins.
>
> I am looking at DSAPlugin in the Monticello history (in the Cryptography
> repository) of CryptographyPlugins-rww.9, and it looks to me like the
> intention (in 2010) was to remove DSAPlugin "because it's already in
> VMMaker", but that it was added back in a later update. Unfortunately the
> class side methods for DSAPlugin were then missing from the plugin.
>
> The two missing methods are present in CryptographyPlugins-rww.4. Can you
> please add these two methods back to DSAPlugin? The missing methods are
> DSAPlugin class>>declareCVarsIn: and DSAPlugin class>>moduleName.
>
> I figured out my earlier problems with compiling. The missing class
> methods (see above) were the cause of my original difficulty, and the
> "cmake problem" that I mentioned was just a dumb mistake on my part,
> I was accidentally compiling the plugin as an internal plugin and did
> not notice my configuration mistake. So all is well with building the
> four Cryptography plugins after the two class side methods are restored
> to DSAPlugin.
>
> Thanks,
> Dave
>
> On Sat, Dec 05, 2015 at 09:26:27PM -0500, David T. Lewis wrote:
>>   
>> On Sat, Dec 05, 2015 at 08:51:30PM -0500, Robert Withers wrote:
>>> On 12/05/2015 08:13 PM, David T. Lewis wrote:
>>>> Therefore the open issues I see for DSAPlugin are:
>>>>
>>>> 1) Which repository/package should DSAPlugin be in?
>>>>
>>>> 2) Why isn't the cmake build working for generating the plugin?
>>>>
>>>> Question 1) should be at the discretion of the authors/maintainers of the
>>>> Cryptography plugins, and 2) is probably just a glitch in the build
>>>> configuration.
>>>>
>>>> FWIW, my personal preference would be to use the plugins directly from the
>>>> Cryptography repository, deleting the DSAPlugin in VMMaker (trunk + oscog),
>>>> and updating configuration maps or build scripts to point to Cryptography.
>>> This is super news, Dave. Thank you for pulling these plugins into the vm.
>>>
>>> I share your opinion that the DSAPlugin stay in the Cryptography
>>> repository. Crypto plugins can be kept together. Since this is no change
>>> to the Cryptography setup, I would expect everyone to be happy with this
>>> proposal; I added the Cryptography team list for their input.
>>>
>>> Are you saying the CryptographyPlugins package could stay in the
>>> Cryptography repository and the Cryptography package and the
>>> CryptographyPlugins package would be automatically pulled into a VMMaker
>>> image? That's sweet. If Cryptography were pulled into the base image,
>>> there would be no need to load it, just the Plugins package. That is
>>> probably a separate discussion, regarding the base image.
>> Yes. I don't see any problem with existing CryptographyPlugins package
>> name, so the plugins can be pulled into a VMMaker image without needing
>> to load anything else from the Cryptography repository. I want to make
>> sure Eliot is ok with this, but it looks straightforward to me.
>>
>>> I have not used CMake, I don't believe - perhaps Pharo uses it - so I
>>> can't add to this. It may be that someone on the Cryptography list knows
>>> more about this.
>>>
>> It's probably no big deal, I just have not looked at it yet. And it's
>> not an issue for Cog/Spur, which is using a different build system. But
>> if you could share whatever makefile or configurations you used to
>> successfully build the plugin on your own system, that would help.
>>   
>>> Another step would be writing a Reed Solomon plugin and getting it
>>> included, as well. This pertains to my interest in getting the whole
>>> SecureSession pipeline pluginized, once I get the RS encoder working.
>>>
>> Great :-)
>>
>> Dave