Releases/Rawhide

Rawhide is the name given to the current development head of Fedora. It consists of a daily snapshot of latest built version of all Fedora packages.

Rawhide mirrors

Rawhide goes by the name of "development" on the mirrors. You can find a local mirror here:
http://mirrors.fedoraproject.org/publiclist/Fedora/development/

Who should use Rawhide?

No-one should use Rawhide as their main day-to-day workstation. As Rawhide is a development branch, many changes are not heavily tested (or tested at all) before being released to Rawhide, and packages in Rawhide can and do break without warning. It is even possible that bugs in Rawhide could cause data loss. However, testing Rawhide is a very valuable activity which helps to direct Fedora development and ensure the quality of stable releases is high. It's also a fun way to try out the latest software almost as soon as it comes out. Testing Rawhide is a great way to contribute to Fedora development. You can try out Rawhide from the nightly live builds without needing to install it at all. Otherwise, you can install it if you have a spare system, or are willing to install Rawhide to spare space on an existing system and dual boot, or use a virtual machine.

Nightly live builds

Since August 2009, nightly builds of all approved live spins of Rawhide are available. These are built automatically without manual tweaking or testing, so they will sometimes be beyond the size of a single CD, and sometimes may not work at all. If there is a bug in the generation toolchain, the images may not be built on a given night; in this case, the last built image will remain available. Using these nightly builds is an ideal way to test Rawhide if you have no spare machine or partition available, or simply do not have the time to maintain a Rawhide installation. It's a very safe way to test, since it will make no changes to your installed system.

Installing Rawhide

Rawhide is meant to be installable, however, since it's automated, any particular Rawhide build may not be installable due to bugs of one sort or another. There are three ways to install Rawhide.

How to avoid disturbing an existing system

There are a few methods to test Rawhide on a machine without disturbing an existing installation:

1. Test a Live version from CD, DVD, or USB drive.
   • For CD or DVD, see How to create and use a Live CD.
   • For USB, see How to create and use Live USB.
   • See http://fedoraproject.org/get-prerelease if you need to download an ISO manually.
   • If you use a LiveUSB with data persistence, you can use the "yum update" method described below to get the latest daily Rawhide RPMs, as opposed to the slightly older Alpha or Beta releases (except for the kernel).
2. Use a virtual machine. See Testing/qemu.
3. Install to a separate partition.

Yum update from official release

For details and information on installing a Fedora release please see the Installation Guide for the appropriate release.

Once your system is installed, you can upgrade to the rawhide repository one of two ways. Using graphical applications:

1. First, modify your software sources using: gpk-repo
   • Leave only the Fedora - Rawhide software source enabled
2. Next, update your system using: gpk-update-viewer

Alternatively, you may upgrade using the command-line:

1. Type:

   # yum --disablerepo=* --enablerepo=rawhide update

You may want to enable/disable repositories in /etc/yum.repos.d/ so that only the "Fedora Development" repository is enabled. This will allow daily Rawhide updates to appear by default in desktop notifications and "yum update".

From a pre-release of Fedora

Get the installer from: http://fedoraproject.org/get-prerelease

Test releases of Fedora are configured to update via Rawhide by default, so you can run "yum update" or wait for desktop notification of updates.

Questions on upgrading from a pre-release to a general release of Fedora is answered at

https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final

Direct daily Rawhide install

The same process used to install an Fedora release (via Anaconda) can often be used to install rawhide. For an overview of the process, please review the Installation Guide.

1. Determine your system architecture
2. Locate a nearby mirror where you can download install media
3. Download the boot.iso for your architecture
4. Burn the downloaded image to a CD/DVD
5. Boot from the CD/DVD

Don't have a CD/DVD burner or spare media?
For tips on installing without media, checkout how to install your system using your network interface http://docs.fedoraproject.org/install-guide/f41/en-US/html/ap-medialess-install.html.

Follow the on-screen instructions from Anaconda, the graphical installer. The installation is very straightforward. You should do a HTTP/FTP install. For the URL of your 'install tree', use "<mirrorroot>/development/<arch>/os/" where <mirrorroot> is the mirror site URL you got from the mirror list.

Via Preupgrade

A faster Anaconda installation can be performed with PreUpgrade. See How to use PreUpgrade for instructions; just select "Rawhide" when choosing the version of Fedora you wish to install.

Testing Rawhide

There are two important things all Rawhide testers should do. First, read the fedora-test-list mailing list, where Rawhide users discuss the latest changes. You'll find discussion of significant changes and warnings of severe breakages here. Reading test-list daily is key to staying on top of Rawhide. Secondly, report all the bugs you find in Rawhide to Bugzilla. Remember to file bugs according to these best practices. Please remember that bugs should always be filed in Bugzilla. Reporting bugs on the mailing list or IRC is not sufficient, as these reports rapidly become lost in history. Only on Bugzilla will they always be accessible to other testers and to the developers.

Beyond that, here is some general advice which may be of use in using Rawhide:

