<div dir="ltr"><div><div><div><div><div><div><div><div>Hi,<br><br></div>I wanted to let you know that I have had success with running the CentOS 7 userland on an Avnet PicoZed module using the Xilinx-provided source for the kernel and U-Boot available on their GitHub project (using the "xilinx-v2016.1.01" tag for the kernel source and the "xilinx-v2016.1" tag for U-Boot).  <br><br></div>We have been running Fedora 20 ARM on these modules (with the same kernel and version of U-Boot) for a little while and thought we would try out CentOS for various reasons (longer term support, similarity to RHEL 7, etc.).<br><br></div>One challenge I have run into, though, is that our software depends on "python-matplotlib" and a few other packages that haven't been prebuilt for CentOS 7 (but were available under Fedora 20 ARM).  I was able to successfully build a number of these packages from source RPMs, but building "python-matplotlib" is starting to get a bit complicated, especially, with what appears to be some circular build dependencies among the source packages.  For example, here is one set of dependencies leading to what appears to be a circular dependency:<br><br></div>python-matplotlib -> gtk2-devel<br>gtk2 SRPM (for gtk2-devel) -> pango-devel  <br>pango SRPM (for pango-devel) -> harfbuzz-devel <br>harfbuzz SRPM (for harfbuzz-devel) -> graphite2-devel <br>graphite2 SRPM (for graphite2-devel) -> asciidoc <br>asciidoc SRPM (for asciidoc) -> graphviz <br>graphviz SRPM (for graphviz)-> gtk2-devel, pango-devel, etc.<br><br></div>Similarly, there is also the following circular dependency, starting with asciidoc:<br><br>...<br>asciidoc -> dblatex <br>dblatex SRPM (for dblatex) ->
 texlive-collection-xetex <br>texlive SRPM (for texlive-collection-xetex) -> gtk2-devel, pango-devel, etc.<br><br></div>Any suggestions for how to deal with these apparent circular dependencies?  I have been building the RPMs by hand with "rpmbuild --rebuild <source RPM>" trying to work through the dependencies and installing as many binary packages as are available.  Clearly, there must be some way to deal with this since these packages have been built successfully for other architectures.<br><br></div>Thanks,<br><br></div>Paul <br></div>