On 1/7/26 11:33 PM, Tianon Gravi wrote:
I was thinking about you *just* yesterday, Rod - you must've somehow
heard the goodwill I was throwing your direction! 😂
Sorry for the late reply; this message got buried. See inline below....
On Wed, 3 Dec 2025 at 08:55, Helmut Grohne <[email protected]> wrote:
refind started to fail to build from source somewhere between three
weeks ago (reproducible builds has a successful log for that time) and
now. The failure now is:
https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/refind_0.14.2-2.1.rbuild.log.gz
| /usr/bin/ld -L./../libeg/ -L./../mok/ -L./../EfiLib/ -L./../gzip -T
/usr/lib/elf_x86_64_efi.lds -shared -Bsymbolic -nostdlib -L/usr/lib -L/usr/lib
/usr/lib/crt0-efi-x86_64.o -znocombreloc -zdefs apple.o config.o crc32.o
driver_support.o gpt.o icns.o install.o launch_efi.o launch_legacy.o lib.o
line_edit.o linux.o log.o main.o menu.o mystrings.o pointer.o scan.o screen.o \
| -o refind_x64.so -leg -lmok -lEfiLib -lgzip -lefi -lgnuefi
/usr/lib/gcc/x86_64-linux-gnu/15/libgcc.a
| /usr/bin/objcopy -j .text -j .sdata -j .data -j .dynamic -j .dynsym -j
.rodata \
| -j .rel -j .rela -j .rel.* -j .rela.* -j .rel* -j .rela* \
| -j .reloc --strip-unneeded --target=efi-app-x86_64 refind_x64.so
refind_x64.efi
| /usr/bin/objcopy: refind_x64.so: file format not recognized
https://sourceforge.net/p/refind/code/ci/cf542da4459ff18535b0ae3a7910af032834e469/
is awesome, thanks for your work!
I don't have a strong preference either way, but do you plan to do a
release soon, or would you rather I cherry-pick that into a patch and
backport it sooner to get it tested before you cycle through a
release?
I don't know when I'll get around to doing another full rEFInd release,
so it's probably best that you merge that one FTBFS bug fix now. I do
have a couple more changes already merged in the Sourceforge git
repository, and more that I want to do, but I've been busy with other
things lately.
PS. for what it's worth, Santiago narrowed it down even further than
2.45.50.20251209 to 2.45.50.20251125 👀
On Wed, 3 Dec 2025 at 09:35, Santiago Vila <[email protected]> wrote:
In case it helps, this is the output from debbisect:
bisection finished successfully
last good timestamp: 20251125T023458Z
first bad timestamp: 20251125T204144Z
the following packages differ between the last good and first bad timestamp:
binutils 2.45-8 -> 2.45.50.20251125-1
binutils-common:amd64 2.45-8 -> 2.45.50.20251125-1
binutils-x86-64-linux-gnu 2.45-8 -> 2.45.50.20251125-1
I'm sure the culprit is in
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=history;f=binutils/objcopy.c;h=ebd2a85c0f660793e91b6512c8f0adc9ea8eb9f2;hb=HEAD
somewhere, but I'm not finding it anything really obvious. 😅
--
Rod Smith
Senior Engineer
[email protected]
