#798 Testing Day for GNOME Software with dnf5
Opened 2 months ago by jkolarik. Modified a month ago

Test Day Issue

This issue helps the QA team to take in test day request and put them on a release cycle. We might have a few follow up after a proposal is made.

Details
  1. Name: GNOME Software with dnf5
  2. Dates/Range of Dates: proposing the week of Feb 10 or Feb 17
  3. Owner: looking for help from QA, co-owner jkolarik
  4. Changeset wiki: basically matching the existing functionality of GNOME Software with PackageKit
Misc

COPR repository with GNOME Software package for testing.

Regarding test cases, IDK if there was already any previous testing day for GNOME Software particularly, so we can reuse it? We could also add there the automated cases from Bodhi updates.


Metadata Update from @sumantrom:
- Issue assigned to sumantrom

2 months ago

Thanks for filing up the issue. Do you intend to spin up an fedora image or recommend one on which you want us to install the COPR software version? Also, is the new version going to also be used for testing upgrades...?

@kparal @adamwill , do you know how we can trick the system into thinking there is an upgrade especially if the build is Rawhide only?

Hi Sumantro,

I didn’t originally plan to create a custom Fedora image for testing, but if you think it would make things easier for users, we can certainly prepare one. Otherwise, since this change is intended for Fedora 42 (current Rawhide), testing it in that environment would likely be best.

As for testing upgrades, I assume you mean system upgrades. That would be useful, though I’m not sure how to approach it without a newer version beyond Rawhide to upgrade to...

Thanks for filing up the issue. Do you intend to spin up an fedora image or recommend one on which you want us to install the COPR software version? Also, is the new version going to also be used for testing upgrades...?

@kparal @adamwill , do you know how we can trick the system into thinking there is an upgrade especially if the build is Rawhide only?

To make sure there will always be an upgrade ready, we are doing the following in openQA:

  1. Disable the updates repositories to prevent the system from knowing about updates.
  2. Remove the acpica-tools package.
  3. Download and install a fake repository curl -o /etc/yum.repos.d/openqa-testrepo-1.repo https://fedorapeople.org/groups/qa/openqa-repos/openqa-testrepo-1.repo. This repository contains an old version of acpica-tools.
  4. Install the acpica-tools from that fake repository while disabling all other repositories to make sure the system does not know about any other packages and will install this particular version of the package, dnf -y --disablerepo=* --enablerepo=openqa-testrepo-1 install acpica-tools.
  5. Now the system has an old version of acpica-tools so the newer version will be always available from the standard repositories, so you can use dnf update and there will be at least the newer version of acpica-tools ready for updates.
    4.

Hi Sumantro,

I didn’t originally plan to create a custom Fedora image for testing, but if you think it would make things easier for users, we can certainly prepare one. Otherwise, since this change is intended for Fedora 42 (current Rawhide), testing it in that environment would likely be best.

As for testing upgrades, I assume you mean system upgrades. That would be useful, though I’m not sure how to approach it without a newer version beyond Rawhide to upgrade to...

Nah lets sure Rawhide in this case. I will come up with test case by tomorrow and we should be able to sync up fix this! Thanks

@lruzicka a thousand hearts for the steps :D

Metadata Update from @sumantrom:
- Custom field story_points adjusted to 3

a month ago

Log in to comment on this ticket.

Metadata