Re: A possible unintended difference in 13.1-RELEASE vs., for example, 13.1-RELEASE-p3
Date: Fri, 04 Nov 2022 21:49:50 UTC
On 2022-Nov-4, at 11:37, Paul Mather <paul@gromit.dlib.vt.edu> wrote: > On Nov 3, 2022, at 11:50 PM, Mark Millard <marklmi@yahoo.com> wrote: > >> I downloaded and looked at: >> >> FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img >> >> # mdconfig -u md0 -f FreeBSD-13.1-RELEASE-arm64-aarch64-RPI.img >> # mount -onoatime /dev/md0s2a /mnt >> # strings /mnt/boot/kern*/kernel | grep 13.1-RELEASE >> @(#)FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC >> FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC >> 13.1-RELEASE >> >> Note the: releng/13.1-n250148-fc952ac2212 >> >> Looking at the live system after the freebsd-update to >> -p3 : >> >> # strings /boot/kernel/kernel | grep 13.1-RELEASE >> @(#)FreeBSD 13.1-RELEASE-p3 GENERIC >> FreeBSD 13.1-RELEASE-p3 GENERIC >> 13.1-RELEASE-p3 >> >> No text analogous to: releng/13.1-n250148-fc952ac2212 > > > I'm just wondering, but could this have anything to reproducible builds? It's my understanding that setting is standard for -RELEASE branches. Note this entry in /usr/src/UPDATING: > > ===== > 20180913: > Reproducible build mode is now on by default, in preparation for > FreeBSD 12.0. This eliminates build metadata such as the user, > host, and time from the kernel (and uname), unless the working tree > corresponds to a modified checkout from a version control system. > The previous behavior can be obtained by setting the /etc/src.conf > knob WITHOUT_REPRODUCIBLE_BUILD. > ===== > Could be, but text like releng/13.1-n250148-fc952ac2212 is reproducible for use of the same commit to do mulitple builds. Use of different commits across builds should be detectable even for reproducible build style activity, or so I would expect. The releng/13.1-n250148-fc952ac2212 type of text does have an issue if incremental style builds are sometimes used instead of from-scratch builds: It is for/from the kernel build and if the kernel is not built but is left at an older build and, say, only part of world is built, the identification would then be out of date (inaccurate) overall. I was not really trying to claim that the releng/13.1-n250148-fc952ac2212 text I referenced was the best place to have the identification of the exact commit used for binary updates. It is just that right now there is no place and some manual inspection/analysis is required to (hopefully) identify the right commit. (The mismerge-fix being an example of something that would need to be noticed.) Glen, Warner, etc. may well determine that the current status relative to the build that produced the binary update is sufficient overall. I've primarily identified related questions for consideration. === Mark Millard marklmi at yahoo.com