Releases/Rawhide/it

In other languages: English (en) español (es) Deutsch (de) italiano (it) português (pt) русский (ru) 中文（中国大陆） (zh-cn) [edit]

Rawhide è la denominazione che viene attribuito al ramo di sviluppo principale di Fedora. Il suo repository, Rawhide, contiene le più recenti compilazioni di tutti i pacchetti, distribuiti da Fedora che vengono aggiornati con scadenza giornaliera. Le Nightly builds (compilazioni giornaliere) diventano disponibili non appena inizia il ciclo di vita di una successiva release (Fedora Release Life Cycle).

Chi usa Rawhide

Gli utenti finali non dovrebbero usare la Rawhide come sistema per le proprie attività quotidiane, siano esse lavorative o di intrattenimento, infatti la Rawhide è parte di un processo continuo di sviluppo, in cui i molti cambiamenti effettuati non vengono intensamente testati, o non testati affatto, e i pacchetti una volta inseriti in Rawhide, potrebbero causare danni non prevedibili e soprattutto perdita di dati. D'altra parte, testare la Rawhide, è un'attività dall'alto valore aggiunto in quanto contribuisce direttamente allo sviluppo di Fedora e serve ad assicurare un livello qualitativamente alto alla successiva release pubblica. Inoltre permette di sperimentare (con cautela) con un certo anticipo le ultime novità sviluppate dalla community e che si troveranno nella release finale generale. Testare la Rawhide diventa quindi un modo per contribuire allo sviluppo di Fedora. Si può testare la Rawhide o la Branched, a seconda del ciclo di rilascio (release cycle) scaricandola da nightly live builds, senza neanche bisogno di installarla. Oppure, se si hanno risorse a disposizione, si può installarla o avviarla da una virtual machine.

Nightly Live Build

Le Nightly Build sono immagini ISO costituite da pacchetti Rawhide, compilate giornalmente, e che sono rese disponibili su http://alt.fedoraproject.org/pub/alt/nightly-composes/, durante il periodo che intercorre tra il rilascio di una final pubblica e l'avvio della Branched successiva (attualmente Fedora 41). Esse vengono compilate automaticamente e senza essere state testate, per cui possono non funzionare e qualche volta superare anche la dimensione di un CD. Comunque se nel corso delle compilazione giornaliere si riscontra un bug di compilazione, le immagini relative non vengono pubblicate e restano disponibili le immagini del giorno precedente. Le Nightly Build rappresentano un modo ideale per testare Rawhide se non si dispone di una mecchina secondaria, o una partizione su disco apposita, o non si vuole dedicare tempo ad installarla sulla propria macchina. E' un metodo sicuro perchè non apporta nessuna modifica ai sistemi esistenti, e se poi la Live per sè funziona bene, si può anche procedere con l'installazione della Rawhide sull'hard disk. Durante il rimanente ciclo di rilascio, a partire dalla Branched, le compilazioni giornaliere vengono dedicate a quest'ultima, e quindi occorre usare un repository dedicato per installare Rawhide.

Rawhide è progettato per essere installabile, tuttavia ci potrebbe essere un qualche stadio di sviluppo Rawhide, che a causa di qualche bug nell'installer o altri pacchetti, potrebbe creare problemi di installazione. Di seguito si indicano i modi per installare Rawhide.

No install: Testare Rawhide

Esistono sostanzialmente tre metodi per testare una release Rawhide senza creare alcun disturbo ad una installazione Fedora o altro S.O. esistente:

• Testare una versione Live su USB o DVD: Vedi avanti nella sezione.
• Usare una virtual machine: Vedi Testing/qemu.
• Installare la branched in una propria partizione.

I passaggi di base sono:

