Re: blue griffon current production successfully built
On Wed, 16 Oct 2013, Jeffrey Anderson wrote: --089e013d0db08caeb504e8e18c7a Content-Type: text/plain; charset=ISO-8859-1 It seems to me that the environment-modules package available from EPEL can address many of your needs. We use it to provide access to multiple versions of python, gcc, boost, gsl and many other tools and libraries, all without interfering with necessary system-level operations. It is quite flexible, has a relatively low learning curve, and is widely used. It allows users to easily switch back and forth between different versions of these tools. Need python 2.7.2? 'module load python/2.7.2' Want to switch to 2.6.4? 'module switch python/2.6.4' Want to go back to the default system python? 'module unload python' and so on. Jeff TUV and thus SL has had the technology known as Software Collections available in SL6 since 6.2 . Software Collections installs packages in /opt/rh and thus preserves the base packages. It provides a utility , scl , to enable these software collections. TUV and thus SL has released Devtoolset which provides newer GCC via Software Collections. Recently TUV and thus SL released Software Collections (uses scl but more than that) that provides mariadb55 postgresql92 ruby193 mysql55 python27 nodejs010 python33 perl516 php54 A README with info about yum repos for these packages is available from ftp://sldist.fnal.gov/linux/scientific/6x/external_products/softwarecollections/README More info from TUV is available at https://access.redhat.com/site/documentation/Red_Hat_Software_Collections/ Note that Oleg responded to this thread with this info a few days ago. The Software Collection python27 solves this problem completely. -Connie Sieh On Wed, Oct 16, 2013 at 1:11 PM, Yasha Karant ykar...@csusb.edu wrote: On 10/16/2013 09:12 AM, Jim Fait wrote: I run into this all the time, as we have a large number of somewhat incompatible software packages that we are required to have. What we have ended up doing is placing the real executable somewhere outside the normal path, and then putting a script with same name in /usr/local/bin or /opt/local/bin that encapsulates all of the foreign dependencies and environment. That way, the particular package can live with its requirements alongside the production system, with very few problems seen by the end user. Of course, this means writing a number of scripts, in our case a couple hundred, that stay fairly static with changes in the OS or the package in question, and that hide all of the nastiness that otherwise would happen, like a PATH environment variable 10 line long. Hope this idea helps. Jim Your example is one of the accepted methods for enabling the idea of polymorphism and encapsulation within an otherwise procedural imperative, possibly structured, environment. Assuming that what you are describing is for both the build environment and the execution environment of the environment/application being built, it should (in most cases) work. And -- it should be the norm when providing application building environments that do NOT require a virtual machine (e.g., maintaining a more modern Linux under VirtualBox under SL6x). I do not know which applications/environments you support in this way. A list of all that are not subject to for-fee or equivalent non-distributable licenses and for which you are willing to provide the scripts greatly would be appreciated. Maintaining such environments across new major OS environment releases often entails a large amount of effort. Yasha
Re: blue griffon current production successfully built
Could you be more specific as to the environment-modules packages? Do these produce a stand-alone executable, or do these require to be installed on both the development and target environments (machines)? Part of the issue is having the environment for a build requiring versions or entire packages that are not available in the stock distribution, but part is having the environment available at run-time for the built program. Does this also work for buildable environments that require libraries incompatible with the stock distribution, particularly after the build during run-time? Yasha Karant On 10/16/2013 01:28 PM, Jeffrey Anderson wrote: It seems to me that the environment-modules package available from EPEL can address many of your needs. We use it to provide access to multiple versions of python, gcc, boost, gsl and many other tools and libraries, all without interfering with necessary system-level operations. It is quite flexible, has a relatively low learning curve, and is widely used. It allows users to easily switch back and forth between different versions of these tools. Need python 2.7.2? 'module load python/2.7.2' Want to switch to 2.6.4? 'module switch python/2.6.4' Want to go back to the default system python? 'module unload python' and so on. Jeff On Wed, Oct 16, 2013 at 1:11 PM, Yasha Karant ykar...@csusb.edu mailto:ykar...@csusb.edu wrote: On 10/16/2013 09:12 AM, Jim Fait wrote: I run into this all the time, as we have a large number of somewhat incompatible software packages that we are required to have. What we have ended up doing is placing the real executable somewhere outside the normal path, and then putting a script with same name in /usr/local/bin or /opt/local/bin that encapsulates all of the foreign dependencies and environment. That way, the particular package can live with its requirements alongside the production system, with very few problems seen by the end user. Of course, this means writing a number of scripts, in our case a couple hundred, that stay fairly static with changes in the OS or the package in question, and that hide all of the nastiness that otherwise would happen, like a PATH environment variable 10 line long. Hope this idea helps. Jim Your example is one of the accepted methods for enabling the idea of polymorphism and encapsulation within an otherwise procedural imperative, possibly structured, environment. Assuming that what you are describing is for both the build environment and the execution environment of the environment/application being built, it should (in most cases) work. And -- it should be the norm when providing application building environments that do NOT require a virtual machine (e.g., maintaining a more modern Linux under VirtualBox under SL6x). I do not know which applications/environments you support in this way. A list of all that are not subject to for-fee or equivalent non-distributable licenses and for which you are willing to provide the scripts greatly would be appreciated. Maintaining such environments across new major OS environment releases often entails a large amount of effort. Yasha -- -- Jeffrey Anderson| jdander...@lbl.gov mailto:jdander...@lbl.gov Lawrence Berkeley National Laboratory | Office: 50A-5104E | Mailstop 50A-5101 Phone: 510 486-4208 | Fax: 510 486-4204
Re: blue griffon current production successfully built
On Thu, Oct 17, 2013 at 8:23 AM, Yasha Karant ykar...@csusb.edu wrote: Could you be more specific as to the environment-modules packages? As I mentioned, the rpm is available from EPEL. 'rpm -qip' on the package will give you a description as well as a pointer to the project web page. Do these produce a stand-alone executable, or do these require to be installed on both the development and target environments (machines)? This package allows users to dynamically alter their environment to easily point to different versions of different packages. It is up to you to install those various versions and make sure they are built correctly. In practice you probably need things installed on both development and target machines in your system. This would not be a good solution for building packages that you are going to distribute to the world in general. It is not a substitute for mock, for example. Part of the issue is having the environment for a build requiring versions or entire packages that are not available in the stock distribution, but part is having the environment available at run-time for the built program. Does this also work for buildable environments that require libraries incompatible with the stock distribution, particularly after the build during run-time? Yes. But you need to have those non-stock libraries installed, and users have to setup their environments accordingly. For that reason, it is really only a solution in a case where you have total control over the development machines, and the target machines. Jeff Anderson Yasha Karant On 10/16/2013 01:28 PM, Jeffrey Anderson wrote: It seems to me that the environment-modules package available from EPEL can address many of your needs. We use it to provide access to multiple versions of python, gcc, boost, gsl and many other tools and libraries, all without interfering with necessary system-level operations. It is quite flexible, has a relatively low learning curve, and is widely used. It allows users to easily switch back and forth between different versions of these tools. Need python 2.7.2? 'module load python/2.7.2' Want to switch to 2.6.4? 'module switch python/2.6.4' Want to go back to the default system python? 'module unload python' and so on. Jeff On Wed, Oct 16, 2013 at 1:11 PM, Yasha Karant ykar...@csusb.edu mailto:ykar...@csusb.edu wrote: On 10/16/2013 09:12 AM, Jim Fait wrote: I run into this all the time, as we have a large number of somewhat incompatible software packages that we are required to have. What we have ended up doing is placing the real executable somewhere outside the normal path, and then putting a script with same name in /usr/local/bin or /opt/local/bin that encapsulates all of the foreign dependencies and environment. That way, the particular package can live with its requirements alongside the production system, with very few problems seen by the end user. Of course, this means writing a number of scripts, in our case a couple hundred, that stay fairly static with changes in the OS or the package in question, and that hide all of the nastiness that otherwise would happen, like a PATH environment variable 10 line long. Hope this idea helps. Jim Your example is one of the accepted methods for enabling the idea of polymorphism and encapsulation within an otherwise procedural imperative, possibly structured, environment. Assuming that what you are describing is for both the build environment and the execution environment of the environment/application being built, it should (in most cases) work. And -- it should be the norm when providing application building environments that do NOT require a virtual machine (e.g., maintaining a more modern Linux under VirtualBox under SL6x). I do not know which applications/environments you support in this way. A list of all that are not subject to for-fee or equivalent non-distributable licenses and for which you are willing to provide the scripts greatly would be appreciated. Maintaining such environments across new major OS environment releases often entails a large amount of effort. Yasha -- --**--**-- Jeffrey Anderson| jdander...@lbl.gov mailto:jdander...@lbl.gov Lawrence Berkeley National Laboratory | Office: 50A-5104E | Mailstop 50A-5101 Phone: 510 486-4208 | Fax: 510 486-4204 -- -- Jeffrey Anderson| jdander...@lbl.gov Lawrence Berkeley National Laboratory | Office: 50A-5104E | Mailstop 50A-5101 Phone: 510 486-4208
Scientific Linux SL 5.10 for i386/x86_66 BETA 1 ready for testing
Scientific Linux SL 5.10 for i386/x86_66 BETA 1 Oct 16, 2013 SL 5.10 BETA 1 is now available for testing. See SL.documentation/RELEASE-NOTES-U10-x86-en.html for Upstream vendor release notes. Send comments/issues/test reports to scientific-linux-de...@fnal.gov ISO images are available at ftp://ftp.scientificlinux.org/linux/scientific/5rolling/iso/i386/cd/ ftp://ftp.scientificlinux.org/linux/scientific/5rolling/iso/i386/dvd/ ftp://ftp.scientificlinux.org/linux/scientific/5rolling/iso/x86_64/cd/ ftp://ftp.scientificlinux.org/linux/scientific/5rolling/iso/x86_64/dvd/ -Scientific Linux Development Team
Re: Newer KDE for SL6?
On 17.10.2013, at 19:05, Konstantin Olchanski olcha...@triumf.ca wrote: ... P.S. Why konqueror? It is the only browser that still can run multiple copies of itself. Unlike firefox and google-chrome who refuse to start with an error this application is already running on computer X when I sit in front of computer Y and need to google something. (Computer X is in a different building and I am google something there *too*) (NIS+NFS cluster). And just creating a new dummy profile so that you can happily google away is not a viable workaround? Matthias -- Konstantin Olchanski Data Acquisition Systems: The Bytes Must Flow! Email: olchansk-at-triumf-dot-ca Snail mail: 4004 Wesbrook Mall, TRIUMF, Vancouver, B.C., V6T 2A3, Canada
