Bug 46747 - tests fail if builddir is near the length limit for an abstract Unix socket
Summary: tests fail if builddir is near the length limit for an abstract Unix socket
Status: RESOLVED FIXED
Alias: None
Product: dbus
Classification: Unclassified
Component: python (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Simon McVittie
QA Contact: John (J5) Palmieri
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-02-28 21:38 UTC by della5@iinet.com.au
Modified: 2012-03-02 00:11 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
a build & test log. (93.97 KB, text/plain)
2012-02-28 21:38 UTC, della5@iinet.com.au
Details

Description della5@iinet.com.au 2012-02-28 21:38:08 UTC
Created attachment 57792 [details]
a build & test log.

grief.  The name was too long

Running dbus-launch --sh-syntax --config-file=/mnt/gen2/TmpDir/portage/dev-python/dbus-python-1.0.0/work/dbus-python-1.0.0-2.7/test/tmp-session-bus.conf
Failed to start message bus: Abstract socket name too long


archtester dbus-python # grep socket /mnt/gen2/TmpDir/portage/dev-python/dbus-python-1.0.0/work/dbus-python-1.0.0-2.6/ChangeLog 
    	(_dbus_read_credentials_unix_socket):

I'd suggest reverting the change, if this is the same unix socket name.  It's not working.

archtester dbus-python # echo $DBUS_SESSION_BUS_ADDRESS
unix:abstract=/tmp/dbus-7mkARpdfAh,guid=bf4cd293f4a2a0e7a95ba971000000f2

Only it possesses not one but two elements in one setting.  So I wouldn't have a clue how to shorten its very long name, despite numerous attempts.
Comment 1 della5@iinet.com.au 2012-02-28 22:33:29 UTC
It seems this is a gentoo thing.  Another dev took a guess and got it right.
My PORTAGE_TMPDIR is "/mnt/gen2/tmpdir".  The name of the socket is appended to tmpdir.  
export PORTAGE_TMPDIR="/tmp" and it completed.

grief.  How to make a fix for that?
Comment 2 Simon McVittie 2012-02-29 05:37:50 UTC
(In reply to comment #0)
> archtester dbus-python # grep socket
> /mnt/gen2/TmpDir/portage/dev-python/dbus-python-1.0.0/work/dbus-python-1.0.0-2.6/ChangeLog 
>         (_dbus_read_credentials_unix_socket):
> 
> I'd suggest reverting the change, if this is the same unix socket name.  It's
> not working.

Anything that far back in the ChangeLog is a relic of the time when dbus and dbus-python were the same source tarball. The code that changed there no longer exists in dbus-python (it links libdbus to get it).

> archtester dbus-python # echo $DBUS_SESSION_BUS_ADDRESS
> unix:abstract=/tmp/dbus-7mkARpdfAh,guid=bf4cd293f4a2a0e7a95ba971000000f2
> 
> Only it possesses not one but two elements in one setting.  So I wouldn't have
> a clue how to shorten its very long name, despite numerous attempts.

This is not the problem. The abstract socket name here is /tmp/dbus-7mkARpdfAh, which is fine.

> Running dbus-launch --sh-syntax
> --config-file=/mnt/gen2/TmpDir/portage/dev-python/dbus-python-1.0.0/work/dbus-python-1.0.0-2.7/test/tmp-session-bus.conf
> Failed to start message bus: Abstract socket name too long

The regression tests name a socket based on the build directory, which in your case results in something like:

/mnt/gen2/TmpDir/portage/dev-python/dbus-python-1.0.0/work/dbus-python-1.0.0-2.7/test/dbus-7mkARpdfAh

which is indeed rather long. It's this line in test/tmp-session-bus.conf.in:

  <listen>unix:tmpdir=@abs_top_builddir@/test</listen>

Fixed in git to use /tmp instead.

To be honest I'm tempted to blame Portage, though: many things fail to compile for assorted reasons if they're in a particularly long path, and there's no reason why it couldn't be built in (for instance) ${PORTAGE_TMPDIR}/portage-dbus-python-1.0.0/work/2.7 (about half the length).
Comment 3 della5@iinet.com.au 2012-03-02 00:11:25 UTC
> 
> To be honest I'm tempted to blame Portage

Red rag to a bull for the gentoo devs, however, I did say it's a gentoo thing.

${PORTAGE_TMPDIR}/portage-dbus-python-1.0.0/work/2.7 is doable, after rewriting half of the portage.  I make my tmpdir on s separate partition, lengthenong an already long path.  This bug is comical really.  It's the first and only one I've seen from a long path name.  The error msg could be cleaned up. It's not the socket name which is too long, it's how "the regression tests name a socket"


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.