fedora-docs-l10n/packaging-guidelines/master/pages/ReviewGuidelines — English @ Fedora Weblate: [[rpmlint]]*MUST*: rpmlint must be run on the source rpm and …

Zen

Source string Source string

English

[[rpmlint]]*MUST*: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review. See xref:index.adoc#_use_rpmlint[Packaging Guidelines: Use rpmlint] +

Needs editing

The string is read only.

Skip

	English	Actions
	Package Review Guidelines
	This is a set of guidelines for Package Reviews. Note that a complete list of things to check for would be impossible, but every attempt has been made to make this document as comprehensive as possible. Reviewers and contributors (packagers) should use their best judgement whenever items are unclear, and if in doubt, ask on the https://lists.fedoraproject.org/admin/lists/packaging.lists.fedoraproject.org/[Fedora packaging list] .
	Package Review Process
	Contributors and reviewers MUST follow the https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/[Package Review Process], with the following exceptions:
	FPC grants an explicit exemption from the process, as indicated https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure[here].
	The package is being created so that multiple versions of the same package can coexist in the distribution (or coexist between EPEL and RHEL). The package MUST be properly named according to the xref:Naming.adoc#_multiple_packages_with_the_same_base_name[naming guidelines] and MUST NOT conflict with all other versions of the same package.
	The package exists in both Fedora and RHEL, but the packager wants to ship it in EPEL under an alternative name (as required by https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy[EPEL policy]) to provide a subpackage that exists in Fedora but does not exist (or is not shipped) in RHEL.
	Things To Check On Review
	There are many many things to check for a review. This list is provided to assist new reviewers in identifying areas that they should look for, but is by no means complete. Reviewers should use their own good judgement when reviewing packages. The items listed fall into two categories: SHOULD and MUST.
	[[rpmlint]]MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review. See xref:index.adoc#_use_rpmlint[Packaging Guidelines: Use rpmlint] +
	[[naming]] MUST: The package must be named according to the xref:Naming.adoc[Package Naming Guidelines] . +
	[[spec-fie-name]] MUST: The spec file name must match the base package `+%{name}+`, in the format `+%{name}.spec+` unless your package has an exemption. See xref:index.adoc#_spec_file_naming[Packaging Guidelines: Spec File Naming] . +
	[[packaging-guidelines]] MUST: The package must meet the xref:index.adoc[Packaging Guidelines] . +
	[[approved-license]] MUST: The package must be licensed with a Fedora approved license and meet the xref:LicensingGuidelines.adoc[Licensing Guidelines] . +
	[[license-field]] MUST: The License field in the package spec file must match the actual license. See xref:LicensingGuidelines.adoc#_valid_license_short_names[Licensing Guidelines: Valid License Short Names] +
	[[license-file]] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in `+%license+`. See xref:LicensingGuidelines.adoc#_license_text[Licensing Guidelines: License Text] +
	[[spec-in-american-english]] MUST: The spec file must be written in American English. See xref:index.adoc#_summary_and_description[Packaging Guidelines: Summary and description] +
	[[legible-spec]] MUST: The spec file for the package MUST be legible. See xref:index.adoc#_spec_legibility[Packaging Guidelines: Spec Legibility] +
	[[build-sources]] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use sha256sum for this task as it is used by the `+sources+` file once imported into git. If no upstream URL can be specified for this package, please see the xref:SourceURL.adoc[Source URL Guidelines] for how to deal with this. +
	[[successful-build]] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. See xref:index.adoc#_architecture_support[Packaging Guidelines: Architecture Support] +
	[[exclude-arch]] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in `+ExcludeArch+`. Each architecture listed in `+ExcludeArch+` MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding `+ExcludeArch+` line. See xref:index.adoc#_architecture_build_failures[Packaging Guidelines: Architecture Build Failures] +
	[[build-dependencies]] MUST: All build dependencies must be listed in `+BuildRequires+`. See xref:index.adoc#buildrequires[Packaging Guidelines: Build-Time Dependencies (BuildRequires)] +
	[[locales]] MUST: The spec file MUST handle locales properly. This is done by using the `+%find_lang+` macro. Using `+%{_datadir}/locale/*+` is strictly forbidden. See xref:index.adoc#_handling_locale_files[Packaging Guidelines: Handling Locale Files] +
	[[bundling]] MUST: Packages must NOT bundle copies of system libraries. See xref:index.adoc#bundling[Packaging Guidelines: Bundling and Duplication of System Libraries] +
	[[relocatable-package]] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. See xref:index.adoc#_relocatable_packages[Packaging Guidelines: Relocatable Packages] +

