Hello,
I just created a new raw Lubuntu 14.04 image to try out tODE and Gemstone 3.2.2. I followed the documentation available at github regarding the Development Kit Server Installation. Here are some remarks: "2. Install Gemstone/S and Pharo ..." If one reads the text more closely it should be clear, that executing the script mentioned in this paragraph also downloads the corresponding Gemstone stuff from their server. I actually did a download of the setup script (known from earlier versions) and started it - that is not needed any more. When this scripts finishes the tode client image should be opened. Well this is not happening here. Have not found the actual reason here - I noticed a message, that libpam.so.0 can not be found. Then I started the client manually and I got the message (via the test login), that 'libgcirpc-3.2.2-32' can not be found. Well, that my actual state .... -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
> Then I started the client manually and I got the message (via the test > login), that 'libgcirpc-3.2.2-32' can not be found. > > Well, that my actual state .... The system expected these libraries at "tODE_3.1.app/Contents/Linux/" ... i actually found them in directory "pharo-vm" - so they seem to be there in some directories. Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Mon, Sep 8, 2014 at 7:55 AM, [hidden email] via Glass <[hidden email]> wrote: Hello, Excellent! I think the earlier users of GsDevTalk have pretty much been using OS X, so I appreciate getting feedback about how the scripts function for Linux users. Technically, Ubuntu 14.04 is not yet supported[1], but we don't think that there should be any reason that GemStone 3.2.2 shouldn't run on 14.04... [1] http://gemtalksystems.com/index.php/community/gss-support/resources/compatibility/gs64-platform/
Yes, the GemStone product download scripts also update the pharo client code with the appropriate gci libraries, so it is important that a product download occur. I actually did a download of the setup I'm not sure what you are telling me here? Did you skip any steps or are you saying it should be possible to skip steps ...
I'm not sure it is related, but I do realize that I have neglected the fact that for the pharo client to run correctly on Ubuntu 12.04, a subset of the 32 bit libraries do need to be installed ... the 64bit libpam library is also needed and I am not sure whether or not libpam is installed by default or not ... I will probably end up installing the necessary libraries as part of the script... I would appreciate some context from the logs for the error, so I can determine if I have addressed the problem that you've seen ...
For this I would like to see the full results of the testLogin command, the contents or the info.ston for the stone that you are trying to connect to ($GS_HOME/gemstone/stones/<your stone name>/info.ston and the results of `ls $GS_HOME/pharo/pharo-vm`. Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Mon, Sep 8, 2014 at 8:02 AM, [hidden email] via Glass <[hidden email]> wrote:
For GsDevKit, you no longer should be using the tODE_3.1.app. To start a tODE client in GsDevKit, you should use `$GS_HOME/bin/todeClient` to start the tODE client. When you download a new version of GemStone the product download script ($GS_HOME/bin/installGemStone) automatlcally copies the gci files from the installation into the $GS_HOME/pharo/pharo-vm directory. Soooo, I think that at the end of the day libpam needs to be installed on your system along with possibly other libraries ... I am getting a clean 12.04 Ubuntu vm built that I can update the install scripts to install the necessary 32 bit and 64 bit libraries for GemStone ... For testing on travis-ci, I had to do the following: sudo apt-get update -qq sudo apt-get -y install libpam0g:i386 sudo ln -s /lib/i386-linux-gnu/libpam.so.0 /lib/libpam.so.0 sudo apt-get install -qq gcc-multilib libcurl3:i386 libstdc++6:i386 sudo ln -s /usr/lib/i386-linux-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so I believe that Travis uses Ubuntu 12.04 LTS Server Edition 64 bit, so I'm not sure what would be required for Ubunutu 14.0.4.... Our Ubuntu machines are configured for building GemStone, which is why I missed these dependencies in my initial testing. Dale
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
The error message that contains "tODE_3.1.app/Contents/Linux/" is misleading ... the text is a constant and that is no longer correct, so I will fix that ... sorry for the confusion:) Dale On Mon, Sep 8, 2014 at 11:37 AM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Am 08.09.2014 um 20:23 schrieb Dale Henrichs:
> > > I actually did a download of the setup > script (known from earlier versions) and started it - that is not needed > any more. > > > I'm not sure what you are telling me here? Did you skip any steps or are > you saying it should be possible to skip steps ... > No, *I* had problems to make the *right* interpretation of that sentance - I thought I had to make the installation of Gemstone using the old script before executing the tODE installation - but when I realized, that I had two downloads riunning I stopped the old script ... and then I knew, how it's working .... Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Actually we are switching now to 14.04 LTS, because it is a new LTS
version, it has much newer Mono support available and we have time. Actually if I remember correctly the lib32 subsystem changed from 12.04 to 14.04 (the packaging structure). Marten _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Ah good ... now I understand ... thanks On Mon, Sep 8, 2014 at 12:23 PM, [hidden email] via Glass <[hidden email]> wrote: Am 08.09.2014 um 20:23 schrieb Dale Henrichs: _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
After I get the 12.04 installation straightened out, I will take a look at 14.0.4 and see where we stand ..... as I said, I assume that GemStone will work correctly in 14.04 so it will be a matter of getting the installation validated there as well ... I appreciate your help! Dale On Mon, Sep 8, 2014 at 12:29 PM, [hidden email] via Glass <[hidden email]> wrote: Actually we are switching now to 14.04 LTS, because it is a new LTS _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Ok, now I executed the scripts again and the 3.2.2 version is
downloaded. I notice, that the /opt/gemstone directory structure is not valid created. Only the directory locks and log are created - nothing more (no link, nothing). But I noticed, that the whole product directory is now located where gsDevKitHome is. That also means, that the user (me) should store (clone) the gsDevKitHome directory in the /opt hierarchy. Right ? Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Am 08.09.2014 um 20:37 schrieb Dale Henrichs:
> > Soooo, I think that at the end of the day libpam needs to be installed > on your system along with possibly other libraries ... I am getting a > clean 12.04 Ubuntu vm built that I can update the install scripts to > install the necessary 32 bit and 64 bit libraries for GemStone ... Ouch, that's a pretty bad base ... we had VASmalltalk servers already running under 12.04LTS and we had to use the 32bit subsystem - our administrators were not that happy to install the 32bit subsystem but instead wished, that the developers (we) move towards 64bit apps. Bok, that can be changed. But I assume, that I do not need to install tOde under Linux - but use it from a Windows clients. Therefore perhaps the script should be divided into two parts: * installation of gemstone * (optional) installation of tODE. Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Marten, Installing gemstone into the /opt/gemstone directory has been a convention ... GemStone itself may be installed in any location on disk (like what is done with GsDevKit) I think that only the /opt/gemstone/locks directory is absolutely required. /opt/gemstone/log is used by default, for some log files, but that can be overridden by the use of env variables.... None of the GsDevKit scripts expect to work directly with /opt/gemstone. For example with GsDevKit, the log files should show up in the $GS_HOME/gemstone/stones/<stone name>/logs directory. For GsDevKit it is not necessary to clone the directory in any particular location ... If you have your own scripts that depend upon finding a product installation in a certain location that is a different matter ... Dale On Mon, Sep 8, 2014 at 12:45 PM, [hidden email] via Glass <[hidden email]> wrote: Ok, now I executed the scripts again and the 3.2.2 version is _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Mon, Sep 8, 2014 at 1:05 PM, [hidden email] via Glass <[hidden email]> wrote: Am 08.09.2014 um 20:37 schrieb Dale Henrichs: Good point and that's absolutely correct, the 32 bit libraries are only required for tODE and I do want to make it easy for the optional installation of tODE ... Over the month or so that GsDevKit has been out, I have seen several places where I need to restructure things, so I am glad that I am getting additional independent feedback (some has come via private mail - but I prefer public mail so that others can benefit from the conversation:) before I make another pass through GsDevKit ... At the end of the day, I do anticipate that tODE will "always" be installed on the server ... many of the GsDevKit scripts themselves leverage tODE and I have also been writing server-side scripts in Pharo (non-tODE) so that I and anyone else writing scripts could avoid having to use bash ... Hmmm, I do expect that the bash scripts will be able to leverage the existence of pharo on the server and therefore scripts that are run on the server will need to have the 32 bit libraries installed .... so at the end of the day I would think that GsDevKit will want to be able to expect that a headless pharo client can be run ... I hate to think that I will have to write the cross-platform scripts in something other than Smalltalk ... bash is such a horrible programming environment ... Is the requirement for 32 bit libraries a deal breaker and if so, how many folks can't use gSdevKit if it requires 32 bit libraries? Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
On Sep 8, 2014, at 1:15 PM, Dale Henrichs via Glass <[hidden email]> wrote:
Actually, we can override the locks directory as well so that an install doesn’t need any access to /opt. GEMSTONE_GLOBAL_DIR _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Just to be clear, the 32-bit requirement is based on using the 32-bit pharo vm. As soon as there is a 64-bit pharo vm, we should be able to use the 64 bit gci libraries and remove the dependence upon 32 bit libraries ... On Mon, Sep 8, 2014 at 1:27 PM, Dale Henrichs <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Marten, Am I correct that doing the install this time around you have been successful in getting pharo running? Today I downloaded a thoughtpolice Ubuntu 12.04 vmware vm[1] and used the VMPlayer to start the vm. After logging in I ran the following commands: sudo apt-get update --qq sudo apt-get install git sudo apt-get install unzip sudo apt-get -y install libpam0g:i386 sudo apt-get libssl1.0.0 sudo apt-get libssl1.0.0:386 sudo ln -s /lib/i386-linux-gnu/libpam.so.0 /lib/libpam.so.0 sudo apt-get install -qq gcc-multilib libstdc++6:i386 sudo ln -s /usr/lib/i386-lin-gnu/libstdc++.so.6 /usr/lib/i386-linux-gnu/libstdc++.so sudo apt-get install xorg sudo apt-get install openbox sudo apt-get install libx11-6:i386 sudo apt-get install libgl1-mesa-dev:i386 sudo apt-get install libxcb-dri2-0:i386 startx cd gsDevKitHome git checkout -b 12.04 export GS_HOME=`pwd` export PATH=$GS_HOME/bin:$PATH installServer devKit 3.2.2 NOTE that after running `startx` the x-server is started and you need to open a terminal window for the remaining commands ... At the end of the script the pharo vm came up and I was able to log into the 3.2.2 devKit stone .... openbox is an x windows manager ... I plan to integrate the above library installs into the $GS_HOME/bin/installServer script as well as partition the scripts a bit more.. Eventually I hope to take the installation procedure to the point where ssh is installed on the 12.04 vm and: - ssh tunneling is used to run a pharo client on the local X client over LAN - ssh tunneling is used to connect to a netldi running on the 12.04 server and a pharo client running as a remote client over WAN Dale On Mon, Sep 8, 2014 at 12:45 PM, [hidden email] via Glass <[hidden email]> wrote: Ok, now I executed the scripts again and the 3.2.2 version is _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
In reply to this post by GLASS mailing list
Am 08.09.2014 um 22:27 schrieb Dale Henrichs:
> > Is the requirement for 32 bit libraries a deal breaker and if so, how > many folks can't use gSdevKit if it requires 32 bit libraries? > > Dale Not really, if it is a must, then it has to be installed - point. But to be honest: -> there are cases where adding the 32 bit subsystem is creating additional library problems. I've run into these problems several times in the past - even with my VASTServers. I had to include 32-bit libraries with my VASTServer application, because doing the equivalent 32bit library os-based-installation broke some of the 64 bit libraries (and yes i know: that should never happen). If these problems happen, then you are really pissed off - and you get the views from people like: "hey programmer, use the right tools and not your 'I do all my stuff in ..' IDE. -> using Pharo as a scripting language ... well that's a suboptimal approach. When one wants to have scripting language then use a real scripting language. Perhaps its better to install Ruby or stuff like this - pretty good development languages and very well suited to scripting and easy to install and some kind of mainstream. This has nothing to do with Smalltalk itself: I would also not use C# or Java for such a scripting approach. -> I suppose that Pharo might run in a true-headless server computer or do you need to install additional libraries to make this happen. In the past the so called true-headless mode was not such a true headless-mde. Regarding where DevKit should be placed ... well it was not clear for me, that the SDK now is also the place for the database and their extents. Its ok, but that should be mentioned - perhaps due to partitions size considerations. Actually I would make a strong line between the product and database Gemstone and the SDK - and this should be made visible also in the installation locations. Marten -- Marten Feldtmann _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
On Mon, Sep 8, 2014 at 10:36 PM, [hidden email] <[hidden email]> wrote: Am 08.09.2014 um 22:27 schrieb Dale Henrichs: I ran into a bit of that yesterday as I was trying to get the proper set of 32-bit libraries installed for Pharo, but I think I at elast found the minimal set of libraries that needed to be installed, so that unwanted side effects should be minimized ... If these problems happen, I am not a fan of "do everything in the IDE", but I am a fan of being able to write scripts in Smalltalk and I am happy to see Pharo move in the direction of making it easier to run a headless scripting vm ... Frankly I was able to pull together the GsDevKit in a matter of a week or so because I was able to write my scripts in Smalltalk and I didn't have to go through the pain of writing them in bash... tODE is also breaking away from the "do everything in the IDE" as well ... the importance of using Smalltalk on the client is that I can seamlessly invoke tODE commands and GUARANTEE that the batch scripts run at the command line run exactly the same way that the command runs when invoked from within the tODE shell or when invoked from a menu in the GUI ... The issue is that Pharo (along with other Smalltalks) has been a bit behind in converting to 64-bit vms, but the work is being done and it is just a matter of time
I don't necessarily agree that it is a suboptimal approach ... As I mentioned earlier, by leaning on Pharo for my scripting language, I am able to seamlessly invoke tODE commands or run arbitrary Smalltalk commands in GemStone as needed by the script that I am writing. If I were to use another language I would be faced with a much larger challenge ...
I think that the interesting piece of the GsDevKit is the structure that is provided ... a regular structure makes it possible to write scripts that can be used in production and reduce the number of custom scripts that are required ... I broke out the various directories: logs, extents, tranlogs precisely because in a production environment it makes sense to locate these directories on different partitions and my expectations are that one would use symbolic links and locate the directories on separate partitions ... On the one hand it is ludicrous to think that the GsDevKit structure/scripts would be sufficient for all production scenarios, but I do believe that the GsDevKit structure/scripts will make it easier for folks to move into production and get to the point where they have enough knowledge and experience with the system to make the next level of structural and scripting decisions ... Finally, I do expect GsDevKit to evolve ... and would appreciate concrete suggestions as to changes that should be made to the structure ... Mariano has already made some contributions in this area with specific suggestions[1] for changes and I welcome more suggestions and discussions about specific things that could/should be done .... I would love to have contributions with improvements to the documentation and/or scripts as well ... I don't think that I should be the only person doing the work:) Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Free forum by Nabble | Edit this page |