I don't think this is a releng/pungi config issue. The images in the official pungi metadata have the subvariant "KDE_Mobile". @jgrulich saw "kde" in https://fedoraproject.org/releases.json , which is produced by something the websites team owns, I believe. I suspect that tool has an issue with a false match on a substring.

After some poking around, that file now seems to live in https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0 , but I can't find any trace of the releases-json.py script that's supposed to generate it any more. I can only guess it's being updated manually, or with a copy of the script that lives somewhere else? @darknao , can you clarify? Thanks!

The script is here: https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0/-/blob/develop/.build/build_fmw_release.py?ref_type=heads and it's using fedfind to fetch metadata.

oh hey it would be funny if the bug is in fedfind! and entirely possible. :P I will look at that.

ahhh, yeah, possibly it is, if you run the script on the synced/modified composes which have their native metadata stripped. that may force fedfind to fall back on metadata synthesis - where it essentially tries to figure out the properties of the images based on their filenames.

there's an additional wrinkle, which is that before it does that it tries to identify the 'original' compose and pull its metadata from an archive. however that archive used to be PDC, and PDC got retired, so I flipped it over to using an archive we keep alongside the composes - https://kojipkgs.fedoraproject.org/compose/metadata-archive/ . but I didn't get around to hacking up a script to import older compose data into that archive yet. So...if you run with an older fedfind, it will still try and use PDC, that'll fail, and it'll fall back on synthesis. If you run with a newer fedfind, it'll check the new 'metadata-archive', but it may not find what it's looking for if it's too old, and...fall back on synthesis.

so on the whole I should fix things up so the synthesis gets the subvariant right for kde mobile images :) I will do that and cut a new fedfind release, once that's done if you regenerate releases.json with the new fedfind, it should be correct.

In the meantime, I pushed an update to the json file with the KDE_Mobile subvariant fixed.
For that, I rewrote the script to fetch the metadata from koji directly since I could find everything I needed there without relying on fedfind (well, except f38, but who needs that? :)).
https://gitlab.com/fedora/websites-apps/fedora-websites/fedora-websites-3.0/-/blob/develop/.build/build_fmw_release_2.py?ref_type=heads

Hmm, yes, that...looks like it should...probably work. I'm a bit afraid that we do something more than just split off half the arches when we mess around with the composes for release, but I can't recall what the other thing is off the top of my head :|

there is a potential corner case when we do a weird thing we've done a couple of times in the past. sometimes we run two composes that might ultimately be released, and pick between them at go/no-go - say, a Beta-1.4 and a Beta-1.5. If we decided to ship the Beta-1.4 compose, we might sync that one, but the -latest symlink might still point to the Beta-1.5 compose, if nobody redirected it. That might result in broken URLs. It's probably not critical, but worth looking out for in future.

I've also fixed it (I hope) fedfind-side with 6.0.4, so if you need to use the old script, if you run it with fedfind 6.0.4 it now ought to get the right subvariant for these images.

So, with that do we need an update to FMW?

So, with that do we need an update to FMW?

No, it should still work, but no longer needs the workaround I applied before.

ok, great. Lets close this then... feel free to reopen if there's anything more to do here.