installation fails on Ubuntu 20.04 because of outdated libssl

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

installation fails on Ubuntu 20.04 because of outdated libssl

GLASS mailing list

Hi,

 

I just tried to install GsDevKit on Ubuntu 20.04 LTS.

The “createStone” step fails presumably because of an old and unavailable ssl library. The log file says:

 

Package libssl1.0.0:i386 is not available, but is referred to by another package.

This may mean that the package is missing, has been obsoleted, or

is only available from another source

 

E: Package 'libssl1.0.0:i386' has no installation candidate

 

Any recommendation to get over this?

 

Thanks,

                Christian

 

P.S. since you probably want the whole log, I attached it (no secrets in there)

 


_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass

install.log (73K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: installation fails on Ubuntu 20.04 because of outdated libssl

GLASS mailing list
Christian,

[sorry for the late reply, but my mail client didn't send this message when I wrote it a week ago, and I didn't notice until now]

This seems to be in intermittent error on 20.04. It was originally reported last July [1], but I was not able to reproduce the failure[2], as the gsDevKitCommandLine.image was created without error ... The original reporter (Marten Feldtmann) reinstalled GsDevKit_home and tried again and was successful[3].

The issue is appearing in 32 bit Pharo3.0 and the missing libssl1.0.0:i386 file does not appear to be the cause of the problem, so I'm not sure if there is very much that can be done to resolve the root problem other than replace Pharo3.0 with a 64 bit solution.

The good news (I suppose) is that back in the March/April timeframe Jupiter Jones and I revived work on issue #260 [4](replacing use 32 bit pharo with topaz solo scripts).

Issue #260 was first opened in October of 2019 and I sent out a call for volunteers[5] at that time which did not garner much support (thank you Bruno for stepping up to the plate at that point in time).

This time around we are using a different solo scripting project, superDoit[6] which is a scripting solution that is specific to GemStone. The scripts include support for help and argument handling and here is a simple example of a script with help and command line arguments[7]. To date, Jupiter has replaced a handful of the $GS_HOME scripts with superDoit .solo scripts, but there is more work to be done. Johan Brichau has also indicated that he is planning to contribute.

None of us has a lot of free time to devote to the conversion project, but it is something that is well overdue. There are around 100 bash scripts that need to be rewritten so if anyone else has some spare time to contribute your help will be appreciated!

Some of the bash scripts are all in bash and should be straight forwrd to translate into smalltalk Some of them make calls to Pharo3.0 and and will be a bit more complicated, since the Pharo code will have to be ported to the solo script. Jupiter has already ported some of the Pharo code to GemStone and that work has been done by creating classes in filetree packages that are loaded into the solo extent when the script is executed.

Part of this project also involves creating a new version of GsDevKit_home and Jupiter has a plan that allows the new version of GsDevKit_home to be used against an existing GsDevKit_home installation or "attached" to non-GsDevKit_home stones as well ... basically the stone meta-data is stored in a directory structure totally independent of the stones directory structure so if all goes well the new version of GsDevKit_home will be useful in a wider range of installations ...

If you are interested in contributing, send me an email and I'll add you to an internal slack channel that is devoted to this project where we'll share additional details and coordinate the work.

Dale


On May 20 2021, at 7:10 am, Christian Haider via Glass <[hidden email]> wrote:
Hi,

 

I just tried to install GsDevKit on Ubuntu 20.04 LTS.

The “createStone” step fails presumably because of an old and unavailable ssl library. The log file says:

 

Package libssl1.0.0:i386 is not available, but is referred to by another package.

This may mean that the package is missing, has been obsoleted, or

is only available from another source

 

E: Package 'libssl1.0.0:i386' has no installation candidate

 

Any recommendation to get over this?

 

Thanks,

                Christian

 

P.S. since you probably want the whole log, I attached it (no secrets in there)

 
_______________________________________________
Glass mailing list
https://lists.gemtalksystems.com/mailman/listinfo/glass

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: installation fails on Ubuntu 20.04 because of outdated libssl

GLASS mailing list

Hi Dale,

 

thank for this great explanation!

 

Argh – wasp nest. Why couldn’t I keep my finger to myself – or researched the issue before reporting a “simple” script problem…

 

The idea is great! Smalltalk instead of shell scripts. Debugging shell scripts is such a pain .

What a relieve if superDoit is “Smalltalk-like” debuggable!

But it seems that there are a few thick loose ends dangling.

And it is still (to me, who has not spent that much time on it) confusing with so many little files and places…

 

Hopefully, this project sees the light as a supported version one day!

But sorry for not jumping in – too much on my plate as well (and I can live fine with Ubuntu 18).

 

Good luck,

                Christian

 

 

Von: Dale Henrichs <[hidden email]>
Gesendet: Mittwoch, 26. Mai 2021 19:22
An: Christian Haider <[hidden email]>; [hidden email]
Betreff: Re: [Glass] installation fails on Ubuntu 20.04 because of outdated libssl

 

Christian,

 

[sorry for the late reply, but my mail client didn't send this message when I wrote it a week ago, and I didn't notice until now]

 

This seems to be in intermittent error on 20.04. It was originally reported last July [1], but I was not able to reproduce the failure[2], as the gsDevKitCommandLine.image was created without error ... The original reporter (Marten Feldtmann) reinstalled GsDevKit_home and tried again and was successful[3].

 

The issue is appearing in 32 bit Pharo3.0 and the missing libssl1.0.0:i386 file does not appear to be the cause of the problem, so I'm not sure if there is very much that can be done to resolve the root problem other than replace Pharo3.0 with a 64 bit solution.

 

The good news (I suppose) is that back in the March/April timeframe Jupiter Jones and I revived work on issue #260 [4](replacing use 32 bit pharo with topaz solo scripts).

 

Issue #260 was first opened in October of 2019 and I sent out a call for volunteers[5] at that time which did not garner much support (thank you Bruno for stepping up to the plate at that point in time).

 

This time around we are using a different solo scripting project, superDoit[6] which is a scripting solution that is specific to GemStone. The scripts include support for help and argument handling and here is a simple example of a script with help and command line arguments[7]. To date, Jupiter has replaced a handful of the $GS_HOME scripts with superDoit .solo scripts, but there is more work to be done. Johan Brichau has also indicated that he is planning to contribute.

 

None of us has a lot of free time to devote to the conversion project, but it is something that is well overdue. There are around 100 bash scripts that need to be rewritten so if anyone else has some spare time to contribute your help will be appreciated!

 

Some of the bash scripts are all in bash and should be straight forwrd to translate into smalltalk Some of them make calls to Pharo3.0 and and will be a bit more complicated, since the Pharo code will have to be ported to the solo script. Jupiter has already ported some of the Pharo code to GemStone and that work has been done by creating classes in filetree packages that are loaded into the solo extent when the script is executed.

 

Part of this project also involves creating a new version of GsDevKit_home and Jupiter has a plan that allows the new version of GsDevKit_home to be used against an existing GsDevKit_home installation or "attached" to non-GsDevKit_home stones as well ... basically the stone meta-data is stored in a directory structure totally independent of the stones directory structure so if all goes well the new version of GsDevKit_home will be useful in a wider range of installations ...

 

If you are interested in contributing, send me an email and I'll add you to an internal slack channel that is devoted to this project where we'll share additional details and coordinate the work.

 

Dale

 

 

On May 20 2021, at 7:10 am, Christian Haider via Glass <[hidden email]> wrote:

Hi,

 

 

 

I just tried to install GsDevKit on Ubuntu 20.04 LTS.

 

The “createStone” step fails presumably because of an old and unavailable ssl library. The log file says:

 

 

 

Package libssl1.0.0:i386 is not available, but is referred to by another package.

 

This may mean that the package is missing, has been obsoleted, or

 

is only available from another source

 

 

 

E: Package 'libssl1.0.0:i386' has no installation candidate

 

 

 

Any recommendation to get over this?

 

 

 

Thanks,

 

                Christian

 

 

 

P.S. since you probably want the whole log, I attached it (no secrets in there)

 

 

_______________________________________________

Glass mailing list


_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass
Reply | Threaded
Open this post in threaded view
|

Re: installation fails on Ubuntu 20.04 because of outdated libssl

GLASS mailing list
Argh – wasp nest. Why couldn’t I keep my finger to myself – or researched the issue before reporting a “simple” script problem…

No problem, I'd rather have a few "false negatives" rather than real problem going unreported...

The idea is great! Smalltalk instead of shell scripts. Debugging shell scripts is such a pain .
What a relieve if superDoit is “Smalltalk-like” debuggable!

There's a standard -D option that brings up a topaz debugger in the event of an error and the classes that are used by the GsDevKit_home scripts are loaded from disk (using Rowan) on every invocation, so most of the code used in a script is accessible on disk ...

Which is good and bad ... The good part is that I can ship new features and bugfixes without a requiring a rebuild of the pharo image (or topaz solo extent). the (sorta) bad news is that we haven't built a smalltalk image based dev environment for superDoit scripts (yet), so development is split across an image and vi ....

But it seems that there are a few thick loose ends dangling.
And it is still (to me, who has not spent that much time on it) confusing with so many little files and places…

I assume you are talking about GsDevKit_home here :) ... but yes the important structure (for me) is that each stone has a standard structure and the scripts can interact with a stone by simply specifying the name of the stone ...  it's also important that the git clones are in well-known locations so that multiple stones can shared the same git repository and SHA ... In the new GsDevKit_home version Jupiter is proposing that there will be multiple families of git repository directories so that development stones and production stones can be isolated from each other while sharing the same management scripts ...

