Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 664650 - dev-libs/wayland test failure due to long socket path
Summary: dev-libs/wayland test failure due to long socket path
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-08-26 13:56 UTC by Alexey
Modified: 2018-10-16 19:33 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments
test-suite.log (test-suite.log,17.53 KB, text/x-log)
2018-08-26 13:56 UTC, Alexey
Details
build.log (build.log,142.53 KB, text/x-log)
2018-08-26 13:57 UTC, Alexey
Details
emerge --info (file_664650.txt,19.18 KB, text/plain)
2018-08-26 13:58 UTC, Alexey
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey 2018-08-26 13:56:40 UTC
Created attachment 545114 [details]
test-suite.log

error: socket path "/mnt/portagetmp/portage/dev-libs/wayland-1.15.0/temp/xdr/wayland-tests-qj3dS0/wayland-test-31730-1535286591751424" plus null terminator exceeds 108 bytes
display-test: /mnt/portagetmp/portage/dev-libs/wayland-1.15.0/work/wayland-1.15.0/tests/test-compositor.c:334: display_create: Assertion `stat == 0 && "Failed adding socket"' failed.
test "zombie_fd_errant_consumption":    signal 6, fail.

and several more tests with the same error
Comment 1 Alexey 2018-08-26 13:57:35 UTC
Created attachment 545116 [details]
build.log
Comment 2 Alexey 2018-08-26 13:58:04 UTC
Created attachment 545118 [details]
emerge --info
Comment 3 Mart Raudsepp gentoo-dev 2018-08-26 14:24:10 UTC
Over a year ago I made it work for /var/tmp/portage, when the path is very close to too long (so with a -r1 it was too long and tests fails). That's why you see a hort "temp/xdr" in there.

But "/mnt/portagetmp/portage" is even longer than "/var/tmp/portage" (23 vs 16 chars), and we'd enter the territory of either forcing /tmp instead of PORTAGE_TMPDIR or having upstream use shorter paths in their part of the full path (then it'll still be a problem, just with even longer PORTAGE_TMPDIR).
Doing both of these was more effort and unsure of sandbox and other concerns. Maybe /tmp is possible, but there will be concerns of cleanup (PORTAGE_TMPDIR gets cleaned up by portage, not so with /tmp) and so on.
I suggest a shorter PORTAGE_TMPDIR (perhaps a symlink from a shorter path to your mount). Personally I use PORTAGE_TMPDIR=/tmp and don't hit this issue anymore thanks to the shorter xdr/ path.