broken dependencies in SL4X for openldap
Hi Folks, I have an x86_64 box that I'm trying to install openldap-servers.x86_64 on and its pulling in strange dependencies ie: # yum install openldap-servers Loading protectbase plugin Loading kernel-module plugin Setting up Install Process Setting up repositories Reading repository metadata in from local files 1561 packages excluded due to repository protections Parsing package install arguments Resolving Dependencies -- Populating transaction set with selected packages. Please wait. --- Package openldap-servers.x86_64 0:2.2.13-12.el4 set to be updated -- Running transaction check -- Processing Dependency: openldap = 2.2.13-12.el4 for package: openldap-servers -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package openldap.i386 0:2.2.13-12.el4 set to be updated -- Running transaction check -- Processing Dependency: libc.so.6(GLIBC_2.3.2) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.1.2) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.1) for package: openldap -- Processing Dependency: libc.so.6 for package: openldap -- Processing Dependency: libcrypto.so.4 for package: openldap -- Processing Dependency: libresolv.so.2 for package: openldap -- Processing Dependency: libresolv.so.2(GLIBC_2.2) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.3) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.0) for package: openldap -- Processing Dependency: libssl.so.4 for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.1.3) for package: openldap -- Processing Dependency: libsasl2.so.2 for package: openldap -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package glibc.i686 0:2.3.4-2.43 set to be updated --- Package openssl.i686 0:0.9.7a-43.17.el4_7.2 set to be updated --- Package cyrus-sasl.i386 0:2.1.19-14 set to be updated -- Running transaction check -- Processing Dependency: libcom_err.so.2 for package: cyrus-sasl -- Processing Dependency: libpam.so.0 for package: cyrus-sasl -- Processing Dependency: libk5crypto.so.3 for package: cyrus-sasl -- Processing Dependency: libkrb5.so.3 for package: openssl -- Processing Dependency: libkrb5.so.3 for package: cyrus-sasl -- Processing Dependency: libgssapi_krb5.so.2 for package: openssl -- Processing Dependency: libk5crypto.so.3 for package: openssl -- Processing Dependency: libz.so.1 for package: openssl -- Processing Dependency: libcom_err.so.2 for package: openssl -- Processing Dependency: libgssapi_krb5.so.2 for package: cyrus-sasl -- Processing Dependency: libgdbm.so.2 for package: cyrus-sasl -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package gdbm.i386 0:1.8.0-24 set to be updated --- Package e2fsprogs.i386 0:1.35-12.24.el4 set to be updated --- Package zlib.i386 0:1.2.1.2-1.2 set to be updated --- Package pam.i386 0:0.77-66.26 set to be updated --- Package krb5-libs.i386 0:1.3.4-62.el4 set to be updated -- Running transaction check -- Processing Dependency: libcrack.so.2 for package: pam -- Processing Dependency: libselinux.so.1 for package: pam -- Processing Dependency: libglib-2.0.so.0 for package: pam -- Processing Dependency: libaudit.so.0 for package: pam -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package cracklib.i386 0:2.8.9-1.3 set to be updated --- Package libselinux.i386 0:1.19.1-7.4 set to be updated --- Package glib2.i386 0:2.4.7-1 set to be updated --- Package audit-libs.i386 0:1.0.16-4.el4 set to be updated -- Running transaction check -- Processing Dependency: cracklib-dicts@i386 = 2.8.9-1.3 for package: cracklib -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package cracklib-dicts.i386 0:2.8.9-1.3 set to be updated -- Running transaction check Beginning Kernel Module Plugin Finished Kernel Module Plugin Dependencies Resolved = Package Arch Version RepositorySize = Installing: openldap-serversx86_64 2.2.13-12.el4sl-base 3.4 M Installing for dependencies: audit-libs i386 1.0.16-4.el4 sl-base39 k cracklibi386 2.8.9-1.3sl-base56 k cracklib-dicts i386 2.8.9-1.3sl-base 3.6 M cyrus-sasl i386 2.1.19-14sl-base 1.2 M e2fsprogs i386 1.35-12.24.el4 sl-base 783 k gdbmi386 1.8.0-24 sl-base26 k glib2 i386 2.4.7-1
Re: broken dependencies in SL4X for openldap
Hi, I'm looking into this. Your subject says SL4x. Is that really where your yum is pointing or is that just generic. Can you send the output of rpm -qa | grep yum | sort Thanks Troy On 04/13/2011 06:32 AM, Andrew Elwell wrote: Hi Folks, I have an x86_64 box that I'm trying to install openldap-servers.x86_64 on and its pulling in strange dependencies ie: # yum install openldap-servers Loading protectbase plugin Loading kernel-module plugin Setting up Install Process Setting up repositories Reading repository metadata in from local files 1561 packages excluded due to repository protections Parsing package install arguments Resolving Dependencies -- Populating transaction set with selected packages. Please wait. --- Package openldap-servers.x86_64 0:2.2.13-12.el4 set to be updated -- Running transaction check -- Processing Dependency: openldap = 2.2.13-12.el4 for package: openldap-servers -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package openldap.i386 0:2.2.13-12.el4 set to be updated -- Running transaction check -- Processing Dependency: libc.so.6(GLIBC_2.3.2) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.1.2) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.1) for package: openldap -- Processing Dependency: libc.so.6 for package: openldap -- Processing Dependency: libcrypto.so.4 for package: openldap -- Processing Dependency: libresolv.so.2 for package: openldap -- Processing Dependency: libresolv.so.2(GLIBC_2.2) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.3) for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.0) for package: openldap -- Processing Dependency: libssl.so.4 for package: openldap -- Processing Dependency: libc.so.6(GLIBC_2.1.3) for package: openldap -- Processing Dependency: libsasl2.so.2 for package: openldap -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package glibc.i686 0:2.3.4-2.43 set to be updated --- Package openssl.i686 0:0.9.7a-43.17.el4_7.2 set to be updated --- Package cyrus-sasl.i386 0:2.1.19-14 set to be updated -- Running transaction check -- Processing Dependency: libcom_err.so.2 for package: cyrus-sasl -- Processing Dependency: libpam.so.0 for package: cyrus-sasl -- Processing Dependency: libk5crypto.so.3 for package: cyrus-sasl -- Processing Dependency: libkrb5.so.3 for package: openssl -- Processing Dependency: libkrb5.so.3 for package: cyrus-sasl -- Processing Dependency: libgssapi_krb5.so.2 for package: openssl -- Processing Dependency: libk5crypto.so.3 for package: openssl -- Processing Dependency: libz.so.1 for package: openssl -- Processing Dependency: libcom_err.so.2 for package: openssl -- Processing Dependency: libgssapi_krb5.so.2 for package: cyrus-sasl -- Processing Dependency: libgdbm.so.2 for package: cyrus-sasl -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package gdbm.i386 0:1.8.0-24 set to be updated --- Package e2fsprogs.i386 0:1.35-12.24.el4 set to be updated --- Package zlib.i386 0:1.2.1.2-1.2 set to be updated --- Package pam.i386 0:0.77-66.26 set to be updated --- Package krb5-libs.i386 0:1.3.4-62.el4 set to be updated -- Running transaction check -- Processing Dependency: libcrack.so.2 for package: pam -- Processing Dependency: libselinux.so.1 for package: pam -- Processing Dependency: libglib-2.0.so.0 for package: pam -- Processing Dependency: libaudit.so.0 for package: pam -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package cracklib.i386 0:2.8.9-1.3 set to be updated --- Package libselinux.i386 0:1.19.1-7.4 set to be updated --- Package glib2.i386 0:2.4.7-1 set to be updated --- Package audit-libs.i386 0:1.0.16-4.el4 set to be updated -- Running transaction check -- Processing Dependency: cracklib-dicts@i386 = 2.8.9-1.3 for package: cracklib -- Restarting Dependency Resolution with new changes. -- Populating transaction set with selected packages. Please wait. --- Package cracklib-dicts.i386 0:2.8.9-1.3 set to be updated -- Running transaction check Beginning Kernel Module Plugin Finished Kernel Module Plugin Dependencies Resolved = Package Arch Version RepositorySize = Installing: openldap-serversx86_64 2.2.13-12.el4sl-base 3.4 M Installing for dependencies: audit-libs i386 1.0.16-4.el4 sl-base39 k cracklibi386 2.8.9-1.3sl-base56 k cracklib-dicts i386 2.8.9-1.3
Re: broken dependencies in SL4X for openldap
Your subject says SL4x. Is that really where your yum is pointing or is that just generic. we try and follow the x versions Can you send the output of rpm -qa | grep yum | sort [root@vtb-generic-34 ~]# rpm -qa | grep yum | sort warning: only V3 signatures can be verified, skipping V4 signature yum-2.4.3-10.SL.noarch yum-conf-4x-1-8.SL.noarch yum-protectbase-0.6-1.SL.noarch [root@vtb-generic-34 ~]# but of more use is the actual conf files probably: [root@vtb-generic-34 yum.repos.d]# cat sl4x.repo sl4x-errata.repo [sl-base] name=SL 4 base baseurl=http://linuxsoft.cern.ch/scientific/4x/$basearch/SL/RPMS http://ftp.scientificlinux.org/linux/scientific/4x/$basearch/SL/RPMS/ #mirrorlist=http://ftp.scientificlinux.org/linux/scientific/mirrorlist/sl-base-4x.txt enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-csieh file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson file:///etc/pki/rpm-gpg/RPM-GPG-KEY-jpolok file:///etc/pki/rpm-gpg/RPM-GPG-KEY-cern file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl4 protect=1 [sl-errata] name=SL 4 errata baseurl=http://linuxsoft.cern.ch/scientific/4x/$basearch/errata/SL/RPMS/ http://ftp.scientificlinux.org/linux/scientific/4x/$basearch/errata/SL/RPMS/ http://ftp1.scientificlinux.org/linux/scientific/4x/$basearch/errata/SL/RPMS/ ftp://ftp.scientificlinux.org/linux/scientific/4x/$basearch/errata/SL/RPMS/ #mirrorlist=http://ftp.scientificlinux.org/linux/scientific/mirrorlist/sl-errata-4x.txt enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-csieh file:///etc/pki/rpm-gpg/RPM-GPG-KEY-dawson file:///etc/pki/rpm-gpg/RPM-GPG-KEY-jpolok file:///etc/pki/rpm-gpg/RPM-GPG-KEY-cern file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl file:///etc/pki/rpm-gpg/RPM-GPG-KEY-sl4 [root@vtb-generic-34 yum.repos.d]# since we add our local mirror in
Re: broken dependencies in SL4X for openldap
Hello, I'm going to trim some of this and do middle posts hope you don't mind. ... On 04/13/2011 06:32 AM, Andrew Elwell wrote: ... # yum install openldap-servers ... Dependencies Resolved = Package Arch Version RepositorySize = Installing: openldap-serversx86_64 2.2.13-12.el4sl-base 3.4 M ... Yum should be getting openldap-servers version 2.2.13-12.el4_8.3 Do you not have your sl-security repo enabled? If you don't, then you should enable it, and all this will clear up. ... [root@vtb-generic-34 ~]# rpm -q openldap openldap-2.2.13-12.el4_8.3.x86_64 ... and I can't do a straight upgrade: [root@vtb-generic-34 ~]# rpm -Uvh http://linuxsoft.cern.ch/scientific/4x/x86_64/SL/RPMS/openldap-2.2.13-12.el4.x86_64.rpm ... What you call and upgrade is really a downgrade. You need to either get the updated version of openldap-servers, http://linuxsoft.cern.ch/scientific/4x/x86_64/errata/SL/RPMS/openldap-servers-2.2.13-12.el4_8.3.x86_64.rpm Or, if you are really determined to downgrade, then use the correct rpm option to downgrade. Troy -- __ Troy Dawson daw...@fnal.gov (630)840-6468 Fermilab ComputingDivision/SCF/FEF/SLSMS Group __
xrdb gone bad. xorg-x11-server-utils-7.1-5.el5_6.1 broken?
Several users started complaining today about various X apps, such as xterm and emacs, that no longer look the way they want. It looks like the resources they set in their .Xresources files are no longer set. In ~/.xsession-errors I find the following: sh: -c: line 0: unexpected EOF while looking for matching `' sh: -c: line 1: syntax error: unexpected end of file sh: -c: line 0: unexpected EOF while looking for matching `' sh: -c: line 1: syntax error: unexpected end of file The following is suspicious: % xrdb -merge .Xresources sh: -c: line 0: unexpected EOF while looking for matching `' sh: -c: line 1: syntax error: unexpected end of file Note that the .Xresources file is fine and hasn't been changed in 3 years. Then there is this: % ls -l /usr/bin/xrdb -rwxr-xr-x 1 root root 25064 Apr 12 06:40 /usr/bin/xrdb* % rpm -q --whatprovides /usr/bin/xrdb xorg-x11-server-utils-7.1-5.el5_6.1.x86_64 I think this package is broken.
Re: xrdb gone bad. xorg-x11-server-utils-7.1-5.el5_6.1 broken?
David M. Cooke writes: Several users started complaining today about various X apps, such as xterm and emacs, that no longer look the way they want. It looks like the resources they set in their .Xresources files are no longer set. Same in EL6. The changelog for this package says: * Wed Mar 16 2011 Adam Jackson a...@redhat.com 7.4-15.el6_0.1 - cve-2011-0465: Sanitize cpp macro expansion. (CVE 2011-0465) which sounds like something that could indeed break .Xresources parsing. Although in my case, not only old-style X apps lost their fonts marbles, but so did the KDE programs, menus, etc -- which I didn't think used the old-style X fonts at all. After wasting 15 minutes resetting fonts in many different places, X is usable again. I'm sure Murphy's Law says that this bug will be fixed tomorrow and we'll all have to re-reset things :) -- Alec Habig, University of Minnesota Duluth Physics Dept. ha...@neutrino.d.umn.edu http://neutrino.d.umn.edu/~habig/
Re: xrdb gone bad. xorg-x11-server-utils-7.1-5.el5_6.1 broken?
On Wed, Apr 13, 2011 at 7:47 AM, Alec T. Habig ha...@neutrino.d.umn.edu wrote: David M. Cooke writes: Several users started complaining today about various X apps, such as xterm and emacs, that no longer look the way they want. It looks like the resources they set in their .Xresources files are no longer set. Same in EL6. The changelog for this package says: * Wed Mar 16 2011 Adam Jackson a...@redhat.com 7.4-15.el6_0.1 - cve-2011-0465: Sanitize cpp macro expansion. (CVE 2011-0465) which sounds like something that could indeed break .Xresources parsing. Although in my case, not only old-style X apps lost their fonts marbles, but so did the KDE programs, menus, etc -- which I didn't think used the old-style X fonts at all. After wasting 15 minutes resetting fonts in many different places, X is usable again. I'm sure Murphy's Law says that this bug will be fixed tomorrow and we'll all have to re-reset things :) Looks like this bug: https://bugzilla.redhat.com/show_bug.cgi?id=695603 Akemi
May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
Hi all, I'm new t Scientific Linux but not to Linux, I'm trying SL because I'm looking for a RHEL 6 free distribution and at CentOS they are still working. I tried to install using SL-60-i386-2011-03-03-Everything-DVD1.iso into a VirtualBox virtual machine. I verified the ISO using sha256sum and also inside installer but it stops installing MAKEDEV claiming it is corrupted on DVD. I tried to download the same image using a different mirror (switch.ch) instead the main FTP site, and even a different PC but the same happened. I successfully installed using the Install DVD. I mounted the two ISO in loopback and check the content MAKEDEV rpm is present in the Everything DVD and not in the Install. I even don't understand why MAKEDEV is needed as SL use udev to populate /dev, so perhaps to disable the installation in Everything DVD would be the correct solution. Is this a known bug? I can do some more test if needed. Bye Stefano -- Stefano Canepa PENTA Engineering srl Via Passo Buole, 5 int.A 16152 Genova - Italy tel.: +39 010 6487183 Fax.: +39 010 6487171
Re: xrdb gone bad. xorg-x11-server-utils-7.1-5.el5_6.1 broken?
On 13/04/11 15:47, Alec T. Habig wrote: David M. Cooke writes: Several users started complaining today about various X apps, such as xterm and emacs, that no longer look the way they want. It looks like the resources they set in their .Xresources files are no longer set. Same in EL6. The changelog for this package says: * Wed Mar 16 2011 Adam Jacksona...@redhat.com 7.4-15.el6_0.1 - cve-2011-0465: Sanitize cpp macro expansion. (CVE 2011-0465) which sounds like something that could indeed break .Xresources parsing. Although in my case, not only old-style X apps lost their fonts marbles, but so did the KDE programs, menus, etc -- which I didn't think used the old-style X fonts at all. After wasting 15 minutes resetting fonts in many different places, X is usable again. I'm sure Murphy's Law says that this bug will be fixed tomorrow and we'll all have to re-reset things :) Thanks for your posts David and Alec. I thought I was losing my marbles when all my fonts went screwy on EL5/KDE so good to know the root cause.
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
On 04/13/2011 08:11 AM, Stefano Canepa wrote: Hi all, I'm new t Scientific Linux but not to Linux, I'm trying SL because I'm looking for a RHEL 6 free distribution and at CentOS they are still working. I tried to install using SL-60-i386-2011-03-03-Everything-DVD1.iso into a VirtualBox virtual machine. I verified the ISO using sha256sum and also inside installer but it stops installing MAKEDEV claiming it is corrupted on DVD. I tried to download the same image using a different mirror (switch.ch) instead the main FTP site, and even a different PC but the same happened. I successfully installed using the Install DVD. I mounted the two ISO in loopback and check the content MAKEDEV rpm is present in the Everything DVD and not in the Install. I even don't understand why MAKEDEV is needed as SL use udev to populate /dev, so perhaps to disable the installation in Everything DVD would be the correct solution. Is this a known bug? I can do some more test if needed. Bye Stefano Hi Stefano, Not to ask a too stupid question, but did you check your md5sums? b37209879c0fb158fac25045527241ee CentOS-5.6-x86_64-bin-DVD-1of2.iso 3eb277f8ca8d49cc8fcaf76d647169c4 CentOS-5.6-x86_64-bin-DVD-2of2.iso Also, I find in Virtual Box, that mounting the ISO's as a DVD/CD device works better than using a loop back device. From the Console, 1st: file, virtual media manager, attach your two iso's 2nd: go to the VM's icon, Settings, Storage, connect a IDE port to both ISO's Also, Virtual Box is riddled with bugs. Try posting on their forum and see if anyone else is having the problem. HTH, -T Stefano
SL vs. RPMForge repo
Hi, I've been a CentOS user for a few years, and I just decided to switch to SL. I installed it on two of my sandbox PCs in my office. First reaction : I like it a lot! I expect a few things to be different than CentOS, and maybe the odd rough edge here and there. First things first. Does the RPMForge third party repo work OK with SL ? Because I just configured it and tried a 'yum install mplayer' and got a load of Yum error messages about missing dependencies. I'm aware this question could possible (also?) belong on the RPMForge mailing list, though I'm not exactly sure. Which third party repo do you guys recommend? Cheers from the sunny South of France, Niki Kovacs -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32
Re: SL vs. RPMForge repo
On Wed, 13 Apr 2011, Nicolas Kovacs wrote: I've been a CentOS user for a few years, and I just decided to switch to SL. I installed it on two of my sandbox PCs in my office. First reaction : I like it a lot! I expect a few things to be different than CentOS, and maybe the odd rough edge here and there. First things first. Does the RPMForge third party repo work OK with SL ? Because I just configured it and tried a 'yum install mplayer' and got a load of Yum error messages about missing dependencies. I'm aware this question could possible (also?) belong on the RPMForge mailing list, though I'm not exactly sure. I would be interested to know what yum errors you got, and distribution/arch and other relevant information. :-) -- -- dag wieers, d...@wieers.com, http://dag.wieers.com/ -- dagit linux solutions, i...@dagit.net, http://dagit.net/ [Any errors in spelling, tact or fact are transmission errors]
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
Stefano Canepa wrote on 04/13/2011 11:11 AM: ... I tried to install using SL-60-i386-2011-03-03-Everything-DVD1.iso into a VirtualBox virtual machine. I verified the ISO using sha256sum and also inside installer but it stops installing MAKEDEV claiming it is corrupted on DVD. I have done multiple installs using the Everything ISOs mounted on the CD/DVD device on VirtualBox 4.0.4 without encountering any issues. What VB version are you using? Todd And Margo Chester wrote on 04/13/2011 02:30 PM: ... Also, Virtual Box is riddled with bugs. Can't say it is perfect, but riddled with bugs seems a bit exaggerated. My overall experiences with VB have been very positive. Phil
Re: SL vs. RPMForge repo
Nicolas Kovacs wrote on 04/13/2011 02:48 PM: I'm aware this question could possible (also?) belong on the RPMForge mailing list, though I'm not exactly sure. Did you install the rpmforge-release package provided by SL? Which third party repo do you guys recommend? This seems like a pretty decent set, although I would be careful about mixing: # yum groupinfo Yum Repositories Loaded plugins: priorities, refresh-packagekit Setting up Group Process Group: Yum Repositories Description: Various Yum Repositories. These are not supported by Scientific Linux but are here for your convenience. Optional Packages: adobe-release atrpms-repo elrepo-release epel-release rpmforge-release Personally ELRepo and RPMforge are my first choices, and I find Adobe is pretty safe. If I can't find what I'm looking for there I will venture (with extra caution) to EPEL and finally ATrpms. Phil
Re: SL vs. RPMForge repo
Le 13/04/2011 20:59, Dag Wieers a écrit : I would be interested to know what yum errors you got, and distribution/arch and other relevant information. :-) Here goes : # cat /etc/issue Scientific Linux release 6.0 (Carbon) # yum repolist repo id repo name status rpmforgeRHEL 6.0 - RPMforge.net - 3 793 sl Scientific Linux 6.0 -2 969 sl-security Scientific Linux 6.0 - updates 552 # yum install mplayer ... -- Finished Dependency Resolution Error: Package: mplayer-1.0-0.46.svn20100703.el6.rf.i686 (rpmforge) Requires: libesd.so.0 Error: Package: dirac-1.0.2-1.el6.rf.i686 (rpmforge) Requires: libcppunit-1.12.so.1 Error: Package: libcaca-0.99-0.1.beta17.el6.rf.i686 (rpmforge) Requires: libglut.so.3 Error: Package: mpg123-1.13.2-1.el6.rf.i686 (rpmforge) Requires: libesd.so.0 Error: Package: mplayer-1.0-0.46.svn20100703.el6.rf.i686 (rpmforge) Requires: liblzo2.so.2 You could try using --skip-broken to work around the problem Any suggestion ? Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
On 04/13/2011 12:38 PM, Phil Schaffner wrote: Can't say it is perfect, but riddled with bugs seems a bit exaggerated. My overall experiences with VB have been very positive. Phil Not exaggerated. Years of pain and experience. Wait until you get your job threatened over it. Fortunately, as a consultant, they are not my only customer. If loose them, I will have to hustle and find someone else. Still sucks though, especially when you have worked for them for over ten years and you have become friends with many of them. -T A collection of some of my recent bug reports. http://www.virtualbox.org/ticket/7628 http://www.virtualbox.org/ticket/7643 http://www.virtualbox.org/ticket/7607 http://www.virtualbox.org/ticket/7948 http://www.virtualbox.org/ticket/7957 http://www.virtualbox.org/ticket/7772 And the one I almost got and still may get fired over: http://www.virtualbox.org/ticket/8478
Re: SL vs. RPMForge repo
On 04/13/2011 01:00 PM, Phil Schaffner wrote: Nicolas Kovacs wrote on 04/13/2011 02:48 PM: I'm aware this question could possible (also?) belong on the RPMForge mailing list, though I'm not exactly sure. Did you install the rpmforge-release package provided by SL? Which third party repo do you guys recommend? This seems like a pretty decent set, although I would be careful about mixing: # yum groupinfo Yum Repositories Loaded plugins: priorities, refresh-packagekit Setting up Group Process Group: Yum Repositories Description: Various Yum Repositories. These are not supported by Scientific Linux but are here for your convenience. Optional Packages: adobe-release atrpms-repo elrepo-release epel-release rpmforge-release Personally ELRepo and RPMforge are my first choices, and I find Adobe is pretty safe. If I can't find what I'm looking for there I will venture (with extra caution) to EPEL and finally ATrpms. Phil What a sweet command. I have a bare SL6 (init 3) in my shop I was about to go looking for repos for and this solves the problem of no browser. On a hunch, I tried this over on CentOS and it bombed. For what it is worth, nvidia drivers a a big deal from me and they are found in ELRepo. -T
Re: SL vs. RPMForge repo
Le 13/04/2011 22:33, Dag Wieers a écrit : These requirements are all SL 6.0 packages, so I assume there's something wrong with your yum configuration. [dag@moria ~]# rpm -qf /usr/lib64/libesd.so.0 esound-libs-0.2.41-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libcppunit-1.12.so.1 cppunit-1.12.1-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libglut.so.3 freeglut-2.6.0-1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/liblzo2.so.2 lzo-2.03-3.1.el6.x86_64 I would start by cleaning the cache: yum clean all Heh, I just found out. I live in a remote village with a slow DSL connection, and with CentOS, my first reflex always was to copy the content of the install DVD to a web server in my local network to make a local repository, and then configure Yum to point to that repo. Which made me wonder if the SL install DVD contained everything there is. Indeed... not :o) Reconfigured Yum to point to a standard SL repo on the Internet, and everything worked out fine. Cheers and thanks for the help. Niki PS: SL rocks! -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32
Re: SL vs. RPMForge repo
On Wed, 13 Apr 2011, Nicolas Kovacs wrote: Le 13/04/2011 22:33, Dag Wieers a =E9crit : These requirements are all SL 6.0 packages, so I assume there's something wrong with your yum configuration. [dag@moria ~]# rpm -qf /usr/lib64/libesd.so.0 esound-libs-0.2.41-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libcppunit-1.12.so.1 cppunit-1.12.1-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libglut.so.3 freeglut-2.6.0-1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/liblzo2.so.2 lzo-2.03-3.1.el6.x86_64 I would start by cleaning the cache: yum clean all Heh, I just found out. I live in a remote village with a slow DSL=20 connection, and with CentOS, my first reflex always was to copy the=20 content of the install DVD to a web server in my local network to make a=20 local repository, and then configure Yum to point to that repo. Which=20 made me wonder if the SL install DVD contained everything there is. There are 2 different DVD sets. One with install in the name which is a subset and with everything in the name which is all of it. -Connie Sieh Indeed... not :o) Reconfigured Yum to point to a standard SL repo on the Internet, and=20 everything worked out fine. Cheers and thanks for the help. Niki PS: SL rocks! --=20 Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'=E9glise - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr T=E9l. : 04 66 63 10 32
Re: SL vs. RPMForge repo
On Wed, Apr 13, 2011 at 4:42 PM, Nicolas Kovacs i...@microlinux.fr wrote: Le 13/04/2011 22:33, Dag Wieers a écrit : These requirements are all SL 6.0 packages, so I assume there's something wrong with your yum configuration. [dag@moria ~]# rpm -qf /usr/lib64/libesd.so.0 esound-libs-0.2.41-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libcppunit-1.12.so.1 cppunit-1.12.1-3.1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/libglut.so.3 freeglut-2.6.0-1.el6.x86_64 [dag@moria ~]# rpm -qf /usr/lib64/liblzo2.so.2 lzo-2.03-3.1.el6.x86_64 I would start by cleaning the cache: yum clean all Heh, I just found out. I live in a remote village with a slow DSL connection, and with CentOS, my first reflex always was to copy the content of the install DVD to a web server in my local network to make a local repository, and then configure Yum to point to that repo. Which made me wonder if the SL install DVD contained everything there is. Indeed... not :o) Reconfigured Yum to point to a standard SL repo on the Internet, and everything worked out fine. Our favorite upstream vendor has the same issues. Bulky materials on the DVD seem to have blocked the inclusion of some utilities, such as audiofile-devel on the upstream vendor's installation media. It requires registered client access to get that. Drove me *nuts* to get nx recompiled. (It's available over at CentOS, along with my updated SL 6.0 .spec file on their bugizilla.) For SL, I'd suggest grabbing the DVD images with Bittorrent, depositing them in a local repository, then adding the external repository as a separate target to be able to grab the local components first. Properly configured, this can seriously localize bandwidth use and profoundly speed system installation and mock setups for package building. Cheers and thanks for the help. Niki PS: SL rocks! Yeah, I just hopped over from CentOS due to the delays in release and the invisibility of the build process there. I'm pretty happy with SL 6.0.
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
On Wed, Apr 13, 2011 at 4:08 PM, Todd And Margo Chester toddandma...@gmail.com wrote: On 04/13/2011 12:38 PM, Phil Schaffner wrote: Can't say it is perfect, but riddled with bugs seems a bit exaggerated. My overall experiences with VB have been very positive. Phil Not exaggerated. Years of pain and experience. Wait until you get your job threatened over it. Fortunately, as a consultant, they are not my only customer. If loose them, I will have to hustle and find someone else. Still sucks though, especially when you have worked for them for over ten years and you have become friends with many of them. -T A collection of some of my recent bug reports. http://www.virtualbox.org/ticket/7628 http://www.virtualbox.org/ticket/7643 http://www.virtualbox.org/ticket/7607 http://www.virtualbox.org/ticket/7948 http://www.virtualbox.org/ticket/7957 http://www.virtualbox.org/ticket/7772 And the one I almost got and still may get fired over: http://www.virtualbox.org/ticket/8478 These all seem to be version 3.x of VirtualBox, and with Windows guest operating systems. From your comments in them, it looks like you've been using Windows Terminal Servers. Do you have a support contract with Oracle? If not, for production servers, I'm afraid you really need one. Scientific Linux, and the various Red Hat based distributions, have been rock stable under VirtualBox for me for the last year. I'm quite pleased with it. The only reason I'd use VMWare is for LabManager or to virtualize SCO OpenServer (which I've had to do). I still avoid KVM where feasible, even under Red Hat or Scientific Linux 6.0. I still find the necessary bridge network manual configuraiton to be nutty for a production server, and the libvirt tools to be a poorly planned nad implemented attempt to merge distinct and incompatible virtualizaiton tools into a single interface. Give me the clean VirtualBox interface any day.
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
On 04/13/2011 07:35 PM, Nico Kadel-Garcia wrote: On Wed, Apr 13, 2011 at 4:08 PM, Todd And Margo Chester toddandma...@gmail.com wrote: On 04/13/2011 12:38 PM, Phil Schaffner wrote: Can't say it is perfect, but riddled with bugs seems a bit exaggerated. My overall experiences with VB have been very positive. Phil Not exaggerated. Years of pain and experience. Wait until you get your job threatened over it. Fortunately, as a consultant, they are not my only customer. If loose them, I will have to hustle and find someone else. Still sucks though, especially when you have worked for them for over ten years and you have become friends with many of them. -T A collection of some of my recent bug reports. http://www.virtualbox.org/ticket/7628 http://www.virtualbox.org/ticket/7643 http://www.virtualbox.org/ticket/7607 http://www.virtualbox.org/ticket/7948 http://www.virtualbox.org/ticket/7957 http://www.virtualbox.org/ticket/7772 And the one I almost got and still may get fired over: http://www.virtualbox.org/ticket/8478 These all seem to be version 3.x of VirtualBox, and with Windows guest operating systems. From your comments in them, it looks like you've been using Windows Terminal Servers. Yes it is Terminal Services (TS) most of the time. TS is a mess I would not wish on anyone. Windows is an unfortunate fact of my life. The only Linux customers I have are the ones I make myself. I have to eat, so I have to work on Windows. I wish I had more Linux customers, but if I want to make a living, I have to work on what my customer actually use. I tried VB 4.0.x, but it was so much slower that 3.2.12 with my XP guest that I ripped it back off and replaced it with 3.2.12. I will be trying KVM on a new server to see how it fares. Do you have a support contract with Oracle? If not, for production servers, I'm afraid you really need one. You are correct about the need. Unfortunately, Oracle does not offer support contracts on Virtual Box. You can not even purchase a single incident. Oracle's left hand does not know what their right hand is doing. I have spent endless hour with Oracle on the phone trying to get help. All I get it business psycobabble (they will reach out to me). Scientific Linux, and the various Red Hat based distributions, have been rock stable under VirtualBox for me for the last year. I'm quite pleased with it. The only reason I'd use VMWare is for LabManager or to virtualize SCO OpenServer (which I've had to do). I run Virtual Box under CentOS 5.5 hosts. Mostly x64 bit. I still avoid KVM where feasible, even under Red Hat or Scientific Linux 6.0. I still find the necessary bridge network manual configuraiton to be nutty for a production server, and the libvirt tools to be a poorly planned nad implemented attempt to merge distinct and incompatible virtualizaiton tools into a single interface. Give me the clean VirtualBox interface any day. I have heard that VB's interface is better. I have also heard that Red Hat is cleaning up theirs. I will see. VB use to use the same bridge networking. I do believe I kept a copy of it around somewhere. It would be nice if KVM handled bridge networking automatically the way VB does. I will suffer a difficult interface for fewer bugs in operation. -T
Re: May be a bug in SL-60-i386-2011-03-03-Everything-DVD1.iso
On Wed, Apr 13, 2011 at 11:58 PM, Todd And Margo Chester toddandma...@gmail.com wrote: I tried VB 4.0.x, but it was so much slower that 3.2.12 with my XP guest that I ripped it back off and replaced it with 3.2.12. I will be trying KVM on a new server to see how it fares. You need to go *straight* to VMWare. Do not stop at Xen, do not stop at KVM. Go right to commercial grade support, and install an ESX server if you can.
Re: SL vs. RPMForge repo
Le 14/04/2011 03:39, Nico Kadel-Garcia a écrit : Yeah, I just hopped over from CentOS due to the delays in release and the invisibility of the build process there. I'm pretty happy with SL 6.0. +1. Quite some familiar names around this mailing list. As far as I'm concerned, I expected some sort of refugee camp, and I'm the more pleasantly surprised to find it's a four star hotel. Less than 24 hours with SL, and it looks like I'm going to stick with it. I just discovered that the text-based version of Anaconda has been seriously amputated in functionality. But that's probably an upstream decision. Plus, I wonder why I can't install SL6 on my good old Fujitsu Lifebook with a Pentium M processor, which the installer kernel refuses to work with. Any know workaround for that apart from installing SL 5.x or buying a new laptop? Cheers, Niki -- Microlinux - Solutions informatiques 100% Linux et logiciels libres 7, place de l'église - 30730 Montpezat Web : http://www.microlinux.fr Mail : i...@microlinux.fr Tél. : 04 66 63 10 32
