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

Reply via email to