Same issue on latest Fedora 32 with audacity-2.3.3-1.fc32.x86_64.

Created attachment 1676915 [details]
With FC31 and Software: 3.34.2, seems to be ok for me

Created attachment 1676916 [details]
detail view: registry.fedoraproject.org

It is not. The registry.fedoraproject.org is a Fedora Flatpak source, not a RPM one. The RPM source is still missing.

Anyway, it seems that the AppStream metadata for Audacity are missing in /usr/share/app-info/xmls/fedora.xml.gz.

Switching to appstream-data.

I also got a FC32/rawhide vm going and tried there. I get the same search results as the previous screenshots.

When I tried to [install] from "software", it doesn't; sitting there for 10-15 minutes and failing is perhaps the nature of the Software App, not Audacity package itself ?
Although, with "only 0.94GB free", perhaps it can't find enough space to fit  audacity which is:
Total download size: 6.9 M
Installed size: 28 M
So, yeah maybe something not going well with "software" - dnf install downloads in 10 seconds, and install scriptlets took many minutes (not normally the case). Bed time - I'm nuking it before ot finishes.

Yeah, this is because you was installing the Fedora Flatpak version, not the RPM one.

Audacity is displayed on the Installed tab of GNOME Software on F32 if it is already installed using dnf, but it has empty icon and unknown source/version. Metadata for Audacity are is still missing in /usr/share/app-info/xmls/fedora.xml.gz.

I see that Audacity appdata file was introduced years ago.
Perhaps it's not up-to-date to the AppStream spec and appstream-compose fails because it doesn't pass validation?

In that case it would be an upstream bug?

I see two errors using two different validators.

1. appstreamcli complains about the missing type property in <launchable>:

$ appstreamcli validate /usr/share/appdata/audacity.appdata.xml
E: org.audacityteam.Audacity:29: launchable-unknown-type
E: org.audacityteam.Audacity:29: type-property-required launchable (audacity.desktop)


2. appstream-util complains only about a missing content rating

