Summary: | dev-python/lmdb-1.6.2: fails tests | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sam James <sam> |
Component: | Current packages | Assignee: | Python Gentoo Team <python> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | mgorny |
Priority: | Normal | Keywords: | TESTFAILURE |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 948759 | ||
Attachments: | build.log |
Description
Sam James
![]() ![]() ![]() ![]() That's some kind of devbox container issue. They pass outside it — but they also pass in my local dev container. Perhaps we need to upgrade systemd on devbox. Let me investigate. I hit it locally too... (In reply to Sam James from comment #2) > Let me investigate. I hit it locally too... (in nspawn, not outside). Seccomp again? 0ve57o/data.mdb", 0x7ffd89285c10, 1023) = -1 EINVAL (Invalid argument) 559056:2509501 openat(AT_FDCWD, "/var/tmp/portage/dev-python/lmdb-1.6.2/temp/lmdb_testd10ve57o/data.mdb", O_WRONLY|O_DSYNC|O_CLOEXEC) = -1 EINVAL (Invalid argument) It's because of --suppress-sync in my nspawn container vs O_DSYNC. That's systemd issue, not lmdb upstream issue, correct? (In reply to Michał Górny from comment #5) > That's systemd issue, not lmdb upstream issue, correct? Correct. I'd prefer it if systemd pretended it succeeded / swallowed O_DSYNC, but I don't know if they'll be open to that. |