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