V Fri, Mar 08, 2024 at 04:54:04PM +0000, Zbigniew Jędrzejewski-Szmek napsal(a):
On Fri, Mar 08, 2024 at 09:07:30AM +0100, Petr Pisar wrote:
(2) Both perl-Alien-pkgconf NEVRAs reports a differing /usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json content. That content looks likes this:
{"libs":"-lpkgconf","version":"2.1.0","install_type":"system","cflags":"-I/usr/include/pkgconf","dll":"/lib64/libpkgconf.so.4.0.0"}That means you had to perform rebuilds of the same NEVRA with different libpkgconf-devel packages in the build roots. That looks like a bug in your mini rebuild scheduler.
Diffoscope says:
├── ./usr/lib64/perl5/vendor_perl/auto/share/dist/Alien-pkgconf/status.json │ ├── Pretty-printed │ │┄ Ordering differences only │ │ @@ -1,7 +1,7 @@ │ │ { │ │ "libs": "-lpkgconf", │ │ + "dll": "/lib64/libpkgconf.so.4.0.0", │ │ "version": "2.1.0", │ │ - "install_type": "system", │ │ "cflags": "-I/usr/include/pkgconf", │ │ - "dll": "/lib64/libpkgconf.so.4.0.0" │ │ + "install_type": "system" │ │ }
It would be great to sort the dictionary to avoid this randomness.
You are right. I completely forgot the ordering. I fixed it in perl-Alien-pkgconf-0.19-10.fc41.
(3) Some packages listed in builds-2024-02-fc41-filtered.txt are missing from builds-2024-02-fc41-filtered.results.txt. E.g. perl-CPAN-Plugin-Sysdeps-0.73-1.fc41 is listed as COMPLETE, yet results are missing.
Yes. Some packages failed to build, and then I finished the build early because there were already enough interesting results.
(The few failures I looked at were caused by differences in BR between architectures. This is currently a corner case that I'm not sure how to deal with. Most of the time, using a srpm from a different architecture works fine, but in some cases the set of installed packages would differ, and then I can't figure out which version of the rpm for the local architecture would have been used and buildroot creation fails. I would be happy to describe the problem in more detail. It's also possible that other packages FTBFS, I didn't look into this and I didn't save the logs.)
(4) dnf5-5.1.13-1.fc41.src reports changes in Requires (e.g. "removed REQUIRES createrepo_c"). That again looks like you built the same NEVRA in different build roots (for some reason "%bcond_without tests" flipped).
Yes, the build root is different. I install the package set that was used for the main package build and just call mock with that and it does both srpm and the binary rpms there. But koji does the srpm build in a separate buildroot that is smaller.
Using SRPMs from a different archicture won't work as you find out. You need to unpack the SRPM and do "dnf builddep THE_UNPACKED_SPEC_FILE". But then you will have a different build root content comparing to the Koji build.
So I guess an architecture of the builder needs to be handled as a piece of the reproducibility environment (i.e. reproducing a noarch package built on s390x on s390x, not on x86_64), or you can assume that noarch builds should not differ among builder archictures and then ignore the build root content and only focus on the resulting binary package.
-- Petr