Bug 1837107 - Review Request: 7kaa - Seven Kingdoms: Ancient Adversaries (claiming ownership of package)
Summary: Review Request: 7kaa - Seven Kingdoms: Ancient Adversaries (claiming ownershi...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Robert-André Mauchin 🐧
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-18 20:30 UTC by Andy Mender
Modified: 2020-09-21 00:00 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-07-22 01:20:07 UTC
Type: Bug
zebob.m: fedora-review+


Attachments (Terms of Use)
Paul Dufresne... version 1 (for this bug) of 7kaa.spec (3.42 KB, text/plain)
2020-05-20 16:33 UTC, Paul Dufresne
no flags Details
License file for the music of 7KAA (apparently original music of the game) (947 bytes, text/plain)
2020-05-25 08:55 UTC, Paul Dufresne
no flags Details

Description Andy Mender 2020-05-18 20:30:25 UTC
Spec URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa.spec
SRPM URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa-2.15.3-1.fc32.src.rpm?raw=true

COPR Project: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/

Description:
Seven Kingdoms is a real-time strategy (RTS) computer game developed
by Trevor Chan of Enlight Software. The game enables players to
compete against up to six other kingdoms allowing players to conquer
opponents by defeating them in war (with troops or machines),
capturing their buildings with spies, or offering opponents money
for their kingdom.

Seven Kingdoms: Ancient Adversaries is a free patch provided by
Interactive Magic and added three new cultures, the Egyptians, the
Mughals and the Zulus, and a new war machine, Unicorn.


rpmlint:
=============

$ rpmlint SPECS/7kaa/7kaa.spec SRPMS/7kaa* RPMS/*/7kaa*
7kaa-data.noarch: W: no-documentation
7kaa-music.noarch: W: no-documentation
7kaa-music.noarch: W: no-manual-page-for-binary 7kaa-data-installer
7kaa-music.noarch: W: dangerous-command-in-%postun rm
7kaa.x86_64: W: no-manual-page-for-binary 7kaa
6 packages and 1 specfiles checked; 0 errors, 5 warnings.

Comment 1 Dominik 'Rathann' Mierzejewski 2020-05-19 14:54:03 UTC
BuildRequires:  gcc-c++
BuildRequires: SDL2-devel, SDL2_net-devel
BuildRequires: enet-devel
BuildRequires: openal-soft-devel, autoconf
BuildRequires: gettext-devel
BuildRequires: desktop-file-utils
BuildRequires: ImageMagick
BuildRequires: libcurl-devel
BuildRequires: automake

It is a matter of taste, but I'd put one dependency per line and sort alphabetically.
It's easier to follow and makes diffs smaller in case of dependency changes.

%postun music
if [ $1 -eq 0 ] ; then
## When Uninstall
    rm -fr %{prj_music_dir}
fi

This is unnecessary (and rpmlint warns about it being dangerous).
You can get the list of files that autodownloader will download and include it with %ghost marker instead.

cd /tmp/%{name}-music
tar xjvf /tmp/%{name}-music/%{name}-music.tar.bz2
sudo install -v -m 644 /tmp/%{name}-music/%{name}-music/music/* %{_datadir}/%{name}/music
sudo install -v -m 644 /tmp/%{name}-music/%{name}-music/*.txt %{_docdir}/%{name}-music

This should use mktemp instead of a hard-coded directory name.
Moreover, /tmp is an in-memory file system and may not have enough space.
mktemp -p /var/tmp -d looks like a good solution here.
Also, you should not assume that sudo will be configured.

Comment 2 Paul Dufresne 2020-05-20 16:31:35 UTC
Hi!
I am in a similar situation as you do... not a developer... yet... and having resurrected (at least for me) 7kaa, about 1 or 2 months ago.

I had/have the feeling that you have to come with your own package to request to become a Fedora developer, rathern than unretire... so as to show your skills. So I was/am still searching a project to package... and got entangled with the release of Fedora 32, and trying to catch up with the devel mailing list.

I did use other distros info when I made my 7kaa package... in part for the description... that I stole from OpenSuse ... I think.

Anyway... I think I will just attach my spec file here... as a point of comparison ... I did not even try to compare with yours yet.

Comment 3 Paul Dufresne 2020-05-20 16:33:29 UTC
Created attachment 1690304 [details]
Paul Dufresne... version 1 (for this bug) of 7kaa.spec

Comment 4 Andy Mender 2020-05-23 11:07:57 UTC
Thank you very much for feedback, both of you. I introduced quite some improvements to the spec file:
- Cleaned up the BuildRequired section for the main package
- Removed the invalid %postun section
- Used wget instead of the autodownloader script + its own external config to allow music downloading post-install
- Removed superfluous 7kaa-data package definition
- Removed dependency on ImageMagick in favor of the new icon supplied with the sources
- Other minor fixes

Spec URL: Spec URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa.spec
SRPM URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa-2.15.3-2.fc32.src.rpm?raw=true

COPR Project: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/

@Paul Per my understanding of the Fedora docs on joining the project, claiming ownership of an orphaned/retired package is also acceptable. If that's not the case, I actually have another gaming project in mind already :).

Comment 5 Paul Dufresne 2020-05-25 08:13:14 UTC
About downloading the music, see:
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_build_time_network_access

"Packages in the Fedora buildsystem are built in a mock chroot with no access to the internet. Packages must not depend or or use any network resources that they don’t themselves create (i.e., for tests). In no cases should source code be downloaded from any external sources, only from the lookaside cache and/or the Fedora git repository."

So I think you are supposed to add a source line for the music files.

Comment 6 Paul Dufresne 2020-05-25 08:38:08 UTC
In fact, I believe that by making music a sub-package of your package, you are tainting your package with the license of the music...

Which I can read from: https://fedora.pkgs.org/31/fedora-x86_64/7kaa-music-2.14.7-6.fc31.noarch.rpm.html:

is "Redistributable, no modification permitted" ... and I don't think you want to add that to your package, because the game would become non-free (not allowing modification to source code).

So I think they "must" be separate packages.

But... I am just a newbie to packaging and I am frankly unsure of what I am saying.

Comment 7 Paul Dufresne 2020-05-25 08:52:22 UTC
The license for the music is describe in a file in the zip (or bzip2) archive shown at:
https://7kfans.com/?p=96

Comment 8 Paul Dufresne 2020-05-25 08:55:23 UTC
Created attachment 1691766 [details]
License file for the music of 7KAA (apparently original music of the game)

Comment 9 Paul Howarth 2020-05-25 09:58:35 UTC
The music license is non-free because it only allows use in conjunction with the game. This is not acceptable for Fedora:
https://fedoraproject.org/wiki/Licensing:Main#Content_Licenses

It think it may be OK for RPM Fusion though. You wouldn't need the downloader script for a package there either, you could just package the music tarball directly.
If such a music package had "Supplements: 7kaa" then users with the additional repo enabled would get the music installed when they installed 7kaa.

Another possible approach would be to use autodownloader:
https://src.fedoraproject.org/rpms/autodownloader

Comment 10 Andy Mender 2020-05-26 09:54:34 UTC
Thanks for feedback, guys!

@Paul Dufresne
I think there is a bit of confusion here. The .spec file doesn't violate the policy stated here: https://docs.fedoraproject.org/en-US/packaging-guidelines/#_build_time_network_access. The 7kaa-music package merely provides a downloader script to get the music. The .spec file instructs rpm that the music files should be owned by the 7kaa package so that there are no leftovers after package uninstallation. I am always very careful about licensing issues, since they're a big no-go in open-source communities :). I know many game packages use various download script gimmicks, even relying on scriplets which run post-installation (so the licensed content isn't inserted into the source nor binary rpm package itself).

@Paul Howarth
The autodownloader was used before, but I removed it, since it required an extra .autorc config. I think a regular Bash script using wget is sufficient. However, I think splitting off the music package entirely and moving it to RPM Fusion might be a safer option. Would it be okay to keep the main 7kaa package in the Fedora repositories and move 7kaa-music to RPM Fusion? I would then draft another .spec for a separate music package and submit a new report to RPM Fusion directly.

Comment 11 Paul Howarth 2020-05-26 20:34:38 UTC
I think keeping 7kaa in Fedora is fine because the license is OK and I believe the game plays OK without the music.

Before committing to this approach though, I would check over at RPM Fusion that they think it's the best approach too. I tried to find an example of something similar but couldn't.

Comment 12 Artur Frenszek-Iwicki 2020-05-27 05:59:28 UTC
I don't think keeping the music in RPM Fusion is gonna fly, since Fedora's Packaging Guidelines say:
>All package dependencies (build-time or runtime, regular, weak or otherwise) MUST ALWAYS be satisfiable within the official Fedora repositories.
https://docs.fedoraproject.org/en-US/packaging-guidelines/#_package_dependencies

So unless you try doing some shenanigans like keeping Fedora's 7kaa-music at some fake, low NVR, so that the RPM Fusion 7kaa-music is always detected as higher version, and thus preferred by dnf - I don't think it's gonna work. You could maybe patch the program to display some tidbit of info saying "to enable music, download package XXX from RPM Fusion", but that's not the best user experience.

If anything, you can always try asking FE-LEGAL for their opinion.

Comment 13 Paul Howarth 2020-05-27 08:09:08 UTC
I wasn't suggesting having a dependency on 7kaa-music from the main package, I was suggesting having a reverse dependency from the 7kaa-music package back to the 7kaa package. This is the sort of case that reverse dependencies are designed for.

From:
https://docs.fedoraproject.org/en-US/packaging-guidelines/WeakDependencies/

  "Reverse dependencies are mainly designed for 3rd party vendors who can attach their plug-ins/add-ons/extensions to distribution or other 3rd party packages."

The Fedora package would not include the music at all (and works without it).

Comment 14 Andy Mender 2020-05-27 16:44:44 UTC
@Artur Iwicki
Thanks a lot for pointing this out! I read the page on weak dependencies Paul linked, but I somehow missed the subtlety of the section you linked.

@Paul Howarth
I think Artur is right, actually. "Weak" dependencies are for packages within Fedora's official repositories. What we could leverage in the case of 7kaa would be "hints". "Enhances:" might be acceptable, correct?

I wrote to the rpmfusion-developers@lists.rpmfusion.org mailing list to ask for opinion, but I noticed that the phrasing in the COPYING file for the 7kaa music is critical here. Since the music files can be used *only* in conjunction with the game, they should theoretically *not* be distributed in a way that would allow their independent use.

Comment 15 Andy Mender 2020-06-17 18:51:19 UTC
So far I haven't received any news from RPMFusion. Meanwhile, I removed the use of licensed music files from the spec file. Latest spec and build logs are available here:
Spec URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa.spec
CORP builds: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/build/1475177/

Is there anything I should still change?

Comment 16 Robert-André Mauchin 🐧 2020-06-27 21:24:38 UTC
 - Use install -p to keep timestamps

 - Use a better name for your archive:

https://github.com/the3dfxdude/%{name}/archive/v%{version}/%{name}-%{version}.tar.gz

 - There is some BSD code:

BSD 3-clause "New" or "Revised" License
---------------------------------------
7kaa-2.15.3/include/misc_uuid.h
7kaa-2.15.3/src/misc_uuid.cpp

 Add it to the license field and add a comment explaining the licenses breakdown:

# Main program: GPLv2+
# misc_uuid: BSD
License:  GPLv2+ and BSD

 - Own this dir by removing the glob:

%{_datadir}/%{name}/

 - Split the data into a noarch data subpackage that you Requires from the main package:

[!]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
     Note: Arch-ed rpms have a total of 105809920 bytes in /usr/share
     7kaa-2.15.3-5.fc33.x86_64.rpm:105809920
     See:
     https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines


Requires: %{name}-data = %{version}-%{release}
Requires: hicolor-icon-theme

[…]

%package data
BuildArch: noarch
Summary: In-Game data Seven Kingdoms: Ancient Adversaries

Requires: %{name} = %{version}-%{release}
Requires: hicolor-icon-theme

%description data
In-Game data Seven Kingdoms: Ancient Adversaries.

[…]

%files data
%{_datadir}/%{name}




Package Review
==============

Legend:
[x] = Pass, [!] = Fail, [-] = Not applicable, [?] = Not evaluated
[ ] = Manual review needed


Issues:
=======
- Package does not use a name that already exists.
  Note: A package with this name already exists. Please check
  https://src.fedoraproject.org/rpms/7kaa
  See: https://docs.fedoraproject.org/en-US/packaging-
  guidelines/Naming/#_conflicting_package_names


===== MUST items =====

C/C++:
[x]: Package does not contain kernel modules.
[x]: Package contains no static executables.
[x]: If your application is a C or C++ application you must list a
     BuildRequires against gcc, gcc-c++ or clang.
[x]: Header files in -devel subpackage, if present.
[x]: Package does not contain any libtool archives (.la)
[x]: Rpath absent or only used for internal libs.

Generic:
[x]: Package is licensed with an open-source compatible license and meets
     other legal requirements as defined in the legal section of Packaging
     Guidelines.
[!]: License field in the package spec file matches the actual license.
     Note: Checking patched sources after %prep for licenses. Licenses
     found: "GNU Lesser General Public License", "Unknown or generated",
     "GPL (v2 or later)", "GNU Lesser General Public License (v2.1 or
     later)", "BSD 3-clause "New" or "Revised" License", "FSF All
     Permissive License". 733 files have unknown license. Detailed output
     of licensecheck in
     /home/bob/packaging/review/7kaa/review-7kaa/licensecheck.txt
[x]: License file installed when any subpackage combination is installed.
[x]: If the package is under multiple licenses, the licensing breakdown
     must be documented in the spec.
[!]: Package requires other packages for directories it uses.
     Note: No known owner of /usr/share/7kaa
[x]: %build honors applicable compiler flags or justifies otherwise.
[x]: Package contains no bundled libraries without FPC exception.
[x]: Changelog in prescribed format.
[x]: Sources contain only permissible code or content.
[-]: Development files must be in a -devel package
[x]: Package uses nothing in %doc for runtime.
[x]: The spec file handles locales properly.
[x]: Package consistently uses macros (instead of hard-coded directory
     names).
[x]: Package is named according to the Package Naming Guidelines.
[x]: Package does not generate any conflict.
[x]: Package obeys FHS, except libexecdir and /usr/target.
[-]: If the package is a rename of another package, proper Obsoletes and
     Provides are present.
[x]: Requires correct, justified where necessary.
[x]: Spec file is legible and written in American English.
[-]: Package contains systemd file(s) if in need.
[x]: Useful -debuginfo package or justification otherwise.
[x]: Package is not known to require an ExcludeArch tag.
[-]: Large documentation must go in a -doc subpackage. Large could be size
     (~1MB) or number of files.
     Note: Documentation size is 10240 bytes in 1 files.
[x]: Package complies to the Packaging Guidelines
[x]: Package successfully compiles and builds into binary rpms on at least
     one supported primary architecture.
[x]: Package installs properly.
[x]: Rpmlint is run on all rpms the build produces.
     Note: There are rpmlint messages (see attachment).
[x]: 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 is included in %license.
[x]: Package does not own files or directories owned by other packages.
[x]: Package uses either %{buildroot} or $RPM_BUILD_ROOT
[x]: Package does not run rm -rf %{buildroot} (or $RPM_BUILD_ROOT) at the
     beginning of %install.
[x]: Macros in Summary, %description expandable at SRPM build time.
[x]: Package contains desktop file if it is a GUI application.
[x]: Package installs a %{name}.desktop using desktop-file-install or
     desktop-file-validate if there is such a file.
[x]: Dist tag is present.
[x]: Package does not contain duplicates in %files.
[x]: Permissions on files are set properly.
[x]: Package use %makeinstall only when make install DESTDIR=... doesn't
     work.
[x]: Package is named using only allowed ASCII characters.
[x]: Package is not relocatable.
[x]: Sources used to build the package match the upstream source, as
     provided in the spec URL.
[x]: Spec file name must match the spec package %{name}, in the format
     %{name}.spec.
[x]: File names are valid UTF-8.
[x]: Packages must not store files under /srv, /opt or /usr/local

===== SHOULD items =====

Generic:
[-]: If the source package does not include license text(s) as a separate
     file from upstream, the packager SHOULD query upstream to include it.
[x]: Final provides and requires are sane (see attachments).
[?]: Package functions as described.
[x]: Latest version is packaged.
[x]: Package does not include license text files separate from upstream.
[-]: Sources are verified with gpgverify first in %prep if upstream
     publishes signatures.
     Note: gpgverify is not used.
[-]: Description and summary sections in the package spec file contains
     translations for supported Non-English languages, if available.
[x]: Package should compile and build into binary rpms on all supported
     architectures.
[-]: %check is present and all tests pass.
[x]: Packages should try to preserve timestamps of original installed
     files.
[x]: Reviewer should test that the package builds in mock.
[x]: Buildroot is not present
[x]: Package has no %clean section with rm -rf %{buildroot} (or
     $RPM_BUILD_ROOT)
[x]: No file requires outside of /etc, /bin, /sbin, /usr/bin, /usr/sbin.
[x]: Fully versioned dependency in subpackages if applicable.
[x]: Packager, Vendor, PreReq, Copyright tags should not be in spec file
[x]: Sources can be downloaded from URI in Source: tag
[x]: SourceX is a working URL.
[x]: Spec use %global instead of %define unless justified.

===== EXTRA items =====

Generic:
[!]: Large data in /usr/share should live in a noarch subpackage if package
     is arched.
     Note: Arch-ed rpms have a total of 105809920 bytes in /usr/share
     7kaa-2.15.3-5.fc33.x86_64.rpm:105809920
     See:
     https://fedoraproject.org/wiki/Packaging:ReviewGuidelines#Package_Review_Guidelines
[x]: Rpmlint is run on debuginfo package(s).
     Note: No rpmlint messages.
[x]: Rpmlint is run on all installed packages.
     Note: There are rpmlint messages (see attachment).
[x]: Package should not use obsolete m4 macros
[x]: Spec file according to URL is the same as in SRPM.


Rpmlint
-------
Checking: 7kaa-2.15.3-5.fc33.x86_64.rpm
          7kaa-debuginfo-2.15.3-5.fc33.x86_64.rpm
          7kaa-debugsource-2.15.3-5.fc33.x86_64.rpm
          7kaa-2.15.3-5.fc33.src.rpm
7kaa.x86_64: W: no-manual-page-for-binary 7kaa
4 packages and 0 specfiles checked; 0 errors, 1 warnings.

Comment 17 Andy Mender 2020-07-05 10:17:25 UTC
Super big thanks for such a thorough review :)

(In reply to Robert-André Mauchin 🐧 from comment #16)
>  - Use install -p to keep timestamps

Done 

>  - Use a better name for your archive:
> 
> https://github.com/the3dfxdude/%{name}/archive/v%{version}/%{name}-
> %{version}.tar.gz

Done.

> 
>  - There is some BSD code:
> 
> BSD 3-clause "New" or "Revised" License
> ---------------------------------------
> 7kaa-2.15.3/include/misc_uuid.h
> 7kaa-2.15.3/src/misc_uuid.cpp
> 
>  Add it to the license field and add a comment explaining the licenses
> breakdown:
> 
> # Main program: GPLv2+
> # misc_uuid: BSD
> License:  GPLv2+ and BSD

Done. I also re-ran licensecheck on the entire sources, since a new version came out this weekend. There are some mentions of FSF All Permissive License for m4 files. Should that also be included?

> 
>  - Own this dir by removing the glob:
> 
> %{_datadir}/%{name}/

I always mess this up. Done.

>  - Split the data into a noarch data subpackage that you Requires from the
> main package:
> 
> [!]: Large data in /usr/share should live in a noarch subpackage if package
>      is arched.
>      Note: Arch-ed rpms have a total of 105809920 bytes in /usr/share
>      7kaa-2.15.3-5.fc33.x86_64.rpm:105809920
>      See:
>     
> https://fedoraproject.org/wiki/Packaging:
> ReviewGuidelines#Package_Review_Guidelines
> (...)

This is totally my fault. The original package would split out music and data files. No idea why I merged the data package back into the main package. Fixed. 
 
> Issues:
> =======
> - Package does not use a name that already exists.
>   Note: A package with this name already exists. Please check
>   https://src.fedoraproject.org/rpms/7kaa
>   See: https://docs.fedoraproject.org/en-US/packaging-
>   guidelines/Naming/#_conflicting_package_names

Makes sense, since the package was orphaned :).

SPEC URL: https://raw.githubusercontent.com/AndyMender/7kaa-rpm/f32/7kaa.spec
SRPM URL: https://github.com/AndyMender/7kaa-rpm/blob/f32/7kaa-2.15.4-1.fc32.src.rpm?raw=true
COPR build: https://copr.fedorainfracloud.org/coprs/andymenderunix/7kaa/build/1518257/

Comment 18 Robert-André Mauchin 🐧 2020-07-05 14:33:38 UTC
> Done. I also re-ran licensecheck on the entire sources, since a new version came out this weekend. There are some mentions of FSF All Permissive License for m4 files. Should that also be included?

If it's not in the resulting binary, it doesn't matter. M4 files are just artifacts for building, they don't matter.


Package approved. You still need to find a sponsor: https://fedoraproject.org/wiki/How_to_get_sponsored_into_the_packager_group

Comment 19 Robert-André Mauchin 🐧 2020-07-07 21:05:58 UTC
Sponsored!

Comment 20 Fedora Update System 2020-07-13 20:39:59 UTC
FEDORA-2020-cd5132634d has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-cd5132634d

Comment 21 Fedora Update System 2020-07-14 01:09:24 UTC
FEDORA-2020-cd5132634d has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-cd5132634d \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-cd5132634d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 22 Fedora Update System 2020-07-14 17:35:33 UTC
FEDORA-2020-703852634d has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-703852634d

Comment 23 Fedora Update System 2020-07-15 02:01:09 UTC
FEDORA-2020-703852634d has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf install --enablerepo=updates-testing --advisory=FEDORA-2020-703852634d \*`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-703852634d

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 24 Fedora Update System 2020-07-22 01:20:07 UTC
FEDORA-2020-cd5132634d has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 25 Fedora Update System 2020-07-22 18:04:52 UTC
FEDORA-2020-2a1d5acd00 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2a1d5acd00

Comment 26 Fedora Update System 2020-07-23 01:06:16 UTC
FEDORA-2020-703852634d has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 27 Fedora Update System 2020-07-23 01:50:31 UTC
FEDORA-2020-2a1d5acd00 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2a1d5acd00`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2a1d5acd00

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 28 Fedora Update System 2020-07-25 20:46:46 UTC
FEDORA-2020-8799364879 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8799364879

Comment 29 Fedora Update System 2020-07-28 15:16:02 UTC
FEDORA-2020-8799364879 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8799364879`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8799364879

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 30 Fedora Update System 2020-07-30 19:08:44 UTC
FEDORA-2020-2a1d5acd00 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 31 Fedora Update System 2020-08-05 01:19:15 UTC
FEDORA-2020-8799364879 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 32 Fedora Update System 2020-09-13 10:35:15 UTC
FEDORA-2020-8a63eb6948 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a63eb6948

Comment 33 Fedora Update System 2020-09-13 10:50:51 UTC
FEDORA-2020-021483c324 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-021483c324

Comment 34 Fedora Update System 2020-09-13 11:02:20 UTC
FEDORA-2020-ba4ff0908c has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-ba4ff0908c

Comment 35 Fedora Update System 2020-09-13 14:17:11 UTC
FEDORA-2020-8a63eb6948 has been pushed to the Fedora 32 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8a63eb6948`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8a63eb6948

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 36 Fedora Update System 2020-09-13 15:18:45 UTC
FEDORA-2020-021483c324 has been pushed to the Fedora 31 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-021483c324`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-021483c324

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 37 Fedora Update System 2020-09-13 18:31:13 UTC
FEDORA-2020-ba4ff0908c has been pushed to the Fedora 33 testing repository.
In short time you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-ba4ff0908c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-ba4ff0908c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 38 Dominik 'Rathann' Mierzejewski 2020-09-14 10:05:35 UTC
Can you please stop adding this bug to your updates in bodhi? It should remain closed as the review is done.

Comment 39 Andy Mender 2020-09-15 20:15:01 UTC
Apologies, will do!

Comment 40 Fedora Update System 2020-09-20 23:58:49 UTC
FEDORA-2020-021483c324 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 41 Fedora Update System 2020-09-21 00:00:50 UTC
FEDORA-2020-8a63eb6948 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.