From Fedora Project Wiki
m (Add space character between words)
 
(13 intermediate revisions by 5 users not shown)
Line 1: Line 1:
{{autolang}}
<!-- page was renamed from Rawhide
<!-- page was renamed from Rawhide
-->
-->
Line 8: Line 9:
http://mirrors.fedoraproject.org/publiclist/Fedora/development/
http://mirrors.fedoraproject.org/publiclist/Fedora/development/


== Кому нужен Rawhide? ==
== Кому необходим Rawhide? ==


Rawhide не нужен если вы хотите использовать свой компьютер в качестве обычной, стабильной рабочей станции. Так как Rawhide это разрабатываемая ветка, большинство изменений серьезно не тестировались (или не тестировались вообще) до включения сюда, и пакеты могут не работать без каких либо предупреждений. Вот почему ошибки, содержащиеся в Rawhide могут привести к потере данных. Однако, тестирование Rawhide очень важный вид деятельности, который помогает обеспечить высокое качество стабильных релизов. Кроме того, это простой способ опробовать последние версии программного обеспечения по мере их появления. Тестирование Rawhide это отличный способ внести свой вклад в разработку Fedora. Вы можете опробовать Rawhide [http://alt.fedoraproject.org/pub/alt/nightly-composes/ ночную live сборку] без установки на компьютер. Или вы можете установить её на запасной компьютер, на основной компьютер с использованием двойной загрузки или используя виртуальную машину.
Rawhide не нужен если вы хотите использовать свой компьютер в качестве обычной, стабильной рабочей станции. Так как Rawhide это разрабатываемая ветка, большинство изменений серьезно не тестировались (или не тестировались вообще) до включения сюда, и пакеты могут не работать без каких либо предупреждений. Вот почему ошибки, содержащиеся в Rawhide могут привести к потере данных. Однако, тестирование Rawhide очень важный вид деятельности, который помогает обеспечить высокое качество стабильных релизов. Кроме того, это простой способ опробовать последние версии программного обеспечения по мере их появления. Тестирование Rawhide это отличный способ внести свой вклад в разработку Fedora. Вы можете опробовать Rawhide [http://alt.fedoraproject.org/pub/alt/nightly-composes/ ночную live сборку] без установки на компьютер. Или вы можете установить её на запасной компьютер, на основной компьютер с использованием двойной загрузки или используя виртуальную машину.
Line 32: Line 33:
# Установите в отдельный раздел.
# Установите в отдельный раздел.


{{anchor|Yum_update_from_official_release}}
=== Обновление с помощью Yum из официального релиза ===
=== Обновление с помощью Yum из официального релиза ===


Line 46: Line 48:
# Наберите: <pre># yum --disablerepo=* --enablerepo=rawhide update</pre>
# Наберите: <pre># yum --disablerepo=* --enablerepo=rawhide update</pre>


Возможно вы пожелаете включить/выключить репозитарии указанные в /etc/yum.repos.d/, так чтобы только репозитарий "Fedora Development" был доступен.  Это позволяет обновлять ежедневную сборку Rowhide с помощью уведомлений появляющихся на рабочем столе или с помощью "yum update".
Возможно вы пожелаете включить/выключить репозитарии указанные в /etc/yum.repos.d/, так чтобы только репозитарий "Fedora Development" был доступен.  Это позволяет обновлять ежедневную сборку Rawhide с помощью уведомлений появляющихся на рабочем столе или с помощью "yum update".


=== Из пре-релизов Fedora ===
=== Из пре-релизов Fedora ===
Line 74: Line 76:
===С помощью Preupgrade===
===С помощью Preupgrade===


Можно выполнить действие PreUpgrade для быстрой установки с помощью Anaconda.  См. [http://fedoraproject.org/wiki/How_to_use_PreUpgrade Как использовать PreUpgrade] для более детальной информации; просто выберите  "Rawhide" когда выбираете версию Fedora, которую собираетесь устанавливать.
Можно выполнить действие PreUpgrade в консоли <pre>preupgrade</pre> для быстрой установки с помощью Anaconda.  См. [[How_to_use_PreUpgrade|Как использовать PreUpgrade]] для более детальной информации; просто выберите  "Rawhide" когда выбираете версию Fedora, которую собираетесь устанавливать.


== Testing Rawhide ==
== Тестирование Rawhide ==


There are two important things all Rawhide testers should do. First, read the [https://www.redhat.com/mailman/listinfo/fedora-test-list 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 [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.
Существуют две важные вещи, которые все тестирующие Rawhide дожны выполнять. Во-первых, читать [https://www.redhat.com/mailman/listinfo/fedora-test-list список рассылки], здесь пользователи Rawhide обсуждают последние изменения. Вы найдёте обсуждение значительных изменений или предостережения о серьезных сбоях. Чтение этой рассылки является ключём, к тому что бы использовать новейшую версию Rawhide. Во-вторых, сообщайте обо всех ошибках, которые вы найдёте в [http://bugzilla.redhat.com Bugzilla] Rawhide. Пожалуйста, помните что об ошибках необходимо сообщать в Bugzilla, при этом соблюдая [[BugsAndFeatureRequests|такие]]. Отсылать сообщения об ошибках в список рассылки или IRC недостаточно, т.к. этот отчет быстро потеряется в логах. Только сообщения в Bugzilla будут всегда доступны для тестирующих Rawhide и для разработчиков.


Beyond that, here is some general advice which may be of use in using Rawhide:
Колме того ниже есть основные советы для тех кто пользуется 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.
* Когда используете yum, найдите немного времени чтобы просмотреть возможные действия над пакетами, прежде, чем вы продолжите. Не пропускайте этот важный шаг.
* Get familiar with the ''/var/log/rpmpkgs'' and ''/var/log/yum.log'' log files.
* Разберитесь с ''/var/log/rpmpkgs'' и ''/var/log/yum.log'' файлами логов.
* 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.
* Познакомьтесь с возможностями grub, чтобы выявлять ошибки при загрузке.  
* 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.
* Если будут какие-то проблемы с зависимостях не преодолевайте их грубым способом (nodeps). Вместо этого сообщите это как об ошибке в тестовый-лист. Если никто не сообщит об этом, это не будет исправлено и попадет в стабильный релиз.
* 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.
* Т.к. дерево разработки не гарантирует ежедневное согласование, то часто исползуемая команда ''yum update'' будет выдавать ошибки. Не паникуйте. Большинство проблем с зависимостями чинится разработчиками за 1 или 2 дня, часто запросом в дальнейшей пересборке пакета. Если вы видите ошибку в ''yum update'' в вашей системе несколько дней подряд, и не видите дискуссии об этом в тест-листе, почитайте далее как вы должны сообщить об этом.
* 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.
* Если есть одна ошибка (если например пакет зависит от старой библиотеки) который останавливает полное обновление Rawhide, вы можете использовать ''yum update --skip-broken'' чтобы обновить все пакеты. Однако убедитесь, что ошибка была сообщена разработчику виноватого пакета.
* 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.
* Вам возможно потребуется отключить проверку GPG в /etc/yum.conf или репозиторий fedora-devel в /etc/yum.repos.d если пакеты неправильно подписаны.


=== 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.
Присутствует ежедневный рапорт о дереве разработки, который посылается в лист fedora-test который посылается каждое утро как часть автоматического продвижения пакетов из деревьев доступа. Ежедневные доклады содержат информацию о новых, удаленных или обновленных пакетах. Также это содержит сводку проблем зависимостей для каждой архитектуры для которых они были собраны. Пожалуйста, если у вас будут какие-то проблемы в обновлением против дерева разработки, первое что вы должны сделать - это просмотреть последние два доклада по сборке. Если вы видите, что проблемы в зависимостях сходятся в последнем рапорте, значит разработчики осведомлены о проблеме. Люди сопровождающие пакет, получают ежедневные сообщения если их пакет в листе.  


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.
Помните, что список сломанных зависимостей, который является частью ежедневных отчетов rawhide представляет только первый слой зависимостей, а не весь лист. Не внесенные пакеты могут быть тоже затронуты, но починены когда большинство внесенных пакетов пересобраны.


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.
# прочитайте fedora-test-list: Вернитесь обратно к вашим архивам или веб архивам fedora-test-list и прочитайте последние сообщения за 48 часов и увидите если здесь дискуссии о каких-то спецефических ошибках обновлений которые вы можете увидеть. В общем говоря эти виды ошибок видят практически все с похожим аппаратным обеспечением, то есть есть большая вероятность, что тестеры ошибку уже обсуждают. Пожалуйста не пишите новое сообщение в fedora-test-list до того момента как не закончили читать последние сообщения за 48 часов. Чтение множества одинаковых сообщений только отнимает время у разработчиков и тестеров.
# search http://bugzilla.redhat.com: Search to see if there are any reports about the update issue you have seen
# поищите в http://bugzilla.redhat.com: поищите есть ли какие нибудь сообщения об проблема с обновлениями которое вы видите
# 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.
# напишите заметку в fedora-test-list: Пожалуйста начните дискуссию только когда убедитесь, что похожее сообщение не появилось в fedora-test-list or или bugzilla. Другие тестеры могут помочь подтвердить проблему, или если не могут, но найдут способ определить в чем причина ее появления типа конфигурирования или действий пользователя. fedora-test-list отличный способ получить помощь от других опытных пользователей, но пожалуйста используйте возможности архивов, чтобы избежать дупликатов дискуссий и ошибок.
# 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.
# Напишите новое сообщение об ошибке: когда проблема в зависимостях держится несколько дней или когда проблема похоже на специализированную в вашей ситуации и не похоже, что разработчик о ней осведомлен. Если вы не уверены в том как сообщить об ошибке, то опытные пользователи в fedora-test-list помогут вам в этом. Пожалуйста не предлагайте это как ошибку yum. 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"? ===


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 ежедневно и автоматически генерируется из последних пакетов которые были собраны. Пакеты которые собираются только для 1 дня обычно предназначены для тестовых дней.


(For the curious, the compose is done at Midnight US Eastern, 0400/0500 UTC.)
(Для любопытных, все сборки проводятся ночью по восточному США, 0400/0500 UTC.)


=== What is a rawhide "push"? ===
=== Что значит "точлек" rawhide? ===


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.
Это что-то в виде релиза rawhide на 1 день. Однако если он сломан он может быть еще раз пересобран.


=== Where do I communicate issues in Rawhide ? ===
=== Где я могу обсудить проблемы Rawhide ? ===


Use the fedora-test list or #fedora-qa IRC channel in Freenode. For bugs, report them to http://bugzilla.redhat.com
Используйте fedora-test лист или #fedora-qa IRC канал на Freenode. Для ошибок, сообщайте их в to http://bugzilla.redhat.com


=== How can I know what is changing in Rawhide? ===
=== Как я могу понято, что меняется в Rawhide? ===


Nightly reports are sent to fedora-test-list and fedora-devel-list, with the subject 'rawhide report: <date> changes'.
Ночные отчеты посылаются в fedora-test-list и fedora-devel-list, с темой '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
http://git.fedoraproject.org/ и http://hg.fedoraproject.org/ и https://fedorahosted.org/ также хорошая идея посмотреть в аптсриме многих проектов Fedora.
the upstream state of many Fedora projects.
 
[[Category:LocalizationRussian]]

Latest revision as of 22:40, 16 March 2018

Rawhide - так называется разрабатываемая в данный момент версия Fedora, состоящая из дневного среза последних скомпилированных версий всех пакетов Fedora.

Rawhide зеркала

Rawhide носит название "development" в дереве каталогов зеркал. Вы можете найти зеркало по следующей ссылке:
http://mirrors.fedoraproject.org/publiclist/Fedora/development/

Кому необходим Rawhide?

Rawhide не нужен если вы хотите использовать свой компьютер в качестве обычной, стабильной рабочей станции. Так как Rawhide это разрабатываемая ветка, большинство изменений серьезно не тестировались (или не тестировались вообще) до включения сюда, и пакеты могут не работать без каких либо предупреждений. Вот почему ошибки, содержащиеся в Rawhide могут привести к потере данных. Однако, тестирование Rawhide очень важный вид деятельности, который помогает обеспечить высокое качество стабильных релизов. Кроме того, это простой способ опробовать последние версии программного обеспечения по мере их появления. Тестирование Rawhide это отличный способ внести свой вклад в разработку Fedora. Вы можете опробовать Rawhide ночную live сборку без установки на компьютер. Или вы можете установить её на запасной компьютер, на основной компьютер с использованием двойной загрузки или используя виртуальную машину.

Ночные live сборки

С августа 2009 года доступна ночная live сборка. Она собирается автоматически, без дополнительной настройки или тестирования, поэтому иногда она не умещается на одном CD и может не работать вообще. Если появляется ошибка в инструментах сборки (toolchain), образ может вообще не собраться, в этом случае доступна последняя ночная сборка. Использование такой ночной сборки является идеальным способом потестировать Rowhide если у вас нет свободной машины, свободного раздела на диске или свободного времени на поддержку Rawhide установку. Это совершенно безопасный способ протестировать Rawhide, потому что не делается никаких изменений в установленной системе.

Установка Rawhide

Rawhide можно установить, однако, так как сборка создаётся автоматически, отдельные сборки могут не устанавливаться по той или иной причине. Существует три способа установить Rawhide.

Как избежать изменений в установленной системе

Существует несколько методов тестирования Rawhide на компьютере без изменений существующей системы:

  1. Тестировать Live версию с CD, DVD или USB носителя.
    • См. http://fedoraproject.org/get-prerelease для загрузки (milestone не ежедневный) пре-релиз ISO.
    • См. http://alt.fedoraproject.org/pub/alt/nightly-composes/ если хотите протестировать пре-релиз ISO собранный из ежедневной сборки. Доступны различные ежедневные сборки, но "desktop" сборка одна из наиболее распространенных.
    • Чтобы за записать CD или DVD, см. инструкцию по записи ISO.
    • Чтобы записать USB см. How to create and use Live USB.
    • Если вы используете LiveUSB с хранилищем данных, вы можете использовать метод "yum update", описанный ниже, чтобы получить последнюю ежедневную сборку Rawhide RPMs (за исключением ядра). Однако рекомендуется загружать ежедневный ISO образ, вместо использования данного метода.
  2. Используйте виртуальную машину. См. Testing/qemu.
  3. Установите в отдельный раздел.

Обновление с помощью Yum из официального релиза

Подробную информацию по установке подходящего релиза Fedora см. на странице Руководство по установке.

Как только ваша система будет установлена, вы можете обновить из репозитария rawhide двумя способами. Используя графические приложения:

  1. Сначала измените источники программного обеспечения (software sources) с помощью: gpk-repo
    • Оставьте отмеченным только Fedora - Rawhide источник
  2. Затем обновите систему с помощью: gpk-update-viewer

Или вы можете обновить систему используя консоль:

  1. Наберите:
    # yum --disablerepo=* --enablerepo=rawhide update

Возможно вы пожелаете включить/выключить репозитарии указанные в /etc/yum.repos.d/, так чтобы только репозитарий "Fedora Development" был доступен. Это позволяет обновлять ежедневную сборку Rawhide с помощью уведомлений появляющихся на рабочем столе или с помощью "yum update".

Из пре-релизов Fedora

Скачайте дистрибутив с: http://fedoraproject.org/get-prerelease

Протестируйте релиз Fedora который по умолчанию сконфигурирован на обновление из Rawhide репозитария, таким образом вы можете запустить "yum update" или подождать появления уведомления об обновлении на рабочем столе.

Вопросы по обновлению с пре-релиза до основного релиза Fedora обсуждаются на странице

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

Прямая установка ежедневной сборки Rawhide

Такой же процесс, какой используется для установки релиза Fedora (с помощью Anaconda), может быть использован и для установки rawhide. Для просмотра описания этого процесса взгляните на Руководство по установке.

  1. Определите архитектуру вашей системы
  2. Отыщите ближайшее зеркало с которого вы можете загрузить установочный носитель
  3. Загрузите файл boot.iso для вашей архитектуры
  4. Запишите загруженный образ на CD/DVD
  5. Загрузитесь с CD/DVD диска
Idea.png
Нет CD/DVD или запасного привода?
См. советы по установке системы, без использования привода, с помощью сетевого интерфейса http://docs.fedoraproject.org/install-guide/f39/en-US/html/ap-medialess-install.html.

Следуйте инструкциям графического установщика Anaconda, появляющимся на экране. Установка очень проста. Вам необходимо выполнить HTTP/FTP установку. В качестве URL вашего 'install tree', используйте "<mirrorroot>/development/<arch>/os/" где <mirrorroot> это зеркало, URL которого вы получили со списка зеркал.

С помощью Preupgrade

Можно выполнить действие PreUpgrade в консоли

preupgrade

для быстрой установки с помощью Anaconda. См. Как использовать PreUpgrade для более детальной информации; просто выберите "Rawhide" когда выбираете версию Fedora, которую собираетесь устанавливать.

Тестирование Rawhide

Существуют две важные вещи, которые все тестирующие Rawhide дожны выполнять. Во-первых, читать список рассылки, здесь пользователи Rawhide обсуждают последние изменения. Вы найдёте обсуждение значительных изменений или предостережения о серьезных сбоях. Чтение этой рассылки является ключём, к тому что бы использовать новейшую версию Rawhide. Во-вторых, сообщайте обо всех ошибках, которые вы найдёте в Bugzilla Rawhide. Пожалуйста, помните что об ошибках необходимо сообщать в Bugzilla, при этом соблюдая такие. Отсылать сообщения об ошибках в список рассылки или IRC недостаточно, т.к. этот отчет быстро потеряется в логах. Только сообщения в Bugzilla будут всегда доступны для тестирующих Rawhide и для разработчиков.

Колме того ниже есть основные советы для тех кто пользуется Rawhide:

  • Правильный подход к тестовому релизу - это ценный шанс узнать больше о вашей системе. Это хорошая возможность встретиться с какими-либо проблемами и багами в сусбсистеме или компонентах с которыми вы не знакомы, как части тестирования. Используйте это как возможность изучить субсистему и документацию. Даже если в документации есть ошибки, вы можете помочь в ее исправлении или если она устарела. Чем больше вы учитесь, тем эффективнее вы можете быть в будущем если вы будете участвовать в процессе разработки. Будьте активными читая документацию о том как вещи работают, это поможет получить вам больше ценного опыта.
  • Когда используете yum, найдите немного времени чтобы просмотреть возможные действия над пакетами, прежде, чем вы продолжите. Не пропускайте этот важный шаг.
  • Разберитесь с /var/log/rpmpkgs и /var/log/yum.log файлами логов.
  • Заведите записную книжку и вносите записи о конфигурациях в системе которые вы делаете. Многие проблемы могут быть отслежены в простых ошибках конфигурации, но шибки так же могут и быть в обновлениях пакетов. Когда работаете вместе с другими тестерами, чтобы подтвердить подтвердить ошибку, заметки которые вы делали в процессе обновления\перезагрузки могут быть очень ценными, чтобы аккуратно локализовать проблему.
  • Всегда храните запасное ядро если вы хотите, чтобы все работало как ожидалось.
  • Перезагружайтесь ежедневно, если вы хотите видеть как обновления подействовали на систему. Гораздо тяжелее найти проблему в загрузке если она появилась со старым обновление, если вы обновлялись ежедневно но не перезагружались.
  • Познакомьтесь с возможностями grub, чтобы выявлять ошибки при загрузке.
  • Если будут какие-то проблемы с зависимостях не преодолевайте их грубым способом (nodeps). Вместо этого сообщите это как об ошибке в тестовый-лист. Если никто не сообщит об этом, это не будет исправлено и попадет в стабильный релиз.
  • Т.к. дерево разработки не гарантирует ежедневное согласование, то часто исползуемая команда yum update будет выдавать ошибки. Не паникуйте. Большинство проблем с зависимостями чинится разработчиками за 1 или 2 дня, часто запросом в дальнейшей пересборке пакета. Если вы видите ошибку в yum update в вашей системе несколько дней подряд, и не видите дискуссии об этом в тест-листе, почитайте далее как вы должны сообщить об этом.
  • Если есть одна ошибка (если например пакет зависит от старой библиотеки) который останавливает полное обновление Rawhide, вы можете использовать yum update --skip-broken чтобы обновить все пакеты. Однако убедитесь, что ошибка была сообщена разработчику виноватого пакета.
  • Вам возможно потребуется отключить проверку GPG в /etc/yum.conf или репозиторий fedora-devel в /etc/yum.repos.d если пакеты неправильно подписаны.

Когда сообщать о проблемах обновления

Присутствует ежедневный рапорт о дереве разработки, который посылается в лист fedora-test который посылается каждое утро как часть автоматического продвижения пакетов из деревьев доступа. Ежедневные доклады содержат информацию о новых, удаленных или обновленных пакетах. Также это содержит сводку проблем зависимостей для каждой архитектуры для которых они были собраны. Пожалуйста, если у вас будут какие-то проблемы в обновлением против дерева разработки, первое что вы должны сделать - это просмотреть последние два доклада по сборке. Если вы видите, что проблемы в зависимостях сходятся в последнем рапорте, значит разработчики осведомлены о проблеме. Люди сопровождающие пакет, получают ежедневные сообщения если их пакет в листе.

Помните, что список сломанных зависимостей, который является частью ежедневных отчетов rawhide представляет только первый слой зависимостей, а не весь лист. Не внесенные пакеты могут быть тоже затронуты, но починены когда большинство внесенных пакетов пересобраны.

Если проблема в вашей систему существует больше нескольких дней, и она не опубликована ни в одном из дневных отчетов, то это может быть индификатором, что вы попали на индивидуальную ошибку и не у всех она проявляется Это все будет понятно, когда вы попадете в шкуру тестера. Но до того как вы опубликуете сообщение об ошибки вот некоторая информация которая позволит вам воздержаться от лишнего заполнения. Пожалуйста помните, что тестовые релизы существуют в первую очередь для того, чтобы разработчики находили проблемы которые они могут починить в время текущего релиза. К сожелению импульсивное сообщение об ошибки (для дупликата) или давно известное решение отнимают у разработчика только время.

  1. прочитайте fedora-test-list: Вернитесь обратно к вашим архивам или веб архивам fedora-test-list и прочитайте последние сообщения за 48 часов и увидите если здесь дискуссии о каких-то спецефических ошибках обновлений которые вы можете увидеть. В общем говоря эти виды ошибок видят практически все с похожим аппаратным обеспечением, то есть есть большая вероятность, что тестеры ошибку уже обсуждают. Пожалуйста не пишите новое сообщение в fedora-test-list до того момента как не закончили читать последние сообщения за 48 часов. Чтение множества одинаковых сообщений только отнимает время у разработчиков и тестеров.
  2. поищите в http://bugzilla.redhat.com: поищите есть ли какие нибудь сообщения об проблема с обновлениями которое вы видите
  3. напишите заметку в fedora-test-list: Пожалуйста начните дискуссию только когда убедитесь, что похожее сообщение не появилось в fedora-test-list or или bugzilla. Другие тестеры могут помочь подтвердить проблему, или если не могут, но найдут способ определить в чем причина ее появления типа конфигурирования или действий пользователя. fedora-test-list отличный способ получить помощь от других опытных пользователей, но пожалуйста используйте возможности архивов, чтобы избежать дупликатов дискуссий и ошибок.
  4. Напишите новое сообщение об ошибке: когда проблема в зависимостях держится несколько дней или когда проблема похоже на специализированную в вашей ситуации и не похоже, что разработчик о ней осведомлен. Если вы не уверены в том как сообщить об ошибке, то опытные пользователи в fedora-test-list помогут вам в этом. Пожалуйста не предлагайте это как ошибку yum. Most dependency issues are packaging bugs in one of the packages detailed in the error messages. Множество примеров ошибок сводятся к тому, что один из пакетов затронут в логах ошибок пакетов.

Что значит если что-то "попадает в Rawhide"?

Rawhide ежедневно и автоматически генерируется из последних пакетов которые были собраны. Пакеты которые собираются только для 1 дня обычно предназначены для тестовых дней.

(Для любопытных, все сборки проводятся ночью по восточному США, 0400/0500 UTC.)

Что значит "точлек" rawhide?

Это что-то в виде релиза rawhide на 1 день. Однако если он сломан он может быть еще раз пересобран.

Где я могу обсудить проблемы Rawhide ?

Используйте fedora-test лист или #fedora-qa IRC канал на Freenode. Для ошибок, сообщайте их в to http://bugzilla.redhat.com

Как я могу понято, что меняется в Rawhide?

Ночные отчеты посылаются в fedora-test-list и fedora-devel-list, с темой 'rawhide report: <date> changes'. Включаются в те доклады тех сообщений который были добавлены, удалены или обновлены, вместе со списком сломанных зависимостей.

http://git.fedoraproject.org/ и http://hg.fedoraproject.org/ и https://fedorahosted.org/ также хорошая идея посмотреть в аптсриме многих проектов Fedora.