• Approach the test release as a valuable chance to learn more about your system. There is a good chance you will run into some bugs in subsystems or components that you are very unfamiliar with as part of the testing process. Use this an opportunity to learn more about that particular subsystem and get familiar with its documentation. Even documentation has bugs, by following up and trying to learn from the documentation you might be able to help clean up badly worded or out of date documentation as well. The more you learn, the more effective you will be in the future if you participate in the development process again. Be as proactive as you can about reading up on how things work and you will have a much more valuable experience overall.
• When using yum, take the time to review the list of package actions before you proceed. Don't disable the review step.
• Get familiar with the /var/log/rpmpkgs and /var/log/yum.log log files.
• Get a notebook and make notes about system configuration changes you make. Many problems can be traced to simple configuration errors, but can appear as package update bugs. When working with other testers to confirm the problem, notes as to the other changes you have made since last update/reboot can be invaluable in tracing the problem down accurately.
• Keep at least one older kernel around that you are confident works as expected.
• Reboot daily, to test to see if any of your updates have affected startup. Its much more difficult to track down a boot up problem that was caused by an old update, if you are updating daily but have not rebooted.
• Get familiar with useful grub features for troubleshooting boot up failures.
• Don't force or nodeps any package to work around dependency problems. Instead, report them as bugs or to test-list. If no-one reports these problems, they will never get fixed, and will persist into stable releases.
• Because the development tree is not guaranteed to be internally consistent every day, you will frequently see yum update fail with errors. Don't Panic. Most dependency problems will be fixed by the developers in one or two days, sometimes simply by requesting more package rebuilds. If you see a dependency problem with yum update on your system for several days in a row, and see no discussion of it on test-list, see below to decide whether and how you should report it.
• If there is one error (such as a package depending on an old library major) holding you back from a full Rawhide update, you can use yum update --skip-broken to update all other packages. However, make sure the error has been reported to the maintainer of the offending package.
• You might need to disable GPG check in /etc/yum.conf or the fedora-devel repository in /etc/yum.repos.d if packages are incorrectly signed.

When to Report Update Problems

There is a daily build report of the development tree sent to the fedora-test-list every morning as part of the automated push of packages out to the publicly accessible trees. The daily report contains information about new, removed and updated packages. It also contains a summary of known dependency problems for each arch for which the development tree is built for. Please, if you experience any problem updating against the development tree the first thing you should review is the last two or three build reports. If you are seeing a dependency problem summarized in the latest build report, you can be sure the developers are aware of the problem. Package maintainers receive daily emails when their packages are on this list.

Note that the broken dependency list which is part of the daily rawhide reports only provides the first layer of dependencies and not the entire list to save build time. Unlisted packages might also be affected, but fixed when one or more of the listed packages are rebuilt.

If however the problem lingers longer than a few days on your system, and the problem package is not listed in the daily report, that could be an indication that you have run into a situational bug that not everyone is seeing. This is when you can spring into action as a tester and make a difference. But, before you file a new bug report there is a short recipe you can follow to avoid filing unnecessarily. Please remember that test releases exist primarily to help the developers identify problems so they can be fixed in time for release. Unfortunately, reactionary bug filing of duplicate or well known issues can take developer time away from actually fixing issues.

1. read fedora-test-list: Go back into your archives or the web archives for fedora-test-list and read over the threads in the last 48 hours and see if there has been any discussion about the specific update errors you have been seeing. Generally, these sorts of errors are seen by most everyone with similar hardware, so its a very good chance that other testers are already discussing it. Please don't just post a new post to fedora-test-list until after you have reviewed the last 48 hours worth of posts. Having multiple discussions about the same issue is a drain on the time of other testers and developers.
2. search http://bugzilla.redhat.com: Search to see if there are any reports about the update issue you have seen
3. drop a note into fedora-test-list: Please only start a new thread only after you attempted to find previous discussion of this problem in the test-list or in bugzilla. Other testers can help you confirm the problem, or if they can't confirm it they can help you determine if its a configuration problem or user error on your part. The test-list is a great way to assistance from other more experienced testers, but please do what you can to use the archives responsibility to avoid duplication of information and discussion.
4. File a new bug report: If the exact nature of the dependency problem during updating is lingering for several days or if the problem seems specialized to your situation and it doesn't appear that the developer is aware of this problem.... file a new bug. If you are unsure how to file, experienced testers in fedora-test-list can make suggestions. Please don't assume its a yum bug. Most dependency issues are packaging bugs in one of the packages detailed in the error messages.

What does it mean when something "hits Rawhide"?

Rawhide is automatically generated once daily from the latest packages that are built. Packages that are built one day are generally in the next days rawhide.

(For the curious, the compose is done at Midnight US Eastern, 0400/0500 UTC.)

What is a rawhide "push"?

A rawhide push is simply the rawhide spin for that day. Occasionally, if the push is extremely broken, it may be regenerated more than once.

Where do I communicate issues in Rawhide ?

Use the fedora-test list or #fedora-qa IRC channel in Freenode. For bugs, report them to http://bugzilla.redhat.com

How can I know what is changing in Rawhide?

Nightly reports are sent to fedora-test-list and fedora-devel-list, with the subject 'rawhide report: <date> changes'. Included in these reports are what packages have been added, removed, or updated (with short changelog snippets), along with a list of any broken dependencies.

http://git.fedoraproject.org/ and http://hg.fedoraproject.org/ and https://fedorahosted.org/ are good places to look at the upstream state of many Fedora projects.