Robotics Service Bus

Interestingly, when downloading tools-trunk from ci-server (https://ci.cor-lab.de/job/rsb-tools-cl-trunk/label=ubuntu_precise_64bit/) it works.

As I said, the installed rsb-loggercl0.10 did not work yesterday. But when dowloading the cl-tools0.10 from the ci-server, it worked. Currently, I cannot test it, because in

/vol/toolkit/nightly/x86_64/successful/bin

0: ((LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX))
1: (SB-IMPL::CALL-WITH-SANE-IO-SYNTAX #<CLOSURE (LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX) {1007DCBE2B}>)
2: (SB-IMPL::%WITH-STANDARD-IO-SYNTAX #<CLOSURE (LAMBDA NIL :IN SB-DEBUG::FUNCALL-WITH-DEBUG-IO-SYNTAX) {1007DCBDFB}>)
3: (PRINT-BACKTRACE :STREAM #<SYNONYM-STREAM :SYMBOL SB-SYS:*STDERR* {10002147A3}> :START 0 :FROM :INTERRUPTED-FRAME :COUNT NIL :PRINT-THREAD T :PRINT-FRAME-SOURCE NIL :METHOD-FRAME-STYLE NIL)
4: (SB-DEBUG::DEBUGGER-DISABLED-HOOK #<SB-POSIX:SYSCALL-ERROR {1007DC88B3}> #<unavailable argument>)
5: (SB-DEBUG::RUN-HOOK *INVOKE-DEBUGGER-HOOK* #<SB-POSIX:SYSCALL-ERROR {1007DC88B3}>)
6: (INVOKE-DEBUGGER #<SB-POSIX:SYSCALL-ERROR {1007DC88B3}>)
7: (ERROR SB-POSIX:SYSCALL-ERROR :NAME SB-POSIX:SYMLINK :ERRNO 13)
8: (SB-POSIX:SYSCALL-ERROR SB-POSIX:SYMLINK)
9: (RSB.TOOLS.MAIN::%MAYBE-CREATE-LINK "rsb-toolscl0.10" "info" NIL NIL)
10: (RSB.TOOLS.MAIN::%MAYBE-CREATE-LINKS "rsb-toolscl0.10" NIL NIL)
11: ((FLET #:WITHOUT-INTERRUPTS-BODY-54 :IN SAVE-LISP-AND-DIE))
12: ((LABELS SB-IMPL::RESTART-LISP :IN SAVE-LISP-AND-DIE))

When, as a work-around, trying to use the creat-links option with an PREFIX like

/vol/toolkit/nightly/x86_64/successful/bin/rsb-toolscl0.10 create-links ~/Downloads/mylinkprefix-

WARNING:
   Failed to load Spread library: Unable to load any of the alternatives:
   ("libspread-without-signal-blocking.so" "libspread.so" "libspread.so.2" 
    "libspread.so.2.0" "libspread.so.1").
   Spread functionality will not be available.
Creating symbolic link /homes/cemmeric/Downloads/mylinkprefix-info ->
rsb-toolscl0.10
Creating symbolic link /homes/cemmeric/Downloads/mylinkprefix-logger ->
rsb-toolscl0.10
Creating symbolic link /homes/cemmeric/Downloads/mylinkprefix-call ->
rsb-toolscl0.10
Creating symbolic link /homes/cemmeric/Downloads/mylinkprefix-send ->
rsb-toolscl0.10

la ~/Downloads/
lrwxrwxrwx   1 cemmeric corstaff        15 Sep  6 15:03 mylinkprefix-call -> rsb-toolscl0.10
lrwxrwxrwx   1 cemmeric corstaff        15 Sep  6 15:03 mylinkprefix-info -> rsb-toolscl0.10
lrwxrwxrwx   1 cemmeric corstaff        15 Sep  6 15:03 mylinkprefix-logger -> rsb-toolscl0.10
lrwxrwxrwx   1 cemmeric corstaff        15 Sep  6 15:03 mylinkprefix-send -> rsb-toolscl0.10

However, I asked Sebastian to create the links (since he has the right permissions to do so) and now the result is:

/vol/toolkit/nightly/x86_64/successful/bin/logger spread://localhost:4803
WARNING:
   Failed to load Spread library: Unable to load any of the alternatives:
   ("libspread-without-signal-blocking.so" "libspread.so" "libspread.so.2" 
    "libspread.so.2.0" "libspread.so.1").
   Spread functionality will not be available.
Failed to participate in the channel designated by #<RSB:SCOPE / ! {1008A029B3}> using transport configuration
+ Spread transport with options
  :HOST           : "localhost", :PORT           : 4803, :EXPOSE         : (:RSB.TRANSPORT.WIRE-SCHEMA :RSB.TRANSPORT.PAYLOAD-SIZE), RSB:&INHERIT
Caused by:
> Failed to construct SPREAD connector for direction IN-PULL with options
>  HOST            : "localhost",
>  PORT            : 4803,
>  EXPOSE          : (:RSB.TRANSPORT.WIRE-SCHEMA :RSB.TRANSPORT.PAYLOAD-SIZE),
>  HOST            : "localhost",
>  PORT            : "4803".
> Caused by:
> > Attempt to call an undefined alien function.

Ok, I thought this was no longer an issue in the toolkit, but I know how to circumvent this:

LD_LIBRARY_PATH=/vol/toolkit/nightly/x86_64/successful/lib/ /vol/toolkit/nightly/x86_64/successful/bin/logger spread://localhost:4803

Long story short: I think there are still some issues with the deployment (that's why I listed them here for you), but the original error who caused me to create this redmine-issue seems to be fixed.

Thanks for the detailed report. And sorry for the trouble. That's the fate of testers, I'm afraid. Also, it doesn't help that we are still changing things rapidly at moment.

As I said, the installed rsb-loggercl0.10 did not work yesterday. But when dowloading the cl-tools0.10 from the ci-server, it worked. Currently, I cannot test it, because in
[...]
there aren't any links created yet for the tools. There is just the rsb-toolscl0.10 binary which proposes to create links, but of course the user has no permission to do so in the toolkit. (I assume that this is the reason that create-links is not working in the toolkit, although the error-message for me is not understandable:
[...]

Yes, that's a permission problem. And the whole deployment method has changed twice since your previous report :)

I believe that the link creation should be fixed after the next successful toolkit build (and deployment). I'm running a build now to see whether it works.

When, as a work-around, trying to use the creat-links option with an PREFIX like
[...]
this doesnt really work since the links are create only locally:
[...]
so they dont point to the toolkit.

Yeah … that's not what is meant by prefix in that context. It refers to the string-prefix meaning, not the directory-prefix meaning: the created links are of the form PREFIXTOOLNAMESUFFIX, are created in the current directory and also link to the current directory. Cross-directory linking is not supported.

I hope to change the mechanism to rsbcl0.10 logger OPTIONS, rsbcl0.10 send OPTIONS, … instead of rsb-loggercl0.10 OPTIONS, rsb-sendcl0.10 OPTIONS, … soon, like in git or svn. All the symlinking problems, which are a PITA for everyone, will be gone then.

However, I asked Sebastian to create the links (since he has the right permissions to do so) and now the result is:
[...]

Ok, I thought this was no longer an issue in the toolkit, but I know how to circumvent this:
[...]
and this finally worked.

You are right: use of LD_LIBRARY_PATH should no longer be necessary. This should be fixed after the next successful toolkit build and deployment.

Long story short: I think there are still some issues with the deployment (that's why I listed them here for you), but the original error who caused me to create this redmine-issue seems to be fixed.

Yes, the original issue should be fixed. Thanks again for the report.

@Christian: does the problem still persist?