Re: [SCIENTIFIC-LINUX-USERS] Upgrade SLC5 to SLC6 ?
On 07/24/2013 01:02 AM, g wrote: hello pat, On 07/23/2013 01:17 PM, Pat Riehecky wrote: It is not possible to upgrade from the 5x branch to the 6x branch. A fresh install is required. Pat i have to disagree with you on this issue. iirc, my last 5x was 5.9. i first ran yum update and then ran yum upgrade, both ran with out any problems. my /etc/reddhat-release shows; Scientific Linux release 6.3 (Carbon) i did not check to insure that all packages are now at 6.3, And just for this reason it is not recommended to try this. You might get a system that runs, but you are not sure what exactly you have got. And one of the days you get strange problems that can not be reproduced elsewhere. We do not support such systems, and if a user that had done that form of upgrade reports a problem we tell him to properly re-install his system first. but i would presume that they are. Perhaps they are, perhaps not. You waste much more time debugging strange issues than you gain by doing a proper install. So why take the risk? Matthias
Re: darktable
On 07/02/2013 07:01 AM, Yasha Karant wrote: There is an open source application that appears to compete with GIMP plus plugins for handling digital camera images. The package is called darktable, URL: http://www.darktable.org/about/ The claim is that it will install under SL6, preferably X86-64 RHEL 6 / SL 6 / Centos 6, using the following sequence: install the linuxtech.repo config file if you don't have it already: su - root cd /etc/yum.repos.d/ wget http://pkgrepo.linuxtech.net/el6/release/linuxtech.repo install darktable: yum --enablerepo=linuxtech-testing install darktable Does anyone have experience with either this application I had a look at it, in particular its photo-management aspects. I don't think it is meant to replace gimp, it rather complements it. Unfortunately it seems that the keyword feature does not yet work too well, and that was the show-stopper for me. For cataloguing and applying simple corrections it might be fine. or the linuxtech repository? I have no experience with it. Matthias Does anyone know if this is a safe repository to use? Had EL proper polymorphism and encapsulation, this sort of issue would not arise; however, under the present design, if a repository (e.g., linuxtech) overwrites a systems library, etc., the results can be less than desirable. Yasha Karant
Re: %_host_vendor Bug in the rpm package of SL 6?
Hallo Frank, do you have the redhat-rpm-config rpm installed on your build node? Schoene Gruesse, Matthias On Feb 7, 2013, at 9:52 AM, ZITBB Büttner, Frank frank.buett...@polizei.brandenburg.de wrote: Hello list, I have try to rebuild an rpm package with use the %configure macro. This will fails, beacuse the %_host_vendor macro witch is placed at: /usr/lib/rpm/macros is set to unknown and not to redhat like the %_vendor macro in the same file. This will result that the build script will think it is an cross build. But it is not. So I think it will be in an bug in SL Linux. package: rpm-4.8.0-27.el6.x86_64 Sample: %configure will result in: ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info but correct will be: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info Thanks Frank Büttner smime.p7s Description: S/MIME cryptographic signature
Re: %_host_vendor Bug in the rpm package of SL 6?
On Feb 7, 2013, at 11:12 AM, Matthias Schroeder matthias.schro...@cern.ch wrote: Hallo Frank, do you have the redhat-rpm-config rpm installed on your build node? Just noticed that it does not matter. It looks as if %host_vendor is not used and not set anymore by TUV, at least on 6.3. Appears to be fine again in 6.4 beta. In the meantime you can set in in your .rpmmacros Matthias Schoene Gruesse, Matthias On Feb 7, 2013, at 9:52 AM, ZITBB Büttner, Frank frank.buett...@polizei.brandenburg.de wrote: Hello list, I have try to rebuild an rpm package with use the %configure macro. This will fails, beacuse the %_host_vendor macro witch is placed at: /usr/lib/rpm/macros is set to unknown and not to redhat like the %_vendor macro in the same file. This will result that the build script will think it is an cross build. But it is not. So I think it will be in an bug in SL Linux. package: rpm-4.8.0-27.el6.x86_64 Sample: %configure will result in: ./configure --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info but correct will be: ./configure --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu --target=x86_64-redhat-linux-gnu --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info Thanks Frank Büttner smime.p7s Description: S/MIME cryptographic signature
Re: LAPACK for SL/CentOS/RHEL 5?
On 02/05/2013 06:51 PM, Alan McKay wrote: I see LAPACK 3.0 when I do yum search, but the latest version is 3.4.2 Is there any place to get the newer RPMs for SL 5? I've looked into building it but the instructions assume a knowledge of using the package. I'm just a lowly Sys Admin and want to build this for some scientists I support. Have these scientists checked whether they really would need a newer version? I know that many people always want the newest version around, but in fact this is rarely justified. http://www.netlib.org/lapack/improvement.html has a list of changes in lapack. I think before you embark on rebuilding the latest lapack the scientists you have in mind just verify that they rely on any of the improvements listed. And if they can not point out which of the improvements have a direct impact on their work but just mumble 'just to be sure' or 'in general much better', I would not try to rebuild the stuff. A non-optimal rebuild might do more harm than good. Matthias thanks, -Alan
Re: Update kernel panic -
On Feb 4, 2013, at 5:36 PM, Jamie Duncan jamie.e.dun...@gmail.com wrote: I just wasn't aware that SL split that way. Please check the URL that Oleg provided in his first post. It points to a repository in russia. I don't think this is a SL endorsed patch. Matthias RH hasn't accepted it, which (I'm assuming) means it hasn't been accepted upstream, either. Are these maintained indefinitely if they are rejected for some reason? On Mon, Feb 4, 2013 at 11:33 AM, Oleg Sadov sa...@linux-ink.ru wrote: That's our patch around modprobe snd-hda-intel kernel crashing. It placed to RH BugZilla, but is not approved by Red Hat at this time. В Пнд, 04/02/2013 в 10:46 -0500, Jamie Duncan пишет: That link gives links to bug-fixed packages, but the Bugzilla is still open. Who generated the patches? On Mon, Feb 4, 2013 at 9:33 AM, Oleg Sadov sa...@linux-ink.ru wrote: В Пнд, 04/02/2013 в 16:45 +0300, Serge A. Salamanka пишет: On 2 февраля 2013 15:50:17 Bob Goodwin - Zuni, Virginia, USA wrote: I did a yum update via ssh on an SL6 server the other day, noticed that it never indicated complete? Yesterday I began to have odd problems and after rebooting the server, it wouldn't, it complains of a kernel panic. Using SL-Live I've installed another hard drive and transferred file to that, now unless someone can tell me a better way all I know is to re-install and start over. That server has been running for a year or more without a problem, usually it's just there, only shut down in a power outage and then always restarted without a problem.. box7 Scientific Linux 6.3 I'm using SL5.8 After a short shutdown today the machine came up with kernel panic (can't find root). It's may be consequence of file system damaging or grub misconfiguration. But we found fix some NULL-pointer references in sound subsystem of last 5x kernel updates: http://listserv.fnal.gov/scripts/wa.exe?A2=ind1302L=scientific-linux-develT=0P=348 -- Thanks, Jamie Duncan @jamieeduncan -- Thanks, Jamie Duncan @jamieeduncan smime.p7s Description: S/MIME cryptographic signature
Re: cernlib for SL 6x
Hi Ken, On Nov 21, 2012, at 6:33 PM, Ken Teh t...@anl.gov wrote: What do folks do about installing the cern program libraries for SL6? I see that they only have pre-built binaries for SL5. Are you building them from source or is there an semi-official repo you can get them from? There is a little confusion around the version(s) of CERNLIB. There is one package called 'cernlib' in epel. That appears to be a version that misses a few of the original libraries, and if I understood it correctly includes a few bug fixes and improvements. It is available for both architectures. Then there is a build that covers more of the original libraries, but has no recent bug fixes or improvements,and is only available for i686. At CERN we have packaged that version as 'CERNLIB'. Hope this helps, Matthias Thanks! smime.p7s Description: S/MIME cryptographic signature
Re: Yum update problem -
On Oct 31, 2012, at 5:21 PM, Bob Goodwin - Zuni, Virginia, USA bobgood...@wildblue.net wrote: On 31/10/12 11:57, Connie Sieh wrote: What source did you use? -Connie Sieh Dunno, I most likely googled SL and used what I found there. All I know is it was a live USB ver. 6.2. I did this several months ago, it has worked perfectly and I forgot the details. The USB thumb drives get reused and that's lost. And you ran no update for several months. I don't think that is very safe for a server. I would carefully check the logs on that node. Matthias smime.p7s Description: S/MIME cryptographic signature
Re: Please update vsftpd package
On 06/08/2012 11:27 AM, Dennis Schridde wrote: Hi! The version of the package currently available in SL6 is vsftpd-2.2.2-6.el6_0.1.x86_64, while RHEL6 apparently ships vsftpd-2.2.2-11.el6 [1]. Can you please update it, as it contains a bugfix that is important for our systems. Kind regards, Dennis Schridde [1] https://bugzilla.redhat.com/show_bug.cgi?id=708657 (Fixed In Version) Please cite properly: should be fixed in... and the comment was made this night at 03:21:47 EDT. What makes you believe that RH has released the fix already? What makes you think it has already passed QA? Matthias
Re: Please update vsftpd package
Hi, On 06/08/2012 04:28 PM, Dennis Schridde wrote: Am Freitag, 8. Juni 2012, 12:58:53 schrieben Sie: On 06/08/2012 11:27 AM, Dennis Schridde wrote: Hi! The version of the package currently available in SL6 is vsftpd-2.2.2-6.el6_0.1.x86_64, Are you sure about this? in fastbugs I see vsftpd-2.2.2-6.el6_2.1 while RHEL6 apparently ships vsftpd-2.2.2-11.el6 [1]. I think that is a mis-understanding. Can you please update it, as it contains a bugfix that is important for our systems. Kind regards, Dennis Schridde [1] https://bugzilla.redhat.com/show_bug.cgi?id=708657 (Fixed In Version) Please cite properly: should be fixed in... and the comment was made this night at 03:21:47 EDT. What makes you believe that RH has released the fix already? What makes you think it has already passed QA? Matthias Sorry for my comment, I fear it was more rude that it was intended to be. And I admit I had not read the bugzilla entry properly... Bug #708657 comment #47 [1] mentions bug #767108 [2] which was closed in January. So it appeared to me as if SL was missing a fix from RHEL for 5 months. I am sorry if I misunderstood the meaning of the bugreports. They can be tricky at times, and I also got confused by the versions mentioned. In detail: https://bugzilla.redhat.com/show_bug.cgi?id=708657 was reported against RHEL6.1 in May 2011, and the affected cvftpd version appears to have been 2.2.2-6.el6_0.1. A solution was proposed on 2011-08-31 07:29:24 EDT. According to https://bugzilla.redhat.com/show_bug.cgi?id=767108 a patched rpm for 6.2 was provided by RH on 2012-01-03, the patched version was 2.2.2-6.el6_2.1. Regarding QA: Bug #708657 changed from ON_QA to VERIFIED in April. I assume that means it passed QA? Again I am sorry if I misunderstood the meaning of that. 708657 is confusing, but 767108 mentions the patched version that was released, and it is 2.2.2-6.el6_2.1, which you also find in SL fastbugs. Hope this helps, Matthias Kind regards, Dennis Schridde [1] https://bugzilla.redhat.com/show_bug.cgi?id=708657#c47 [2] https://bugzilla.redhat.com/show_bug.cgi?id=767108
Re: SL 5.7 Intel Integrated HD Graphics 3000 SandyBridge
Hi Yasha, On 10/17/2011 03:37 PM, Yasha Karant wrote: After much searching, I found for my wife a laptop that we could afford given that her Department had no funds to replace her stolen laptop, one that does work under EL including the 802.11 WNIC. It is a Lenovo G570 that uses an Intel Integrated HD Graphics 3000 (SandyBridge) graphics/video controller. The supplied display is 15.6” HD screen (1366x768), 16:9 widescreen. The 1366x768 resolution is not one of the choices, and I am not certain that the default VESA Xwindows driver has this resolution. Thus, the display is not optimum. Does anyone either have experience with this unit (I did hunt on Linux on Laptops) or with the correct Xwin driver for Intel Integrated HD Graphics 3000 and/or the 1366x768 screen? The intel driver for the SandyBridge built-in graphics controller is not compatible with the Sl5.7 kernel, so I don't think that SL5.X is suitable for that hardware. I would expect SL6.1 to be ok though. Matthias Yasha Karant
Re: evolution crashing after glibc update
On 04/06/2011 07:21 PM, Simon Butcher wrote: Hello After last night's yum security updates on our 5.3 and 5.5 machines, evolution is crashing with the dump below when trying to compose/send an email Does a reboot help? Matthias
Re: yum problem
On 04/02/2011 06:34 PM, Kay Diederichs wrote: Dear all, to be able to do 32bit-compilation/linking (e.g. using gfortran -m32) on a 64bit machine I need /usr/lib/crt1.o . I know this file is in glibc-devel.i686 so I try % yum install glibc-devel.i686 Loaded plugins: fastestmirror, refresh-packagekit Loading mirror speeds from cached hostfile * sl: scientificlinux.physik.uni-muenchen.de * sl-security: scientificlinux.physik.uni-muenchen.de Setting up Install Process Resolving Dependencies -- Running transaction check --- Package glibc-devel.i686 0:2.12-1.7.el6 set to be updated -- Processing Dependency: glibc = 2.12-1.7.el6 for package: glibc-devel-2.12-1.7.el6.i686 -- Processing Dependency: glibc-headers = 2.12-1.7.el6 for package: glibc-devel-2.12-1.7.el6.i686 -- Finished Dependency Resolution Error: Package: glibc-devel-2.12-1.7.el6.i686 (sl) Requires: glibc = 2.12-1.7.el6 Installed: glibc-2.12-1.7.el6_0.3.i686 (@sl-updates/6) glibc = 2.12-1.7.el6_0.3 Installed: glibc-2.12-1.7.el6_0.3.x86_64 (@sl-updates/6) glibc = 2.12-1.7.el6_0.3 Available: glibc-2.12-1.7.el6.i686 (sl) glibc = 2.12-1.7.el6 Available: glibc-2.12-1.7.el6.x86_64 (sl) glibc = 2.12-1.7.el6 Error: Package: glibc-devel-2.12-1.7.el6.i686 (sl) Requires: glibc-headers = 2.12-1.7.el6 Installed: glibc-headers-2.12-1.7.el6_0.3.x86_64 (@sl-updates/6) glibc-headers = 2.12-1.7.el6_0.3 Available: glibc-headers-2.12-1.7.el6.x86_64 (sl) glibc-headers = 2.12-1.7.el6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest What is the underlying problem? Looks as if the repos/mirrors you use do not have glibc-devel 2.12-1.7.el6_0.3 for i686. So they offer you glibc-devel-2.12-1.7.el6.i686. But that one is not compatible with the glibc package versions you already have installed. Hope this helps, Matthias
Re: SL 5.6 released?
On 02/11/2011 06:00 PM, Larry Vaden wrote: On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahone...@macmahon.me.uk wrote: I'm a little bit hazy on the details, but there are some slides from the meeting here[1]: http://indico.cern.ch/getFile.py/access?contribId=8sessionId=1resId=1materialId=slidesconfId=106641 Troy, Ewan's URL says, in part: • 5.6 release history: – RedHat released RHEL 5.6 on 13-Jan – CERN released SLC 5.6 on 20-Jan – FNAL released SL 5.6 last week • CERN rolled out SLC 5.6 on desktops and central systems around 28-Jan Is this correct or incorrect? That is a question of definition. For SLC, most of the packages that make up SLC5.6 have been released, but the installer is still in testing. In that state it is almost 5.6, but it is not yet called 5.6. For SLC everything is 'rolling', the individual minor releases are not maintained as such, so there is no way to stay with eg 5.3 and only get security updates for it. That is a feature of SLC (watch for the 'C'!). HTH, Matthias (read: my curiosity is killing me based on what I read here.} My presumption is that non-government use of SL is permitted if not welcome; feel free to correct me on that. As an ISP using CentOS, we'd like to migrate to SL if we are welcome to do that. kind regards/ldv Larry Vaden, CoFounder Internet Texoma, Inc. Serving Rural Texomaland Since 1995 We Care About Your Connection!
Re: SL 5.6 released?
On 02/10/2011 02:59 AM, Larry Vaden wrote: On Wed, Feb 9, 2011 at 11:27 AM, Ewan Mac Mahone...@macmahon.me.uk wrote: I'm a little bit hazy on the details, but there are some slides from the meeting here[1]: http://indico.cern.ch/getFile.py/access?contribId=8sessionId=1resId=1materialId=slidesconfId=106641 THANKS! On Wed, Feb 9, 2011 at 12:41 PM, Chris Jones christopher.rob.jo...@cern.ch wrote: I would say a bug in tcmalloc, not SL or RHEL. See for instance http://code.google.com/p/google-perftools/issues/detail?id=305 The fix is to move to google perftools 1.7 Because of a problem with not running the current BIND release a couple of weeks ago, I would like to ask: a) is RedHat likely to choose to backport the fix to 1.6 or will it adopt 1.7 or leave as is until 5.7 or later? google-perftools comes from epel, not rhel. What the epel google-perftools maintainer will do is not easy to judge. I don't know how to interpret https://bugzilla.redhat.com/show_bug.cgi?id=675376. But since this is epel and not rhel, I see no relation to the 5.7 release. I would expect that epel maintainers react to this incompatibility between google-perftools and the current rhel release. But then again i have not found an epel bugzilla entry that explicitly mentions the problem. Matthias b) will Centos and/or SL follow RH exactly or will their approaches differ? IOW, how far does the binary compatiblity policy extend? kind regards/ldv
Re: missing glibc-devel
Franchisseur Robert wrote:
-- Le (On) 2010-10-07 -0500 à (at) 14:27:17 Troy Dawson écrivit (wrote): --
Franchisseur Robert wrote:
Hello,
I cannot install glibc-devel.i386 under SL5.5 on x86_64 machines.
(no problem under SL 5.4)
bunker:{root}:/home/bob yum install glibc-devel
...
glibc-devel-2.5-42.i386 from sl-base has depsolving problems
-- Missing Dependency: glibc-headers = 2.5-42 is needed by package
glibc-devel-2.5-42.i386 (sl-base)
glibc-devel-2.5-42.i386 from sl-base has depsolving problems
-- Missing Dependency: glibc = 2.5-42 is needed by package
glibc-devel-2.5-42.i386 (sl-base)
...
I don't understand why it is looking for 2.5-42 as there is 2.5-49 in the
repo.
Thanks for your help.
Hello,
The odds are that you have more than one glibc-devel (or some other
glibc package) installed, and I mean more than one per arch.
Do an
rpm -qa | grep glibc | sort
I have 2.5-49 installed so I wonder why it wants 2.5-42
Just an idea: there is no 2.5-49.i386 in the x86_64 repo?
Matthias
compat-glibc-2.3.4-2.26.i386
compat-glibc-2.3.4-2.26.x86_64
compat-glibc-headers-2.3.4-2.26.x86_64
glibc-2.5-49.i686
glibc-2.5-49.x86_64
glibc-common-2.5-49.x86_64
glibc-devel-2.5-49.x86_64
glibc-headers-2.5-49.x86_64
on a 5.4 machine I could install glibc-devel
compat-glibc-2.3.4-2.26.i386
compat-glibc-2.3.4-2.26.x86_64
compat-glibc-headers-2.3.4-2.26.x86_64
glibc-2.5-42.i686
glibc-2.5-42.x86_64
glibc-common-2.5-42.x86_64
glibc-devel-2.5-42.i386 === @@
glibc-devel-2.5-42.x86_64
glibc-headers-2.5-42.x86_64
Re: problem with acroread SLC on SL4.8
Hello, Franchisseur Robert wrote: Hello, we have recently noticed that acroread-9.3.3-1.slc4 from the repo http://linuxsoft.cern.ch/cern/slc4X/$basearch/yum/updates/ takes almost 100% of the CPU. Scientific Linux SL release 4.8 (Beryllium) Linux reynolds.lmd.jussieu.fr 2.6.9-89.0.26.EL #1 Wed Jun 16 04:44:53 CDT 2010 i686 i686 i386 GNU/Linux Does anybody see the same behavior ? Yes, it is a known feature. Just don't use acroread... Matthias
Re: xorg-x11-fonts-ISO8859-1-75dpi breaks when using rpm
Faye Gibbins wrote: We're using xorg-x11-font-utils-7.1-2 on SL5.4 and I've noticed that the header for the rpm says it requires mkfontdir. Should that not be either '/usr/bin/mkfontdir' or 'xorg-x11-font-utils'? Just having 'mkfontdir' seems to break things when using rpm to install the package. What do you mean by 'sees to break things'? Without any knowledge what goes wrong we can only speculate what the issue might be. I assume you know that rpm does nothing to resolve the requirements... Matthias Faye
Re: kernel stack size problems with xfs NFS4 for i386 arch.
Thomas Kress wrote: Hello All, at RWTH Aachen, Germany, we are experiencing frequent kernel freezings of our (a bit older) data servers when using (SL5,) the xfs file system and NFS4 with i386 data server architectures. No problems with 64 bit servers. You are aware that xfs is not really supported on 32 bit systems? From the /var/log messages we think that the problem is due to a smaller stack size for the i386 kernel as described here: http://www.mythtv.org/pipermail/mythtv-users/2005-May/089314.html Any chance that for future SL kernel upgrades 8k instead of 4k stack size is used also for the 32 bit architecture (kernel parameter CONFIG_4KSTACKS=n) Epsilon, I would say. or any idea how to cure the problem ? Go to 64 bit. In our opinion ext3 is not a very good choice for big data servers in case of fs crashes. Why insist on a 32 bit system for 'a big data server'??? Matthias I found this issue discussed already in Jan 2006 on this list but I wonder whether there was any progress during the last four years. Thanks cheers, Thomas. -- Mit besten Gruessen/With kind regards, Thomas Kress, RWTH Aachen, III. Physikalisches Institut, Lehrstuhl B Office Aachen: 28A 206, Phone: +49 241 80 27281, Fax: ... 22244 Office CERN: B40 4-A16, Phone: +41 22 76 71682, Fax: ... 78940 Email: thomas.kr...@physik.rwth-aachen.demailto:thomas.kr...@physik.rwth-aachen.de ; thomas.kr...@cern.chmailto:thomas.kr...@cern.ch Signed with a certificate issued by GridKa-CA (GermanGrid)
Re: Dependency gcc / libgomp
Jean-Michel Barbet wrote: Hello, I came accross a strange dependency problem upgrading SL5.3/x86_64 and some of you may have an explaination : Installing the last update libgomp-4.4.0-6.el5.x86_64.rpm was refused because gcc43 4.3.2-7.el5 needs libgomp = 4.3.2-7.el5. gcc43 4.3.2-7.el5 is part of SL 5.3, and it requires the matching libgomp. libgomp-4.4.0-6.el5 is part of SL 5.4. I think you should decide whether you want to use SL5.3 or SL5.4. I had to prevent the update of libgomp. ...or go to gcc44 (SL 5.4) Matthias Anyone had the same problem ? Is this normal ? Thanks. JM
Re: Dependency gcc / libgomp
Jean-Michel Barbet wrote: ... gcc43 and gcc44 are obviously two different packages and one choose to install one of them or both but I am not sure both versions of libgomp can be installed simultaneously, so there is a problem here. Why not just de-install gcc43, and install gcc44? Matthias I suppose the right way to do it would be to have different package names for libgomp and allow to install both versions using different names or locations for the libraries. JM
Re: Dependency gcc / libgomp
Jean-Michel Barbet wrote: Matthias Schroeder wrote: Jean-Michel Barbet wrote: ... gcc43 and gcc44 are obviously two different packages and one choose to install one of them or both but I am not sure both versions of libgomp can be installed simultaneously, so there is a problem here. Why not just de-install gcc43, and install gcc44? This I cannot do without a careful study of the impact... The impact should be that you can update libgomp. There should not be any side-effects to production systems, since gcc43 and gcc44 are 'Technology Previews' and should not be used in production environments. And it does not solve the original problem if one wants to keep gcc34 which should be allowed and supported IMHO. Since these are Technology Previews, I don't quite see why they need to be installed in parallel. Matthias JM
Re: glib2-2.12.3-4.el5_3.1.x86_64 and /lib64/libglib-2.0.so
Ron Rechenmacher wrote: Hi, On my SL5 x86_64 machine, I tried to build a package that wanted libglib-2.0 and it could not build because although /lib64/libglib-2.0.so.0 exists, the sym link /lib64/libglib-2.0.so did not. The rpm that /lib64/libglib-2.0.so.0 belongs to is /lib64/libglib-2.0.so.0. Should the install of this rpm create the link? Assuming so, could someone check to see if it does or not. I created the link myself so that my software builds, but I would like to know if my system somehow deleted the link. The rpm that should provide libglib-2.0 is glib2-devel. Hope this helps, Matthias Thanks, Ron
Re: SL and Oracle
Howard, Chris wrote: I've been an Oracle DBA for quite a number of years, working on HP-UX systems. Now I'm also running some Oracle Application Server on Linux machines and I could use some advice about Oracle and Linux. For SL, I'm assuming I can call my SL 5.3 installation equivalent to Red Hat 5.3 for Oracle support purposes? Not from the point of view of Oracle. If you want support from them, you better run RH. ... Is it safe to do regular yum updates on a dedicated Oracle App Server/SL 5.3 box? Maybe I should just let it run at the current configuration and not chance breaking something. If you want support from Oracle, you might want to restrict yourself to security updates only, and of course RH (or the Oracle clone). Matthias
Re: Yum install; subversion on x86_64
Hi, Tim Edwards wrote: Troy Dawson wrote: Hi Chris, This is a feature of yum in RHEL5 and SL5. The problem already starts with anaconda installing all sorts of 32bit packages in addition to the 64 bit ones. If you are certain that you want no 32bit packages at all, you can # yum remove *.i386 # yum remove *.i686 Once you have done that you can configure yum to ignore all .i386 and .i686 packages - BUT: as soon as you install a 32bit package, and you still tell yum to ignore 32bit packages, you can be sure that it won't take long until your yum updates fail. Just been there, and was really confused why it failed ;) Matthias
Re: SL-5.1Need help to know name of rpms
Sangamesh B wrote: Dear SL-5.1 users, I'm trying to install an application on CentsOS-5.2. The application works well on ScientificLinux-5.1but its failing to run on CentsOS-5.2(compilation goes smooth). That's because CentOS is lacking some of the rpms compared to SL-5.1. As the program fails by just showing library name.so not found error, I'm not able to find from which rpm that library come from. Following is the list of missing libraries: libGeoBase.so libParBase.so libBase.so libCbmBase.so libCbmData.so libField.so libGen.so libPassive.so libSts.so libTrd.so libTof.so libMuch.so To me this sounds like root libs or experiment specific libs, but nothing coming from SL, whatever release. Matthias As I don't have SL-5.1, I request any one of you to check which rpm these library belong to, i.e. the following 2 commands $ locate libGeoBase It will give the path of libGeoBase $ rpm -qf path of libGeoBase It will give the name of rpm. Same steps should be carried for other libraries also. Send me the list of rpms. Thanks for your kind help
Re: NFS Bug 469848 - [RHEL5.2] nfs_getattr() hangs during heavy write workloads
Jan Schulze wrote: Hi all, some questions regarding this bug (https://bugzilla.redhat.com/show_bug.cgi?id=469848), as I do not quite understand the information in the bug tracking system. - Will there be a real patch for this bug, or will it just be mentioned in the Release Notes? I don't understand the question. - What version will the patch be for (5.2, 5.3, ...)? My guess: a patched version will be released with/for 5.4. - When can we expect a patch release (status is RELEASE_PENDING since 2009-08-11)? My guess: when 5.4 will be released. - How long does it usually take for such patches to be available in Scientific Linux? For a 'normal' security or bugfix release: a few days. For a new minor version (like 5.4): a few days more. Many packages need rebuilding, and the infrastructure has to be made for the new minor release. HTH, Matthias Best Regards, Jan
Re: kernel security
Troy Dawson wrote: Stephan Wiesand wrote: On Fri, 2009-08-14 at 11:59 +0100, Dr Andrew C Aitchison wrote: On Fri, 14 Aug 2009, Urs Beyerle wrote: I guess SL is affected like most other Linux distributions. I'm not 100% sure, but setting vm.mmap_min_addr to a value above 0 should prevent an exploit. # sysctl vm.mmap_min_addr=4096 The default on my SL53 machines appears to be 65536 so there may be no need to do this. And Stephan Wiesand stephan.wies...@desy.de replied: I successfully rooted a 32bit SL5 system with SELinux enabled and vm.mmap_min_addr=64k with the public exploit :-( Did this machine have kernel-2.6.18-128.4.1.el5 and hence the fix for CVE-2009-1895 which allows a user to bypass mmap_min_addr - see Yes. https://rhn.redhat.com/errata/RHSA-2009-1193.html ? Though I did see that there are other ways of bypassing vm.mmap_min_addr :-( Yes, and they work fine :-/ Has anyone with a TAM with RedHat reported this to them yet? You mean https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2009-2692, right? I'm pretty sure someone has, I just want to verify and get a bug tracking number. There is also an IT, you should be able to see it. Matthias Troy
Re: SL 4.x problems with ATI fglrx after kernel-update
Hi, I have no answer to your questions, but we have problems with the .22 kernel and ati-gflrx drivers. For some machines the screen simply stays black, and X is completely stuck. Apparently while initialising the hardware acceleration. Disabling that gives you a working X, but slow is not the right description... One workaround is to use the vesa driver, but I already had complaints about the limited resolution :( In our case the unresolved 'floor' also gets mentioned when we boot with the old kernel (and get a working X). Matthias Michael Bontenackels wrote: Hello, we encountered a problem with the newest kernel for SL 4.x on our institute cluster: after installing the new kernel-smp-2.6.9-78.0.22.EL.i686 on our machines the ATI Catalyst 9.3/9.4 drivers crash when X is started. All kernel modules have been rebuilt suiting to the new kernel. The Xorg.0.log shows following error messages: . (WW) fglrx(0): Only one display is connnected,so single mode is enabled Symbol fbGetWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! Symbol fbGetWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! Symbol fbGetWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! Symbol fbGetWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! Symbol fbGetWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! Symbol fbGetWinPrivateIndex from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! Symbol fbPictureInit from module /usr/X11R6/lib/modules/drivers/fglrx_drv.o is unresolved! *** If unresolved symbols were reported above, they might not *** be the reason for the server aborting. Fatal server error: Caught signal 11. Server aborting . Switching back to kernel 2.6.9-78.0.17.EL or even much older versions and rebuilding the fglrx kernel modules works fine. Does anyone know what has happend to the new kernel? Why can the symbols (I guess they have something to do with framebuffer access) not be resolved with the newest kernel update? Actualy I would expect bug-fixes to be included in the new kernels but no changes of interfaces etc. Any ideas (or new kernel version) are welcome. Cheers, Michael.
Re: running 32bit Firefox on SL5.x x86_64 machines
Hi Jayakumar, J S Jayakumar wrote: Dear All, As you know, on starting Firefox on x86_64 machines, by default the 64bit version starts. This version does not support lava fully and hence many sites are not displayed properly. How to start the 32 bit Firefox on such systems. I hae found no way to do it. First of you would have to install the 32 bit version. That is the easy part. But then it does conflict with the 64bit evolution packages. The dependencies for these do not specify the architecture, so for yum, rpm etc the 64 bit versions that are already installed appear to be fine. But the 32 bit firefox does not work with them. Ok, I thought, remove the 64 bit evolution stuff and install the 32 bit versions. That can be done, but it does not work. Some methods are not found. I had also tried to install the 64bit and the 32bit evolution stuff in parallel. That needs some rpm options to achieve that, but also that does not help. So I gave up on this... Matthias Jayakumar.
Re: openssl breaks ldap on SL5.0?
Hi, Jeffrey D Anderson wrote: On Sunday 25 May 2008 1:21:41 am Jan Iven wrote: On 05/23/2008 07:07 PM, Jeffrey D Anderson wrote: [..] The pam_console_apply signal 13 (broken pipe) is obviously at the core of the bug, but I don't know enough about pam to really understand what is going wrong. I would suggest to set up a test: # strace -s 256 -f -o /tmp/somefile -p PID_OF_GETTY_ON_CONSOLE If you are running nscd, suggest to strace this as well. Then repeat your login test, and search the tracefile(s) for signal 13, identify which process held the other end of the pipe, and why it went away - most likely some subprocess died/segfaulted without leaving other traces in the logs. Hope this helps jan Thanks for the suggestion. I ran the strace with both the new, problematic nss_ldap, and the old version that works. I find three places where broken pipes result. Since this is obviously not an SL specific issue, I'm moving my debugging off the list. It looks like this is already reported as https://bugzilla.redhat.com/show_bug.cgi?id=447881 No solution yet, though. 447881 is marked as a duplicate of 448014 (https://bugzilla.redhat.com/show_bug.cgi?id=448014), and that one does have a proposed patch. Matthias
Re: g77 in SL 5.1
Konstantin Olchanski wrote: On Mon, Jun 02, 2008 at 08:22:24PM +0100, Jon Peatfield wrote: I installed SL5.1 and seems g77 isn't installed. Yes, in recent GCCs, the very nice g77 compiler was replaced by something called gfortran. If I remember right, the main reason was the retirement of the g77 main author and maintainer. The new compiler is written by some new people and it strives to implement the recent Fortran standards (F-95, etc). Last time I looked a few years ago, compatibility with Fortran-II, Fortran-4, DEC Fortran, Fortran-77 and need to compile antique (but still quite usable) programs was not high in the priority list for gfortran developers. Proper Fortran-77 is no problem any more with gfortran, but with vendor specific, non-standard extensions you will have no luck. Matthias
Re: Grub question
P. Larry Nelson wrote: I apologize to the list but don't understand why, if I changed the subject, it would be part of a previous thread. The header has a in-reply-to field, and a references field. They are used for the threading. I always thought threads keyed off the subject line, That would be much too simple. and I've been using email since it was invented back in the 70's. Oh well - learn something new every day Keep it like that ;) Matthias Thanks! - Larry
Re: SL5 and [TUV] Enterprise Linux 5 - compatability?
Keith Lofstrom wrote: I will be setting up a server for Cadence chip design software, and that company specifies Enterprise Linux 5 from The Upstream Vendor for the OS, accept no substitutes. This is the case with a lot of commercial software. The cost of [T.U.V.] EL5, with support, is miniscule compared to the CAD tool licenses, so I have no problem with running that. The other half dozen existing machines are SL5 (and one CentOS5), and will not be running Cadence, so they will stay with SL5. I am assuming that these machines will coexist peacefully; So would I. I will keep them separate, and not ask TUV tech support any SL5 questions. With my SLx experience, I probably won't need any tech support at all. I assume Cadence specifies an EL5 support contract so that Cadence isn't saddled with OS vendor questions from newbies. If you ever did user support you know these cases where the user 'changed nothing, I promise you' except perhaps that print statement... They just want to make sure the base OS _is_ identical, and that there are no changes that should not make a difference, except if ... So, the question is, does anyone know of any technical or legal or business reasons why mixing SL5 and TUVEL5 is difficult? No. Or is this going to be very easy, like I expect? I would be surprised if not. You will have the extra work to set up the infrastructure for the TUV machine(s), but the boxen themselves will be nice to each other. Matthias Keith
Re: g77 compatibility issue
Christoph P. Kukulies wrote: On Thu, Sep 20, 2007 at 10:12:50AM +0200, Klaus Wacker wrote: On Wed, Sep 19, 2007 at 10:25:55AM -0500, Hendrik van Hees wrote: Thank you very much for all the responses. I think I didn't make the problem clear. With the older version of gcc (I am using the fortran compiler, g77) gcc version 3.3.5 20050117 (prerelease) (SUSE Linux) the little code runs fine. With the newer version, which is definitely in my installation of SL 5 (I use yum as a package manager), gcc version 3.4.6 20060404 (Red Hat 3.4.6-4) the same code does not work any more. Perhaps it helps, when I give the relevant piece of code: open(unit=1, $ file='RW-total-tadmix4pi-6pi-DY.dat') do x=0.2d0,1.45d0,0.01d0 erg=ipol(x1,set1,x)+ipol(x2,set2,x)+ipol(x3,set3,x) $+ipol(x4,set4,x)+ipol(x5,set5,x) write(unit=1,fmt='(2g25.8e3)') $x,erg end do close(unit=1) c add omega and phi (all pT) open (unit=2, file='RW-total-tadmix4pi-6pi-DY.dat', $ status='old') do j=1,nmax1 read(unit=2,fmt='(2g25.8e3)') x1(j),set1(j) c write(*,*) x1(j),set1(j) end do close(unit=2) As you see. It simply writes some columns of double precision, and in the next step it reads the same in again. Somehow the code you show doesn't fit the error message. You seem to be using unit 1 only for writing, whereas the error message talks about reading from unit 1. the crucial statement is read(unit=2,fmt='(2g25.8e3)') x1(j),set1(j) Maybe, but I would not bet on that. As Klaus pointed out the number of interations in the first loop is not defined. By chance the OP apparently got away with that on the first systems he used. We don't know which value nmax1 has, so maybe he is trying to read one more element than he has written I anyhow don't quite understand why he first writes the values to a file (in a not well defined format (format real as decimal or exponential )) only to read it back in a later stage by the same program. To me it looks as if there are a few things that are not well defined, which is not always a good thing in programming... Matthias albeit the error message talks about unit 1 in the OP (but I guess he changed the unit numbers in the code snippet). The format '(2g25.8e3)' is obviously triggering the error message I would assume. It could be a matter of the math libs used or also the fortran runtime library may have changed in that point. Have you (OP) looked at the intermediate data file and compared it under the different platforms? -- Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de
Re: SL5 installation - Everything is missing
Miles O'Neal wrote: Connie Sieh said... |Sorry but that is the way TUV has it coded and I agree with them for |taking it out. I actually like the idea of not allowing a Everything |install. It installs things that exist but are not configured and can |lead to security issues since they are are not configured. It is also |hard to support as some packages just conflict. | |In the past when it was hard to install packages after a install was done |I can see how this option could be useful. Today with yum and the gui |yum front ends making it easy to install packages later I do not see the |real need for this. The thing is, some of us like a one step installation process. Every time I have ever used anything less than everything (with one exception, see below) it has caused lots of problems. Inevitably things failed because of dependancy problems someone missed along the way, and some package we expected to be somewhere wasn't, so it took a lot of extra effort. These have bitten us many times over the years; loading Everything never bit us with conflicts. I have spent quite some time fixing obscure problems with updates on machines that had suffered an Everything install, so I see it as a good news that that option is gone now... Matthias
