Re: SL vs. RPMForge repo
On Wed, 18 May 2011, Akemi Yagi wrote: On Wed, May 18, 2011 at 8:53 AM, Orion Poplawski or...@cora.nwra.com wrote: RPMforge now offers two repos - [rpmforge] and [rpmforge-extras]. Packages in [rpmforge] will not have conflict with the distro ones whereas those in [rpmforge-extras] may overwrite distro files. AH yes, forgot about that. I guess the packages it is wanting to replace on my machine mostly come from EPEL, not the SL repositories. But there is one: # yum list environment-modules Loaded plugins: downloadonly Installed Packages environment-modules.x86_64 3.2.7b-6.el6 @anaconda-ScientificLinux-201102250955.x86_64 Available Packages environment-modules.x86_64 3.2.8a-1.el6.rf rpmforge That one must have been missed. I will let Dag know. Thanks for reporting. Yes, thanks for reporting ! I fixed it yesterday by moving this package to RPMforge-extras. When we started building RHEL6 packages last year, we did a large effort to find those duplicate packages, also for older distributions. The environment-modules RPM is a newly introduced package (I presume for RHEL5 only) and we obviously did not verify if it was already in RHEL6. There's more than one issue here: - if a package is introduced for RHEL5, we need to check if it is needed for RHEL6 and if there's a need to have a different version there. - we should avoid releasing a newer package in RHEL5 than is available in upstream RHEL6. It's often better to backport the RHEL6 package to RHEL5. - we need a (preferably) automated check to avoid this in the future. It would be nice if the packager could easily check before doing any effort at all, but as a last resort the buildsystem should refuse by default. (It's easier to automate on the buildsystem side as a DAR plugin, even when it's still bash :-/) So I am sorry for this mishap, I hope we can avoid it in the future. -- -- 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: SL vs. RPMForge repo
On Thu, May 19, 2011 at 6:05 AM, Dag Wieers d...@wieers.com wrote: On Wed, 18 May 2011, Akemi Yagi wrote: On Wed, May 18, 2011 at 8:53 AM, Orion Poplawski or...@cora.nwra.com wrote: RPMforge now offers two repos - [rpmforge] and [rpmforge-extras]. Packages in [rpmforge] will not have conflict with the distro ones whereas those in [rpmforge-extras] may overwrite distro files. AH yes, forgot about that. I guess the packages it is wanting to replace on my machine mostly come from EPEL, not the SL repositories. But there is one: # yum list environment-modules Loaded plugins: downloadonly Installed Packages environment-modules.x86_64 3.2.7b-6.el6 @anaconda-ScientificLinux-201102250955.x86_64 Available Packages environment-modules.x86_64 3.2.8a-1.el6.rf rpmforge That one must have been missed. I will let Dag know. Thanks for reporting. Yes, thanks for reporting ! I fixed it yesterday by moving this package to RPMforge-extras. When we started building RHEL6 packages last year, we did a large effort to find those duplicate packages, also for older distributions. The environment-modules RPM is a newly introduced package (I presume for RHEL5 only) and we obviously did not verify if it was already in RHEL6. Hi, Dag!! Nice to see you over here. There's also stil the ongoing boobytrap for RHEL and SL before version 6.x: They built, and provided, and installed, both i386 and x86_64 versions in the main x86_64 repository of many packages such as Subversion. So does EPEL. RPMforge does not, and in fact, *building* Subversion for i386 under x86_64 architecutre was a real pain in the neck: I threw in the towel on it. The result was that upgrading Subversion for x86_64 from RPMforge got... tricky if you didn't manually rip out the i386 packages before updating to RPMforge's version (of which I posted .spec files for a few releases). RHEL and SL 6 now install only the best architectural fit, by default, which was an excellent move and avoids this issue. There's more than one issue here: - if a package is introduced for RHEL5, we need to check if it is needed for RHEL6 and if there's a need to have a different version there. - we should avoid releasing a newer package in RHEL5 than is available in upstream RHEL6. It's often better to backport the RHEL6 package to RHEL5. Subversion is one of these. The continuing updates from RPMforge are welcome, RHEL's upstream version is going to continue to lag, especially after Subversion 1.7 comes out. - we need a (preferably) automated check to avoid this in the future. It would be nice if the packager could easily check before doing any effort at all, but as a last resort the buildsystem should refuse by default. (It's easier to automate on the buildsystem side as a DAR plugin, even when it's still bash :-/) So I am sorry for this mishap, I hope we can avoid it in the future. And this sort of thing is why RPMforge is so respected. When an issue pops up, it gets fixed *FAST*.
Re: SL vs. RPMForge repo
On 04/13/2011 02:00 PM, Phil Schaffner wrote: 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 Just curious - why do you feel the need to treat EPEL with extra caution? I happen to have reversed feeling about EPEL/RPMforge. I note that out of the box RPMforge will replace some system packages (perhaps without any problems), something EPEL avoids. -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: SL vs. RPMForge repo
On Wed, May 18, 2011 at 8:34 AM, Orion Poplawski or...@cora.nwra.com wrote: I note that out of the box RPMforge will replace some system packages (perhaps without any problems), something EPEL avoids. Not any more. :-) RPMforge now offers two repos - [rpmforge] and [rpmforge-extras]. Packages in [rpmforge] will not have conflict with the distro ones whereas those in [rpmforge-extras] may overwrite distro files. Akemi
Re: SL vs. RPMForge repo
On Wed, 2011-05-18 at 09:34 -0600, Orion Poplawski wrote: On 04/13/2011 02:00 PM, Phil Schaffner wrote: 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 Just curious - why do you feel the need to treat EPEL with extra caution? I happen to have reversed feeling about EPEL/RPMforge. I note that out of the box RPMforge will replace some system packages (perhaps without any problems), something EPEL avoids. Sounds like you need to update rpmforge-release. The default RPMforge repository does not replace any CentOS base packages. In the past it used to, but those packages are now in a separate repository (rpmforge-extras) which is disabled by default. http://wiki.centos.org/AdditionalResources/Repositories/RPMForge Steve
Re: SL vs. RPMForge repo
On 05/18/2011 09:40 AM, Akemi Yagi wrote: On Wed, May 18, 2011 at 8:34 AM, Orion Poplawskior...@cora.nwra.com wrote: I note that out of the box RPMforge will replace some system packages (perhaps without any problems), something EPEL avoids. Not any more. :-) RPMforge now offers two repos - [rpmforge] and [rpmforge-extras]. Packages in [rpmforge] will not have conflict with the distro ones whereas those in [rpmforge-extras] may overwrite distro files. Akemi AH yes, forgot about that. I guess the packages it is wanting to replace on my machine mostly come from EPEL, not the SL repositories. But there is one: # yum list environment-modules Loaded plugins: downloadonly Installed Packages environment-modules.x86_64 3.2.7b-6.el6 @anaconda-ScientificLinux-201102250955.x86_64 Available Packages environment-modules.x86_64 3.2.8a-1.el6.rf rpmforge -- Orion Poplawski Technical Manager 303-415-9701 x222 NWRA/CoRA DivisionFAX: 303-415-9702 3380 Mitchell Lane or...@cora.nwra.com Boulder, CO 80301 http://www.cora.nwra.com
Re: SL vs. RPMForge repo
On Wed, 18 May 2011, Orion Poplawski wrote: On 04/13/2011 02:00 PM, Phil Schaffner wrote: 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 Just curious - why do you feel the need to treat EPEL with extra caution? I happen to have reversed feeling about EPEL/RPMforge. I note that out of the box RPMforge will replace some system packages (perhaps without any problems), something EPEL avoids. I believe that RPMForge does not do this in SL6 - they have split there stuff into two repos - rpmforge and rpmforge-extras one which updates existing SL packages and one with only new packages. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge a.c.aitchi...@dpmms.cam.ac.uk http://www.dpmms.cam.ac.uk/~werdna
Re: SL vs. RPMForge repo
On Wed, May 18, 2011 at 8:53 AM, Orion Poplawski or...@cora.nwra.com wrote: RPMforge now offers two repos - [rpmforge] and [rpmforge-extras]. Packages in [rpmforge] will not have conflict with the distro ones whereas those in [rpmforge-extras] may overwrite distro files. Akemi AH yes, forgot about that. I guess the packages it is wanting to replace on my machine mostly come from EPEL, not the SL repositories. But there is one: # yum list environment-modules Loaded plugins: downloadonly Installed Packages environment-modules.x86_64 3.2.7b-6.el6 @anaconda-ScientificLinux-201102250955.x86_64 Available Packages environment-modules.x86_64 3.2.8a-1.el6.rf rpmforge That one must have been missed. I will let Dag know. Thanks for reporting. Akemi
Re: SL vs. RPMForge repo
On 18 May 2011, at 18:00, Dr Andrew C Aitchison wrote: On Wed, 18 May 2011, Orion Poplawski wrote: On 04/13/2011 02:00 PM, Phil Schaffner wrote: 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 Just curious - why do you feel the need to treat EPEL with extra caution? I happen to have reversed feeling about EPEL/RPMforge. I note that out of the box RPMforge will replace some system packages (perhaps without any problems), something EPEL avoids. I believe that RPMForge does not do this in SL6 - they have split there stuff into two repos - rpmforge and rpmforge-extras one which updates existing SL packages and one with only new packages. This is good news indeed. In any case, there is always the option of using the yum-protectbase and/or yum-priorities plugins to prevent external repos from overriding the core OS ones. Cheers, Sergio -- Sergio Ballestrero - http://physics.uj.ac.za/psiwiki/Ballestrero University of Johannesburg, Physics Department ATLAS TDAQ sysadmin group - Office:75282 OnCall:164851
Re: SL vs. RPMForge repo
On 04/15/2011 08:02 PM, Lamar Owen wrote: On Friday, April 15, 2011 11:47:07 AM you wrote: Phil In looking into the background of non-pae c pu's this seems an issue for mobile processors Pentium M based 400mhz FSB and before. One wouldn't think that there were this many devices out there still kicking, but I guess I am wrong. Heh, I have Pentium II's, III's, and even a couple of Pentium Pro's still in production, in addition to a dozen or so Pentium M laptops (unsure of FSB, but these laptops are probably PAE-capable); also several Pentium III and 4 laptops. If it works, and does the job reliably. On the non-linux side, have a VAXstation 4000 still up, controlling a heavily modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even though it weighs 7,000+ pounds avoirdupois. Is it something like this? http://www.astro.virginia.edu/~srm4n/engines/PDSMicro.html Vaclav M.
[OT] GAMMA (was:Re: [SPAM] ** Re: SL vs. RPMForge repo)
On Saturday, April 16, 2011 12:24:17 PM you wrote: On 04/15/2011 08:02 PM, Lamar Owen wrote: On the non-linux side, have a VAXstation 4000 still up, controlling a heavily modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even though it weighs 7,000+ pounds avoirdupois. Is it something like this? http://www.astro.virginia.edu/~srm4n/engines/PDSMicro.html Yes, but overhauled. The left hand image in the top of that page looks like the two GAMMAs we have (Guide star Automated Measuring MAchine). Hmmm, see http://www.pari.edu/library/apda/rooms/ down close to the bottom of the page.
Re: SL vs. RPMForge repo
Le 15/04/2011 00:48, Dag Wieers a écrit : Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful... Yes, I do have a clear need for this. My company is specialized in providing Linux solutions for professionals (mostly small town halls, schools, public libraries). From time to time, I give one of the various consumer grade distros a spin, but I always seem to come back to some RHEL clone on desktops as well as on servers. More often than not, I have to perform installs on hardware that's quite old, if not completely outdated. The sort of dinosaur hardware that nothing - short of a meteor strike - can kill. CentOS 5 is still churning away on one of my client's PIII-500 with 128 MB RAM (recently beefed up to 256 MB). Of course, most of the time, folks ask for decent hardware. But I like to still be able to install a decent system on older hardware. Cheers from the sunny South of France, 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: SL vs. RPMForge repo
It appears that not all Pentium M CPUs are created equal. I have SL6 installed in a dual boot config w/WinXP on my Dell Latitude D610 w/a Pentium M, 1.86GHz (x86 Family 6 Model 13 Stepping 8). A check with Auslogics' System Information analyzer indicates that it supports PAE. If the limitations of the current 32-bit kernel are spelled out and posted, at least folks would have a heads up for potential roadblocks. -- Jon On 14 Apr 2011 at 19:50, Phil Schaffner wrote: [snip] My non-PAE-capable IBM T42p Pentium-M laptop is dead ATM from a fan failure, but the possibility of a compatible SL6 release might prompt me to resurrect it. Part of the reason I have not bothered to hack the hardware is the upstream decision to drop support for non-PAE 32-bit systems. As a matter of principle I heartily endorse the idea. There is a lot of functional hardware out there that does not do PAE, but still has life left in it. Phil
Re: SL vs. RPMForge repo
I would like to see this - I very much doubt that all my non-PAE hardware will go away by the time I want to have switched to SL6. thanks! -- Steve Gaarder System Administrator, Dept of Mathematics Cornell University, Ithaca, NY, USA gaar...@math.cornell.edu On Fri, 15 Apr 2011, Dag Wieers wrote: There might be a case for a drop-in replacement kernel that supports non-PAE 32bit systems. So at least a PXE/USB installation works fine, without the need to respin the ISO (which may be too troublesome). Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful...
Re: SL vs. RPMForge repo
- Original Message - From: Jon Sent: 04/15/11 11:21 AM To: SCIENTIFIC-LINUX-USERS@LISTSERV.FNAL.GOV Subject: Re: SL vs. RPMForge repo It appears that not all Pentium M CPUs are created equal. I have SL6 installed in a dual boot config w/WinXP on my Dell Latitude D610 w/a Pentium M, 1.86GHz (x86 Family 6 Model 13 Stepping 8). A check with Auslogics' System Information analyzer indicates that it supports PAE. If the limitations of the current 32-bit kernel are spelled out and posted, at least folks would have a heads up for potential roadblocks. -- Jon On 14 Apr 2011 at 19:50, Phil Schaffner wrote: [snip] My non-PAE-capable IBM T42p Pentium-M laptop is dead ATM from a fan failure, but the possibility of a compatible SL6 release might prompt me to resurrect it. Part of the reason I have not bothered to hack the hardware is the upstream decision to drop support for non-PAE 32-bit systems. As a matter of principle I heartily endorse the idea. There is a lot of functional hardware out there that does not do PAE, but still has life left in it. Phil In looking into the background of non-pae c pu's this seems an issue for mobile processors Pentium M based 400mhz FSB and before. One wouldn't think that there were this many devices out there still kicking, but I guess I am wrong. --- Dan :w! saves
Re: SL vs. RPMForge repo
On Friday, April 15, 2011 11:47:07 AM you wrote: Phil In looking into the background of non-pae c pu's this seems an issue for mobile processors Pentium M based 400mhz FSB and before. One wouldn't think that there were this many devices out there still kicking, but I guess I am wrong. Heh, I have Pentium II's, III's, and even a couple of Pentium Pro's still in production, in addition to a dozen or so Pentium M laptops (unsure of FSB, but these laptops are probably PAE-capable); also several Pentium III and 4 laptops. If it works, and does the job reliably. On the non-linux side, have a VAXstation 4000 still up, controlling a heavily modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even though it weighs 7,000+ pounds avoirdupois.
Re: SL vs. RPMForge repo
On Fri, Apr 15, 2011 at 12:02 PM, Lamar Owen lo...@pari.edu wrote: On the non-linux side, have a VAXstation 4000 still up, controlling a heavily modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even though it weighs 7,000+ pounds avoirdupois. Wow, the VAX machine I had access to was retired 20 years ago ... Akemi
RE: SL vs. RPMForge repo
owner-scientific-linux-us...@listserv.fnal.gov wrote: On 14 April 2011 23:48, Dag Wieers d...@wieers.com wrote: On Thu, 14 Apr 2011, Alan Bartlett wrote: I believe that processor does not support PAE, so you are out of luck. Again, this is a Red Hat decision. The EL6 32-bit kernel is what was a PAE kernel for EL5. Putting it another way, the EL5 32-bit non-PAE kernel has been dropped for EL6 and so what would known as a PAE kernel has had that descriptor removed. There might be a case for a drop-in replacement kernel that supports non-PAE 32bit systems. So at least a PXE/USB installation works fine, without the need to respin the ISO (which may be too troublesome). Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful... You've obviously had similar thoughts just like mine . . . but have developed them that bit further. It really depends upon the need for non-PAE 32-bit kernels for EL6. Alan. All my field hardware is non-PAE (AMD Geode LX800 = -march=586); as are many, if not most embedded and/or low-power targets. I'm running RH7.3 (pre-Fedora) because I need to hack the kernel source to support legacy hardware. I would like (greatly) to see a non-PAE 32-bit 586-aware kernel available, and to be able to yum install full-kernel-source Insert spiffy .sig here: Life is complex: it has both real and imaginary parts. //me *** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept for the presence of computer viruses. www.Hubbell.com - Hubbell Incorporated**
Re: SL vs. RPMForge repo
On 15 April 2011 20:02, Lamar Owen lo...@pari.edu wrote: On the non-linux side, have a VAXstation 4000 still up, controlling a heavily modified Perkin-Elmer PDS-2020 microdensitometer..aka 'a scanner' even though it weighs 7,000+ pounds avoirdupois. Cowabunga! That brings back memories! Alan.
Re: SL vs. RPMForge repo
On 15 April 2011 20:37, Brunner, Brian T. bbrun...@gai-tronics.com wrote: All my field hardware is non-PAE (AMD Geode LX800 = -march=586); as are many, if not most embedded and/or low-power targets. I'm running RH7.3 (pre-Fedora) because I need to hack the kernel source to support legacy hardware. I still have my RH9 installation disks but no longer run the OS. Being a person who is loath to make change just for the sake of it, my pathway to the present was RH9 --- EL5 --- EL6. I would like (greatly) to see a non-PAE 32-bit 586-aware kernel available, and to be able to yum install full-kernel-source The wish list gets longer! Can I just clarify that Dag and I were musing about a non-PAE 32-bit i686 kernel for SL6 . . . i586 may be possible. Alan.
Re: SL vs. RPMForge repo
On 14 April 2011 05:49, Nicolas Kovacs i...@microlinux.fr wrote: Quite some familiar names around this mailing list. Smiles. I just discovered that the text-based version of Anaconda has been seriously amputated in functionality. But that's probably an upstream decision. Correct. 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. I believe that processor does not support PAE, so you are out of luck. Again, this is a Red Hat decision. The EL6 32-bit kernel is what was a PAE kernel for EL5. Putting it another way, the EL5 32-bit non-PAE kernel has been dropped for EL6 and so what would known as a PAE kernel has had that descriptor removed. Alan.
Re: SL vs. RPMForge repo
On 04/14/2011 05:49 AM, Nicolas Kovacs wrote: 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. If you need the text mode for a remote installation, you can run vnc server and install it with Anaconda. 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
Re: SL vs. RPMForge repo
On Thu, 14 Apr 2011, Alan Bartlett wrote: On 14 April 2011 05:49, Nicolas Kovacs i...@microlinux.fr wrote: Quite some familiar names around this mailing list. Smiles. I just discovered that the text-based version of Anaconda has been seriously amputated in functionality. But that's probably an upstream decision. Correct. 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. I believe that processor does not support PAE, so you are out of luck. Again, this is a Red Hat decision. The EL6 32-bit kernel is what was a PAE kernel for EL5. Putting it another way, the EL5 32-bit non-PAE kernel has been dropped for EL6 and so what would known as a PAE kernel has had that descriptor removed. There might be a case for a drop-in replacement kernel that supports non-PAE 32bit systems. So at least a PXE/USB installation works fine, without the need to respin the ISO (which may be too troublesome). Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful... -- -- 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: SL vs. RPMForge repo
On 14 April 2011 23:48, Dag Wieers d...@wieers.com wrote: On Thu, 14 Apr 2011, Alan Bartlett wrote: On 14 April 2011 05:49, Nicolas Kovacs i...@microlinux.fr wrote: 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. I believe that processor does not support PAE, so you are out of luck. Again, this is a Red Hat decision. The EL6 32-bit kernel is what was a PAE kernel for EL5. Putting it another way, the EL5 32-bit non-PAE kernel has been dropped for EL6 and so what would known as a PAE kernel has had that descriptor removed. There might be a case for a drop-in replacement kernel that supports non-PAE 32bit systems. So at least a PXE/USB installation works fine, without the need to respin the ISO (which may be too troublesome). Of course, that would also mean we'd have to update that non-PAE kernel as part of that repository. If people have a clear need for this (and there is at least one committed to support this) do speak up. It might be the beginning of something beautiful... You've obviously had similar thoughts just like mine . . . but have developed them that bit further. It really depends upon the need for non-PAE 32-bit kernels for EL6. Alan.
Re: SL vs. RPMForge repo
Alan Bartlett wrote on 04/14/2011 06:55 PM: ... You've obviously had similar thoughts just like mine . . . but have developed them that bit further. It really depends upon the need for non-PAE 32-bit kernels for EL6. My non-PAE-capable IBM T42p Pentium-M laptop is dead ATM from a fan failure, but the possibility of a compatible SL6 release might prompt me to resurrect it. Part of the reason I have not bothered to hack the hardware is the upstream decision to drop support for non-PAE 32-bit systems. As a matter of principle I heartily endorse the idea. There is a lot of functional hardware out there that does not do PAE, but still has life left in it. Phil
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: 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: 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: 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