• Scaricare una immagine Live (.iso), compilata giornalmente, dal sito di distribuzione Fedora, http://alt.fedoraproject.org/pub/alt/nightly-composes/.
• Creare un supporto di boot (d'avvio) (vedi la sezione Realizzare un supporto di boot da una ISO) per avviare il sistema dalla Rawhide.
• Avviare il test: usare il nuovo sistema provando le varie funzionalità, i programmi comunemente usati e segnalando eventuali bug riscontrati.

Se si vuole installare la Branched sull'hard disk o effettuare un up-grade da una versione già presente, all'avvio della sessione avviare la procedura guidata d'installazione facendo un doppio-click sull'icona Installa sull'Hard Disk, presente in alto sul desktop.

Se si usa una LiveUSB con persistenza dei dati, si possono aggiornare i pacchetti RPM Rawhide, alle ultime versioni disponibili ad eccezione del kernel (except for the kernel), usando yum o il gestore grafico dei pacchetti PackageKit. Notare che occorre installare il pacchetto 'fedora-release-rawhide' ed abilitare il repository Rawhide. Tuttavia, in questa fase, per essere più sicuri sugli aggiornamenti, si raccomanda di utilizzare sempre una nuova versione ISO, fresca di giornata.

Installazione diretta via Live installer

{{Admon/note Il tempo è prezioso Questo metodo funziona solo tra il rilascio di una final e l'avvio della successiva Branched. Vedere la relese schedule per le scadenze. In fase Branched, seguire le istruzioni relative a questa fase. }}

1. Scaricare e creare un supporto d'avvio.
2. Avviare la sessione dalla Rawhide e fare doppio-click sull'icona Installa sull'hard disk, posta in alto sul desktop.
3. Seguire le istruzioni della procedura guidata per completare l'installazione.

Installazione diretta via Anaconda

Anaconda è il programma di installazione di Fedora, che può essere avviato direttamente senza bisogno di ricorrere ad una Live. Inoltre sono disponibili diverse opzioni di installazione il che lo rendono un programma molto flessibile.

Installazione diretta usando una release ISO di Anaconda

Si può usare la versione di Anaconda distribuita con una release finale (pubblica) (l'ultima disponibile è 40). Con questo metodo, si usa una versione dell'installer,
nota e funzionante in grado di installare il contenuto presente nel repository.

Di seguito si riportano tre opzioni possibili e consigliate, per installare una Rawhide:

Opzione 1 - Usare una copia di una precedente release

Se si possiede un disco CD/DVD o USB d'avvio, o una partizione contenente un'immagine *-DVD.iso/*-disc1.iso, è possibile usare una di esse per procedere all'installazione della Rawhide. Comunque, siccome queste immagini contengono le liste dei pacchetti RPM che costituisono la release generale di Fedora, precedente, essi non sono potranno essere usati per creare dischi di distribuzione della successiva release (la Rawhide). (Per maggiori informazioni vedi Downloading Fedora della Installation Guide). Le immagini di una Live, non possono essere usate per installare una Rawhide.

Opzione 2 - Scaricare un installer minimo

In questo caso si crea un supporto d'avvio su CD/DVD o USB, o su una partizione dell'hard disk (vedi Avviare Anaconda dall'hard disk), scaricando una immagine di boot, minima e successivamente si utilizza il supporto per avviare il sistema e scaricare i pacchetti RPM attraverso la rete. Tali file di boot sono denominati boot.iso o più generalmente *-netinst.iso (p.e. Fedora-13-i386-netinst.iso). Al momento essi non vengono distribuiti via BitTorrent.

I passaggi da seguire sono:

• Andare sul sito http://download.fedoraproject.org/ - da quì si sarà rediretti al mirror locale più vicino.
• Spostarsi nella directory releases/40/Fedora.
• Spostarsi nella directory dell'architettura del proprio sistema, i386, x86_64 o ppc (per maggiori informazioni vedi Which Architecture Is My Computer? della Installation Guide). Trovare e scaricare il file os/images/boot.iso.
• Usando il file boot.iso, creare un supporto d'avvio (CD/DVD o USB) o una partizione d'avvio sull'hard disk, seguendo le indicazioni in Making Fedora Media della Guide. Si può usare il metodo livecd-iso-to-disk ivi descritto, che riguarda una immagine Live, ma che funziona anche con un file boot.iso e per creare partizioni di avvio sull'hard disk.

Opzione 3 - Installare dalla rete senza supporto di avvio

Nel caso si decida di non usare un supporto d'avvio, nella Installation Guide si può vedere come avviare l'installer direttamente dalla rete.
(Preparing for a Network Installation).

Passi successivi

L'installazione è molto intuitiva, occorre solo fornire il mirror HTTP/FTP e seguire le indicazioni fornite dall'installer grafico di Anaconda. Per ottenere la Branched, a partire dall'URL del mirror di installazione, aggiungere "<mirrorroot>/development/rawhide/<arch>/os/ dove <mirrorroot>" è uno dei siti mirror ottenuti dalla lista dei mirror ufficiali e <arch> la propria architecture (i386, x86_64, o ppc). Per esempio:

• URL=http://fedora.mirror.garr.it/mirrors/fedora/linux/ (GARR MIRROR)
• mirroroot= /rawhide/i386/os/ (per un'architettura i386)

La compilazione giornaliera di Anaconda, non è più automaticamente disponibile in Rawhide, ma solo nella Branched.

Daily Anaconda builds are no longer automatically available in Rawhide, only in 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 has been created) rather than the release after the next release.

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

Upgrade via Anaconda

Upgrade da una precedente release via Preupgrade ed Anaconda

Una installazione molto più veloce, può essere effettuata da una copia esisente di Fedora con PreUpgrade. (Per istruzioni vedi How to use PreUpgrade). Durante questo processo, abilita la check-box accanto all'etichetta Display unstable test releases e abilita Fedora 41 (Branched), dall'elenco.

Upgrade da una test release

Se è disponibile una test release o pre-release (alpha o beta), esse solitamente si trovano sul sito http://fedoraproject.org/get-prerelease.

La test release non è configurata per aggiornarsi alla Rawhide, ma occorre dapprima installare il pacchetto "fedora-release-rawhide" e poi abilitare il repository Rawhide. Per ottenere gli aggiornamenti dei pacchetti, si può usare il comando yum update, in una console, o la GUI Aggiornamento Software, oppure attendere le notifiche di aggiornamento nel system tray (in alto a destra), da parte del sistema.

Poi, se successivamente si vuole passare dalla Rawhide alla release finale, vedere la pagina upgrading from pre-release to final.

Upgrade via Yum (sconsigliato)

Anche se generalmente non raccomandato, è possibile usare yum per aggiornare il sistema alla Branched. Anaconda infatti potrebbe effettuare dei cambiamenti che sono fuori della portata del sistema di gestione dei pacchetti. Inoltre si potrebbe incorrere in problemi di dipendenze, difficili da risolvere. Si ricordi inoltre, che l'upgrade va effettuato partendo dalla release immeditamente precedente (p.e. per passare alla Branched 41, partendo dalla 39, occorre aggiornare prima alla 40). Comunque la procedura è tediosa e soggetta a incongruenze, e riservata ad utenti molto esperti, quindi ci si tenga preparati ad inevitabili re-installazioni!.

Scaricare il pacchetto fedora-release-rawhide da https://admin.fedoraproject.org/pkgdb/acls/name/fedora-release.

Per completare l'installazione, usando la GUI:

1. Installare il pacchetto scaricato.

• Cliccare sul controllo Builds della pagina koji-packageinfo
• Controllare l'ultima compilazione disponibile (per esempio, fedora-release-15-0.2).
• Scaricare i file RPM corrispondenti (p.e. usando wget).
• Installare i file RPM: rpm -Uvh fedora-release-*.noarch.rpm.

1. Modificare i repository del software, usando gpk-repo, abilitando soltanto i repository Fedora e Rawhide.
2. Aggiornare il sistema usando gpk-update-viewer (Sistema -> Applicazioni -> Aggiorna il Software)

Per completare l'installazione, da un terminale, esguire in successione i seguenti comandi:

1. yum install fedora-release-rawhide
2. yum --disablerepo=* --enablerepo=rawhide,fedora update

Si potrebbere abilitare/disabilitare i repository in /etc/yum.repos.d/ in modo da avere abilitato solo il repo "Fedora Development". In tal modo gli aggiornamenti giornalieri verranno automaticamente segnalati nel system-tray del desktop, tes to appear by default in desktop notifications and "yum update".

Se il gestore dei pacchetti (yum) non riesce ad installare il pacchetto fedora-release-rawhide, si può procedere con una installazione manuale tramite rpm, dopo aver scaricato il pacchetto presente in "development/rawhide/<arch>/os/Packages/" da uno dei mirror Rawhide (per esempio, http://fedora.mirror.garr.it/mirrors/fedora/linux//development/rawhide/i386/os/Packages/fedora-release-rawhide-15-0.2.noarch.rpm).

Riferimenti

Realizzare un supporto di boot da una ISO

• Se si usa un supporto USB, vedere How to create and use Live USB:
• Se si usa un supporto ottico (CD/DVD), vedere Burning ISOs readme.

Avviare Anaconda dall'hard disk

I passi da seguire per avviare l'installer dall'hard disk sono i seguenti:

1. Salvare in una locazione, i file vmlinuz ed initrd.img, estratti da boot.iso di Anaconda. Prendere nota del numero del disco, della partizione e della directory in cui si trovano i files.
2. Modificare il file di grub, aggiungendo le informazioni raccolte, alla fine del file, per esempio come nelle seguenti righe:

title Avvio di Anaconda dall'hard disk (Fedora 41)
root (hd0,1) 
kernel /boot/vmlinuz lang=it_IT keymap=it
initrd /boot/initrd.img

dove

• title: è una stringa editabile a piacere
• root: punta al disco ed alla partizione contenente i file vmlinuz ed initrd da caricare. Nell'esempio (hd0,1), i files si trovano nella directory /boot (terza e quarta riga) della seconda partizione del primo disco.

I mirror della Rawhide

Rawhide sui mirrors, si trova in "development/rawhide". Per una lista di mirror "development", locali vedere elenco mirror.

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.

1. 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.
2. Search Bugzilla: Search to see if there are any reports about the update issue you have seen.
3. 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.
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 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.

Good resources for the state of many Fedora projects:

• http://git.fedoraproject.org/
• http://hg.fedoraproject.org/
• https://fedorahosted.org/

Reference

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