From Fedora Project Wiki
No edit summary
No edit summary
Line 8: Line 8:
The rest of this page is laid out based on what task you are trying to accomplish.
The rest of this page is laid out based on what task you are trying to accomplish.


== Building the Source ==
== Installing Build Dependencies ==
 
Why might you just want to compile anaconda instead of building a package?  Of course, there's the obvious reason that you are working on something in the loader and need to see if your changes still compile.  You may also want to build a new loader for testing out in an updated initrd.  Also, sometimes it's good to do a test build real quick to make sure sources still compile and translations still work before submitting it to the build system.


First you need all the requirements installed.  If you are running the same version of Fedora that you want to build anaconda for (say, you're using F15 and want to build the F15 anaconda sources), this is pretty straightforwardThe easiest way to do this is to build a SRPM file and then automatically install all the build requirements from that using the yum-builddep tool included in the yum-utils package.
Before you can do any local builds, you need to have the build dependencies installed.  We have a Makefile target to help with that, but if you have never built anaconda before, the steps needed to generate the real Makefile won't workSo you can just grab the line out of the Makefile.am and do it yourself:


<pre>
<pre>
clumens@exeter:~$ cd src/
clumens@exeter:$ cd src/
clumens@exeter:~/src$ ./autogen.sh
clumens@exeter:~/src$ sudo yum install $(grep BuildRequires: anaconda.spec.in | cut -d ' ' -f 2)
...
clumens@exeter:~/src$ ./configure
...
clumens@exeter:~/src$ make scratch
...
clumens@exeter:~/src$ rpmbuild -ts anaconda-15.0.tar.bz2
Wrote: /home/clumens/rpm/SRPMS/anaconda-15.0-1.fc15.src.rpm
clumens@exeter:~/src$ yum-builddep /home/clumens/rpm/SRPMS/anaconda-15.0-1.fc15.src.rpm
</pre>
</pre>


This may take a little while, but will end up pulling in all the programs required to build anaconda.  This includes compilers and basic libraries if you don't already have them installed.  Of course, you will need make to build the SRPM.  It's possible to build an SRPM without the makefile target, but it's so much less convenient.
This may take a little while, but will end up pulling in all the programs required to build anaconda.  This includes compilers and basic libraries if you don't already have them installed.


Then, building anaconda is a simple matter of:
== Building the Source ==


<pre>
Why might you just want to compile anaconda instead of building a package?  Of course, there's the obvious reason that you are working on something in the loader and need to see if your changes still compile.  You may also want to build a new loader for testing out in an updated initrd.  Also, sometimes it's good to do a test build real quick to make sure sources still compile and translations still work before submitting it to the build system.
clumens@exeter:~/src$ make
</pre>


If you aren't running the same version of Fedora that you want to target a build of anaconda for (say, you're running F15 and want to build the Rawhide anaconda sources), it's still possible.  You'll first need to install the mock package and install all the build dependencies of the anaconda package in the right mock chroot.  Follow the above instructions through creating an SRPM.  Then:
Once you've got the build dependencies installed, building anaconda is a simple matter of:


<pre>
<pre>
clumens@exeter:~/src$ mock -r fedora-16-i386 /home/clumens/rpm/SRPMS/anaconda-15.0-1.fc14.src.rpm
clumens@exeter:~/src$ make
...
</pre>
 
The first time you run this, it will take a long while as it downloads and installs all the package build dependencies.  The slower your repos, the longer it will take.  Afterwards, you will have a mock chroot populated with all the libraries and programs needed to compile anaconda.  You can then chroot into it and do a build:
 
<pre>
clumens@exeter:~$ sudo su -
root@exeter:~# mount -o bind /home/clumens/src /var/lib/mock/fedora-16-i386/root/root
root@exeter:~# chroot /var/lib/mock/fedora-16-i386/root/
root:~# make
...
</pre>
</pre>



Revision as of 15:47, 29 October 2010

Building anaconda

Building and packaging anaconda is not overly difficult, but it does involve a lot of steps. Building anaconda refers to building the source in place. Packaging refers to creating either a local package or an official build in the Fedora build system. These will be described using the official Fedora build infrastructure.

The first step is having both the anaconda source and the Fedora package source checked out. Checking out the anaconda source is described in detail on the main page. Checking out the package source is described in detail on the page. For now, let's assume the anaconda source is in src/ and the package source is in pkg/.

The rest of this page is laid out based on what task you are trying to accomplish.

Installing Build Dependencies

Before you can do any local builds, you need to have the build dependencies installed. We have a Makefile target to help with that, but if you have never built anaconda before, the steps needed to generate the real Makefile won't work. So you can just grab the line out of the Makefile.am and do it yourself:

clumens@exeter:$ cd src/
clumens@exeter:~/src$ sudo yum install $(grep BuildRequires: anaconda.spec.in | cut -d ' ' -f 2)

This may take a little while, but will end up pulling in all the programs required to build anaconda. This includes compilers and basic libraries if you don't already have them installed.

Building the Source

Why might you just want to compile anaconda instead of building a package? Of course, there's the obvious reason that you are working on something in the loader and need to see if your changes still compile. You may also want to build a new loader for testing out in an updated initrd. Also, sometimes it's good to do a test build real quick to make sure sources still compile and translations still work before submitting it to the build system.

Once you've got the build dependencies installed, building anaconda is a simple matter of:

clumens@exeter:~/src$ make

Building a Test Package and Tree Compose

