flatpak-module-tools

#17 renaming metainfo with xmlns fails
Closed by yselkowitz. Opened by yselkowitz.

Closed
Reopen Issue

gucharmap's metainfo file includes an xmlns (upstream link):

<component type="desktop-application"
  xmlns="https://specifications.freedesktop.org/metainfo/1.0">
  <id>gucharmap.desktop</id>

This breaks the container build with rename-appdata-file:

  File "/usr/lib/python3.11/site-packages/flatpak_module_tools/flatpak_builder.py", line 215, in _rename_desktop_file
    raise RuntimeError("Root node is not <application> or <component>")

The reason being is that ElementTree considers the root node tag to be {https://specifications.freedesktop.org/metainfo/1.0}component due to the xmlns. But If I change n_root.tag to n_root.tag.rpartition('}')[2] in flatpak_builder.py (multiple lines) then I get past that error, but the altered file fails later on:

Processing application org.gnome.Charmap
(appstream-compose:1241194): As-DEBUG: 21:53:04.080: looking for appdata path '/home/yselkowi/modulebuild/flatpaks/gucharmap-stable-3720230104014544/build/files/share/appdata/org.gnome.Charmap.appdata.xml'
Error loading AppData file: failed to parse /home/yselkowi/modulebuild/flatpaks/gucharmap-stable-3720230104014544/build/files/share/appdata/org.gnome.Charmap.appdata.xml: no <component> node

The reason possibly being that the altered XML's nodes are all prefixed with ns0, e.g.ns0:component instead of component etc.

The spec says that an xmlns should generally be avoided, but it seems to still be allowed. (FWIW AFAICS gucharmap is the only metainfo file on my system with xmlns.) Can/should flatpak-module-tools handle this correctly, or should this be treated as a bug in the affected package(s) and fixed there?

I am not sure how to handle the xml namespace, but if you need a hacky workaround, it's possible to sed the files in container.yaml flatpak cleanup-commands section, something like:

    cleanup-commands: |
        sed -i 's@<id>gucharmap\.desktop</id>@<id>org.gnome.Charmap</id>@' \
            /app/share/metainfo/gucharmap.metainfo.xml

cleanup-commands gets run before appstream-compose so you can hack it in whatever way is necessary to get it to pass.

See e.g. https://src.fedoraproject.org/flatpaks/flatpak-runtime/blob/f37/f/container.yaml for an example.

Although maybe ask upstream first if they would be willing to change the ID to avoid having the do the renames downstream?

Thanks, that gave me the hint I needed to get this working:

https://src.fedoraproject.org/flatpaks/gucharmap/blob/stable/f/container.yaml#_19

Metadata Update from @yselkowitz:
- Issue status updated to: Closed (was: Open)
Metadata
None
None
None
None
None
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.