Hopefully, this project sees the light as a supported version one day!

Haha, you and me both!

But sorry for not jumping in – too much on my plate as well (and I can live fine with Ubuntu 18).

Understood, everyone is busy and there is not a lot of free time to go around ... my excuse is that I'm working on a official development environment for GemStone :)

Dale

On May 28 2021, at 4:30 am, Christian Haider <[hidden email]> wrote:
Hi Dale,

 

thank for this great explanation!

 

Argh – wasp nest. Why couldn’t I keep my finger to myself – or researched the issue before reporting a “simple” script problem…

 

The idea is great! Smalltalk instead of shell scripts. Debugging shell scripts is such a pain .

What a relieve if superDoit is “Smalltalk-like” debuggable!

But it seems that there are a few thick loose ends dangling.

And it is still (to me, who has not spent that much time on it) confusing with so many little files and places…

 

Hopefully, this project sees the light as a supported version one day!

But sorry for not jumping in – too much on my plate as well (and I can live fine with Ubuntu 18).

 

Good luck,

                Christian

 

 

Von: Dale Henrichs <[hidden email]>
Gesendet: Mittwoch, 26. Mai 2021 19:22
An: Christian Haider <[hidden email]>; [hidden email]
Betreff: Re: [Glass] installation fails on Ubuntu 20.04 because of outdated libssl
 

