The problem here kinda is the buildsystem, which uses an old kernel but a very new glibc: "4.4.0-161-generic #189-Ubuntu" and "2.30-0ubuntu1". bolt uses the "copy_file_range", which was introduced in 4.5. glibc had an emulation layer for it but that was removed with 2.30[1], and now the combination of a rather old kernel (4.4) and a very new glibc (2.30) will make "copy_file_range" return ENOSYS and thus will make bolt's "bolt_copy_bytes" function fail.
Not entirely sure how to handle it. Given that bolt's functionality itself is kinda depended on 4.13[2] it seems counter-productive to add fallback code that will *only* get executed in the test environment but never run in production (because eoan ships with linux 5.x) and the actual code that will run will indeed never get tested. Might as well skip the relevant tests. [1] https://sourceware.org/ml/libc-alpha/2019-08/msg00029.html [2] Thunderbolt security levels were only introduced in 4.13. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1843728 Title: bolt ftbfs in eoan (test failures) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/bolt/+bug/1843728/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs