On Fri, Aug 14, 2020 at 7:12 AM Rich Mattes <richmattes@gmail.com> wrote:

On Fri, Aug 14, 2020, 7:37 AM Richard Shaw <hobbes1069@gmail.com> wrote:

I'm getting consistent differences across at least two versions of zipios and the offending arches seem to always be s390x and ppc64le.

BuildError: The following noarch package built differently on different architectures: zipios-doc-2.2.1.0-5.fc33.noarch.rpm
rpmdiff output was:
removed     /usr/share/doc/zipios/html/dir_0f7abfb91da657dcb27dff31b827312f.html
removed     /usr/share/doc/zipios/html/dir_32504400af4b8c553a85c61a7ef01dea.html
added       /usr/share/doc/zipios/html/dir_8f6b9ad7431774f92e3ec3efe35ac7da.html
added       /usr/share/doc/zipios/html/dir_dd208edd458824e9eaf902c6da16200d.html

zipios 2.2.5.0

zipios 2.2.1.0

Is this likely a big vs little endian thing?

Is it a CMake package? The vpath_builddir that is now used for out of source builds is different for each architecture. If that directory is included in the doxygen processing paths you'll get this error.

Yes, but why is doxygen using that to generate a directory name? Bah...

 
I worked around this in a few of my packages by adding the cmake build directory to the EXCLUDE list in the doxyfile.

I added a patch to the doxy.in file and it seemed to get rid of one of the directory problems, but not both...

https://koji.fedoraproject.org/koji/taskinfo?taskID=49250574

Patch:
 
$ cat zipios-doxygen.patch
Index: doc/zipios.doxy.in
===================================================================
--- Zipios/doc.orig/zipios.doxy.in
+++ Zipios/doc/zipios.doxy.in
@@ -152,7 +152,7 @@ FULL_PATH_NAMES        = YES
 # will be relative from the directory where doxygen is started.
 # This tag requires that the tag FULL_PATH_NAMES is set to YES.
 
-STRIP_FROM_PATH        = @CMAKE_CURRENT_SOURCE_DIR@
+STRIP_FROM_PATH        = @CMAKE_CURRENT_BINARY_DIR@
 
 # The STRIP_FROM_INC_PATH tag can be used to strip a user-defined part of the
 # path mentioned in the documentation of a class, which tells the reader which

Thanks,
Richard