The package fails to build on various architectures. See https://buildd.debian.org/status/package.php?p=bootterm&suite=sid. Able to reproduce the issue while building the package on pp64el and checked the build logs from pp64el (https://buildd.debian.org/status/fetch.php?pkg=bootterm&arch=ppc64el&ver=0.5-1&stamp=1744757613&raw=0). The error seems to be because of some library missiing. Checking more on this. make[2]: Entering directory '/build/reproducible-path/bootterm-0.5' cc -Wdate-time -D_FORTIFY_SOURCE=2 -g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/bootterm-0.5=. -fstack-protector-strong -Wformat -Werror=format-security '-DVERSION="0.5-1"' -o src/bt.o -c src/bt.c src/bt.c: In function ‘set_port’: src/bt.c:527:9: error: implicit declaration of function ‘tcgetattr’ [-Wimplicit-function-declaration] 527 | tcgetattr(fd, &tio); | ^~~~~~~~~ src/bt.c:552:21: error: implicit declaration of function ‘cfsetospeed’ [-Wimplicit-function-declaration] 552 | if (cfsetospeed(&tio, baud_flag) == -1) | ^~~~~~~~~~~ src/bt.c:554:21: error: implicit declaration of function ‘cfsetispeed’ [-Wimplicit-function-declaration] 554 | if (cfsetispeed(&tio, baud_flag) == -1) | ^~~~~~~~~~~ src/bt.c:561:16: error: implicit declaration of function ‘tcsetattr’ [-Wimplicit-function-declaration] 561 | return tcsetattr(fd, TCSANOW, &tio); | ^~~~~~~~~ src/bt.c: In function ‘get_baud_rate’: src/bt.c:572:15: error: implicit declaration of function ‘cfgetospeed’ [-Wimplicit-function-declaration] 572 | spd = cfgetospeed(&tio); | ^~~~~~~~~~~ src/bt.c: In function ‘forward’: src/bt.c:1934:33: error: implicit declaration of function ‘tcsendbreak’ [-Wimplicit-function-declaration] 1934 | tcsendbreak(fd, 0); | ^~~~~~~~~~~ make[2]: *** [Makefile:65: src/bt.o] Error 1
Thank you for your report. Confirmed, although to clarify, it's just ppc64el that's affected, and it's not a regression (it never worked). 32-bit powerpc is the only other Linux port that is affected, but it's an unofficial port, as are the Hurd ports. I had brought this up with upstream about a year ago. This is about non-standard custom baud rates and platform differences, on either the kernel side, glibc side, or both -- that part is unclear to me. In the time since, glibc 2.41 was released, which includes a news entry on <termios.h> gaining support for arbitrary baud rates, so perhaps the right cross-platform fix here is to change the code to rely on that, instead of using <termbits.h> directly. It needs a bit more research, and ideally to run this by upstream as well, as I don't have any way to test this particular functionality. Feel free to take this on, otherwise I may find some time in the next few months to look at it. Regards, Faidon
Thank you Faidon for the info. The issue is because the functions (which throws error) are defined in <termios.h> and seems like somehow it is not getting added in the source. Currently, this library is added based on the following condition: #if defined(__linux__) && !defined(NO_TCGETS2) #include <asm/termbits.h> #else #include <termios.h> #endif Removing the lib from condition and adding it explicitly gives the error like "|error: redefinition of 'struct termios'|" because the similar structure also been defined in <termbits.h>. I am trying to check if termbits is required by any of the archs, if not we can remove it, else we can rely on some code tweaks to fix this redifinition error
Hello Faidon, I've looked into it further and confirmed thatt he support for arbitrary baud rates via <termios.h> was introduced in *glibc 2.42*. However, most current Debian environments (including stable and testing) are still using glibc versions *< *2.42, so the new support is not yet available there. Given this, we’d still need to rely on the <termbits.h>. But once Debian moves to glibc 2.42, we can definitely consider simplifying the code by switching to the standard <termios.h> API conditionally.
Ah, you're right of course! It's 2.42, not 2.41. Thank you for the additional research & correction! stable is not relevant here, as any fix to this bug is going to be targeting unstable/testing. A missing architecture is not enough grounds for a stable update, especially in such a minor package. With regards to unstable, you're correct that 2.42 is not available there yet. It is in experimental, though, and given it's already a released version, I'd expect it to reach unstable soon. So I think it's meaningful to take that into account for any suggested fix here. Note, however, that I have not verified whether that glibc change makes a difference to this bug or not; this is just speculation on my end, based on a vague memory of the issue at hand, and a drive-by read of glibc's release notes. Regards, Faidon