Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_As_Native_Wayland_Applicati…
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-anaconda-as-nati…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Currently, Anaconda is still an X11 application, which we would like
to fix and make Anaconda Wayland native application to allow us drop
of the X11 dependencies from installation ISO images. However, this
change is not just a simple switch and we need to do some adjustments
during the path which will impact user experience.
== Owner ==
* Name: Anaconda team ([[User:jkonecny| Jiří Konečný]])
* Email: jkonecny(a)redhat.com
== Detailed Description ==
Anaconda is required to migrate to Wayland native application to drop
dependencies from the installation ISO images which are deprecated.
Package owners want to drop libXklavier from Fedora (see
https://bugzilla.redhat.com/show_bug.cgi?id=1955025 ) but also Xorg
server from CentOS Stream and RHEL. However, this change won’t be just
simple switching from X11 to Wayland, we also need to change a few
things in Anaconda to be able to remove the X11 dependencies. This
will have two main visible impacts listed below.
=== VNC switch to RDP for remote GUI installations ===
Anaconda has to remove ‘TigerVNC' which is used for VNC connection to
be able to install your machine remotely with graphical UI. Reason is
that TigerVNC is built from the Xorg server sources, so we would still
depend on the Xorg server with this project. As replacement, we follow
the recommendation of the Fedora Workstation to switch to Gnome Remote
Desktop (grd) with a better protocol Remote Desktop Protocol (RDP)
which gives users better performance and security.
This will have an impact on current vnc kickstart commands and kernel
boot options of Anaconda. This will impact only the Anaconda
installation environment (boot.iso).
=== Consistent keyboard control ===
Currently, Anaconda experiences difficulties in handling keyboard
layouts in the installation environment, particularly on Wayland.
Formerly, libXklavier was utilized by Anaconda to manage keyboard
layout configuration, however, it proved unstable on Wayland. As a
result, Anaconda has disabled keyboard handling during Wayland Live
media installations due to unexpected behavior (refer to
https://bugzilla.redhat.com/show_bug.cgi?id=2016613 ). This approach
may lead to situations when users encountering issues while unlocking
LUKS devices or using user passwords in the installed system because
installation was done with a different keyboard layout.
To exacerbate the situation, there is no universally applicable
solution for keyboard handling on Wayland systems, as Wayland lacks a
unified API for keyboard management. It means that each Fedora Desktop
Environment developed their own API. Unfortunately, the Anaconda team
is not able to maintain a custom solution for each Fedora spin. Some
Desktop environments started to use '''systemd-localed''' DBus API to
address this issue and similar issues. The systemd-localed API seems
to be the best approach currently, so we want to promote it as a
shared solution for all Fedora spins.
The plan is:
* All Fedora spins and Anaconda listen on
'''org.freedesktop.locale1''' and reflect configuration on the
currently running system (might be only for Live media if desired)
* All Fedora spins and Anaconda reflect their configuration to
org.freedesktop.locale1
* In case Fedora spin will not support '''org.freedesktop.locale1''',
the keyboard configuration of Anaconda won’t be reflected in the
current system and the situation will be similar to the current Live
Wayland experience
All the spin owners were notified about this request:
* https://pagure.io/fedora-workstation/issue/430
* https://pagure.io/fedora-kde/SIG/issue/504
* https://gitlab.com/fedora/sigs/sway/SIG/-/issues/36
* https://bugzilla.redhat.com/show_bug.cgi?id=2278655
* https://bugzilla.redhat.com/show_bug.cgi?id=2278658
* https://bugzilla.redhat.com/show_bug.cgi?id=2278656
* https://bugzilla.redhat.com/show_bug.cgi?id=2278864
* https://bugzilla.redhat.com/show_bug.cgi?id=2278866
* https://bugzilla.redhat.com/show_bug.cgi?id=2278869
* https://bugzilla.redhat.com/show_bug.cgi?id=2278874
* https://pagure.io/fedora-cosmic/SIG/issue/1
* https://pagure.io/fedora-budgie/project/issue/4
* https://pagure.io/fedora-lxqt/SIG/issue/4
* https://pagure.io/i3-sig/Fedora-i3-Spin/issue/70
== Feedback ==
We have some feedback from the SIG owners for the keyboard handling
(see the links above).
We don’t have feedback for the VNC to RDP switch yet.
== Benefit to Fedora ==
* This change will enable removal of X11 dependencies from the
Anaconda which may result in reduction of installed software to the
system when installing from Live ISO where ISO content is copied to
the installed system (depends on the spin dependencies).
* Switching from VNC to RDP allow users to use remote graphical
installations which are more secure and have better performance .
== Scope ==
* Proposal owners: The Anaconda team will implement changes required
in the Anaconda project. More specifically:
** Switch Anaconda code to start Wayland environment on boot.iso instead of X11
** Change keyboard switching logic to use systemd-localed DBus instead
of libXklavier
** Switch remote graphical installations from VNC (TigerVNC) to RDP (GRD)
* Other developers: Fedora SIG owners needs to add support for their
environment to listen and use systemd-localed DBus API to reflect
current state of the DE/WM or they won’t have support of keyboard
layout switching in Anaconda.
* Release engineering: [https://pagure.io/releng/issue/12138 #12138]
* Policies and guidelines: Yes should be done after the implementation
(https://docs.fedoraproject.org/en-US/fedora-server/installation/interactive…
should switch to RDP)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
This will impact only Fedora installations so no compatibility or
upgrade issues.
== Early Testing (Optional) ==
We will reach Fedora QE to coordinate testing approach.
== How To Test ==
# Download any installation media
# Run the installation
# Look for breakages during the installation
Testing should be especially focused on:
* Changing resolution with ''inst.resolution'' kernel boot option
* Test new RDP solution (API will be clarified)
** Password can be set to the RDP
** Username can be set to the RDP
* Test keyboard layout switching works correctly
** On Live media, Anaconda should react on keyboard layout change in
the DE and set that to the installed system
** On Live media, Anaconda should be able to set the keyboard layout
changes to the live environment
** In the network installation (boot.iso) Anaconda should correctly
reflect keyboard layouts changes so text in the Anaconda is written by
the correct layout
** Check if specific keyboard layouts are configured and installed as expected
== User Experience ==
The only visible change to a user should be:
* Remote graphical installations will use RDP instead of VNC.
* Anaconda will be able to control keyboard layouts in the Wayland
environment on Live ISOs. This will improve user experience when
installing Fedora Workstation, Fedora KDE, Fedora Sway and other
Wayland based environments.
== Dependencies ==
No dependencies of this package related to this change.
== Contingency Plan ==
* Contingency mechanism: Postpone this change to the next Fedora
release. Revert landed changes in Anaconda if required.
* Contingency deadline: 100% code completion deadline
* Blocks release? No
== Documentation ==
No documentation yet. However, there are a few PRs ready for merge for
CentOS Stream 10:
* https://github.com/rhinstaller/anaconda/pull/5463
* https://github.com/rhinstaller/anaconda/pull/5470
* https://github.com/rhinstaller/anaconda/pull/5485
* https://github.com/rhinstaller/anaconda/pull/5498
== Release Notes ==
TBD
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
--
_______________________________________________
devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org
To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr…
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Hi!
I'm trying to get
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin implemented.
It was approved for F40, but only a few days before the mass rebuild,
so there wasn't time to do much, so it was retargeted to F41.
We now have some time before the F41 mass rebuild, so I want to push
all the changes required in various packages so that we have time to
work out any kinks before the mass rebuild commences.
When I started looking at individual packages, I discovered that we
have an old rule that packages are SUPPOSED to use "historical paths"
to list their files. This rule was introduced to make the transition
easier when UsrMove was implemented for F17. For example, mount.nfs
was historically installed as /sbin/mount.nfs, so nfs-utils must use
%files:/sbin/mount.nfs, even though /sbin is a symlink to /usr/sbin,
meaning that the real path after installation is /usr/sbin/mount.nfs.
And packages using a file path dependency on mount.nfs must use
/sbin/mount.nfs too.
To implement this rule, packages must use %buildroot/sbin during
installation and use literal "/sbin/" in the files section. This idea
made sense at the time, but now it seems overcomplicated and
unecessary. It requires additional work from packagers who create the
packages that provide the files, but also additional work from
packagers that want to refer to those files. In fact, I only found
three packages that implement the rule correctly: nfs-utils, glibc,
and ocfs2-tools. So step 0. is to drop the packaging rule:
https://pagure.io/packaging-committee/pull-request/1355
As to the actual sbin merge:
Currently, we have %_bindir==/usr/bin, %_sbindir==/usr/sbin,
and /sbin->/usr/sbin, /bin->/usr/sbin.
In the end state, we will have %_bindir==%_sbindir==/usr/bin,
and /bin,/sbin,/usr/sbin -> /usr/bin. This end state is simple:
_any_ path will works for any binary.
It's the transition, as we rebuild packages with the new definition,
that requires some careful handling.
After experimenting with a few different ways to handle this, the
following approach seems to work best:
1. rpm is patched to provide %_sbindir==/usr/bin.
(This affects what paths packages will list after being rebuilt.)
2. filesystem is patched to not contain /usr/sbin in %files,
but instead symlink /usr/sbin -> bin in %pretrans.
On fresh installations, this will succeed, so the merge is in place.
On upgrades, this will fail, meaning that /usr/sbin remains a dir.
There is also a %posttrans scriptlet to attempt a merge on upgrades,
more about this below.
In particular, since buildroots are created afresh for each build,
package builds will get merged-sbin.
3. We need to handle the case where package foo had /usr/sbin/foo, but
this file will be in /usr/bin/foo after rebuild. After the merge is
done, /usr/sbin/foo and /usr/bin/foo will point to the same
location, no problem, but during the transition, users or scripts
might call /usr/sbin/foo. To make this work, filesystem rpm gets a
scriptlet that will create symlinks from /usr/sbin to /usr/bin, for
any files which were installed by packages in /usr/sbin. (A list
was obtained using repoquery.)
Initially, I wanted to put those scriptlets in individual packages,
but that turns out to be a lot of duplicate work. Some packages
have multiple subpackages with files (currently) in /usr/sbin, so
we'd end up with a lot of churn. Doing it once in filesystem turns
out to be fairly easy.
4. We also need to handle the case where other package bar has
Requires:/usr/sbin/foo. Once foo has been rebuilt, it has only an
automatic provides for /usr/bin/foo. We could adjust bar for the
new path, but then bar would not be installable on old systems.
Instead, a compat virtual Provides:/usr/sbin/foo is added to foo.
We know that either /usr/sbin will be a symlink, or that filesystem
will create the /usr/sbin/foo symlink.
We need to ensure that the filesystem package that is installed is
actually new enough so that the Provides is not a lie.
filesystem.rpm gets a virtual
Provides:filesystem(unmerged-sbin-symlinks)=1 which is used as
Requires:filesystem(unmerged-sbin-symlinks) by foo.
(An explicit Provides/Requires allows us to adjust or rescind the
mechanism in the future.)
5. After this preparatory work is done, we can rebuild
various packages with updated rpm and filesystem.
Packages which don't use %_sbindir generally don't care.
Some packages which use %_sbindir need small adjustments.
There are some common failure modes:
a. 'mv %buildroot/%_bindir/foo %buildroot/%_sbindir/'
b. 'ln -s ../bin/foo %buildroot/%_sbindir/foo'
c. Listing both %_bindir/foo and %_sbindir/foo in %files
d. 'ln -sf ../bin/foo %buildroot/%_sbindir/foo.alt'
e. 'ln -sf ../sbin/foo %buildroot/%_bindir/foo.alt'
To make builds work both before and after the merge, a-c should be
conditionalized on '%if "%{_sbindir}" != "%{_bindir}"'.
d-e are fixed by using
'ln -sf --relative %{buildroot}/%_bindir/foo %buildroot/%_sbindir/foo.alt'
or
'ln -sf --relative %{buildroot}/%_sbindir/foo %buildroot/%_bindir/foo.alt'
I submitted / will submit a bunch of pull requests for various packages,
but not all, so I'm describing this here so that packagers can use this
as a hint.
6. As we rebuild packages in merged buildroots, and those packages are
deployed on user systems, in completely new installations,
/usr/sbin will be created as a symlink. On upgraded installations,
/usr/sbin is a directory and will contain a mix of files and symlinks.
filesystem.rpm also has a scriptlet to check if /usr/sbin contains
symlinks only, and once that's true, it will nuke /usr/sbin and
replace it by a symlink to /usr/bin. This will finalize the merge
on upgraded systems.
The plan:
I. Merge https://pagure.io/packaging-committee/pull-request/1355.
This isn't stricly necessary, but makes things simpler.
II. I've been doing test rebuilds of packages and filing pull requests
as described in 1–4. above. Those should be merged before the other
things, changes are conditionalized on '"%{_sbindir}"=="%{_bindir}"'.
Some pull requests have already been merged. If you get a pull
request, please review and/or merge.
https://src.fedoraproject.org/rpms/rpm/pull-request/56https://src.fedoraproject.org/rpms/filesystem/pull-request/11https://src.fedoraproject.org/rpms/chkconfig/pull-request/13https://src.fedoraproject.org/rpms/coreutils/pull-request/15https://src.fedoraproject.org/rpms/cyrus-sasl/pull-request/11 MERGED
https://src.fedoraproject.org/rpms/dmidecode/pull-request/8https://src.fedoraproject.org/rpms/exim/pull-request/16 MERGED
https://src.fedoraproject.org/rpms/exim/pull-request/17https://src.fedoraproject.org/rpms/glibc/pull-request/91https://src.fedoraproject.org/rpms/kmod/pull-request/12https://src.fedoraproject.org/rpms/libcap/pull-request/29 MERGED
https://src.fedoraproject.org/rpms/nfs-utils/pull-request/15https://src.fedoraproject.org/rpms/ocfs2-tools/pull-request/2https://src.fedoraproject.org/rpms/opensmtpd/pull-request/1https://src.fedoraproject.org/rpms/policycoreutils/pull-request/42https://src.fedoraproject.org/rpms/procps-ng/pull-request/7https://src.fedoraproject.org/rpms/rpcbind/pull-request/4https://src.fedoraproject.org/rpms/shadow-utils/pull-request/22https://src.fedoraproject.org/rpms/systemd/pull-request/131https://src.fedoraproject.org/rpms/util-linux/pull-request/17
III. I have two coprs:
https://copr.fedorainfracloud.org/coprs/zbyszek/merged-sbin/builds/https://copr.fedorainfracloud.org/coprs/zbyszek/unmerged-sbin/builds/
The first one has rpm and filesystem with the changes, so the builds
done there get %{_sbindir}==%{_bindir}. Other packages are
rebuilt with the patches from pull requests.
The second has old rpm and filesystem, and it serves as a check
that the same srpms as from the first copr still build fine without
the merge.
It should be possible to install the packages from the first copr
onto a system and either end up with a system with some links and
files in /usr/sbin, or /usr/sbin being a symlink.
I still need to do more builds in the coprs. If it all turns out to
work as expected, I think we're ready to execute the merge.
IV. After the pull requests for rpm and filesystem are accepted,
I'll build those in a side tag so that they appear in the
buildroots at the same time. (Things would be even more confusing
with just one of those.)
[rpm, filesystem]
There is a bunch of packages which do 5c in the list above.
Those will FTI until they have been rebuilt. I'll build those
in the same side tag so that the buildroot is not broken and
we don't get cascading build failures.
[rpcbind, systemd-udev, policycoreutils]
Once that's done, the side tag can be merged and packages
will see the new buildroot layout as they are rebuilt.
V. Other packages will need to rebuild to change the layout.
I think it'll make sense to rebuild any packages which have had
patches applied. There is no "flag day", but it'd be great if
we rebuild most packages with files in /usr/sbin, so that we can
actually test if the full transition works as expected.
VI. A special case of V. is packages using usermode helper with files
in /usr/bin and /usr/sbin. Here, each package is different and
input from maitainers will be needed.
As long as those packages are not rebuilt, they will continue to
function in the old state, but as point they'll need to be fixed or
retired.
I looked into setuptool, and AFAICT, the package is absolete and
doesn't actually work. A candidate for retirement.
I'm sure that I missed some corner cases. In case something breaks,
let me know, I'll try to fix or help to fix.
I want to finish working on rpm, filesystem, and other packages
soon (hopefully this week), and merge everything about a week later.
Zbyszek
Hi everyone,
I have just orphaned magic-wormhole (the original one written in
Python) and its dependencies. I no longer use it, I have no time to
fix the packages for new Python versions, and upstream is pretty much
dead since they started porting the project to Rust.
- python-magic-wormhole
- python-magic-wormhole-mailbox-server
- python-magic-wormhole-transit-relay
- python-txtorcon
- python-spake2
- python-hkdf
There is an alternative Go implementation of the "Wormhole Protocol"
(wormhole-william), for which eclipseo already submitted a review
request. It seems to be better maintained than the Python original, if
we want to have a Wormhole client in Fedora:
https://bugzilla.redhat.com/show_bug.cgi?id=1922806
The official port of magic-wormhole to Rust also seems to be
progressing, we might want to package that one instead once it's
released:
https://github.com/magic-wormhole/magic-wormhole.rs
Fabio
HI,
Development has effectively ended. For years Red Hat drove development for
its RHGS product, but with the EOL of RHGS at the end of 2024 [1], and the
disbanding of RHGS engineering at Red Hat, no development is being done.
The last update (11.1) was on 6 Nov., 2023. Little or no, development is
taking place in the greater Gluster community (such as it is), and no new
updates appear to be forthcoming from any direction.
Over in the CentOS world, the CentOS Storage SIG members have decided not
to build GlusterFS RPMs for Stream 10.
Therefore I intend to retire the GlusterFS package in Fedora 42, unless
someone else would like to step in and take over as package owner.
[1] https://access.redhat.com/support/policy/updates/rhs/
--
Kaleb
Hi everyone!
RPM 4.19 added automatic sysuser handling [1]. In Fedora 39 this feature
was not enabled right away [2] as it requires some care to properly
transition to it. Also going back to 4.18 was technically still the
fallback option during this change.
I just noticed in an issue in the RPM upstream repository [3] that the
sysuser feature is still not enabled. May be right now might be a good
time to get this going for Fedora 41. I am happy to help with the
technical details but would prefer if this effort was driven from within
Fedora.
Currently users are either done manually by calling useradd in
scriptlets or using the macros in systemd-rpm-macros which is a sub
package of the systemd package. RPM's mechanism is switched off by
rpm-4.18.92-disable-sysusers.patch in the rpm package.
This whole thing probably needs to be a Global Change involving a change
to the Packaging Guidelines [4] and may be an Mass Package Change
(although that might be avoided by changing the macros in
systemd-rpm-macros to NOPs).
Anyone interested in picking this up? I remember quite a few people
being exited about this when it was announced with the rpm-4.19 Change.
Florian
[1]
https://rpm-software-management.github.io/rpm/manual/users_and_groups.html
[2] https://fedoraproject.org/wiki/Changes/RPM-4.19
[3] https://github.com/rpm-software-management/rpm/issues/3073
[4] https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups
Hello!
Latest live555-2024.03.08 comes with an SONAME bump from 107 to 112.
The only consumer seems to be vlc, which I'll rebuild in a side-tag
(f41-build-side-87311) and submit together as an update.
This is rawhide only.
Regards,
Dominik
--
Fedora https://fedoraproject.org
Deep in the human unconscious is a pervasive need for a logical universe that
makes sense. But the real universe is always one step beyond logic.
-- from "The Sayings of Muad'Dib" by the Princess Irulan
Hi,
Phoronix recently release article[1] about Intel's Clear Linux with some
cool graphs showing nice performance gain compared to Xubuntu.
I didn't have time to dig in and look how it's performing against Fedora,
but I'd assume Fedora can be compared to Xubuntu in terms of compiler
settings.
I think i'll be interesting to look into it and find out if Fedora can't
tweak compiler settings (eg use LTO for critical things like Mesa, Kernel,
...). I think it could be interesting fo Fedora users to have this enabled
if there are not any disadvantages other than compile time, compile memory
usage and so on.
What do you think?
[1]
http://www.phoronix.com/scan.php?page=article&item=intel-clr-opengl&num=1
--
Best regards / S pozdravem,
František Zatloukal
Project Coordinator
Red Hat
I'm trying to figure out the best way to handle the situation where a
project decides to use submodules in Git. The archive generated doesn't
incorporate the submodule files.
I've done some searching on this, and haven't really come up with much.
I've reviewed: Packaging:Github
<https://fedoraproject.org/wiki/Packaging:SourceURL?rd=Packaging/SourceURL#G…>
; but that really doesn't address the submodule issue.
I looked through some packages that are currently in the Fedora repository
and found where a few folks have rebuilt the tarball and referenced that
version as the Source in the spec file; then they put in a comment stating:
The source of this package was pulled from upstreams' vcs. Use the
following
commands to generate the tarball:
...
- git clone
...
- git submodule init
- git submodule update
...
This approach is the best that I've found. Any other suggestions?
Thanks much!
Hi Folks,
We would like to replace power-profiles-daemon with tuned. There are
many power-related software that offer similar functions. Advanced
users may install several power management tools, for example, tuned
and power-profiles-daemon (ppd), and get confused about which tools
manage the system and cause unexpected behaviors for the system. By
integrating power-profiles-daemon with tuned, the user can get extra
features to finetune the system, and the basic feature provided by ppd
can be used according to the user's demand. It also can reduce the
efforts of the maintainer.
The impact of this plan would be gnome-control-center (power panel),
KDE, sysprof, and tuned (or some projects depending on ppd). We should
move the ppd API and features to tuned to provide the same features of
it. From the API aspect, we also can design a new API for the basic
feature, ppd provided but the software dependent on ppd should be
modified to use the new API. Although, for the long-term plan, a set
of new API is a good option. For the short-term plan, moving the
original one to tuned is good for those applications depending on ppd.
Moreover, the detailed change proposal can be found here.
https://fedoraproject.org/wiki/Changes/TunedReplacesPower-profiles-daemon
If you have any suggestions, please let us know.
Thank you. :)
--
BR,
Kate
We've been looking at the AppStream extractor issues in Fedora, and
we've come across a few broken applications. Broken apps are not
visible in the application installer. The apps include:
* albumart
* apitrace-gui
* appstream
* asylum
* audience
* bomber
* bovo
* calligra-braindump
* cervisia
* choqok
* classified-ads
* crrcsim
* cube
* curblaster
* dsi
* escape
* ettercap
* font-manager
* freedink-engine
* gap-core
* gnofract4d
* gvrng
* hgview
* hyperrogue
* kaddressbook
* key-mon
* kgraphviewer
* knotes
* konqueror
* LabPlot
* nextcloud-client (maybe fixed in distgit)
* openms
* openvibe
* owncloud-client
* pingus
* pioneer
* portecle
* qdigidoc
* qjackctl
* qsynth
* qtikz
* recoll
* renku
* rodent
* screengrab
* screenruler
* simple-ccsm
* slashem
* spectacle
* speed-dreams
* tennix
* tilp2
* tortoisehg
* trophy
* tzclock
* uzbl-defaults
* vdrift
* vegastrike
* wireshark-gtk
* xfce4-power-manager
* xfpanel-switch
* xskat
* yakuake
* zanshin
* zathura
The full list, along with what failed is available here:
https://dl.fedoraproject.org/pub/alt/screenshots/f26/failed.html
If you want any suggestions or advice, I'm happy to help. Most of the
failures are pretty self explanatory, e.g. "No <summary> in AppData"
or "icon was too small 24x24" -- our guidelines are here:
https://github.com/hughsie/appstream-glib/blob/master/README.md#guidelines-…
As a reminder, you can validate AppData files using: appstream-util
validate-relax file.appdata.xml
Thanks, and comments welcome. I can set up a script that sends email
to the package maintainer if this would be helpful, but I thought we
might be able to get the majority of these sorted with this email.
Richard.