Description of problem: It looks like erlang-bbmustache is a noarch package, but that perhaps it used to be an archful package when the most recent build of erlang-relx was made. The fix is easy though - we just need to rebuild erlang-relx against the noarch bbmustache so it picks up the noarch version of the requires. Version-Release number of selected component (if applicable): erlang-relx-3.26.0-1.fc30.x86_64
It looks like relx itself could also be a good candidate for conversion to noarch, though it will likewise require its dependent packages to be rebuilt.
Ah, looks like relx doesn't have any dependent packages, so we could just convert it to noarch and the act of that rebuild would make it pick up the noarch bbmustache too. I'll send you a PR for that.
https://src.fedoraproject.org/rpms/erlang-relx/pull-request/1
How can an erlang package be noarch since the beam files live under %{_libdir} (which is arch-specific)?
I mean: how does it play with `/usr/lib64/erlang` on my x86_64 system? Peter's guideline [0] uses arch-dependent packages, did something change recently allowing us to package erlang librairies as noarch? [0] https://fedoraproject.org/wiki/User:Peter/Erlang_Packaging_Guidelines
Starting with Fedora 29 Erlang packages can also go into /usr/share/erlang: https://fedoraproject.org/wiki/Changes/TrueNoarchErlangPackages I would not recommend changing any Fedora 29 packages at this point, but it's OK to do on Rawhide. The macros will automatically put the lib in the right place if it's a noarch.
erlang-relx-3.26.0-3 [0] should now be in rawhide. Closing. [0] https://koji.fedoraproject.org/koji/buildinfo?buildID=1153458