RPM build on openSUSE Build Service fails

RPM build on openSUSE Build Service fails. The relevant bit of the build log reads:

[   27s] ... checking for files with abuild user/group
[   27s] ... running 00-check-install-rpms
[   27s] ... installing all built rpms
[   28s] Preparing packages...
[   28s] python311-hzb-rdm-web-0.1-lp156.1.1.noarch
[   28s] python3-hzb-rdm-web-0.1-lp156.1.1.noarch
[   28s] ... running 50-check-binary-kernel-log
[   28s] ... running 50-check-core-files
[   28s] ... checking for core files
[   28s] ... running 50-check-debuginfo
[   28s] ... testing for empty debuginfo packages
[   28s] ... running 50-check-filelist
[   28s] ... checking filelist
[   28s] ... running 50-check-gconf-scriptlets
[   28s] ... testing GConf scriptlet presence
[   28s] ... running 50-check-installtest
[   28s] ... testing for pre/postinstall scripts that are not idempotent
[   28s] ... running 50-check-invalid-provides
[   28s] ... running 50-check-invalid-requires
[   28s] ... running 50-check-kernel-build-id
[   28s] ... running 50-check-lanana
[   28s] ... running 50-check-libtool-deps
[   28s] ... testing devel dependencies required by libtool .la files
[   28s]     (can be skipped by "skip-check-libtool-deps" anywhere in spec)
[   28s] ... running 50-check-packaged-twice
[   28s] found conflict of python3-hzb-rdm-web-0.1-lp156.1.1.noarch with python311-hzb-rdm-web-0.1-lp156.1.1.noarch:
[   28s]   - /srv/www/htdocs/favicon.ico
[   28s]   - /srv/www/htdocs/images/hzb-logo.svg

So the actual build of the packages succeeds, but the openSUSE post-build-checks complain about some files being packaged twice.

Background: we are using subpackages to build multiple RPM packages from a single source to provide the package for multiple Python versions, 3.6 and 3.11 in this case. We include some static web content (the HZB logo), because we anticipate that most web service scripts will need it. Now the RPM linter complains that we include this static web content in more than one subpackage.

Actually, packaging these files twice doesn't cause any real problems. So we could solve this by disabling this particular linter check and ignoring the issue. We probably also could solve it with a somewhat smarter package design.