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
Re: blue griffon current production successfully built
On Tue, Oct 15, 2013 at 2:03 PM, Yasha Karant ykar...@csusb.edu wrote: From a terminal application within gnome, my default Python is: [ykarant@jb344 ~]$ python Python 2.6.6 (r266:84292, Feb 21 2013, 19:26:11) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type help, copyright, credits or license for more information. despite having to install whatever the BlueGriffon build required. A number of the responses concerning the build of BlueGriffon further underscore the general lack of polymorphism and encapsulation in the Linux environment as distributed. In a proper modern OS environment, an application that requires non-system versions of applications (other than the core libraries required by the OS itself, a more daunting problem) would have only these in the path of both the building steps and during the execution of the built application, preferably still allowing a dynamic rather than a static image of the built application. You've gone on about this before, and it's just not going to happen with this OS. SL is a rebuild of a server class operating system, not a maximal flexibility operating system. The trade-off is that there is a hope for stability and interoperability and consistent behavior from day to day, due to the consistent library versions, package layouts, and build environments. And such a multi-component, multi featured system is vulnerable to serious incompatiblities between even minor library or feature changes. Python 2.6 and Python 2.7, for example, have notable feature and syntax differences. So at run-time of particular Python modules, which is the default to select? Do all python scripts have to be written as /usr/bin/python2.6 or /usr/bin/python2.7? And how is a tool author writing their Makefile or configure.ac to know? Or even just running a remote shell script. Do not get me *started* on software tools that auto-update your local workspace databases to enable new features and make it impossible to revert back to the older binaries, such as Subversion and RPM. running both versions on the same system at the same time is *fraught* with adventure. This is just not a Linux problem. It's a consistent environment problem. there have been attempts to deal with the need for multiple versions of components at the same time with the /usr/bin/Java and /usr/bin/gcc symlink fun and games, but it's an unavoidable problem, especially in a system for which the paying customers need a consistent environment and a 10 year life cycle (which our favorite upstream vendor currently provides.)
Re: blue griffon current production successfully built
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 -- James Fait, Ph.D Beamline Scientist SER-CAT, APS Argonne National Laboratory Building 436B-008 9700 S. Cass Ave. Argonne, IL 60439 Email: f...@anl.gov Phone: 630-252-0644 Fax: 630-252-0652 - Original Message - | From: Yasha Karant ykar...@csusb.edu | To: scientific-linux-users@fnal.gov | Sent: Wednesday, October 16, 2013 10:30:28 AM | Subject: Re: blue griffon current production successfully built | | On 10/16/2013 03:46 AM, Nico Kadel-Garcia wrote: | On Tue, Oct 15, 2013 at 2:03 PM, Yasha Karant ykar...@csusb.edu | mailto:ykar...@csusb.edu wrote: | | From a terminal application within gnome, my default Python | is: | | [ykarant@jb344 ~]$ python | Python 2.6.6 (r266:84292, Feb 21 2013, 19:26:11) | [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 | Type help, copyright, credits or license for more | information. | | | despite having to install whatever the BlueGriffon build | required. | | A number of the responses concerning the build of BlueGriffon | further underscore the general lack of polymorphism and | encapsulation in the Linux environment as distributed. In a | proper | modern OS environment, an application that requires non-system | versions of applications (other than the core libraries | required by | the OS itself, a more daunting problem) would have only these | in the | path of both the building steps and during the execution of the | built application, preferably still allowing a dynamic rather | than a | static image of the built application. | | You've gone on about this before, and it's just not going to happen | with | this OS. SL is a rebuild of a server class operating system, not a | maximal flexibility operating system. The trade-off is that there | is a | hope for stability and interoperability and consistent behavior | from day | to day, due to the consistent library versions, package layouts, | and | build environments. And such a multi-component, multi featured | system is | vulnerable to serious incompatiblities between even minor library | or | feature changes. Python 2.6 and Python 2.7, for example, have | notable | feature and syntax differences. So at run-time of particular Python | modules, which is the default to select? Do all python scripts have | to | be written as /usr/bin/python2.6 or /usr/bin/python2.7? And how | is a | tool author writing their Makefile or configure.ac | http://configure.ac | to know? Or even just running a remote shell script. | | Do not get me *started* on software tools that auto-update your | local | workspace databases to enable new features and make it impossible | to | revert back to the older binaries, such as Subversion and RPM. | running | both versions on the same system at the same time is *fraught* with | adventure. | | This is just not a Linux problem. It's a consistent environment | problem. there have been attempts to deal with the need for | multiple | versions of components at the same time with the /usr/bin/Java and | /usr/bin/gcc symlink fun and games, but it's an unavoidable | problem, | especially in a system for which the paying customers need a | consistent | environment and a 10 year life cycle (which our favorite upstream | vendor | currently provides.) | | | You may oppose modern software engineering design and implementation | principles and practices. I have never proposed a lack of stability | or | reliability in any environment, whether that environment is an | operating | system or an end-user application specific to only one segment of the | population. | | Indeed, the designed language or environment that is required by a | build | should be specified in the build. If Application N.m is required, it | should be specified. | | As you factually point out, a number of the core applications (such | as | RPM or other production maintenance utilities) routinely are updated | by | TUV and even by the community (other software application | maintainers, | both for-profit and commons) and then auto-update, and do not | necessarily
Re: blue griffon current production successfully built
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 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 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 Wed, Oct 16, 2013 at 4: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 Various approaches have been tried, and are still in use. RHEL, and thus Scientific Linux, attempt to do this somewhat with Java and SMTP servers by manipulating symlinks using the update-alternatives tools, which you might want to look into. For tools that are compiled with numerous multiple versions, outside the RPM infrastructure, Years ago, I got fond of encap to keep software form /usr/local/encap[package-version] organized in /usr/local/bin, /usr/local/man, /usr/local/lib, /usr/local/include, etc. It was very effective at symlinking the holw magilla in to /usr/local for you, The approach fell out of favor, but the code is still available at http://www.encap.org/epkg/ 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). That's what mock is for, which is what Red Hat and Fedora and others use to provide RPM based build environments, with good control over the actual dependencies in the toolchain. 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
From a terminal application within gnome, my default Python is: [ykarant@jb344 ~]$ python Python 2.6.6 (r266:84292, Feb 21 2013, 19:26:11) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type help, copyright, credits or license for more information. despite having to install whatever the BlueGriffon build required. A number of the responses concerning the build of BlueGriffon further underscore the general lack of polymorphism and encapsulation in the Linux environment as distributed. In a proper modern OS environment, an application that requires non-system versions of applications (other than the core libraries required by the OS itself, a more daunting problem) would have only these in the path of both the building steps and during the execution of the built application, preferably still allowing a dynamic rather than a static image of the built application. Yasha Karant On 10/15/2013 12:06 AM, Steven J. Yellin wrote: Python2.7 can be installed in, say, /usr/local/..., while leaving 2.6 (or for SL5, 2.4) as the default version. When you then need to use version 2.7 there may be some pain with libraries, but perhaps not too much to endure. Steven Yellin On Mon, 14 Oct 2013, Nico Kadel-Garcia wrote: I took a look a thte Fedora SRPM's, which unfortunately ended about 3 years ago with a very out of date release. The current release requires Python 2.7, which is begging for pain to install on an SL 6 system. SL 7 should be much more compatible with current releases. On Mon, Oct 14, 2013 at 9:42 PM, Yasha Karant ykar...@csusb.edu wrote: On 10/14/2013 04:20 PM, ToddAndMargo wrote: On 10/14/2013 04:18 PM, Yasha Karant wrote: I now have built from source BlueGriffon for X86-64 SL6x, version 1.7.2.99.20130729, Build 20131013142156, Codename 'Cla-de-Lue' I can provide detailed instructions or just a copy of both the mozconfig file used for the build and the typescript of the building. I have had to add a few RPMs to SL6x from other distributions. There was a query on a different thread (same general topic, but a different subject line) as to why I used a 5x CentOS RPM for one of the dependencies of the build. I could not find a 6x EL version. The application was not a systems application that would overwrite/override other files, and seemed to be constrained with a unique identifier. My experience is that many EL 5 and even EL 4 applications still work with EL 6, as did this. Presumably, if the EL 6 version is available, that too would work. Yasha Karant Do you have a place to download the RPM? I have the full directory as well as the built files -- but the source code did not come with any obvious configuration/script software to build a RPM. Moreover, I do not have the personnel resources to support this application for future updates, although I expect that the steps that I did will work for such updates. I have not built this for the IA-32 platform, only X86-64. Is anyone with an IA-32 SL6x development system willing to repeat the exercise to produce an IA-32 platform version? Can you supply the necessary information to build a RPM as well as properly specify dependencies? Yasha Karant
Re: blue griffon current production successfully built
Python 2.7 may be installed from Software Collections 1.0 for SL6: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1309L=scientific-linux-develT=0P=501 On Tue, Oct 15, 2013 at 10:03 PM, Yasha Karant ykar...@csusb.edu wrote: From a terminal application within gnome, my default Python is: [ykarant@jb344 ~]$ python Python 2.6.6 (r266:84292, Feb 21 2013, 19:26:11) [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2 Type help, copyright, credits or license for more information. despite having to install whatever the BlueGriffon build required. A number of the responses concerning the build of BlueGriffon further underscore the general lack of polymorphism and encapsulation in the Linux environment as distributed. In a proper modern OS environment, an application that requires non-system versions of applications (other than the core libraries required by the OS itself, a more daunting problem) would have only these in the path of both the building steps and during the execution of the built application, preferably still allowing a dynamic rather than a static image of the built application. Yasha Karant On 10/15/2013 12:06 AM, Steven J. Yellin wrote: Python2.7 can be installed in, say, /usr/local/..., while leaving 2.6 (or for SL5, 2.4) as the default version. When you then need to use version 2.7 there may be some pain with libraries, but perhaps not too much to endure. Steven Yellin On Mon, 14 Oct 2013, Nico Kadel-Garcia wrote: I took a look a thte Fedora SRPM's, which unfortunately ended about 3 years ago with a very out of date release. The current release requires Python 2.7, which is begging for pain to install on an SL 6 system. SL 7 should be much more compatible with current releases. On Mon, Oct 14, 2013 at 9:42 PM, Yasha Karant ykar...@csusb.edu wrote: On 10/14/2013 04:20 PM, ToddAndMargo wrote: On 10/14/2013 04:18 PM, Yasha Karant wrote: I now have built from source BlueGriffon for X86-64 SL6x, version 1.7.2.99.20130729, Build 20131013142156, Codename 'Cla-de-Lue' I can provide detailed instructions or just a copy of both the mozconfig file used for the build and the typescript of the building. I have had to add a few RPMs to SL6x from other distributions. There was a query on a different thread (same general topic, but a different subject line) as to why I used a 5x CentOS RPM for one of the dependencies of the build. I could not find a 6x EL version. The application was not a systems application that would overwrite/override other files, and seemed to be constrained with a unique identifier. My experience is that many EL 5 and even EL 4 applications still work with EL 6, as did this. Presumably, if the EL 6 version is available, that too would work. Yasha Karant Do you have a place to download the RPM? I have the full directory as well as the built files -- but the source code did not come with any obvious configuration/script software to build a RPM. Moreover, I do not have the personnel resources to support this application for future updates, although I expect that the steps that I did will work for such updates. I have not built this for the IA-32 platform, only X86-64. Is anyone with an IA-32 SL6x development system willing to repeat the exercise to produce an IA-32 platform version? Can you supply the necessary information to build a RPM as well as properly specify dependencies? Yasha Karant
blue griffon current production successfully built
I now have built from source BlueGriffon for X86-64 SL6x, version 1.7.2.99.20130729, Build 20131013142156, Codename 'Cla-de-Lue' I can provide detailed instructions or just a copy of both the mozconfig file used for the build and the typescript of the building. I have had to add a few RPMs to SL6x from other distributions. There was a query on a different thread (same general topic, but a different subject line) as to why I used a 5x CentOS RPM for one of the dependencies of the build. I could not find a 6x EL version. The application was not a systems application that would overwrite/override other files, and seemed to be constrained with a unique identifier. My experience is that many EL 5 and even EL 4 applications still work with EL 6, as did this. Presumably, if the EL 6 version is available, that too would work. Yasha Karant
Re: blue griffon current production successfully built
On 10/14/2013 04:20 PM, ToddAndMargo wrote: On 10/14/2013 04:18 PM, Yasha Karant wrote: I now have built from source BlueGriffon for X86-64 SL6x, version 1.7.2.99.20130729, Build 20131013142156, Codename 'Cla-de-Lue' I can provide detailed instructions or just a copy of both the mozconfig file used for the build and the typescript of the building. I have had to add a few RPMs to SL6x from other distributions. There was a query on a different thread (same general topic, but a different subject line) as to why I used a 5x CentOS RPM for one of the dependencies of the build. I could not find a 6x EL version. The application was not a systems application that would overwrite/override other files, and seemed to be constrained with a unique identifier. My experience is that many EL 5 and even EL 4 applications still work with EL 6, as did this. Presumably, if the EL 6 version is available, that too would work. Yasha Karant Do you have a place to download the RPM? I have the full directory as well as the built files -- but the source code did not come with any obvious configuration/script software to build a RPM. Moreover, I do not have the personnel resources to support this application for future updates, although I expect that the steps that I did will work for such updates. I have not built this for the IA-32 platform, only X86-64. Is anyone with an IA-32 SL6x development system willing to repeat the exercise to produce an IA-32 platform version? Can you supply the necessary information to build a RPM as well as properly specify dependencies? Yasha Karant
Re: blue griffon current production successfully built
I took a look a thte Fedora SRPM's, which unfortunately ended about 3 years ago with a very out of date release. The current release requires Python 2.7, which is begging for pain to install on an SL 6 system. SL 7 should be much more compatible with current releases. On Mon, Oct 14, 2013 at 9:42 PM, Yasha Karant ykar...@csusb.edu wrote: On 10/14/2013 04:20 PM, ToddAndMargo wrote: On 10/14/2013 04:18 PM, Yasha Karant wrote: I now have built from source BlueGriffon for X86-64 SL6x, version 1.7.2.99.20130729, Build 20131013142156, Codename 'Cla-de-Lue' I can provide detailed instructions or just a copy of both the mozconfig file used for the build and the typescript of the building. I have had to add a few RPMs to SL6x from other distributions. There was a query on a different thread (same general topic, but a different subject line) as to why I used a 5x CentOS RPM for one of the dependencies of the build. I could not find a 6x EL version. The application was not a systems application that would overwrite/override other files, and seemed to be constrained with a unique identifier. My experience is that many EL 5 and even EL 4 applications still work with EL 6, as did this. Presumably, if the EL 6 version is available, that too would work. Yasha Karant Do you have a place to download the RPM? I have the full directory as well as the built files -- but the source code did not come with any obvious configuration/script software to build a RPM. Moreover, I do not have the personnel resources to support this application for future updates, although I expect that the steps that I did will work for such updates. I have not built this for the IA-32 platform, only X86-64. Is anyone with an IA-32 SL6x development system willing to repeat the exercise to produce an IA-32 platform version? Can you supply the necessary information to build a RPM as well as properly specify dependencies? Yasha Karant
Re: blue griffon current production successfully built
On 10/14/2013 08:37 PM, Nico Kadel-Garcia wrote: SL 7 should be much more compatible with current releases. For about three months. :-( -- ~~ Computers are like air conditioners. They malfunction when you open windows ~~