$ appstream-util validate /usr/share/appdata/audacity.appdata.xml
/usr/share/appdata/audacity.appdata.xml: FAILED:
• tag-missing           : <content_rating> required [use https://odrs.gnome.org/oars]

I don't think this is an upstream bug. The Fedora Flatpak version of Audacity does not have any issues with its AppData. I think that there were some issues with the upstream AppData year or two ago, but they were already fixed some time ago, at least as far as I know.

Maybe Audacity was somehow blacklisted in the appstream-data generator when it had these issues and was still not removed from such blacklist? Anyway, this is just my assumption, I don't know any technical details regarding the appstream-data generation process.

Yep, the Audacity AppStream metadata file seems to be correct. As far as I know, OARS metadata are not required, at least in Fedora.

$ appstream-util validate /usr/share/appdata/audacity.appdata.xml
/usr/share/appdata/audacity.appdata.xml: FAILED:
• tag-missing           : <content_rating> required [use https://odrs.gnome.org/oars]
Validation of files failed

$ appstream-util validate-relax /usr/share/appdata/audacity.appdata.xml
/usr/share/appdata/audacity.appdata.xml: OK

I did some digging into this tonight, and a small change in Audacity's appdata.xml file can fix this I believe.

The log of a run of the appstream-builder utility shows the following:
    (appstream-builder:313832): Asb-DEBUG: 23:52:32.120: WARNING: Ignoring: a desktop file is required for org.audacityteam.Audacity
and
    <vetos>
      <veto>Has no Icon</veto>
    </vetos>
for the Audacity RPM.

So apparently it wasn't finding the desktop file. After some experimenting, this looks to be caused by the <launchable> line having an incorrect type. The version packaged from upstream has:
  <launchable type="desktop">audacity.desktop</launchable>
whereas changing it to
  <launchable type="desktop-id">audacity.desktop</launchable>
makes the warning about no desktop file go away. So apparently appstream-builder requires the tag to be "desktop-id" specifically, but the validation programs don't flag that the "desktop" tag is incorrect (I looked at the spec - https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-launchable - and it lists "desktop-id" but not "desktop", so I think "desktop-id" is the standard form, but this says the spec was most recently updated in May of this year).

So it looks like Audacity should be using the "desktop-id" type in its appdata file instead of "desktop" and appstream-util-validate is failing to recognize that "desktop" is an invalid type when it is used - with any of the validate options - so there is a bug in both those packages.

I will move this back to the Audacity component and take it.


@rhughes: Which releases should this be fixed in? I will definitely fix it in Rawhide, but is it worth backporting the fix to f31/32 and EPEL7/8, or are no new runs of the appstream-builder going to be done for those branches now that they are released?

There is a two years old upstream Pull Request that fixes this: https://github.com/audacity/audacity/pull/324

Unfortunately, it was still not merged.

Upstream has now merged that PR into master (I also emailed their devel list asking for someone to look at it earlier today, and they didn't respond with any issues before merging), so this will be fixed in the next upstream release 2.4.2 (currently scheduled for the end of June apparently). That just leaves the question of if I need to backport this to F31/32 (if the appstream data will be regenerated for those releases).

Nice, thanks for tracking this down! Please backport to F32 and F31 as well. There's definitely going to be appstream-data updates there (but I can't promise the schedule as it's only hughsie that can regenerate the data).

*** Bug 1846764 has been marked as a duplicate of this bug. ***

FEDORA-2020-7063229f08 has been submitted as an update to Fedora 32. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7063229f08

FEDORA-2020-8fb64af012 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8fb64af012

audacity-2.3.3-6.fc32 has been pushed to the Fedora 32 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7063229f08

FEDORA-2020-8fb64af012 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-8fb64af012`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8fb64af012

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

The update is now in stable F32, thanks! Audacity is however still not displayed in GNOME Software, but I think that this is because it needs the appstream-data to be updated as well. Adding Kalev Lember to needinfo.

Oops, sorry, I have overlooked the "There's definitely going to be appstream-data updates there" part in #c16. :)

Yes, the appstream update still has to happen. My plan is to open bugs against the appstream-data component when the Audacity updates reach stable as a reminder in that component to do the update.

FEDORA-2020-7063229f08 has been pushed to the Fedora 32 stable repository.
If problem still persists, please make note of it in this bug report.

FEDORA-2020-8fb64af012 has been pushed to the Fedora 31 stable repository.
If problem still persists, please make note of it in this bug report.

There is now a new appstream-data build available for F32 (https://koji.fedoraproject.org/koji/buildinfo?buildID=1554585), however Audacity still seems to be missing.

$ rpm -q appstream-data
appstream-data-32-7.fc32.noarch

$ zcat fedora.xml.gz | grep Audacity
$ 

Audacity is also still missing in GNOME Software (except the Fedora Flatpak version).

Richard, do you have any idea what could be wrong? The AppData file should be fine now.

Can you try generating it with the logfile being saved (--logdir=logdir/). Then there should be a logdir/a/audacity.log file that gives information about how it was parsed. Specifically, there will be lines inside a <veto> block that tells why appstream didn't accept it.

What command should I use? The appstream-compose one does not seem to understand --logdir switch. However, when I tried running appstream-compose on manually extracted content of the audacity-2.3.3-6.fc32.x86_64.rpm package, everything was fine:

$ appstream-compose --prefix audacity_files/usr/ audacity
WARNING: Metadata origin not set, using 'example'
Processing application audacity
Saving icon audacity_files/usr/share/app-info/icons/64x64/audacity.png
Saving icon audacity_files/usr/share/app-info/icons/128x128/audacity.png
Saving AppStream /home/drusek/Downloads/audacity_files/usr/share/app-info/xmls/example.xml.gz
Done!

$ zcat audacity_files/usr/share/app-info/xmls/example.xml.gz|head
<?xml version="1.0" encoding="UTF-8"?>
<components origin="example" version="0.8">
  <component type="desktop">
    <id>org.audacityteam.Audacity</id>
    <name>Audacity</name>
    <summary>Record and edit audio files</summary>
    <description><p>Audacity® is a free, easy-to-use, multi-track audio editor and recorder for Windows, Mac OS X, GNU/Linux and other operating systems. The interface is translated into many languages.</p><p>You can use Audacity to:</p><ul><li>Record live audio</li><li>Convert tapes and records into digital recordings or CDs</li><li>Edit WAV, AIFF, FLAC, MP2, MP3 or Ogg Vorbis sound files</li><li>Cut, copy, splice or mix sounds together</li><li>Change the speed or pitch of a recording</li><li>Apply a wide range of other effects to audio recordings</li></ul></description>
    <icon type="cached" height="64" width="64">audacity.png</icon>
    <icon type="cached" height="128" width="128">audacity.png</icon>
    <categories>

Which id is appstream-compose using for Audacity?
AppData file is called audacity.appdata.xml, but its id is org.audacityteam.Audacity

I guess the only way to understand is building the appstream-data rpm?

$ sudo appstream-compose --verbose --origin=audacity org.audacityteam.Audacity
Processing application org.audacityteam.Audacity
Error loading AppData file: no file found for org.audacityteam.Audacity

$ sudo appstream-compose --verbose --origin=audacity audacity
Processing application audacity
(appstream-compose:6705): As-DEBUG: 07:18:43.239: looking for appdata path '/usr/share/appdata/audacity.appdata.xml'
(appstream-compose:6705): GLib-GIO-DEBUG: 07:18:43.245: _g_io_module_get_default: Found default implementation dconf (DConfSettingsBackend) for ‘gsettings-backend’
(appstream-compose:6705): dconf-DEBUG: 07:18:43.245: watch_fast: "/system/proxy/" (establishing: 0, active: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.246: watch_fast: "/system/proxy/http/" (establishing: 0, active: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.246: watch_fast: "/system/proxy/https/" (establishing: 0, active: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.246: watch_fast: "/system/proxy/ftp/" (establishing: 0, active: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.246: watch_fast: "/system/proxy/socks/" (establishing: 0, active: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.246: unwatch_fast: "/system/proxy/" (active: 0, establishing: 1)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.246: unwatch_fast: "/system/proxy/http/" (active: 0, establishing: 1)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.246: unwatch_fast: "/system/proxy/https/" (active: 0, establishing: 1)
(appstream-compose:6705): GLib-DEBUG: 07:18:43.246: posix_spawn avoided (fd close requested) 
(appstream-compose:6705): dconf-DEBUG: 07:18:43.247: unwatch_fast: "/system/proxy/ftp/" (active: 0, establishing: 1)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.247: unwatch_fast: "/system/proxy/socks/" (active: 0, establishing: 1)
(appstream-compose:6705): GLib-GIO-DEBUG: 07:18:43.251: _g_io_module_get_default: Found default implementation libproxy (GLibproxyResolver) for ‘gio-proxy-resolver’
(appstream-compose:6705): dconf-DEBUG: 07:18:43.256: watch_established: "/system/proxy/" (establishing: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.257: watch_established: "/system/proxy/http/" (establishing: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.257: watch_established: "/system/proxy/https/" (establishing: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.258: watch_established: "/system/proxy/ftp/" (establishing: 0)
(appstream-compose:6705): dconf-DEBUG: 07:18:43.258: watch_established: "/system/proxy/socks/" (establishing: 0)
(appstream-compose:6705): As-DEBUG: 07:18:43.310: looking for desktop path '/usr/share/applications/audacity.desktop'
Saving icon /usr/share/app-info/icons/audacity/64x64/audacity.png
(appstream-compose:6705): As-DEBUG: 07:18:43.327: trying to load /usr/share/icons/hicolor/scalable/apps/audacity.svg
Saving icon /usr/share/app-info/icons/audacity/128x128/audacity.png
(appstream-compose:6705): As-DEBUG: 07:18:43.356: fixing up ID for desktop merge
(appstream-compose:6705): As-DEBUG: 07:18:43.356: merging duplicate desktop:appdata entries: */*/*/desktop/org.audacityteam.Audacity/*:*/*/*/desktop/org.audacityteam.Audacity/*
(appstream-compose:6705): GLib-GIO-DEBUG: 07:18:43.357: _g_io_module_get_default: Found default implementation local (GLocalVfs) for ‘gio-vfs’
Saving AppStream /usr/share/app-info/xmls/audacity.xml.gz
Done!

Daniel, the --log-dir is a flag of appstream-builder (not appstream-compose).

I've tried the following:

mkdir ~/audacity
cd audacity
wget https://kojipkgs.fedoraproject.org//packages/audacity/2.3.3/6.fc32/x86_64/audacity-2.3.3-6.fc32.x86_64.rpm
mkdir /tmp/logs

appstream-builder --verbose --log-dir=/tmp/logs --packages-dir=/home/fede/audacity --basename="audacity"

It works correctly.

Created attachment 1710605 [details]
Log of appstream-builder command on audacity rpm

Federico, I have also noticed that the app id and appdata/desktop file names are different, but I think that this should not be an issue as long as the correct desktop file name is mentioned in the appdata file.

The difference in appdata and desktop file naming shouldn't be an issue anymore, but that was the problem originally. The <launchable type="desktop-id">audacity.desktop</launchable> tag tells it to look for a desktop file called "audacity.desktop. If that tag isn't there, then it looks for a desktop file called org.audacity.Audacity.desktop (I think).

That log file seems to look fine, no <vetos> are present. When running it, I don't even need to specify the basename and it works:

appstream-builder --output-dir=metadata/ --temp-dir=tmp/ --packages-dir=appstream-test/ --log-dir=log/


Has the actual appdata XML been updated yet? When I look at the RPM spec file, it looks like it just pulls in the built appdata from a source file and doesn't build it itself (see the spec: https://src.fedoraproject.org/rpms/appstream-data/blob/master/f/appstream-data.spec). It may be that the new F33 RPM from the mass rebuild is still using the old appdata from before I fixed Audacity.

Yeah, F33 still has the old appdata build from before you fixed Audacity. However, the latest F32 build should be new. But I am not sure, this is rather a question for Richard. :)

I wasn't including f32-updates. I've fixed up the tools and an downloading all the packages now. New metadata expected tomorrow?

Fixed in appstream-data-32-8.fc32

I confirm it's fixed.
Thank you Richard