Dear Maintainer, Since the release of version 2.119.0, the package trackers for many (possibly all) packages that have Appstream metadata are showing the warning "appstream-metadata-validation-failed". However, the metadata is valid according to "appstreamcli validate" & "appstream-util validate". The link in the tag notes https://wiki.debian.org/AppStream/Guidelines does not contain any clues as to what might be the problem here. If these are not false positives, please provide information on what maintainers are expected to do about them. Appstream is an optional upstream feature. Please consider introducing Appstream related tags at a lower severity than Warning. Regards, Peter
Hi, Thanks for reporting this issue. The lintian tag message says the command you should run is `appstreamcli validate-tree --no-net` and not `appstreamcli validate`. Can you try that instead? As for more information, the wiki page refers to https://appstream.debian.org/, which seems to give detailed information about issues flagged. Cheers,
Hi, Running `appstreamcli validate-tree --no-net` gives the response I: ~:~: dir-no-metadata-found ✔ Validation was successful: infos: 1 The result is always the same irrespective of whether a path to the source tree, or the actual metadata file is given as the parameter. I can't see any reference to 'appstreamcli validate-tree' from your link, and haven't found any useful information anywhere else. I mentioned `appstreamcli validate` because it shows that the metadata is correct. It is probably a more reliable test than 'appstreamcli validate-tree' (There is also appstream-util validate, which also shows the metadata is valid) Regards, Peter
The command that is ran is in the Lintian tag explanation (the message that you see on the CLI, or on the HTML output). You can also find this message here: https://udd.debian.org/lintian-tag/appstream-metadata-validation-failed As for the right command to run, I'm adding pere in CC, as he's the one who wrote that code. I'm certainly no expert on this subject and he'll probably have a more interesting opinion than I.
[Louis-Philippe Véronneau] Thank you for the heads up. The lintian test is using appstreamcli validate-tree, and as far as I know this do not report any false positives, but the same issues that would make the appstream parser ignore the Appstream information. Peter, do you have an example package I could look at to see the false positives you are talking about? The example fragments mentioned earlier are confusing, as the lintian check should only run if a file is discovered in /usr/share/metainfo/, and the message "I: ~:~: dir-no-metadata-found" indicate that no metainfo XML file was present in the directory. Just as a test and to check, I fetched the source for a random package listed on <URL: https://udd.debian.org/lintian-tag/appstream-metadata-validation-failed?affected=yes >, catfish, and its lintian detected Appstream error was present (W: org.xfce.Catfish:~: metainfo-filename-cid-mismatch). If there is a false positive somewhere, I am happy to investigate.
Hi Petter, In my tests so far, appstreamcli validate-tree always reports 'dir-no-metadata-found' when run against a directory with valid metadata. However, the exit code is zero (no error). Many reports in https://udd.debian.org/lintian-tag/appstream-metadata-validation-failed?affected=yes checking a few installed on my system atril audacity mp3guessenc tkinfo c-evo-dh (overriden) cevomapgen (overriden) have no obvious Appstream issues. On doing my own random checks, I'm finding several on the above (affected=yes) list do indeed have some Appstream issues, but would seriously question whether they merit a lintain tag at Warning severity. IMHO Info, or even Pedantic would be more appropriate. Regards, Peter
[Peter Blackman] I had a look at two of them, first tried atril but lacked the required disk space to build it, so ended up building two smaller packages and running 'appstreamcli validate-tree debian/<packagename>' to see what the issue is. mp3guessenc.metainfo.xml W: io.sourceforge.mp3guessenc.mp3guessenc:~: metainfo-filename-cid-mismatch tkinfo.appdata.xml I: de.uni_paderborn.math_.tkinfo:17: url-not-secure http://math-www.uni-paderborn.de/~axel/tkinfo/ I: de.uni_paderborn.math_.tkinfo:18: url-not-secure http://math-www.uni-paderborn.de/~axel/tkinfo/README-tkinfo-2.11.txt I: de.uni_paderborn.math_.tkinfo:30: screenshot-media-url-not-secure http://math-www.uni-paderborn.de/~axel/tkinfo/tkinfo.gif W: de.uni_paderborn.math_.tkinfo:~: metainfo-filename-cid-mismatch If your appstreamcli validate-tree do not report this, I suspect there is something wrong with it. I'm using the one from appstream version 0.16.1-2. In any case, the cid mismatch issue is a fatal one, as far as I know, and will cause the entry to not make it into the Appstream database. The 'I' (information/hint) issues are not fatal, and will not trigger a lintian issue either. <URL: https://www.freedesktop.org/software/appstream/docs/chap-Validation.html#asv-metainfo-filename-cid-mismatch > got some hints on how to fix it. File name and 'id' tag must have common base. Please be more specific. I do not know which Appstream issues you see, and can thus not provide any insight about their severity levels.
[Petter Reinholdtsen] It occured to me that I do not really need to build and test locally, I can just have a look at <URL: https://tracker.debian.org/pkg/atril > for the Appstream info, and sure enough, under 'action needed', there is a link to <URL: https://appstream.debian.org/sid/main/issues/atril-common.html > listing one error and two warnings, gui-app-without-icon, asv-cid-desktopapp-is-not-rdns and missing-launchable-desktop-file. On the other hand, audacity, c-evo-dh and cevomapgen do nto list any Appstream issues on the package tracker, so I will have a closer look at these.
Agreed, My mistake. Sorry about that one, Peter
Hi Petter, is debian/<packagename> related to a directory on your system? I still can't get any useful output from 'appstreamcli validate-tree' In fact, if I try 'appstreamcli validate-tree garbage' the result is exactly the same, as if I point it to a source package! 'appstreamcli --version' gives 'AppStream version: 1.0.3' Regards, Peter
I can reproduce these messages now. I followed "Steps to reproduce the issues" from this link; https://github.com/qgis/QGIS/issues/59220 The key part is to unpack a BINARY package. I was trying to run validate-tree on source packages. Maybe this 'bug' can be closed, but I would suggest improving the tag notes, with clear instructions on how to run appstream validate-tree Regards, Peter
Again, I'm no expert, but changing the tag description isn't very technical and I'll be happy to review and merge a MR against Lintian for this on Salsa.
[Peter Blackman] Yes. It is the directory where the content of the binary package is present after building a debian package from source. In other words, the directory is present after unpacking the source and running 'debuild' inside the source directory. Very good to hear you was able to reproduce the messages, and very good to hear your feedback on the lintian instructions. I have no objections to improving the instructions, but am unsure if I am the right person to come up with a better text, as I am welding blind to what is difficault and thus not a good judge for what should be put in there. Do you have a proposal for a better text, now that you have figured out the trick?
Hi Petter, Maybe change 'path-to-package-root' to be 'path-to-unpacked-binary-package-root' and add a link to https://www.freedesktop.org/software/appstream/docs/chap-Validation.html Perhaps be even more specific; "To reproduce for a given binary package foo.deb dpkg-deb -R foo.deb /tmp/foo appstreamcli validate-tree /tmp/foo" Regards, Peter
I believe a lintian patch like this might include the improvements suggested by Peter: diff --git a/tags/a/appstream-metadata-validation-failed.tag b/tags/a/appstream-metadata-validation-failed.tag index 52d1be670..e45f8d009 100644 --- a/tags/a/appstream-metadata-validation-failed.tag +++ b/tags/a/appstream-metadata-validation-failed.tag @@ -2,5 +2,13 @@ Tag: appstream-metadata-validation-failed Severity: warning Check: appstream-metadata See-Also: https://wiki.debian.org/AppStream/Guidelines -Explanation: The specified AppStream metadata file fail to validate using - 'appstreamcli validate-tree --no-net path-to-package-root'. +Explanation: + The specified AppStream metadata file fail to validate using + 'appstreamcli validate-tree --no-net path-to-unpacked-binary-package-root'. + + The various issues with hints on solutions are described in + https://www.freedesktop.org/software/appstream/docs/chap-Validation.html. + + To reproduce for a given binary package foo.deb, run 'dpkg-deb -R + foo.deb /tmp/foo-unpacked && appstreamcli validate-tree --no-net + /tmp/foo-unpacked'.
Hi, I'm reopening this bug as I am still seeing appstream-metadata-validation-failed in https://udd.debian.org/lintian/?packages=cevomapgen I cannot see anything wrong with the metadata, and cannot reproduce the issue locally. No issues with the package reported here. https://appstream.debian.org/sid/main/issues/index.html Regards, Peter
In my experiences, this particular error has to do with inconsistencies between the appstream metadata file name, the appstream ID name, and the desktop file name. In my experience, the following always resolves the issue. 1. Use reverse DNS naming for the appstream metadata file appended by metainfo.xml. 2. Use reverse DNS naming for the appstream ID. 3. Use reverse DNS naming for the desktop file appended by .desktop. For example, see privacybrowser: 1. Reverse DNS naming for the appstream metadata file: com.stoutner.privacybrowser.metainfo.xml https://salsa.debian.org/soren/privacybrowser/-/blob/master/src/ com.stoutner.privacybrowser.metainfo.xml?ref_type=heads 2. Reverse DNS naming for the appstream ID: com.stoutner.privacybrowser https://salsa.debian.org/soren/privacybrowser/-/blob/master/src/ com.stoutner.privacybrowser.metainfo.xml?ref_type=heads#L26 3. Reverse DNS naming for the desktop file: com.stoutner.privacybrowser.desktop https://salsa.debian.org/soren/privacybrowser/-/blob/master/src/ com.stoutner.privacybrowser.metainfo.xml?ref_type=heads#L57 https://salsa.debian.org/soren/privacybrowser/-/blob/master/src/ com.stoutner.privacybrowser.desktop Running validate-tree on an installed binary checks these file name relationships, whereas a normal validate only checks the contents of the metainfo.xml file itself, but not the relationship of the file names.
<snip> Hi Soren, Right. It looks possible that my failure to rDNS the .desktop name may be the issue with the package. What is tedious, is that I cannot reproduce the problem locally, to check. UDD claims a lintian warning against the package https://udd.debian.org/lintian/?packages=cevomapgen But if I run either ..validate-tree or lintian itself against the .deb, no errors are shown. Salsa CI has SALSA_CI_LINTIAN_FAIL_WARNING set but nothing shows there either. https://salsa.debian.org/PeterB/cevomapgen/-/jobs/7567926 So the lintian "bug" I'm seeing, is that when run via UDD the result is different to when run locally or via Salsa CI. Regards, Peter P.S. attaching a little basic test script. It takes the .deb file as a parameter.
On Monday, May 12, 2025 11:31:26 AM Mountain Standard Time Peter Blackman wrote: I also don’t see any lintian tags when I run the following command with lintian from testing: lintian -iIE --pedantic My guess is that the factors for determining this tag have changed and that UDD is running either a newer or an older version of either lintian or "appstreamcli validate”. In the past, when I have dealt with this error I was able to reproduce it locally with lintian. If you want to make UDD happy you could upload a version with a corrected .desktop entry (it is recommended it use reverse DNS naming anyway). "The name of the desktop entry should follow the "reverse DNS" convention: it should start with a reversed DNS domain name controlled by the author of the application, in lower case.” https://specifications.freedesktop.org/desktop-entry-spec/latest-single/#file-naming Similar language also exists for the AppStream file name and ID tag. https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html I think in the past the recommendation to use reverse DNS naming wasn’t as strong, which is why you see a lot of .desktop files that follow other patterns, especially for programs that have been around for a long time.
Seems not to be the case. If I rDNS the .desktop name locally, that CAUSES appstream-metadata-validation-failed Problems reported by "appstreamcli validate-tree" WTF!!! What I tried adding to d/rules is # Rename desktop file to rDNS style execute_after_dh_auto_install: mv -v debian/c-evo-map-gen/usr/share/applications/cevomapgen.desktop \ debian/c-evo-map-gen/usr/share/applications/net.sourceforge.cevomapgen.desktop
On Monday, May 12, 2025 12:03:26 PM Mountain Standard Time Peter Blackman wrote: net.sourceforge.cevomapgen.desktop You need to both rename the file and edit the name it is looking for in the metainfo.xml here: https://salsa.debian.org/PeterB/cevomapgen/-/blob/master/ net.sourceforge.cevomapgen.metainfo.xml?ref_type=heads#L11 When I have done this I have usually submitted an upstream patch to implement it on their end, which usually, but not always, is accepted with appreciation.
Of course!! Forgot that bit. Will try again tomorrow. Thanks, Peter
This remains a mystery. Lintian version 2.122.0 is used throughout. I tried installing older versions of appstream and its library, but still could not reproduce the problem locally. Notwithstanding that I can't reproduce the problem, I agree this seems highly likely to be the issue. I'll attempt a fix on the next upload. That seems to explain why over 600 reports of this tag! https://udd.debian.org/lintian-tag/appstream-metadata-validation-failed?affected=yes Thanks for helping, Peter