I want to build the 64bit version of Xen 3.2, they only show one srpm available. I assume if its compiled on a x86_64 version of CentOS 5.1 it will be a 64bit rpm when its done?
I am aware its not good to build as root but out of curiosity, if I used a vm that I would later destroy, is the only caveat to building as root potential damage to the build system, or can the actual rpm be built incorrectly?
Thanks for any hints, jlc
Joseph L. wrote:
I want to build the 64bit version of Xen 3.2, they only show one srpm available. I assume if its compiled on a x86_64 version of CentOS 5.1 it will be a 64bit rpm when its done?
I am aware its not good to build as root but out of curiosity, if I used a vm that I would later destroy, is the only caveat to building as root potential damage to the build system, or can the actual rpm be built incorrectly?
Thanks for any hints, jlc _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
I build mine as root ( a normal user account gave me some erorrs), and all seems well?
On Tue, 08 Apr 2008 19:29:01 +0200 Rudi Ahlers Rudi@SoftDux.com wrote:
I build mine as root ( a normal user account gave me some erorrs), and all seems well?
Use yum to install rpmdevtools. Then rpmdev-setuptree will do all of the work that's required to build rpms as a user.
On Tue, Apr 8, 2008 at 10:34 AM, Frank Cox theatre@sasktel.net wrote:
On Tue, 08 Apr 2008 19:29:01 +0200 Rudi Ahlers Rudi@SoftDux.com wrote:
I build mine as root ( a normal user account gave me some erorrs), and all seems well?
Use yum to install rpmdevtools. Then rpmdev-setuptree will do all of the work that's required to build rpms as a user.
I suppose rpmdevtools is only available from EPEL. But the following procedures will do the job:
cd mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} echo "%_topdir %(echo $HOME)/rpmbuild" > .rpmmacros
Then as root, yum install rpm-build
Akemi
Akemi Yagi wrote:
On Tue, Apr 8, 2008 at 10:34 AM, Frank Cox theatre@sasktel.net wrote:
On Tue, 08 Apr 2008 19:29:01 +0200 Rudi Ahlers Rudi@SoftDux.com wrote:
I build mine as root ( a normal user account gave me some erorrs), and all seems well?
Use yum to install rpmdevtools. Then rpmdev-setuptree will do all of the work that's required to build rpms as a user.
I suppose rpmdevtools is only available from EPEL. But the following procedures will do the job:
cd mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} echo "%_topdir %(echo $HOME)/rpmbuild" > .rpmmacros
Then as root, yum install rpm-build
Johnny wrote a nice article here about building SRPMs:
http://www.linuxhelp.net/forums/How_to_Build_Enterprise_Srpms_t3384.html
Never had any problems since following Johnny's advice :)
You can modify Johnny's scripts to build for different targets (i386, i686, x86_64 etc). For a build target of x86_64, you may want to specify -m64.
On Tue, Apr 08, 2008 at 1:48 PM, Akemi Yagi wrote:
On Tue, Apr 8, 2008 at 10:34 AM, Frank Cox wrote:
On Tue, 08 Apr 2008 19:29:01 +0200, Rudi Ahlers wrote:
Use yum to install rpmdevtools. Then rpmdev-setuptree will do all of the work that's required to build rpms as a user.
I suppose rpmdevtools is only available from EPEL. But the following procedures will do the job:
cd mkdir -p rpmbuild/{BUILD,RPMS,SOURCES,SPECS,SRPMS} echo "%_topdir %(echo $HOME)/rpmbuild" > .rpmmacros
Then as root, yum install rpm-build
Akemi
Adding to Rudi Ahlers's & Akemi's suggestions, also define the distro while you are at it (.el4, .el5, etc.):
$ rpmdev-setuptree
$ echo "%dist .el5" >> ~/.rpmmacros
$ cat ~/.rpmmacros
%_topdir %(echo $HOME)/rpmbuild %_smp_mflags -j3 %__arch_install_post /usr/lib/rpm/check-rpaths /usr/lib/rpm/check-buildroot %dist .el5
Steve Tindall
Use yum to install rpmdevtools. Then rpmdev-setuptree will do all of the work that's required to build rpms as a user.
Frank, So reading through all of this, it looks like the rpmdevtools from epel is the simplest. Once I create a non root user, then as that user create the build environment, where should I execute the `rpmbuild --rebuild xen.srpm` command from? I assume that matters so the rpmbuild command finds whatever file it needs to work under the fake root?
Just to clarify, if I am on an x64 system, will this only create the x64 rpm as expected?
Thanks! jlc
On Tue, 08 Apr 2008 16:51:04 -0600 "Joseph L. Casale" jcasale@ActiveNetwerx.com wrote:
So reading through all of this, it looks like the rpmdevtools from epel is the simplest. Once I create a non root user, then as that user create the build environment, where should I execute the `rpmbuild --rebuild xen.srpm` command from?
Anywhere you like, as long as you're not changing anything in or about the srpm.
I assume that matters so the rpmbuild command finds whatever file it needs to
work under the fake root?
Not unless you're making changes.
Just to clarify, if I am on an x64 system, will this only create the x64 rpm as expected?
Yes.
On Tue, 2008-04-08 at 10:49 -0600, Joseph L. Casale wrote:
I want to build the 64bit version of Xen 3.2, they only show one srpm available. I assume if its compiled on a x86_64 version of CentOS 5.1 it will be a 64bit rpm when its done?
Yes.
I am aware its not good to build as root but out of curiosity, if I used a vm that I would later destroy, is the only caveat to building as root potential damage to the build system, or can the actual rpm be built incorrectly?
Both. Consider using mock.
Ignacio Vazquez-Abrams wrote:
On Tue, 2008-04-08 at 10:49 -0600, Joseph L. Casale wrote:
I want to build the 64bit version of Xen 3.2, they only show one srpm available. I assume if its compiled on a x86_64 version of CentOS 5.1 it will be a 64bit rpm when its done?
Yes.
I am aware its not good to build as root but out of curiosity, if I used a vm that I would later destroy, is the only caveat to building as root potential damage to the build system, or can the actual rpm be built incorrectly?
Both. Consider using mock.
Ignacio's suggestion to use mock, especially on x86_64 is a good one.
You will have an endless source of problems trying to build x86_64 RPMS on a normally installed tree if there are any i386 packages on there except for:
glibc.i686 and glibc-devel.i386
AND ... if you have not installed from a x86_64 ONLY tree, then you do have i386 packages on your x86_64 machine.
If, however, you configure mock properly (and EPEL should have some good config files for centos too I think) then you will get good clean buildroots for your x86_64 packages.
Trying to build packages with i[3,4,5,6]86 stuff polluting your buildroots can cause you to link to the wrong libraries or cause you to not be able to build things with ld errors. Building on multilib arches is not the easiest thing to do.
Johnny Hughes wrote:
Ignacio Vazquez-Abrams wrote:
On Tue, 2008-04-08 at 10:49 -0600, Joseph L. Casale wrote:
I want to build the 64bit version of Xen 3.2, they only show one srpm available. I assume if its compiled on a x86_64 version of CentOS 5.1 it will be a 64bit rpm when its done?
Yes.
I am aware its not good to build as root but out of curiosity, if I used a vm that I would later destroy, is the only caveat to building as root potential damage to the build system, or can the actual rpm be built incorrectly?
Both. Consider using mock.
Ignacio's suggestion to use mock, especially on x86_64 is a good one.
You will have an endless source of problems trying to build x86_64 RPMS on a normally installed tree if there are any i386 packages on there except for:
glibc.i686 and glibc-devel.i386
AND ... if you have not installed from a x86_64 ONLY tree, then you do have i386 packages on your x86_64 machine.
If, however, you configure mock properly (and EPEL should have some good config files for centos too I think) then you will get good clean buildroots for your x86_64 packages.
Trying to build packages with i[3,4,5,6]86 stuff polluting your buildroots can cause you to link to the wrong libraries or cause you to not be able to build things with ld errors. Building on multilib arches is not the easiest thing to do.
I second what both Ignacio and Johnny said and can attest to the problems of building on mixed arch.
Having said that though, xen 3.2 builds clean on x86_64 as root without mock.
I must also say, if you are building with Xen, then PVs provide the same functionality as mock for a build environment, and if you use LVM and snapshots you can get easy roll-back, though mock does provide the nifty feature of pulling in the build requirements.
It would be nice to have yum install the build requirements. Has anybody developed a plugin to allow yum to install SRPMs and optionally install the requirements as part of this?
When I do a rpm -qp --requires on the source package it lists the build requirements, so it seems like it wouldn't be an impossible task to write a yum plugin to handl this.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.
On Fri, 2008-04-11 at 10:26 -0400, Ross S. W. Walker wrote:
It would be nice to have yum install the build requirements. Has anybody developed a plugin to allow yum to install SRPMs and optionally install the requirements as part of this?
You mean like yum-builddep in yum-utils?
Ignacio Vazquez-Abrams wrote:
On Fri, 2008-04-11 at 10:26 -0400, Ross S. W. Walker wrote:
It would be nice to have yum install the build requirements. Has anybody developed a plugin to allow yum to install SRPMs and optionally install the requirements as part of this?
You mean like yum-builddep in yum-utils?
Yes, but work on any src rpm not just the ones in the repos.
And if there is something in the requirements that isn't in the repos or already installed it fails.
I believe the functionality is in yum right now, all that needs to be done is allow yum to install a package that doesn't actually upgrade/update anything.
-Ross
______________________________________________________________________ This e-mail, and any attachments thereto, is intended only for use by the addressee(s) named herein and may contain legally privileged and/or confidential information. If you are not the intended recipient of this e-mail, you are hereby notified that any dissemination, distribution or copying of this e-mail, and any attachments thereto, is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and permanently delete the original and any copy or printout thereof.