I had noticed this too. Thanks for doing the investigation to uncover the relevant spec. I suppose this is a bug in bodhi: it shouldn't permit updates to ship with unsupported markdown.

Thanks for doing the investigation to uncover the relevant spec

Actually I learned this from one of the Software app maintainers hehe.

Can someone file an issue against whatever component needs fixing, please?

I will move it.

https://github.com/fedora-infra/bodhi/issues/4669

https://github.com/fedora-infra/bodhi/issues/4669

No responses to this since it was filed. Do we need to chase someone?

Some changelogs also attempt to use links, which aren't supported either:

I have now filed an infrastructure ticket to request that markdown be disabled entirely: https://pagure.io/fedora-infrastructure/issue/10986

It seems this is a GNOME Software bug: GNOME Software is itself interpreting the markdown and replacing it with markup that it does not actually support.

I reopened the issue. By the way, Milan Crha made a comment in there that I didn't see:

"Hmm, the PackageKit plugin has gs_plugin_packagekit_fixup_update_description, which uses markdown = gs_markdown_new (GS_MARKDOWN_OUTPUT_PANGO);. The GsMarkdown is a built-in thing in the gnome-software."

Can I close this issue and set the "Deferred to upstream" label?

Let's leave this open here so we can continue tracking it. Thanks for reopening the Software issue.

Well, I see the Software issue is already fixed, so let's move this to Testing state to verify that it's true.

Don't know if this example below will count, but this changelog is using hashtags for headers:

This still looks pretty bad indeed. I'd say this is QA fail. We really are going to need to remove markdown from bodhi. Reopened https://pagure.io/fedora-infrastructure/issue/10986.

Also pinging @mattdm on this for visibility because it looks like the infrastructure issue has been triaged low gain high trouble, which is not encouraging.

Happened again today:

I'll just say the original problem really is fixed. There is no more markup in the update descriptions. Now it's only mark_down_. But markdown isn't supported either, so... back to square one.

@mcrha is working on supporting all of Fedora-flavored Markdown in https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2054

https://gitlab.gnome.org/GNOME/gnome-software/-/issues/2054 has landed and will be in 44.beta. Moving back to QA.

I see this in 44.1:

I see this in 44.1:

OK, clearly this issue is unfortunately not fixed. The update in question is here and it appears to use completely normal markdown. I don't think anything is wrong with this update; it looks like a GNOME Software problem.

@mcrha is this something you could investigate?

That simple markdown parser in gnome-software does not support links. I believe it's because appstream has very limited set of the tags:
https://www.freedesktop.org/software/appstream/docs/chap-Metadata.html#tag-description

Fedora markdown can do more that that. I know there had been suggested to disable markdown for bodhi, but I'd not do it. The above does not look great, but it's not that bad either.

Sigh. We're going to want to either (a) disable support for links in bodhi, or else (b) add support for links in GNOME Software.

We want both sides to match for all supported formatting, not just links. We don't ever want to see raw markdown in GNOME Software update descriptions.

Right, I can understand that, but I'm afraid gnome-software upstream won't need to support full markdown, it's tight to the appstream specification, which is way more limited.

I thought the advantage of the markdown is that if the reader app does not understand it, the user can still read it. The text looks more techy that way, no doubt, but I consider this more like a nice-to-have, than a show stopper.

I won't limit either side of this "equation". The web page can look better than the gnome-software, it's okay.

We discussed this at today's meeting and agreed:

• The problem with unprocessed markdown appearing in changelogs is much less severe than the original problem here, which was markup appearing in changelogs. This doesn't happen anymore.
• It would be nice for GNOME Software to support the same markdown as is supported by bodhi. Update descriptions are not provided by appstream metadata, so we're not sure why Software should be limited to what is supported by appstream. We don't want to ask bodhi to remove support for markdown links or limit allowable markdown.
• Regardless, links are useful, and appstream should probably support markdown links in metadata.

Action item here: Michael and Kalev to discuss with Milan and decide where to report bugs. We'll likely at least want GNOME Software to support links.

We will close this downstream issue after upstream bug reports are created, since with the markup issue fixed, the remaining problem is no longer severe enough to merit further downstream tracking.

we're not sure why Software should be limited to what is supported by appstream.

It's not provided by appstream in case of bodhi/PackageKit, but otherwise gnome-software heavily depends on the appstream, including version history. I've been told by upstream there's not much will to support more than what appstream allows, but it was long ago, I even do not have a pointer to that text.

We'll likely at least want GNOME Software to support links.

Feel free to file a bug for it in gnome-software upstream. I can try to cook something for it there.

Ouch, I sent the comment too early...

Maybe one could use something like cmark to convert the markdown to HTML and then strip anything unknown/unneeded from the HTML output. Whether that would be more trouble that extending current in-code markdown converter I do not know. The gnome-sofware surely cannot show HTML and an added dependency on cmark, or some such library, might be too much overhead.

Found this bug by yours truly. I will reopen that one.

We will close this downstream issue after upstream bug reports are created, since with the markup issue fixed, the remaining problem is no longer severe enough to merit further downstream tracking.

We're done here. Thanks everyone (especially Milan)!