On Mon, 2020-10-26 at 12:38 +0100, Lubomír Sedlář wrote:
It's very much not obvious. I believe the root cause is that there are
two raw.xz images for Server on armhfp, which are indistinguishable in
the metadata. This causes loading of the metadata to fail. The script
that partial copy script needs the information from the metadata to
know what it should copy. Since loading the metadata fails, it ignores
the file and images are not copied.
My theory is that the image is updated only when the one of the armhfp
images fail and is missing from the compose.
I believe that in order to fix this, the ambiguity in metadata has to
be resolved in some way, like this:
https://pagure.io/pungi-fedora/pull-request/923
This does make me think of a few other questions...
1) If we consider this an Unacceptable State of Affairs, could we not
set things up such that pungi refuses to run such a compose at all?
2) Does productmd *really* have to choke on this case? I suppose it
depends exactly how it wants to parse the metadata, but fedfind parses
the same metadata and it doesn't choke on this; if you asked it to find
the 'Minimal armhfp raw-xz' image and expected to get only one result
you might have fun, but as long as you aren't actually doing something
that happens to exactly hit the 'duplicate' images, you can otherwise
work with the metadata OK.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net