| |
@@ -4,13 +4,13 @@
|
| |
It consists of a xref:quick-docs::repositories.adoc[package repository] called "rawhide" and contains the latest build of all Fedora Linux packages updated on a daily basis.
|
| |
Each day, the build system attempts to create a full set of deliverables (installation images and so on), and all that compose successfully are included in the Rawhide tree for that day.
|
| |
|
| |
- Rawhide is sometimes called "development" or "main" (as it's the "main" branch in package git repositories).
|
| |
+ Rawhide is sometimes called "development" or "main" (as it's the "main" branch in package git repositories).
|
| |
|
| |
== Goals
|
| |
|
| |
- Rawhide has the following Goals:
|
| |
+ Rawhide has the following Goals:
|
| |
|
| |
- * To allow package maintainers to integrate the newest _usable_ versions of their packages into Fedora.
|
| |
+ * To allow package maintainers to integrate the newest _usable_ versions of their packages into Fedora.
|
| |
* To allow advanced users access to the newest _usable_ packages in a rolling manner.
|
| |
* To allow incremental changes to packages that are either too minor or major to go to stable Fedora releases.
|
| |
* To identify and fix issues with packages before they reach a stable release of Fedora.
|
| |
@@ -18,9 +18,9 @@
|
| |
|
| |
== Audience
|
| |
|
| |
- Rawhide is targeted at advanced users, testers, and package maintainers.
|
| |
+ Rawhide is targeted at advanced users, testers, and package maintainers.
|
| |
|
| |
- As a Rawhide consumer, you should:
|
| |
+ As a Rawhide consumer, you should:
|
| |
|
| |
* Be willing to update on an almost daily basis.
|
| |
Rawhide gets hundreds of updates a day, and applying those updates on a regular basis allows you to more easily isolate when a bug appeared and what package(s) are responsible.
|
| |
@@ -31,7 +31,7 @@
|
| |
Rawhide packages stick closely to upstream projects, so interfaces and command-line options are subject to frequent changes.
|
| |
* Be willing to reboot frequently to test new kernel versions and confirm functionality of the boot process.
|
| |
If you can't reboot often, consider using a stable release instead.
|
| |
- * Be willing and able to report bugs to bugzilla as you find them and help maintainers gather information to fix them.
|
| |
+ * Be willing and able to report bugs to Bugzilla as you find them and help maintainers gather information to fix them.
|
| |
|
| |
If the above doesn't match you, you may wish to instead follow the xref:branched.adoc[Branched] release (depending on the point in the https://fedorapeople.org/groups/schedule/[release cycle]) or use regular stable Fedora releases.
|
| |
|
| |
@@ -41,7 +41,7 @@
|
| |
|
| |
== Discussing Rawhide
|
| |
|
| |
- There are a number of ways to communicate with other Rawhide users:
|
| |
+ There are a number of ways to communicate with other Rawhide users:
|
| |
|
| |
=== IRC
|
| |
|
| |
@@ -54,7 +54,7 @@
|
| |
=== Bugzilla
|
| |
|
| |
Rawhide bugs should be reported against the _Fedora_ product, _rawhide_ version and the affected component.
|
| |
- Please do follow https://fedoraproject.org/wiki/Bugs_and_feature_requests[best practices] when filing.
|
| |
+ Please do follow xref:quick-docs::howto-file-a-bug.adoc[best practices] when filing.
|
| |
Remember that IRC and mailing lists are useful to help narrow down if some behavior is a bug or where to report it, but are themselves not bug reporting channels.
|
| |
Always file bugs in http://bugzilla.redhat.com[Bugzilla].
|
| |
|
| |
@@ -63,9 +63,9 @@
|
| |
|
| |
== Producing Rawhide
|
| |
|
| |
- Package owners must build for Rawhide using koji just like you would any other build; you do not go through the Bodhi process and the build becomes available almost immediately.
|
| |
+ Package owners must build for Rawhide using Koji just like you would any other build; you do not go through the Bodhi process and the build becomes available almost immediately.
|
| |
|
| |
- The Rawhide repository is composed every day starting at 05:15UTC.
|
| |
+ The Rawhide repository is composed every day starting at 05:15 UTC.
|
| |
All rawhide builds in the buildsystem at that time are included in the compose attempt.
|
| |
The compose process also attempts to build all the standard Fedora 'deliverables' (live and install images, ARM and Cloud disk images, container images and so on).
|
| |
If any release-blocking image fails to build as part of the compose, the compose is considered to have failed.
|
| |
@@ -73,42 +73,42 @@
|
| |
(A system where the sync only happens if a set of automated tests run on it passes is planned, but not yet fully implemented).
|
| |
|
| |
Rawhide is under `development/rawhide` on the mirrors.
|
| |
- You can find a local "development" mirror on the http://mirrors.fedoraproject.org/publiclist/Fedora/development/[public mirror list]. Compose time varies depending on number of changes but is typically between 5 and 8 hours.
|
| |
+ You can find a local "development" mirror on the http://mirrors.fedoraproject.org/publiclist/Fedora/development/[public mirror list]. Compose time varies depending on number of changes, but is typically between 5 and 8 hours.
|
| |
|
| |
- Composes are done in a rawhide chroot using the 'pungi' tool called from https://pagure.io/pungi-fedora/blob/master/f/nightly.sh[a script maintained by Fedora Release engineering].
|
| |
- If the base set of packages in Rawhide needed to compose Rawhide are broken, the daily compose may fail.
|
| |
+ Composes are done in a rawhide chroot using the 'pungi' tool called from https://pagure.io/pungi-fedora/blob/main/f/nightly.sh[a script maintained by Fedora Release engineering].
|
| |
+ If the base set of packages in Rawhide needed to compose Rawhide are broken, the daily compose may fail.
|
| |
|
| |
A report for each Rawhide compose is sent to to the https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org/[test] and https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org/[devel] lists.
|
| |
This report contains output from the repodiff tool from the previous compose as well as a broken dependency report for packages with broken dependencies.
|
| |
- Additionally, private email is sent to maintainers with packages containing broken dependencies.
|
| |
+ Additionally, private email is sent to maintainers with packages containing broken dependencies.
|
| |
|
| |
- Package maintainers should read and follow the xref:fesco::Updates_Policy.adoc#rawhide[Rawhide updates policy] for building any packages in Rawhide.
|
| |
+ Package maintainers should read and follow the xref:fesco::Updates_Policy.adoc#_rawhide[Rawhide updates policy] for building any packages in Rawhide.
|
| |
|
| |
If needed and approved by xref:fesco::index.adoc[FESCo], mass rebuilds are done by Release Engineering in Rawhide a month or so before the next release branches from it.
|
| |
- Typically these are done for a global change over all packages such as a new gcc release, or rpm package format.
|
| |
+ Typically these are done for a global change over all packages such as a new gcc release, or rpm package format.
|
| |
|
| |
== Questions and Answers
|
| |
|
| |
*Doesn't rawhide eat babies / kill pets / burn down houses / break constantly?*
|
| |
|
| |
No.
|
| |
- Please stop telling everyone that.
|
| |
+ Please stop telling everyone that.
|
| |
|
| |
*So Rawhide is very stable and we can all use it?*
|
| |
|
| |
No. See audience above.
|
| |
- There are things that break from time to time, but if you are able to downgrade or troubleshoot such issues aren't too severe.
|
| |
+ There are things that break from time to time, but if you are able to downgrade or troubleshoot, such issues aren't too severe.
|
| |
Most users should still stick to stable Fedora releases, but Rawhide is a viable option for enthusiasts to experiment with.
|
| |
|
| |
*I'm using a Stable Fedora release, but I want a newer package version that's only available in Rawhide. Can I just `dnf install` it?*
|
| |
|
| |
No
|
| |
- Mixing releases like this is a bad idea. Better options are:
|
| |
+ Mixing releases like this is a bad idea. Better options are:
|
| |
|
| |
* Ask the Fedora maintainer in a bug report to update the stable version if permitted by policy.
|
| |
If not, there may be a http://copr.fedoraproject.org/[Copr repository] that provides the updated version.
|
| |
See the COPR page for more details.
|
| |
- * Obtain the src.rpm for the package you wish and try and to `rpmbuild --rebuild` it (which may or may not work depending on dependencies).
|
| |
+ * Obtain the src.rpm for the package you wish and try to `rpmbuild --rebuild` it (which may or may not work depending on dependencies).
|
| |
|
| |
*I want to run the Rawhide kernel on my stable Fedora machine. Can I do that?*
|
| |
|
| |
@@ -123,7 +123,7 @@
|
| |
|
| |
*How can I tell when the Rawhide compose for the day has finished?*
|
| |
|
| |
- Check the for the reports sent to the https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org/[test] and https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org/[devel] lists, or watch fedora-messaging for the `org.fedoraproject.prod.pungi.compose.status.change` topic.
|
| |
+ Check the reports sent to the https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org/[test] and https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org/[devel] lists, or watch fedora-messaging for the `org.fedoraproject.prod.pungi.compose.status.change` topic.
|
| |
|
| |
*What happens during branching, does it affect my Rawhide release somehow?*
|
| |
|
| |
@@ -152,7 +152,7 @@
|
| |
*As a package maintainer do I have to build rawhide packages or does the nightly compose take care of that?*
|
| |
|
| |
You must build for Rawhide yourself (using Koji).
|
| |
- The nightly compose only collects packages already built and marked with the appropriate target (rawhide) in koji.
|
| |
+ The nightly compose only collects packages already built and marked with the appropriate target (rawhide) in Koji.
|
| |
|
| |
*Are rawhide packages signed?*
|
| |
|
| |
@@ -166,22 +166,22 @@
|
| |
** `dnf history`
|
| |
** `dnf update --skip-broken`
|
| |
** `koji download-build`
|
| |
- * If you are using a immutable variant like Silverblue, you should make good use of the features of OSTree like:
|
| |
+ * If you are using an immutable variant like Silverblue, you should make good use of the features of OSTree like:
|
| |
** `rpm-ostree rollback`
|
| |
** `ostree admin config-diff`
|
| |
** `ostree admin pin 0`
|
| |
* You should update frequently (preferably every day).
|
| |
This allows you to more easily narrow down when a problem or issue appeared.
|
| |
- If you apply a week of Rawhide updates at once you have many more packages to examine to narrow down issues.
|
| |
+ If you apply a week of Rawhide updates at once, you have many more packages to examine to narrow down issues.
|
| |
* Reboot often (preferably whenever new kernels arrive).
|
| |
This allows you to test the boot up process and packages related to it, as well as newer kernels.
|
| |
- Read and understand the Dracut troubleshooting steps.
|
| |
+ Read and understand the Dracut troubleshooting steps.
|
| |
* Follow the https://lists.fedoraproject.org/admin/lists/test@lists.fedoraproject.org/[test] and https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org/[devel] lists for Rawhide issues.
|
| |
Try to at least skim them before doing your daily Rawhide updates.
|
| |
Look for '[rawhide]' subjects or reports of issues.
|
| |
- Additionally if you find a problem and are not sure what to file bugs against you can open a discussion there.
|
| |
+ Additionally, if you find a problem and are not sure what to file bugs against, you can open a discussion there.
|
| |
* Rawhide kernels are often built with varying degrees of debugging code enabled, which will result in worse performance and increased resource usage. See https://fedoraproject.org/wiki/KernelDebugStrategy[Kernel Debugging Strategy] for details on exactly what debugging code is enabled for which kernel builds.
|
| |
- You can disable SLUB debugging for those builds for which it is enabled by passing `slub_debug=-` to your kernel command line in `/etc/default/grub` (and re-generating your grub config, or just adding it directly).
|
| |
+ You can disable SLUB debugging for those builds for which it is enabled by passing `slub_debug=-` to your kernel command line in `/etc/default/grub` (and re-generating your GRUB config, or just adding it directly).
|
| |
Additionally, you can run kernels in the https://fedoraproject.org/wiki/RawhideKernelNodebug[Rawhide Kernel Nodebug] repo that have all debugging disabled.
|
| |
* If you are using a graphical desktop environment in your Rawhide install, you may wish to install several of them.
|
| |
This allows you to still login and troubleshoot when your primary desktop environment is not working for some reason.
|
| |
@@ -189,9 +189,9 @@
|
| |
|
| |
== History
|
| |
|
| |
- Red Hat Linux "Raw Hide" http://lwn.net/1998/0820/rawhide.html[announcement]
|
| |
+ Red Hat Linux "Raw Hide" http://lwn.net/1998/0820/rawhide.html[announcement].
|
| |
|
| |
- The name might come from the http://en.wikipedia.org/wiki/Rawhide_%28song%29[song with the same name] that starts with "Rolling, rolling, rolling, ..."
|
| |
+ The name might come from the http://en.wikipedia.org/wiki/Rawhide_%28song%29[song with the same name] that starts with "Rolling, rolling, rolling, ...".
|
| |
|
| |
At one time, Rawhide would freeze before release milestones.
|
| |
This was changed with the https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal[No Frozen Rawhide Proposal] and Branched process which we now follow.
|
| |