Loading…

None

String added in the repository

English

English 209 characters edited Current translation Read only

3 months ago

Browse all string changes

Things to check

Multiple failing checks

Following checks are failing:
Trailing newline: Finnish, Finnish, Portuguese (Brazil), Portuguese (Brazil)

Reset

Glossary

English	English
No related strings found in the glossary.

18363220 String information

Source string description

type: Plain text

Flags

read-only

Source string location

./pages/ReviewGuidelines.adoc:18

String age

3 months ago

Last updated

3 months ago

Source string age

3 months ago

Translation file

pot/master/pages/ReviewGuidelines.pot, string 10

	English	Actions
	Package Review Guidelines
	This is a set of guidelines for Package Reviews. Note that a complete list of things to check for would be impossible, but every attempt has been made to make this document as comprehensive as possible. Reviewers and contributors (packagers) should use their best judgement whenever items are unclear, and if in doubt, ask on the https://lists.fedoraproject.org/admin/lists/packaging.lists.fedoraproject.org/[Fedora packaging list] .
	Package Review Process
	Contributors and reviewers MUST follow the https://docs.fedoraproject.org/en-US/package-maintainers/Package_Review_Process/[Package Review Process], with the following exceptions:
	FPC grants an explicit exemption from the process, as indicated https://fedoraproject.org/wiki/Packaging_Committee#Review_Process_Exemption_Procedure[here].
	The package is being created so that multiple versions of the same package can coexist in the distribution (or coexist between EPEL and RHEL). The package MUST be properly named according to the xref:Naming.adoc#_multiple_packages_with_the_same_base_name[naming guidelines] and MUST NOT conflict with all other versions of the same package.
	The package exists in both Fedora and RHEL, but the packager wants to ship it in EPEL under an alternative name (as required by https://fedoraproject.org/wiki/EPEL/GuidelinesAndPolicies#Policy[EPEL policy]) to provide a subpackage that exists in Fedora but does not exist (or is not shipped) in RHEL.
	Things To Check On Review
	There are many many things to check for a review. This list is provided to assist new reviewers in identifying areas that they should look for, but is by no means complete. Reviewers should use their own good judgement when reviewing packages. The items listed fall into two categories: SHOULD and MUST.
	[[rpmlint]]MUST: rpmlint must be run on the source rpm and all binary rpms the build produces. The output should be posted in the review. See xref:index.adoc#_use_rpmlint[Packaging Guidelines: Use rpmlint] +
	[[naming]] MUST: The package must be named according to the xref:Naming.adoc[Package Naming Guidelines] . +
	[[spec-fie-name]] MUST: The spec file name must match the base package `+%{name}+`, in the format `+%{name}.spec+` unless your package has an exemption. See xref:index.adoc#_spec_file_naming[Packaging Guidelines: Spec File Naming] . +
	[[packaging-guidelines]] MUST: The package must meet the xref:index.adoc[Packaging Guidelines] . +
	[[approved-license]] MUST: The package must be licensed with a Fedora approved license and meet the xref:LicensingGuidelines.adoc[Licensing Guidelines] . +
	[[license-field]] MUST: The License field in the package spec file must match the actual license. See xref:LicensingGuidelines.adoc#_valid_license_short_names[Licensing Guidelines: Valid License Short Names] +
	[[license-file]] MUST: If (and only if) the source package includes the text of the license(s) in its own file, then that file, containing the text of the license(s) for the package must be included in `+%license+`. See xref:LicensingGuidelines.adoc#_license_text[Licensing Guidelines: License Text] +
	[[spec-in-american-english]] MUST: The spec file must be written in American English. See xref:index.adoc#_summary_and_description[Packaging Guidelines: Summary and description] +
	[[legible-spec]] MUST: The spec file for the package MUST be legible. See xref:index.adoc#_spec_legibility[Packaging Guidelines: Spec Legibility] +
	[[build-sources]] MUST: The sources used to build the package must match the upstream source, as provided in the spec URL. Reviewers should use sha256sum for this task as it is used by the `+sources+` file once imported into git. If no upstream URL can be specified for this package, please see the xref:SourceURL.adoc[Source URL Guidelines] for how to deal with this. +
	[[successful-build]] MUST: The package MUST successfully compile and build into binary rpms on at least one primary architecture. See xref:index.adoc#_architecture_support[Packaging Guidelines: Architecture Support] +
	[[exclude-arch]] MUST: If the package does not successfully compile, build or work on an architecture, then those architectures should be listed in the spec in `+ExcludeArch+`. Each architecture listed in `+ExcludeArch+` MUST have a bug filed in bugzilla, describing the reason that the package does not compile/build/work on that architecture. The bug number MUST be placed in a comment, next to the corresponding `+ExcludeArch+` line. See xref:index.adoc#_architecture_build_failures[Packaging Guidelines: Architecture Build Failures] +
	[[build-dependencies]] MUST: All build dependencies must be listed in `+BuildRequires+`. See xref:index.adoc#buildrequires[Packaging Guidelines: Build-Time Dependencies (BuildRequires)] +
	[[locales]] MUST: The spec file MUST handle locales properly. This is done by using the `+%find_lang+` macro. Using `+%{_datadir}/locale/*+` is strictly forbidden. See xref:index.adoc#_handling_locale_files[Packaging Guidelines: Handling Locale Files] +
	[[bundling]] MUST: Packages must NOT bundle copies of system libraries. See xref:index.adoc#bundling[Packaging Guidelines: Bundling and Duplication of System Libraries] +
	[[relocatable-package]] MUST: If the package is designed to be relocatable, the packager must state this fact in the request for review, along with the rationalization for relocation of that specific package. Without this, use of Prefix: /usr is considered a blocker. See xref:index.adoc#_relocatable_packages[Packaging Guidelines: Relocatable Packages] +

Shortcut	Action
`?`	Open available keyboard shortcuts.
`Alt` + `Home`	Navigate to the first translation in the current search.
`Alt` + `End`	Navigate to the last translation in the current search.
`Alt` + `PageUp` or `Ctrl` + `↑` or `Alt` + `↑` or `Cmd` + `↑` or	Navigate to the last translation in the current search.
`Alt` + `PageDown` or `Ctrl` + `↓` or `Alt` + `↓` or `Cmd` + `↓` or	Navigate to the next translation in the current search.
`Ctrl` + `Enter` or `Cmd` + `Enter`	Submit current form; this works the same as pressing Save and continue while editing translation.
`Ctrl` + `Shift` + `Enter` or `Cmd` + `Shift` +`Enter`	Unmark translation as Needing edit and submit it.
`Alt` + `Enter` or `Option` + `Enter`	Submit the string as a suggestion; this works the same as pressing Suggest while editing translation.
`Ctrl` + `E` or `Cmd` + `E`	Focus on translation editor.
`Ctrl` + `U` or `Cmd` + `U`	Focus on comment editor.
`Ctrl` + `M` or `Cmd` + `M`	Shows Automatic suggestions tab.
`Ctrl` + `1` to `Ctrl` + `9` or `Cmd` + `1` to `Cmd` + `9`	Copies placeable of a given number from source string.
`Ctrl` + `M` followed by `1` to `9` or `Cmd` + `M` followed by `1` to `9`	Copy the machine translation of a given number to current translation.
`Ctrl` + `I` followed by `1` to `9` or `Cmd` + `I` followed by `1` to `9`	Ignore one item in the list of failing checks.
`Ctrl` + `J` or `Cmd` + `J`	Shows the Nearby strings tab.
`Ctrl` + `S` or `Cmd` + `S`	Focus on search field.
`Ctrl` + `O` or `Cmd` + `O`	Copy the source string.
`Ctrl` + `Y` or `Cmd` + `Y`	Toggle the Needs editing checkbox.
`→`	Browse the next translation string.
`←`	Browse the previous translation string.