We no longer automatically generate nightly trees for rawhide. This makes it a little hard to test updates to the loader or tree composition scripts. For this, you need to create a test package of anaconda and then use that test package in a run of pungi to compose a new tree. In order to do those tasks, you need anaconda's build dependencies installed (see above), pungi installed, enough disk space to store a tree, and space somewhere to put a small package repository.

Again, this is easiest if you are building a tree for the same architecture as you will be testing. First, you need to build a new anaconda binary package:

clumens@exeter:~$ cd src/
clumens@exeter:~/src$ ./autogen.sh
...
clumens@exeter:~$ ./configure
...

Then edit configure.ac and increment the version number in the following line:

AC_INIT([anaconda], [15.5], [anaconda-devel-list@redhat.com])

Commit it temporarily:

clumens@exeter:~/src$ git commit -m 'Temporary build.' configure.ac
...

We have makefile targets to do this last bit automatically, but you don't want to use them for test builds. The real targets also add a new %changelog entry to the spec file and tag the build with a GPG signed tag. You don't really want to accidentally push a new tag to the remote repo.

Then you create a new tarball, build an RPM from it, install it to your local system (you need the updated versions of the scripts on the local system for pungi to find), and create a package repo containing the updated package:

clumens@exeter:~/src$ make scratch
...
clumens@exeter:~/src$ rpmbuild -tb anaconda-15.5.tar.bz2
...
Wrote: /home/clumens/rpm/RPMS/x86_64/anaconda-15.5-1.fc15.x86_64.rpm
Wrote: /home/clumens/rpm/RPMS/x86_64/anaconda-debuginfo-15.5-1.fc15.x86_64.rpm
...
clumens@exeter:~/src$ sudo rpm -Uvh --force /home/clumens/rpm/RPMS/x86_64/anaconda-15.5-1.fc15.x86_64.rpm
...
clumens@exeter:~/src$ mkdir ~/repo
clumens@exeter:~/src$ cp /home/clumens/rpm/RPMS/x86_64/anaconda-15.5-1.fc15.x86_64.rpm ~/repo
clumens@exeter:~/src$ cd
clumens@exeter:~$ createrepo -p -d repo
1/1 - anaconda-15.5-1.fc15.x86_64.rpm                                           
Saving Primary metadata
Saving file lists metadata
Saving other metadata
Generating sqlite DBs
Sqlite DBs complete
clumens@exeter:~$

At this point, you are all set to run pungi and create a whole new Fedora tree to test with. In order to run pungi, you need the fedora-kickstarts package installed. pungi takes a kickstart file as input and generates a tree using the various repo commands and the %packages section. I copy one of the basic kickstart files from that package as the basis. I remove a bunch of the stuff out of the %packages section since I don't care, and then I add in a new repo line so pungi finds my updated anaconda in preference to whatever we're shipping in the distribution right now (that's also why you've got to update the version number in configure.ac above).

Add the following to your pungi kickstart file:

repo --name=anaconda --baseurl=file:///home/clumens/repo

And then it's time to run pungi. This will take a good long while.

clumens@exeter:~$ sudo setenforce permissive
clumens@exeter:~$ sudo pungi --destdir=/home/clumens/install --nosource --nodebuginfo --nosplitmedia -GCBI -c fedora-install-fedora.ks
...

Building an Official Package

Doing an official build of anaconda for Fedora is much simpler because of our Makefile targets and the fact that you don't need to do any tree composition. The first step is to build a tarball from anaconda source. Before doing that, it's good to make sure you've got the latest stuff.

dcantrel@mitre ~$ cd src/
dcantrel@mitre src (master)$ git fetch && git rebase origin
dcantrel@mitre src (master)$ make bumpver

This last command updates the anaconda.spec.in file with a new %changelog entry, increments the version number in configure.ac, and regenerates po/anaconda.pot for the translators. The %changelog entry is made automatically from the git logs, so you should examine what was written to anaconda.spec.in and remove unnecessary messages. We remove 'Sending translation for' messages as well as merge commit messages. When you are finished with anaconda.spec.in, check in the files as 'New version' to signify we are making a new version:

dcantrel@mitre anaconda (master)$ git add anaconda.spec.in configure.ac po/anaconda.pot
dcantrel@mitre anaconda (master)$ git commit -m "New version."

Now we have the version updated and the spec file template updated. We need to tag the git repository and generate a new release archive. Here's how I do that:

dcantrel@mitre src (master)$ git clean -d -x -f
dcantrel@mitre src (master)$ ./autogen.sh && ./configure
dcantrel@mitre src (master)$ make release

The git tag procedure will attempt to sign the tag using the GnuPG key for the default email address in your local git configuration. If you do not have GnuPG set up, now is a good time.

Now it's time to push the new version changes and tags and move the files over to the package GIT directory:

dcantrel@mitre src (master)$ git push && git push --tags
dcantrel@mitre src (master)$ mv anaconda.spec *.bz2 ~/pkg/devel/
dcantrel@mitre src (master)$ cd ~/pkg/devel/
dcantrel@mitre pkg$ fedpkg upload *.bz2

Now update the sources file like you are told to and remove the old entry. I also remove old entries from the .gitignore file. Then continue like so:

dcantrel@mitre pkg$ fedpkg clog
dcantrel@mitre pkg$ fedpkg commit -F clog
dcantrel@mitre pkg$ fedpkg clean
dcantrel@mitre pkg$ fedpkg push
dcantrel@mitre pkg$ fedpkg build

Then you just wait for the package to work its way through the build system. If all goes well, there's nothing left to do. However if the build fails, you can check the provided link and view the log files to determine the cause of the problem. Then it's back to the beginning of the whole packaging process to try again.