This is actually not true or at least from what I can see from spec file. Meson is listed as BuildRequires which means it is needed only on build time. So unless you want to rebuild this components, which is not supported as far as I know, this is not a bug.

Can you please share more info?

-Tom

(In reply to Tomas Pelka from comment #2)

> So unless you want to rebuild this components, which is not supported
> as far as I know, this is not a bug.
> 
> Can you please share more info?
> 
> -Tom

That is the problem.

FTBFS = Fails To Build From Source

Rebuild projects such as CentOS and Scientific Linux are affected.

I think there are other GNOME packages also used meson.

Maybe we need to add meson to RHEL 7.6?

OK that explains it. Majority of Gnome packages are build with meson/ninja-build no more autotools.

There is meson/ninja-build in EPEL can you use it?

> There is meson/ninja-build in EPEL can you use it?

For Scientific Linux I've rebuilt these locally to get the i686 versions.  However, they require python36 and a handful of other packages.

Meson should be available in RHEL 7.6, no?

meson is not packaged with RHEL.  It is in EPEL7 though.

It took me a while to grok this problem/request since it is nothing specific to pango...

I suspect the answer will be WONTFIX, since I understand that it is difficult to include meson in RHEL7 due to dependency issues, but moving this to the meson component where it belongs (or possibly should be distribution).

I believe both meson and ninja-build are in epel.

(In reply to Tomas Pelka from comment #12)
> I believe both meson and ninja-build are in epel.

Correct, but in my opinion, it is beyond this problem.
If someone needs to rebuild an original src.rpm, whatever the reason, should be able to do it without needing epel.
If RHEL uses meson and ninja-build to build its packages, they should be available "somewhere" within RHEL, it could even be a toolset.

Pablo

(In reply to Pablo Greco from comment #13)
> (In reply to Tomas Pelka from comment #12)
> > I believe both meson and ninja-build are in epel.
> 
> Correct, but in my opinion, it is beyond this problem.
> If someone needs to rebuild an original src.rpm, whatever the reason, should
> be able to do it without needing epel.
> If RHEL uses meson and ninja-build to build its packages, they should be
> available "somewhere" within RHEL, it could even be a toolset.
> 
> Pablo

Correct but if I'm not mistaken self-hosting is not supported so even if you rebuild pkg from src.rpm you will lose the support as it is technically a different package.

I can share with you as an end customer who is having to build X11 to compile with some perforamnce testing needs and security requirements .... not having meson or ninja in with the tools has made compiling software a mother of all evils situation.

If you want to capture a feel of what happens to a customer .... take a minimal build system, and then take the goal of compiling X11R7 as the end product so you can have the software located in a non-Jail filesystem (in my example /pac).

Look at this hot mess ...

https://www.x.org/wiki/Building_the_X_Window_System/

Just from my notes ... so far (to help if you decide to try this out ....) ..

What can happen if RHEL isn't careful is an alternative linux can be used since it will work fine with the debian way.    Do note I am a big fan of your stuff, but in the past week I keep wondering which tech alter I need to bleed the sacrifical chickens on to make things go ....


# subscription-manager register
# subscription-manager auto-attach
# for f in rhel-7-server-{devtools,extras,optional}-{debug-rpms,source-rpms,rpms} rhel-7-server-rh-common-{debug-rpms,source-rpms,rpms} rhel-7-server-thirdparty-oracle-java-{rpms,source-rpms} rhel-server-rhscl-7-{debug-rpms,rpms}; do subscription-manager repos --enable=${f}; done
# rpm -qa > sncr-pac-build-1.txt
# sort sncr-pac-build-1.txt | awk '{split($0,a,".");!b[gensub(/-[0-9B].*/,"",a[1])]++}END{for(k in b) printf "%s\n", k; print}' > sncr-pac-build-1
# sort phs.txt | awk '{split($0,a,".");!b[gensub(/-[0-9B].*/,"",a[1])]++}END{for(k in b) printf "%s\n", k; print}' > phs
# yum remove desktop-file-utils emacs-filesystem iwl\* NetworkManager\* xdg-utils
# yum install zlib-devel devtoolset-8 devtoolset-8-\* byacc byaccj byaccj-debuginfo python-ply gettext gperf gperftools gperf-\* gperftools-\* m4 ncurses ncurses-\* autoconf automake libtool libtool-\*
# yum install llvm-toolset-7.0 llvm-toolset-7.0-\* llvm-private llvm-private\-* libpng libpng-\* libtalloc libtalloc-\* zlib zlib-\* mesa-\* mtdev mtdev-\* libgudev1 libgudev1-\* libgcrypt libgcrypt-\* crypto-utils fontconfig fontconfig-\* freetype freetype-\* asciidoc asciidoc-\* doxygen doxygen-\* xmlto xmlto-\* xmltoman libxslt pixman pixman-\* xkeyboard-config xkeyboard-config-\* libevdev libevdev-\*
# cd /tmp; wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
# yum localinstall epel-release-latest-7.noarch.rpm 
# yum repolist
# yum -y install 
 xorg-x11-util-macros bison bison-\* python-mako libxshmfence libxshmfence-\* libxcb xcb-\* compat-libxcb-\* compat-xcb-util libXrandr libXrandr-\* libgcrypt libgcrypt-\* xorg-x11-apps xorg-x11-docs xorg-sgml-doctools xorg-x11-drivers xorg-x11-drv-\* xorg-x11-fonts-\* xorg-x11-resutils xorg-x11-server-\* xorg-x11-utils xorg-x11-xinit-session xorg-x11-fonts-misc xorg-x11-xkb-\* xorg-x11-xinit-debuginfo xorg-x11-xtrans-devel xorg-x11-server-debuginfo

After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.