Rawhide is the name given to the current development head of Fedora. It consists of a package repository called "rawhide", which contains the latest build of all Fedora packages, updated daily. During the early part of the [[Fedora Release Life Cycle]], nightly composes are also available.

+

{{autolang|base=yes}}

+

+

Rawhide is the name given to the current development head of Fedora. It consists of a package repository called "rawhide" and contains the latest build of all Fedora packages updated on a daily basis. Nightly builds are also available during the early portion of the [[Fedora Release Life Cycle]].

== Who should use Rawhide? ==

== 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 or [[Releases/Branched|Branched]] (depending on the point in the [[Releases/{{FedoraVersion||next}}/Schedule|release cycle]]) from the [http://alt.fedoraproject.org/pub/alt/nightly-composes/ 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.

+

End users should not use Rawhide as their main day-to-day workstation. Because 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 direct Fedora development and ensure that the quality of the stable releases is high. It's also a fun way to try out the latest software almost as soon as it's released. Testing Rawhide is a great way to contribute to Fedora development. You can try Rawhide or [[Releases/Branched|Branched]] (depending on the point in the [[Releases/{{FedoraVersion||next}}/Schedule|release cycle]]) from the [http://alt.fedoraproject.org/pub/alt/nightly-composes/ 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 on an existing system and dual boot, or use a virtual machine.

== Nightly live builds ==

== Nightly live builds ==

−

After the go ahead for the previous final release, but before the [[Releases/{{FedoraVersion||next}}|Branch event]] [http://alt.fedoraproject.org/pub/alt/nightly-composes/ nightly builds] will be composed of Rawhide pacakges. 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. You can also later install Rawhide to your hard drive from the Live desktop if the Live image is working well for you. During the rest of the release cycle, daily builds will contain [[Releases/Branched|Branched]] content, and to install Rawhide you must use a repository (though you can build a custom spin using Revisor if you need to test a Live distribution).

+

After the release of the previous final release, but before the [[Releases/{{FedoraVersion||next}}|Branch event]], [http://alt.fedoraproject.org/pub/alt/nightly-composes/ nightly builds] will be composed of Rawhide packages. 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 most recent 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. You can also install Rawhide to your hard drive from the Live desktop if the Live image is working well for you. During the rest of the release cycle, daily builds will contain [[Releases/Branched|Branched]] content, and you must use a repository to install Rawhide - though you can build a custom spin using Revisor if you need to test a Live distribution.

+

+

See [[FedoraLiveCD]] for more information.

== Installing Rawhide ==

== Installing Rawhide ==

Line 15:

Line 19:

=== Rawhide mirrors ===

=== Rawhide mirrors ===

−

Rawhide is under "development/rawhide" on the mirrors. You can find a local "development" mirror here: <BR>

+

Rawhide is under "development/rawhide" on the mirrors. You can find a local "development" mirror [http://mirrors.fedoraproject.org/publiclist/Fedora/development/ here]. Continue reading for specific instructions on how to install mirrored content.

−

http://mirrors.fedoraproject.org/publiclist/Fedora/development/

+

−

+

−

(Continue reading for specific instructions on how to install mirrored content.)

+

=== How to avoid disturbing an existing system ===

=== How to avoid disturbing an existing system ===

Line 24:

Line 25:

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

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

# Test a Live version from CD, DVD, or USB drive.

# Test a Live version from CD, DVD, or USB drive.

−

#* To burn to CD or DVD, see the [http://docs.fedoraproject.org/readme-burning-isos/ burning ISOs readme].

+

#* To burn to CD or DVD, see [http://docs.fedoraproject.org/readme-burning-isos/ burning ISOs].

#* To write to USB, see [[How to create and use Live USB]].

#* To write to USB, see [[How to create and use Live USB]].

#* If you use a LiveUSB with data persistence, you can use the "yum update" method described below to get the latest daily Rawhide RPMs ([https://bugzilla.redhat.com/show_bug.cgi?id=446935 except for the kernel]). Note that you may also need to install the 'fedora-release-rawhide' package and enable the rawhide repository. However, downloading daily ISOs is recommended instead of this method.

#* If you use a LiveUSB with data persistence, you can use the "yum update" method described below to get the latest daily Rawhide RPMs ([https://bugzilla.redhat.com/show_bug.cgi?id=446935 except for the kernel]). Note that you may also need to install the 'fedora-release-rawhide' package and enable the rawhide repository. However, downloading daily ISOs is recommended instead of this method.

Line 34:

Line 35:

Anaconda is the Fedora installer. It can be booted directly, rather than run from a Live desktop.

Anaconda is the Fedora installer. It can be booted directly, rather than run from a Live desktop.

−

==== Using a general release Anaconda ISO ====

+

==== Using a general release Fedora ISO ====

You can use the version of Anaconda distributed with a final public release (the latest being Fedora {{FedoraVersion}}). Using this method, you will be using an older but known-to-be-working installer to install the latest content in the Rawhide repository.

You can use the version of Anaconda distributed with a final public release (the latest being Fedora {{FedoraVersion}}). Using this method, you will be using an older but known-to-be-working installer to install the latest content in the Rawhide repository.

−

;Option 1 - Use a copy you've already downloaded

+

; Option 1 - Use a copy you've already downloaded

−

If you already have a bootable CD, DVD, USB stick, or hard drive partition containing the *-DVD.iso or *-disc1.iso you can use that to install Rawhide. However, if you need to download new boot media, these files are not recommended because they contain general release versions of Fedora RPMs, and you wish to install Rawhide RPMs. (See [http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch-new-users.html#sn-howto-download installation guide download page] for instructions if you want to download these files anyway.) A general release ''Live'' image cannot be used to install Rawhide, only the general release version of Fedora which it contains.

+

: If you already have a bootable CD, DVD, USB stick, or hard drive partition containing the *-DVD.iso or *-disc1.iso, you can use that to install Rawhide. However, if you need to download new boot media, these files are not recommended because they contain general release versions of Fedora RPMs, and you wish to install Rawhide RPMs. See [http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch-new-users.html#sn-howto-download installation guide download page] for instructions if you want to download these files anyway. A general release ''Live'' image cannot be used to install Rawhide, only the general release version of Fedora which it contains can be used.

−

;Option 2 - Download the minimal installer

+

; Option 2 - Download the minimal installer

−

If you need to make a bootable CD, DVD, USB stick, or hard drive partition, the best way is to download the minimal boot.iso installer, and load RPMs over the network. This is the same as the *-netinst.iso (e.g. Fedora-12-i386-netinst.iso) which you may find elsewhere. These files are not available by BitTorrent.

+

: If you need to make a bootable CD, DVD, USB stick, or hard drive partition, the best way to do this is to download the minimal boot.iso installer and load RPMs over the network. This is the same as the *-netinst.iso (e.g. Fedora-12-i386-netinst.iso) which you may find elsewhere. These files are not available by BitTorrent.

+

: To obtain and use a boot.iso file:

+

: * Go to http://download.fedoraproject.org/ - you will be redirected to a nearby mirror.

: * Create a bootable CD, DVD, USB media, or hard drive partition following the instructions [http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch-new-users.html#sn-making-media here] using your newly downloaded boot.iso file. You can use the livecd-iso-to-disk method described there even though boot.iso is not a Live image, and it should also work on hard drive partitions, not just USB media.

−

To get and use a boot.iso file:

+

; Option 3 - Pure network install with no boot media

−

* Go to http://download.fedoraproject.org/ - you will be redirected to a nearby mirror.

+

: The Installation Guide documents how to [http://docs.fedoraproject.org/en-US/Fedora/{{FedoraVersion}}/html/Installation_Guide/ap-medialess-install.html boot the installer directly from the network], in case you cannot or choose not to create local boot media.

* Create a bootable CD, DVD, USB media, or hard drive partition following the instructions at [http://docs.fedoraproject.org/install-guide/f12/en-US/html/ch-new-users.html#sn-making-media] and using your newly downloaded boot.iso file. You can use the livecd-iso-to-disk method described there even though boot.iso is not a Live image, and it should also work on hard drive partitions, not just USB media.

+

−

;Option 3 - Pure network install with no boot media

+

; What to do after booting Option 1, 2 or 3

−

The Installation Guide documents how to [http://docs.fedoraproject.org/install-guide/f{{FedoraVersion}}/en-US/html/ap-medialess-install.html boot the installer directly from the network], in case you cannot or choose not to create local boot media.

+

: Start the installer and follow the on-screen instructions. Proceed to [http://docs.fedoraproject.org/en-US/Fedora/{{FedoraVersion}}/html/Installation_Guide/s1-pkgselection-x86.html Package Group Selection]. To install rawhide, deselect all {{FedoraVersion|long|current}} package repositories, and manually add rawhide using the instructions provided at [http://docs.fedoraproject.org/en-US/Fedora/{{FedoraVersion}}/html/Installation_Guide/s1-pkgselection-x86.html#sn-additional-repos Installing from Additional Repositories]. Obtain a valid Rawhide mirror from [http://mirrors.fedoraproject.org/publiclist/Fedora/development/ the mirror list].

−

;What to do after booting Option 1, 2 or 3

+

; Option 4 - Without network access at install time

−

Follow the on-screen instructions from Anaconda, the graphical installer. The installation is very straightforward. You should do a HTTP/FTP install. To get Rawhide instead of a supported release, for the URL of your 'install tree', use "<mirrorroot>/development/rawhide/<arch>/os/" where <mirrorroot> is the mirror site URL you got from [http://mirrors.fedoraproject.org/publiclist/Fedora/development/ the mirror list] and <arch> is your architecture (i386, x86_64, or ppc).

+

: If you have no network access during the install process, you will need to download the Rawhide (development) repository from a [http://mirrors.fedoraproject.org/publiclist/Fedora/development/ Rawhide mirror] and use the hard drive installation method described in the [http://docs.fedoraproject.org/install-guide/ Installation Guide], or it might be easier to choose a different method to install Rawhide from another section of this page.

−

;Option 4 - With no network access at install time

+

=== Direct Rawhide install via Live installer ===

−

If you have no network access during the install process, you will need to download the Rawhide (development) repository from a [http://mirrors.fedoraproject.org/publiclist/Fedora/development/ Rawhide mirror] and use the hard drive installation method described in the [http://docs.fedoraproject.org/install-guide/ Installation Guide], or it might be easier to choose a different method to install Rawhide from another section of this page.

+

{{admon/note|Timing is everything|This method only works after {{FedoraVersion|long}} is released, and before {{FedoraVersion|long|next}} has branched. See the [[Releases/{{FedoraVersion||next}}|release schedule]] for appropriate timing. Once branched, follow the instructions at [[Releases/Branched|Branched]]: after branching, the nightly images are of the Branched release, not of Rawhide.}}

−

==== Using daily Rawhide Anaconda build ====

+

{{admon/note|Presence and viability of nightly images not guaranteed|The nightly images are built by a script with little human intervention. As generating an entire bootable and installable Fedora image is a fairly complex operation which requires a rather large subset of packages to be present, functional, and interoperable, they will quite often fail to install correctly, fail to boot, or fail to compose at all: you cannot rely on a recent image being available, or any given image actually providing a usable installation. This is quite normal.}}

−

Daily Anaconda builds are no longer automatically available in Rawhide, only in [[Releases/Branched|Branched]] code. Pre-Alpha Anaconda code is generally not testable, and it is important to test the installer that will appear in the next release (since it cannot easily be fixed after distribution media have been created) rather than the release after the next release.

+

# Download a daily Live image (.iso) from http://alt.fedoraproject.org/pub/alt/nightly-composes/

+

# Follow the steps at [[How to create and use Live USB]] or [[How to create and use a Live CD]] to prepare and boot from the image you select.

+

# Log in and double click the ''Install to Hard Drive'' icon on the desktop.

+

# Follow the on-screen instructions to complete the installation.

−

Installer images ''can'' be provided on demand for test days if they are needed but not automatically available; please contact James Laska.

+

=== Yum update from a stable release or pre-release ===

−

=== Direct Rawhide install via Live installer ===

+

As an alternative to a direct installation of Rawhide, you can install an existing stable release or pre-release and try to upgrade to Rawhide using yum. When a pre-release is available, Rawhide corresponds to the '''following''' release: when Fedora 17 Alpha is available, the Rawhide repositories contains what will become Fedora 18. As with any method of installing Rawhide, success is not guaranteed. If you cannot get a direct installation to work, the yum method may work; on the other hand, if you cannot get a yum upgrade to work, try the direct installation method (above) instead.

−

'''''This method only works pre-Branch Event in the [[Releases/{{FedoraVersion||next}}|release schedule]]; after that, it will produce [[Releases/Branched|Branched]] content.'''''

+

It is generally best to start from the most recent release available, even if this is a pre-release: only use a stable release if no pre-release of the following version is yet available, or you cannot get the pre-release to install.

−

* Download a daily Live image (.iso) from http://alt.fedoraproject.org/pub/alt/nightly-composes/

+

If a test release or "pre-release" (Alpha or Beta) is currently available, you can download it [http://fedoraproject.org/get-prerelease here]. Otherwise, you can download the latest stable release [http://fedoraproject.org/get-fedora here].

−

* Follow the steps at [[How to create and use Live USB]] or [[How to create and use a Live CD]] to prepare and boot from the image you select.

+

−

* Log in and double click on the "Install to Hard Drive" icon on the desktop.

+

−

* Follow the on-screen instructions.

+

−

=== Yum update from a test release ===

+

You may run into dependency problems which could take time and manual effort to resolve: if the upgrade refuses to proceed, look carefully at the errors yum reports and consider appropriate action (often, you need to remove a few problematic packages to let the rest of the system update). Remember that Rawhide installations in general may need to be wiped and re-installed from scratch at any time.

−

If a test release or "pre-release" (Alpha or Beta) is currently available, you can download it from: http://fedoraproject.org/get-prerelease

+

You can upgrade to the rawhide repository one of two ways. The most reliable is to use the command line method from a console; this avoids the case where an update causes the X server to crash or restart, killing the yum process in mid-upgrade as a consequence. The results of this case are usually sub-optimal.

−

Test releases are not configured to update via Rawhide by default (they follow the [[Releases/Branched|Branched]] version for their release), so you need to first install the "fedora-release-rawhide" package and enable the rawhide repo. You can then run "yum update" or wait for desktop notification of updates.

+

==== Graphical ====

−

If you later want to switch from Rawhide to the final general release, see: https://fedoraproject.org/wiki/Upgrading_from_pre-release_to_final

+

All names and commands are for the GNOME desktop and gnome-packagekit - use equivalents in other desktops:

−

=== Yum update from previous release ===

+

# Run the ''Add/Remove Software'' application ({{command|gpk-application}}), and install the {{package|fedora-release-rawhide}} package

This method is available but not recommended for any but the bravest testers. Anaconda can make changes that are outside what the packaging system can normally deal with. You may also run into dependency problems which could take time to untangle. You may also need to upgrade from the immediately previous release (e.g. install Fedora 10, 11, then Fedora 12 Rawhide, not jump directly from Fedora 10 to Fedora 12 Rawhide). Remember than Rawhide installations in general may need to be wiped and re-installed from scratch at any time.

+

−

+

−

You can upgrade to the rawhide repository one of two ways. Using graphical applications:

If you have third-party repositories enabled, the command may fail due to no 'Rawhide' repository being available for these; in this case, temporarily disable the offending repositories to allow the upgrade to proceed.

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".

+

You may then want to enable/disable repositories in {{filename|/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".

−

If you cannot install fedora-release-rawhide from within the package system, you can download the RPM directly from a Rawhide mirror, under: <code>development/rawhide/<arch>/os/Packages/</code>

+

If you cannot install fedora-release-rawhide from within the package system, you can download the RPM directly from a Rawhide mirror, under: <code>development/rawhide/<arch>/os/Packages/</code> (for instance:

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 ==

== Testing Rawhide ==

−

There are two important things all Rawhide testers should do. First, read the [https://admin.fedoraproject.org/mailman/listinfo/test test] 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 [http://bugzilla.redhat.com Bugzilla]. Remember to file bugs according to these [[BugsAndFeatureRequests|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.

+

There are two important things all Rawhide testers should do. First, read the [https://admin.fedoraproject.org/mailman/listinfo/test test] mailing list, where Rawhide users discuss the latest changes. You'll find discussion of significant changes and warnings of severe breakage here. Reading test-list daily is key to staying on top of Rawhide. Secondly, report all the bugs you find in Rawhide to [http://bugzilla.redhat.com Bugzilla]. Remember to file bugs according to these [[BugsAndFeatureRequests|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:

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.

+

* 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 unfamiliar with as part of the testing process. Use this an opportunity to learn more about that particular subsystem and become 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 about 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.

* 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.

+

* Become 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.

+

* 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, make notes as to the other changes you have made since the 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.

+

* Keep at least one older kernel 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.

+

* 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.

+

* Become 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.

+

* 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.

+

* 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 how you should report it or if a report is necessary.

−

* 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.

+

* If there is one error (such as a package depending on an old library) 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.

+

* You might need to disable GPG checking in /etc/yum.conf or the fedora-devel repository in /etc/yum.repos.d if packages are incorrectly signed.

=== When to Report Update Problems ===

=== 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.

+

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. If you experience any problems 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.

+

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, this saves 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.

+

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.

−

# 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.

+

# Read fedora-test-list: Go back into your archives or the web archives for fedora-test-list and read over the threads for 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 there's a very good chance that other testers are already discussing it. Please don't 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 other testers and developers.

−

# Search http://bugzilla.redhat.com: Search to see if there are any reports about the update issue you have seen

+

# Search [http://bugzilla.redhat.com Bugzilla]: Search to see if there are any reports about the update issue you have seen.

−

# 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.

+

# Drop a note into fedora-test-list: Please start a new thread only after you have attempted to find a previous discussion of this problem in the test-list or in bugzilla. Other testers can help you confirm the problem. 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 obtain assistance from other more experienced testers, but please do what you can to use the archives responsibly to avoid duplication of information and discussion.

−

# 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.

+

# 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"? ===

=== 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.

+

Rawhide is automatically generated once daily from the latest packages that are built. Packages that are built one day are generally in rawhide the next day. For the curious, the build is done at Midnight US Eastern, 0400/0500 UTC.

−

+

−

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

+

=== What is a rawhide "push"? ===

=== What is a rawhide "push"? ===

Line 152:

Line 147:

=== Where do I communicate issues in Rawhide ? ===

=== 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

+

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

=== How can I know what is changing in Rawhide? ===

=== 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'.

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.

+

Included in these reports are lists of packages that 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

+

Good resources for the state of many Fedora projects:

−

the upstream state of many Fedora projects.

+

* http://git.fedoraproject.org/

+

* https://fedorahosted.org/

== Reference ==

== Reference ==

Original press release at http://www.redhat.com/about/presscenter/1998/press_aug1498.html

Original press release at http://www.redhat.com/about/presscenter/1998/press_aug1498.html

Revision as of 09:46, 16 September 2012

Rawhide is the name given to the current development head of Fedora. It consists of a package repository called "rawhide" and contains the latest build of all Fedora packages updated on a daily basis. Nightly builds are also available during the early portion of the Fedora Release Life Cycle.

Who should use Rawhide?

End users should not use Rawhide as their main day-to-day workstation. Because 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 direct Fedora development and ensure that the quality of the stable releases is high. It's also a fun way to try out the latest software almost as soon as it's released. Testing Rawhide is a great way to contribute to Fedora development. You can try Rawhide or Branched (depending on the point in the release cycle) 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 on an existing system and dual boot, or use a virtual machine.

Nightly live builds

After the release of the previous final release, but before the Branch event, nightly builds will be composed of Rawhide packages. 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 most recent 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. You can also install Rawhide to your hard drive from the Live desktop if the Live image is working well for you. During the rest of the release cycle, daily builds will contain Branched content, and you must use a repository to install Rawhide - though you can build a custom spin using Revisor if you need to test a Live distribution.

If you use a LiveUSB with data persistence, you can use the "yum update" method described below to get the latest daily Rawhide RPMs (except for the kernel). Note that you may also need to install the 'fedora-release-rawhide' package and enable the rawhide repository. However, downloading daily ISOs is recommended instead of this method.

Direct Rawhide install via standalone Anaconda

Anaconda is the Fedora installer. It can be booted directly, rather than run from a Live desktop.

Using a general release Fedora ISO

You can use the version of Anaconda distributed with a final public release (the latest being Fedora 21). Using this method, you will be using an older but known-to-be-working installer to install the latest content in the Rawhide repository.

Option 1 - Use a copy you've already downloaded

If you already have a bootable CD, DVD, USB stick, or hard drive partition containing the *-DVD.iso or *-disc1.iso, you can use that to install Rawhide. However, if you need to download new boot media, these files are not recommended because they contain general release versions of Fedora RPMs, and you wish to install Rawhide RPMs. See installation guide download page for instructions if you want to download these files anyway. A general release Live image cannot be used to install Rawhide, only the general release version of Fedora which it contains can be used.

Option 2 - Download the minimal installer

If you need to make a bootable CD, DVD, USB stick, or hard drive partition, the best way to do this is to download the minimal boot.iso installer and load RPMs over the network. This is the same as the *-netinst.iso (e.g. Fedora-12-i386-netinst.iso) which you may find elsewhere. These files are not available by BitTorrent.

* Choose the directory for your architecture (i386, x86_64, or ppc - help available), then find os/images/boot.iso and download it.

* Create a bootable CD, DVD, USB media, or hard drive partition following the instructions here using your newly downloaded boot.iso file. You can use the livecd-iso-to-disk method described there even though boot.iso is not a Live image, and it should also work on hard drive partitions, not just USB media.

If you have no network access during the install process, you will need to download the Rawhide (development) repository from a Rawhide mirror and use the hard drive installation method described in the Installation Guide, or it might be easier to choose a different method to install Rawhide from another section of this page.

Direct Rawhide install via Live installer

Timing is everythingThis method only works after Fedora 21 is released, and before Fedora 22 has branched. See the release schedule for appropriate timing. Once branched, follow the instructions at Branched: after branching, the nightly images are of the Branched release, not of Rawhide.

Presence and viability of nightly images not guaranteedThe nightly images are built by a script with little human intervention. As generating an entire bootable and installable Fedora image is a fairly complex operation which requires a rather large subset of packages to be present, functional, and interoperable, they will quite often fail to install correctly, fail to boot, or fail to compose at all: you cannot rely on a recent image being available, or any given image actually providing a usable installation. This is quite normal.

Log in and double click the Install to Hard Drive icon on the desktop.

Follow the on-screen instructions to complete the installation.

Yum update from a stable release or pre-release

As an alternative to a direct installation of Rawhide, you can install an existing stable release or pre-release and try to upgrade to Rawhide using yum. When a pre-release is available, Rawhide corresponds to the following release: when Fedora 17 Alpha is available, the Rawhide repositories contains what will become Fedora 18. As with any method of installing Rawhide, success is not guaranteed. If you cannot get a direct installation to work, the yum method may work; on the other hand, if you cannot get a yum upgrade to work, try the direct installation method (above) instead.

It is generally best to start from the most recent release available, even if this is a pre-release: only use a stable release if no pre-release of the following version is yet available, or you cannot get the pre-release to install.

If a test release or "pre-release" (Alpha or Beta) is currently available, you can download it here. Otherwise, you can download the latest stable release here.

You may run into dependency problems which could take time and manual effort to resolve: if the upgrade refuses to proceed, look carefully at the errors yum reports and consider appropriate action (often, you need to remove a few problematic packages to let the rest of the system update). Remember that Rawhide installations in general may need to be wiped and re-installed from scratch at any time.

You can upgrade to the rawhide repository one of two ways. The most reliable is to use the command line method from a console; this avoids the case where an update causes the X server to crash or restart, killing the yum process in mid-upgrade as a consequence. The results of this case are usually sub-optimal.

Graphical

All names and commands are for the GNOME desktop and gnome-packagekit - use equivalents in other desktops:

Command line

If you have third-party repositories enabled, the command may fail due to no 'Rawhide' repository being available for these; in this case, temporarily disable the offending repositories to allow the upgrade to proceed.

You may then 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".

Testing Rawhide

There are two important things all Rawhide testers should do. First, read the test mailing list, where Rawhide users discuss the latest changes. You'll find discussion of significant changes and warnings of severe breakage 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 unfamiliar with as part of the testing process. Use this an opportunity to learn more about that particular subsystem and become 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 about 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.

Become 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, make notes as to the other changes you have made since the last update/reboot can be invaluable in tracing the problem down accurately.

Keep at least one older kernel 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.

Become 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 how you should report it or if a report is necessary.

If there is one error (such as a package depending on an old library) 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 checking in /etc/yum.conf or the fedora-devel repository in /etc/yum.repos.d if packages are incorrectly signed.

When to Report Update Problems

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. If you experience any problems 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, this saves 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.

Read fedora-test-list: Go back into your archives or the web archives for fedora-test-list and read over the threads for 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 there's a very good chance that other testers are already discussing it. Please don't 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 other testers and developers.

Search Bugzilla: Search to see if there are any reports about the update issue you have seen.

Drop a note into fedora-test-list: Please start a new thread only after you have attempted to find a previous discussion of this problem in the test-list or in bugzilla. Other testers can help you confirm the problem. 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 obtain assistance from other more experienced testers, but please do what you can to use the archives responsibly to avoid duplication of information and discussion.

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 rawhide the next day. For the curious, the build 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 Bugzilla

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 lists of packages that have been added, removed, or updated (with short changelog snippets), along with a list of any broken dependencies.