If some package has (just) ppc64le in ExclusiveArch list, building on ppc64le COPR builders won't work because they will complain their arch is powerpc64le instead, which is being excluded by the spec directive. Would it be possible to make them report ppc64le instead?
Odd. I assume the f25 ones work as expected?
Perhaps @jwboyer or @sharkcz or @pbrobinson know whats going on here?
and 'uname -m' returns 'powerpc64le' on those cloud images?
One possible explanation is that COPR somehow (new mock possibly?) uses the architecture part from the compiler triplet (powerpc64le-unknown-linux-gnu) and koji is doing a translation to the canonical arches defined by rpm. I think this is something the COPR guys should answer.
@clime, do you have a link to such broken build task?
This is a problem in rpm-4.13.0.1-4.fc26.ppc64le package:
From ppc64le builder:
[root@copr-builder-440635433 dist-git]# rpm --showrc | grep host_cpu
-14: _build_cpu %{_host_cpu} -14: _host_cpu powerpc64le
Build CPU value is the main determinant here. rpm takes its value as arch of the machine. You can see it here https://github.com/rpm-software-management/rpm/blob/master/build/parsePreamble.c#L426. It's not connected to the way the cloud image is built.
Having powerpc64le as _host_cpu is valid, it's the value normally passed to configure. The problem is that it doesn't get translated into ppc64le by the build tools.
A build in koji does
./nspr/configure --build=ppc64le-redhat-linux-gnu --host=ppc64le-redhat-linux-gnu --program-prefix=
even with _host being powerpc64le
[root@ibm-p8-generic-02-guest02 ~]# rpmbuild --showrc | grep host -14: ___build_cmd %{?_sudo:%{_sudo} }%{?_remsh:%{_remsh} %{_remhost} }%{?_remsudo:%{_remsudo} }%{?_remchroot:%{_remchroot} %{_remroot} }%{___build_shell} %{___build_args} -14: _build %{_host} -14: _build_alias %{_host_alias} -14: _build_cpu %{_host_cpu} -14: _build_os %{_host_os} -14: _build_vendor %{_host_vendor} -14: _host powerpc64le-redhat-linux-gnu -14: _host_alias ppc64le-redhat-linux-gnu%{nil} -14: _host_cpu powerpc64le -14: _host_os linux -14: _host_vendor redhat -14: _target_alias %{_host_alias} -14: _target_vendor %{_host_vendor} %{_configure} --build=%{_build} --host=%{_host} \
The Fedora koji builder config contains
; The _host string to use in mock mockhost=redhat-linux-gnu
mock config for the build mentioned above
[dan@eagle ~]$ koji mock-config --task 20074770 # Auto-generated by the Koji build system config_opts['chroothome'] = '/builddir' config_opts['use_host_resolv'] = False config_opts['basedir'] = '/var/lib/mock' config_opts['rpmbuild_timeout'] = 86400 config_opts['yum.conf'] = '[main]\ncachedir=/var/cache/yum\ndebuglevel=1\nlogfile=/var/log/yum.log\nreposdir=/dev/null\nretries=20\nobsoletes=1\ngpgcheck=0\nassumeyes=1\nkeepcache=1\ninstall_weak_deps=0\nstrict=1\n\n# repos\n\n[build]\nname=build\nbaseurl=https://kojipkgs.fedoraproject.org//repos/f27-build/762213/ppc64le\n' config_opts['chroot_setup_cmd'] = 'groupinstall build' config_opts['target_arch'] = 'ppc64le' config_opts['root'] = 'f27-build-repo_762213' config_opts['plugin_conf']['root_cache_enable'] = False config_opts['plugin_conf']['yum_cache_enable'] = False config_opts['plugin_conf']['ccache_enable'] = False config_opts['macros']['%_host'] = 'ppc64le-koji-linux-gnu' config_opts['macros']['%_host_cpu'] = 'ppc64le' config_opts['macros']['%vendor'] = 'Koji' config_opts['macros']['%distribution'] = 'Koji Testing' config_opts['macros']['%_topdir'] = '/builddir/build' config_opts['macros']['%_rpmfilename'] = '%%{NAME}-%%{VERSION}-%%{RELEASE}.%%{ARCH}.rpm' config_opts['macros']['%packager'] = 'Koji'
see https://pagure.io/koji/blob/master/f/koji/__init__.py#_1494
Ok, good to know. So we can optionally fix this by adding config_opts['macros']['%_host_cpu'] = 'ppc64le'.
I would say this would be the correct solution even. Another could be updating /usr/lib/rpm/platform in rpm itself.
And same translation should be done for powerpc64 -> ppc64
Whats the status here? Is this issue solved?
This is an issue in rpm directly. This bug has been open: https://bugzilla.redhat.com/show_bug.cgi?id=1461288. It's not a cloud image issue as I thought in the beginning.
Well, last I see in that bug is that they are thinking it's NOTABUG. :smile:
So, if there is nothing to do from our side should we close this? (and track it in the rpm bug, wherever the fix seems to be)?
CLosing this now. Please reopen if there's anything we can do from the infra side.
:suspension_railway:
Metadata Update from @kevin: - Issue close_status updated to: Upstream - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.