Just my luck, None of my CentOS systems or my Fedora systems can #yum groupinstall "Development Tools" "Development Libraries"? Both are having dep issues? Is that a coincidence, or what's going on?
The CentOS boxes all complain:
--> Processing Dependency: glibc-common = 2.5-18.el5_1.1 for package: glibc Error: No Package Matching glibc.i686
jlc
On Thu, Aug 21, 2008 at 10:26 PM, Joseph L. Casale JCasale@activenetwerx.com wrote:
Just my luck, None of my CentOS systems or my Fedora systems can #yum groupinstall "Development Tools" "Development Libraries"? Both are having dep issues? Is that a coincidence, or what's going on?
The CentOS boxes all complain:
--> Processing Dependency: glibc-common = 2.5-18.el5_1.1 for package: glibc Error: No Package Matching glibc.i686
There are two times when this becomes an issue. One is on x86_64 systems where build deps can cross architectures, and the other is when using systems like openvz/virtuozzo where the glibc is often replaced or otherwise lobotomized.
Which one is yours?
There are two times when this becomes an issue. One is on x86_64 systems where build deps can cross architectures, and the other is when using systems like openvz/virtuozzo where the glibc is often replaced or otherwise lobotomized.
Which one is yours?
Ahh, all the CentOS boxes are either x64 Xen Dom0 or U... What happens to glibc on these, especially in the Dom0 case where I hand installed the xen rpm's and glibc wasn't touched after initial update?
I assume the x86 non virt FC9 box is a coincidence.
Thanks! jlc
On Thu, Aug 21, 2008 at 10:45 PM, Joseph L. Casale JCasale@activenetwerx.com wrote:
There are two times when this becomes an issue. One is on x86_64 systems where build deps can cross architectures, and the other is when using systems like openvz/virtuozzo where the glibc is often replaced or otherwise lobotomized.
Which one is yours?
Ahh, all the CentOS boxes are either x64 Xen Dom0 or U... What happens to glibc on these, especially in the Dom0 case where I hand installed the xen rpm's and glibc wasn't touched after initial update?
which xen rpms did you install? The ones from centos, or the ones from xensource?
Generally when building for x86_64, it's best to remove all traces of x86 packages on the system. If you're doing some cross-compiling (building x86 on x86_64) then it's far easier to use a build utility like mock which creates your environment for you in a separate area. While it requires a bunch more space, it produces 'clean' rpms which are untainted by any strays packages or source installed bits you may have on the system.
which xen rpms did you install? The ones from centos, or the ones from xensource?
Rolled my own from the 3.2.0 srpm.
Generally when building for x86_64, it's best to remove all traces of x86 packages on the system.
How do you do this at install? Wouldn't that be cleaner? I suppose a rpm command with a --queryformat ARCH string would list all that is x86 and I couild pipe that into a remove command? Any ideas on how to do this cleanly?
If you're doing some cross-compiling (building x86 on x86_64) then it's far easier to use a build utility like mock which creates your environment for you in a separate area. While it requires a bunch more space, it produces 'clean' rpms which are untainted by any strays packages or source installed bits you may have on the system.
I have to learn more about mock, I just a trivial build root...
Thanks! jlc
On Fri, Aug 22, 2008 at 9:02 AM, Joseph L. Casale JCasale@activenetwerx.com wrote:
which xen rpms did you install? The ones from centos, or the ones from xensource?
Rolled my own from the 3.2.0 srpm.
Generally when building for x86_64, it's best to remove all traces of x86 packages on the system.
How do you do this at install? Wouldn't that be cleaner? I suppose a rpm command with a --queryformat ARCH string would list all that is x86 and I couild pipe that into a remove command? Any ideas on how to do this cleanly?
First inspect what i386 packages are on your system:
rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" | grep i386
If you are sure you can delete all of them, then:
yum remove *.i386
will do the job. It will ask Y/n, so look through the list before hitting the Enter key :-D
Akemi
On Fri, 22 Aug 2008 at 9:37am, Akemi Yagi wrote
On Fri, Aug 22, 2008 at 9:02 AM, Joseph L. Casale JCasale@activenetwerx.com wrote:
which xen rpms did you install? The ones from centos, or the ones from xensource?
Rolled my own from the 3.2.0 srpm.
Generally when building for x86_64, it's best to remove all traces of x86 packages on the system.
How do you do this at install? Wouldn't that be cleaner? I suppose a rpm command with a --queryformat ARCH string would list all that is x86 and I couild pipe that into a remove command? Any ideas on how to do this cleanly?
First inspect what i386 packages are on your system:
rpm -qa --queryformat "%{name}-%{version}-%{release}.%{arch}\n" | grep i386
If you are sure you can delete all of them, then:
yum remove *.i386
will do the job. It will ask Y/n, so look through the list before hitting the Enter key :-D
Actually, both of those commands should be looking for i[36]86, otherwise you'll miss, e.g., glibc.i686.
On Fri, 22 Aug 2008 at 11:41am, Joseph L. Casale wrote
Actually, both of those commands should be looking for i[36]86, otherwise you'll miss, e.g., glibc.i686.
Any way to simply not install them when doing an install?
Unfortunately, not that I'm aware of.
On Fri, Aug 22, 2008 at 11:10 AM, Joshua Baker-LePain jlb17@duke.edu wrote:
On Fri, 22 Aug 2008 at 11:41am, Joseph L. Casale wrote
Actually, both of those commands should be looking for i[36]86, otherwise you'll miss, e.g., glibc.i686.
Any way to simply not install them when doing an install?
Unfortunately, not that I'm aware of.
There is a known issue with yum. See, for example,
http://lists.centos.org/pipermail/centos-devel/2008-June/002961.html
And a newer version of yum has a fix for that:
http://lists.centos.org/pipermail/centos-devel/2008-June/002967.html
For people who are interested, yum-3.2.17-0_beta is in the *testing* repo at this moment.
Akemi
On Fri, 22 Aug 2008 at 11:22am, Akemi Yagi wrote
On Fri, Aug 22, 2008 at 11:10 AM, Joshua Baker-LePain jlb17@duke.edu wrote:
On Fri, 22 Aug 2008 at 11:41am, Joseph L. Casale wrote
Actually, both of those commands should be looking for i[36]86, otherwise you'll miss, e.g., glibc.i686.
Any way to simply not install them when doing an install?
Unfortunately, not that I'm aware of.
There is a known issue with yum. See, for example,
http://lists.centos.org/pipermail/centos-devel/2008-June/002961.html
And a newer version of yum has a fix for that:
http://lists.centos.org/pipermail/centos-devel/2008-June/002967.html
For people who are interested, yum-3.2.17-0_beta is in the *testing* repo at this moment.
When Joseph said "when doing an install", I assumed that meant at system install time. I know of no way of doing a pure x86_64 install via anaconda (although I'd love to be told I'm wrong on that).
For installing packages/package groups, then yum comes into the picture.
For people who are interested, yum-3.2.17-0_beta is in the *testing* repo at this moment.
That fixed it! Its installing now...
When Joseph said "when doing an install", I assumed that meant at system install time. I know of no way of doing a pure x86_64 install via anaconda (although I'd love to be told I'm wrong on that).
For installing packages/package groups, then yum comes into the picture.
Yea, I was after a way to install a x64 system only. Seems bizarre that a facility to accomplish does not exist at install time given the requirement exists.
Thanks guys! jlc
On Fri, Aug 22, 2008 at 11:32 AM, Joshua Baker-LePain jlb17@duke.edu wrote:
On Fri, 22 Aug 2008 at 11:22am, Akemi Yagi wrote
Any way to simply not install them when doing an install?
Unfortunately, not that I'm aware of.
There is a known issue with yum. See, for example,
http://lists.centos.org/pipermail/centos-devel/2008-June/002961.html
And a newer version of yum has a fix for that:
http://lists.centos.org/pipermail/centos-devel/2008-June/002967.html
For people who are interested, yum-3.2.17-0_beta is in the *testing* repo at this moment.
When Joseph said "when doing an install", I assumed that meant at system install time. I know of no way of doing a pure x86_64 install via anaconda (although I'd love to be told I'm wrong on that).
You are correct I believe. anaconda is another story. It might depend on the package selection but "pure" x86_64 installation is problematic. If I remember correctly, even with a minimal install, a few i386 packages were installed.
Akemi
-
Akemi Yagi -
Jim Perrin -
Joseph L. Casale -
Joshua Baker-LePain