Christian,
 

[sorry for the late reply, but my mail client didn't send this message when I wrote it a week ago, and I didn't notice until now]
 

This seems to be in intermittent error on 20.04. It was originally reported last July [1], but I was not able to reproduce the failure[2], as the gsDevKitCommandLine.image was created without error ... The original reporter (Marten Feldtmann) reinstalled GsDevKit_home and tried again and was successful[3].
 

The issue is appearing in 32 bit Pharo3.0 and the missing libssl1.0.0:i386 file does not appear to be the cause of the problem, so I'm not sure if there is very much that can be done to resolve the root problem other than replace Pharo3.0 with a 64 bit solution.
 

The good news (I suppose) is that back in the March/April timeframe Jupiter Jones and I revived work on issue #260 [4](replacing use 32 bit pharo with topaz solo scripts).
 

Issue #260 was first opened in October of 2019 and I sent out a call for volunteers[5] at that time which did not garner much support (thank you Bruno for stepping up to the plate at that point in time).
 

This time around we are using a different solo scripting project, superDoit[6] which is a scripting solution that is specific to GemStone. The scripts include support for help and argument handling and here is a simple example of a script with help and command line arguments[7]. To date, Jupiter has replaced a handful of the $GS_HOME scripts with superDoit .solo scripts, but there is more work to be done. Johan Brichau has also indicated that he is planning to contribute.
 

None of us has a lot of free time to devote to the conversion project, but it is something that is well overdue. There are around 100 bash scripts that need to be rewritten so if anyone else has some spare time to contribute your help will be appreciated!
 

Some of the bash scripts are all in bash and should be straight forwrd to translate into smalltalk Some of them make calls to Pharo3.0 and and will be a bit more complicated, since the Pharo code will have to be ported to the solo script. Jupiter has already ported some of the Pharo code to GemStone and that work has been done by creating classes in filetree packages that are loaded into the solo extent when the script is executed.
 

Part of this project also involves creating a new version of GsDevKit_home and Jupiter has a plan that allows the new version of GsDevKit_home to be used against an existing GsDevKit_home installation or "attached" to non-GsDevKit_home stones as well ... basically the stone meta-data is stored in a directory structure totally independent of the stones directory structure so if all goes well the new version of GsDevKit_home will be useful in a wider range of installations ...
 

If you are interested in contributing, send me an email and I'll add you to an internal slack channel that is devoted to this project where we'll share additional details and coordinate the work.
 

Dale
 

 

On May 20 2021, at 7:10 am, Christian Haider via Glass <[hidden email]> wrote:
Hi,
 

 
 

I just tried to install GsDevKit on Ubuntu 20.04 LTS.
 

The “createStone” step fails presumably because of an old and unavailable ssl library. The log file says:
 

 
 

Package libssl1.0.0:i386 is not available, but is referred to by another package.
 

This may mean that the package is missing, has been obsoleted, or
 

is only available from another source
 

 
 

E: Package 'libssl1.0.0:i386' has no installation candidate
 

 
 

Any recommendation to get over this?
 

 
 

Thanks,
 

                Christian
 

 
 

P.S. since you probably want the whole log, I attached it (no secrets in there)
 

 
_______________________________________________
Glass mailing list

_______________________________________________
Glass mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/glass