Package: src:delve Version: 1.26.1-1 Severity: serious Tags: ftbfs sid delve 1.26.1-1 fails to build from source in sid with golang-1.26 (1.26.3-2). The test TestDisassPosCmd fails because the disassembly output shows raw addresses instead of resolved symbol names.
The package built successfully on buildd with golang-1.26-go 1.26.2-1 (see https://buildd.debian.org/status/package.php?p=delve&suite=sid), but fails with golang-1.26-go 1.26.3-2 currently in sid. Reproduced with: sbuild -d sid delve_1.26.1-1.dsc Go version installed in chroot: Unpacking golang-1.26-go (1.26.3-2) ... Test failure: === RUN TestDisassPosCmd command_test.go:1468: "> main.main() /build/reproducible-path/delve-1.26.1/obj-x86_64-linux-gnu/src/github.com/go-delve/delve/_fixtures/testvariables2.go:439 (PC: 0x4b1fb9)\n\ttestvariables2.go:435\t0x4b1f84\t48c78424d02800001a000000\tmov qword ptr [rsp+0x28d0], 0x1a\n\ttestvariables2.go:435\t0x4b1f90\t48c78424d82800001a000000\tmov qword ptr [rsp+0x28d8], 0x1a\n\ttestvariables2.go:437\t0x4b1f9c\t48c784249024000001000000\tmov qword ptr [rsp+0x2490], 0x1\n\ttestvariables2.go:438\t0x4b1fa8\te8f321faff\t\t\tcall 0x4541a0\n\ttestvariables2.go:439\t0x4b1fad\t48c784248824000000000000\tmov qword ptr [rsp+0x2488], 0x0\n=>\ttestvariables2.go:439\t0x4b1fb9\teb00\t\t\t\tjmp 0x4b1fbb\n\ttestvariables2.go:439\t0x4b1fbb\t4883bc24882400000a\t\tcmp qword ptr [rsp+0x2488], 0xa\n\ttestvariables2.go:439\t0x4b1fc4\t7c05\t\t\t\tjl 0x4b1fcb\n\ttestvariables2.go:439\t0x4b1fc6\te9af000000\t\t\tjmp 0x4b207a\n\ttestvariables2.go:440\t0x4b1fcb\t440f11bc2428400000\t\tmovups xmmword ptr [rsp+0x4028], xmm15\n\ttestvariables2.go:440\t0x4b1fd4\t488d8c2428400000\t\tlea rcx, ptr [rsp+0x4028]\n" command_test.go:1470: output doesn't look like disassembly --- FAIL: TestDisassPosCmd (0.59s) The test expects the step-instruction output to contain either "call $runtime.Breakpoint" or "CALL runtime.Breakpoint(SB)", but the output shows "call 0x4541a0" (raw address). The disassembly code in delve has not changed between 1.26.1 and 1.26.3, so this appears to be caused by a change in Go 1.26.3 binary output. Found while running reverse-dependency rebuilds (ratt) for the golang-golang-x-arch 0.13.0 -> 0.27.0 transition.
