Bug 1568277

Warnings come from libmodulemd, Reassigning.

This error message is actually correct. The bug here was that the repodata was being generated with the wrong key for module name.

*** This bug has been marked as a duplicate of bug 1567921 ***

(In reply to Stephen Gallagher from comment #2)
You say that "the repodata was being generated with the wrong key for module name.", but I can't see any link between the messages and what you said. Why the message says something completely incomprehensible?

The repodata YAML was generated with the word “name” instead of the word “module” to reference the module this defaults object applies to. libmodulemd is a strict parser, and because it can’t figure out what module this document is meant to apply to, it skips it and warns that the reason it was skipped was that it had no module name.

I suppose I could try to figure out a different phrasing, but “Invalid [ModulemdDefaults] document. [Module name not specified]” reads fairly clearly to me.

(In reply to Stephen Gallagher from comment #4)
> I suppose I could try to figure out a different phrasing, but “Invalid
> [ModulemdDefaults] document. [Module name not specified]” reads fairly
> clearly to me.

No, it does not. I read it as I should specify some modulename somewhere on DNF command line, which is apparently not the case. It does not mention repository data or anything else.

Really, this message might make a sense in libmodulemd context, but does not make any sense in DNF context.

TBH, it is surprising to see some libmodulemd message in DNF output.

(In reply to Vít Ondruch from comment #5)
> (In reply to Stephen Gallagher from comment #4)
> > I suppose I could try to figure out a different phrasing, but “Invalid
> > [ModulemdDefaults] document. [Module name not specified]” reads fairly
> > clearly to me.
> 
> No, it does not. I read it as I should specify some modulename somewhere on
> DNF command line, which is apparently not the case. It does not mention
> repository data or anything else.
> 
> Really, this message might make a sense in libmodulemd context, but does not
> make any sense in DNF context.
> 
> TBH, it is surprising to see some libmodulemd message in DNF output.

Yeah, you're correct about that... I'll see what I can do about it. I'm a little wary of turning it off by default though; because of a mistake (mine) in the API design, right now it's the only way for us to know if a defaults document is being skipped because it was incorrect.

I'll reopen this ticket and use it to track fixing that for 2.0.0 (because it will probably involve an ABI break).

Wonderful, thx. Looking forward to it.

libmodulemd-1.4.0-2.fc27 has been submitted as an update to Fedora 27. https://bodhi.fedoraproject.org/updates/FEDORA-2018-3967567d37

libmodulemd-1.4.0-2.el7 has been submitted as an update to Fedora EPEL 7. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b882e25943

libmodulemd-1.4.0-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-de1730ac2f

libmodulemd-1.4.0-2.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2018-e46780b82c

I was able to avoid an ABI break, so this made it into 1.4.0. Now all of the libmodulemd messages are triggered at DEBUG level only, and only if `G_DEBUG_MESSAGES=libmodulemd` (or "all") is set in the environment.

libmodulemd-1.4.0-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-de1730ac2f

(In reply to Stephen Gallagher from comment #12)
Thx. I have not tested it, but it sounds promising :)

libmodulemd-1.4.0-2.el7 has been pushed to the Fedora EPEL 7 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b882e25943

libmodulemd-1.4.0-2.fc26 has been pushed to the Fedora 26 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e46780b82c

libmodulemd-1.4.0-2.fc27 has been pushed to the Fedora 27 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-3967567d37

libmodulemd-1.4.0-2.fc28 has been pushed to the Fedora 28 stable repository. If problems still persist, please make note of it in this bug report.

libmodulemd-1.4.0-2.fc26 has been pushed to the Fedora 26 stable repository. If problems still persist, please make note of it in this bug report.

libmodulemd-1.4.0-2.fc27 has been pushed to the Fedora 27 stable repository. If problems still persist, please make note of it in this bug report.

libmodulemd-1.4.0-2.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.