Gnome Software Testing - eopkg

[TraceyC77]

Testing task for Gnome Software - eopkg packages

DRAFT

Gnome Software is not yet ready to test with eopkgs. We will let the community know when it is.

Test objective

Exercise Gnome Software to ensure everything works as intended with eopkgs management, and facilitate technical discussions of potential issues. This is for software packaged by Solus aka eopkgs (as opposed to flatpaks which will be tested in another task).

Setting Up

This testing is being performed on the unstable repository and may also involve or require real-time communication via our development Matrix room. If you are not in Matrix, use any supported Matrix client that we provide in the repo (e.g. Element, Nheko, Neochat) and look at our Getting Involved Page for connection details.

If you are not on the unstable repository and wish to help test, assuming you understand that the intent of unstable is to be the place where we break stuff and operate under the assumption you check the topic of the Packaging Matrix room to know when not to update, you can run the below mentioned command to switch to the unstable repository:

sudo eopkg ar Solus https://cdn.getsol.us/repo/unstable/eopkg-index.xml.xz

See this for details on repo management, if necessary.

Testing List

A non-exhaustive list of things to test. Feel free to go beyond this. Explore! Feel free to report any bugs or unexpected behavior, even if it isn't on this list.

• Gnome Software launches and shows the list of software available, with proper text and graphics
• Currently installed software is listed correctly
• Search works properly
• Packages can be installed
• Packages with dependencies can be installed
• Packages have appropriate information shown (from metadata.xml), such as name, description, homepage, icon etc.
• Updates work correctly
• Packages can be removed

[EbonJaeger]

Testing with Budgie Desktop

• Gnome Software launches and shows the list of software available, with proper text and graphics
• Currently installed software is listed correctly
• Search works properly
  • The caveat to this is only packages with metadata can be found
  • Some applications may have duplicate entries. The one instance of this I found was with Brave. One entry was for the Solus repo version, the other for that Flathub version.
• Packages can be installed
• Packages with dependencies can be installed
• Packages have appropriate information shown (from metadata.xml), such as name, description, homepage, icon etc.
• Updates work correctly
• Packages can be removed

[sebo505]

Am I supposed to already find all the same packages in GNOME Software that I can find in Solus Software Center? Because I don't. For example searching for poppler or mupdf doesn't bring up the desired results.

[joebonrichie]

Am I supposed to already find all the same packages in GNOME Software that I can find in Solus Software Center? Because I don't. For example searching for poppler or mupdf doesn't bring up the desired results.

Unfortunately only packages that provide appstream metainfo (e.g. the files in /usr/share/metainfo/ show up in G-S/Discover unless they are updates. This is by design.

See our issue #1389 for tracking that. If you are comfortable with packaging feel free to send a patch including appstream metainfo for the mupdf package or create an issue for it.

[infinitymdm]

Not sure if this belongs here or on #718 , but I wanted to note that G-S prefers flatpaks to eopkgs where the repositories overlap. I understand this to be an intentional feature of G-S.

Is this the behavior we want? In my mind it conflicts with the whole idea of curated rolling release, where we're trying to make sure the user always has the latest tested and stable version of software. If users end up getting flatpaks over .eopkgs/.stones we potentially have less control to guarantee that.

[malfisya]

Micro nitpick : Why it is "Solus" is lower case on GS and uppercase in Discover ? I prefer the uppercase.
GS

Discover

[sebo505]

G-S prefers flatpaks to eopkgs where the repositories overlap

Packaging format preferences can be set via dconf-editor/gesettings for GNOME Software.
eopkg can be set as preferred over flatpak with:
gsettings set org.gnome.software packaging-format-preference "['eopkg', 'flatpak']"

This should be set as default setting.

[joebonrichie]

That works but it is quite laggy when opening an application

Screencast.from.2024-03-09.21-05-47.webm

[joebonrichie]

You can see it prefers the flatpak initially but then after resolving via packagekit it'll switch to the eopkg version.

[sebo505]

Right, I made the same observation. Though in my case (I am on shannon) it only was a fraction of a second that Flatpak was selected, merely noticable.

[sebo505]

simplescreenrecorder-2024-03-09_22.19.08.mp4

[sebo505]

For testing purposes I have set in Fedora packaging-format-preference from ['flatpak:fedora-testing', 'flatpak:fedora', 'rpm'] to ['rpm', 'flatpak:fedora-testing', 'flatpak:fedora'].
If you pay close attention you can see that in Fedora, it defaults to flatpak:fedora (blue) initially and then switches to rpm (red).

[sebo505]

simplescreenrecorder-2024-03-11_06.01.36.mp4

[joebonrichie]

Made the change, in my testing it was only abiword that was really slow to resolve for some reason. Possibly due to it using legacy appstream data paths.