Hi Philipp, On Tue, 14 Jul 2020 16:12:34 +0200 Philipp Rudo <prudo@xxxxxxxxxx> wrote: > Hi everybody, > > I was reported that 'dnf builddep kernel' fails on RHEL8 on s390 with > > No matching package to install: 'pesign >= 0.10-4' you got it right in the analysis, any (downloaded) srpm must be ideally rebuilt before doing a build to avoid such surprises and the buildsystems (koji, mock) are doing it themselves. There is not much else we do as it is how RPM works. Dan > > which doesn't make sense as the kernel.spec only adds pesign as build > requirement for x86_64 and aarch64. While looking into this I think I > fond a rather fundamental problem in the building process not only > affecting RHEL8 but also RHEL7 and Fedora (guess CentOS too, but > haven't checked). So I'm reaching out to you in the hope we can find > a solution together. > > My theory is that the BuildRequires in the .spec file are only > evaluated once during the creation of the srpm and then stored in a > simple list in some rpm meta data in the header [1]. After that the > meta data is fixed and any condition (architecture, with_* flags) are > fixed to what was chosen while creating the srpm. Thus by sharing a > srpm among the architectures all architectures get the same build > requirements regardless of what's been defined for them in the > kernel.spec. > > To proof the theory I took a closer look at a freshly downloaded the > srpm (dnf download --source kernel) for RHEL8 on s390 and indeed its > architecture (rpm -qi) is x86_64. After rebuilding the srpm (rpmbuild > -rs) on s390 pesign is no longer listed as build requirement and dnf > builddep works again. > > As said above RHEL7 and Fedora are also affected by the problem. The > only reason why it does not show is that their srpms are build on ppc > (3.10.0-1152.el7) and armv7hl (5.7.7-200.fc32), which both don't > require pesign (which of course is missing for x86 in these > cases...). Using the same trick from above, i.e. rebuilding the srpm > on x86 and running dnf builddep on s390 triggers the same error as > for RHEL8. > > To be honest I'm not really sure what I shall make of this problem > myself. Currently it only seems to affect the build requirements, > which is annoying but no real deal beaker. But it is easy to create > cases where, e.g. Conflicts or even the License are affected, which > elevates the problem to completely different levels. > > Sorry for the long mail > Philipp > > P.S. Checking resent RHEL8 brew builds I see in the root.log that it > too calls 'dnf builddep' on s390. Apparently without any problem. I > have absolutely no clue what kind of magic is responsible for that. > > [1] > http://ftp.rpm.org/max-rpm/s1-rpm-file-format-rpm-file-format.html#S2-RPM-FILE-FORMAT-HEADER > _______________________________________________ kernel mailing list > -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to > kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List > Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
