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
Attachment:
signature.asc
Description: PGP signature
-- _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
