On Mon, Mar 11, 2024 at 12:29:49PM +0100, Petr Pisar wrote:
> 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.
Ah, cool, thanks! I can confirm that with
perl-Alien-pkgconf-0.19-10.fc41, rpmdiff reports no differences.
> > > (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.
Yes, but that'd be a bummer. If we were strict about this, the number
of packages that can be rebuilt would go down by a large percentage.
So I think we need to take some hybrid approach, where we try to redo
the srpm build on a different architecture.
Zbyszek
P.S. I pasted this in the Matrix channel already, but here is a summary
of the rebuild:
#################### SUMMARY ####################
total builds: 1810
reproducible: 989 (55%)
only src metadata: 76 (4%)
irreproducible: 745 (41%)
by rpm:
total rpms: 12259
src, non-src: 1810 (15%), 10449 (85%)
reproducible: 8879 (72%)
only src metadata: 279 (2%)
irreproducible: 3101 (25%)
rpms with irreproducibility:
src_metadata: 288
static_library: 529
jar_library: 718
mingw_binary: 92
debuginfo_metadata: 205
debuginfo_hash: 775
javadoc_html: 338
doc_pdf: 7
rpm_metadata: 24
payload_paths: 32
payload_mods: 1286
unknown: 13
If we ignore the bogus metadata on srpms, we're 59% reproducible by
package, and 75% reproducible counting individual rpms. The next order
of business is to handle those static libraries and jars, which should
make a sizeable dent in the remaining list. I started working on some
tooling for this on the weekend.
Zbyszek
--
_______________________________________________
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
