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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
