smuxi stfl hangs on start

Bug #1300299 reported by Chad Miller
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
smuxi (Ubuntu)
Confirmed
High
Unassigned
stfl (Ubuntu)
Confirmed
High
Unassigned

Bug Description

2014-03-31 11:50:17,458 [-628353088] INFO Smuxi.Frontend.Stfl.MainClass - Registering signal handlers
2014-03-31 11:50:17,489 [Main] DEBUG TRACE - [smuxi-frontend-stfl.exe] Frontend.Init(engine = 'zippy')
2014-03-31 11:50:17,491 [Main] INFO Smuxi.Frontend.Stfl.Frontend - Smuxi - STFL frontend 0.11.0.0 starting
2014-03-31 11:50:17,510 [Main] FATAL Smuxi.Frontend.Stfl.MainClass - System.DllNotFoundException: libstfl.so.0
  at (wrapper managed-to-native) Stfl.StflApi:stfl_create (intptr)
  at Stfl.StflApi.stfl_create (System.String text) [0x00000] in <filename unknown>:0
  at Stfl.Form..ctor (System.Reflection.Assembly assembly, System.String resourceName) [0x00000] in <filename unknown>:0
  at Smuxi.Frontend.Stfl.MainWindow..ctor () [0x00000] in <filename unknown>:0
  at Smuxi.Frontend.Stfl.Frontend.Init (System.String engine) [0x00000] in <filename unknown>:0
  at Smuxi.Frontend.Stfl.MainClass.Main (System.String[] args) [0x00000] in <filename unknown>:0

Can't find stfl library?

Strace says it did.

open("/usr/lib/smuxi/libstfl.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/smuxi/libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/smuxi/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/smuxi/libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libstfl.so.0", O_RDONLY|O_CLOEXEC) = 9
open("libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/tls/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/tls/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/tls", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=16384, ...}) = 0
open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/tls/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/tls/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/tls", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64-linux-gnu", {st_mode=S_IFDIR|0755, st_size=81920, ...}) = 0
open("/lib/tls/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/tls/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/lib/tls/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/tls", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/lib/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/lib/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/lib", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
open("/usr/lib/tls/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/tls/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/usr/lib/tls/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/tls", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No such file or directory)
open("/usr/lib/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
stat("/usr/lib", {st_mode=S_IFDIR|0755, st_size=28672, ...}) = 0
open("libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libstfl.so.0", O_RDONLY|O_CLOEXEC) = 9
open("libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/smuxi/libstfl.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/smuxi/libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/smuxi/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/smuxi/libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libstfl.so.0", O_RDONLY|O_CLOEXEC) = 9
open("libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/lib/x86_64-linux-gnu/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/x86_64-linux-gnu/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/lib/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("/usr/lib/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
open("libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib/libstfl.so.0", O_RDONLY|O_CLOEXEC) = 9
open("libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or directory)

$ dpkg -S /usr/lib/libstfl.so.0
libstfl0: /usr/lib/libstfl.so.0

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: smuxi-frontend-stfl 0.11~rc5-1
Uname: Linux 3.14.0-031400rc7-generic x86_64
ApportVersion: 2.13.3-0ubuntu1
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Mar 31 11:49:54 2014
EcryptfsInUse: Yes
PackageArchitecture: all
SourcePackage: smuxi
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Chad Miller (cmiller) wrote :
Revision history for this message
Mirco Bauer (meebey) wrote :

STFL is probably incorrectly linked, check the output of ldd

Revision history for this message
Chad Miller (cmiller) wrote : Re: [Bug 1300299] Re: smuxi stfl hangs on start
Download full text (8.5 KiB)

ldd against what? I know nothing of Mono or its dynamic linker.

$ ldd /usr/lib/smuxi/smuxi-frontend-stfl.exe
not a dynamic executable

$ file !$
file /usr/lib/smuxi/smuxi-frontend-stfl.exe
/usr/lib/smuxi/smuxi-frontend-stfl.exe: PE32 executable (console) Intel
80386 Mono/.Net assembly, for MS Windows

$ ldd /usr/lib/libstfl.so.0
linux-vdso.so.1 => (0x00007fffa5ff7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f1b4a5a6000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b4a1e0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1b4a9ef000)

On Mon, Mar 31, 2014 at 6:15 PM, Mirco Bauer <email address hidden> wrote:

> STFL is probably incorrectly linked, check the output of ldd
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1300299
>
> Title:
> smuxi stfl hangs on start
>
> Status in "smuxi" package in Ubuntu:
> New
>
> Bug description:
> 2014-03-31 11:50:17,458 [-628353088] INFO Smuxi.Frontend.Stfl.MainClass
> - Registering signal handlers
> 2014-03-31 11:50:17,489 [Main] DEBUG TRACE - [smuxi-frontend-stfl.exe]
> Frontend.Init(engine = 'zippy')
> 2014-03-31 11:50:17,491 [Main] INFO Smuxi.Frontend.Stfl.Frontend -
> Smuxi - STFL frontend 0.11.0.0 starting
> 2014-03-31 11:50:17,510 [Main] FATAL Smuxi.Frontend.Stfl.MainClass -
> System.DllNotFoundException: libstfl.so.0
> at (wrapper managed-to-native) Stfl.StflApi:stfl_create (intptr)
> at Stfl.StflApi.stfl_create (System.String text) [0x00000] in
> <filename unknown>:0
> at Stfl.Form..ctor (System.Reflection.Assembly assembly, System.String
> resourceName) [0x00000] in <filename unknown>:0
> at Smuxi.Frontend.Stfl.MainWindow..ctor () [0x00000] in <filename
> unknown>:0
> at Smuxi.Frontend.Stfl.Frontend.Init (System.String engine) [0x00000]
> in <filename unknown>:0
> at Smuxi.Frontend.Stfl.MainClass.Main (System.String[] args) [0x00000]
> in <filename unknown>:0
>
>
> Can't find stfl library?
>
> Strace says it did.
>
> open("/usr/lib/smuxi/libstfl.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
> such file or directory)
> open("/usr/lib/smuxi/libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> open("/usr/lib/smuxi/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> open("/usr/lib/smuxi/libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/usr/lib/libstfl.so.0", O_RDONLY|O_CLOEXEC) = 9
> open("libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/lib/x86_64-linux-gnu/tls/x86_64/libstfl.so.0.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No
> such file or directory)
> open("/lib/x86_64-linux-gnu/tls/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) =
> -1 ENOENT (No such file or direc...

Read more...

Revision history for this message
Mirco Bauer (meebey) wrote :
Download full text (9.4 KiB)

On Apr 1, 2014 3:01 PM, "Chad Miller" <email address hidden> wrote:
>
> ldd against what? I know nothing of Mono or its dynamic linker.

ldd of libstfl.so.0

>
>
> $ ldd /usr/lib/smuxi/smuxi-frontend-stfl.exe
> not a dynamic executable
>
> $ file !$
> file /usr/lib/smuxi/smuxi-frontend-stfl.exe
> /usr/lib/smuxi/smuxi-frontend-stfl.exe: PE32 executable (console) Intel
> 80386 Mono/.Net assembly, for MS Windows
>
> $ ldd /usr/lib/libstfl.so.0
> linux-vdso.so.1 => (0x00007fffa5ff7000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f1b4a5a6000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b4a1e0000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f1b4a9ef000)

And here is the issue, it doesn't link ncursesw but it needs its symbols.
Thus smuxi fails using stfl dynamically via dlopen (that is what Mono does)

>
>
>
> On Mon, Mar 31, 2014 at 6:15 PM, Mirco Bauer <email address hidden> wrote:
>
> > STFL is probably incorrectly linked, check the output of ldd
> >
> > --
> > You received this bug notification because you are subscribed to the bug
> > report.
> > https://bugs.launchpad.net/bugs/1300299
> >
> > Title:
> > smuxi stfl hangs on start
> >
> > Status in "smuxi" package in Ubuntu:
> > New
> >
> > Bug description:
> > 2014-03-31 11:50:17,458 [-628353088] INFO
 Smuxi.Frontend.Stfl.MainClass
> > - Registering signal handlers
> > 2014-03-31 11:50:17,489 [Main] DEBUG TRACE - [smuxi-frontend-stfl.exe]
> > Frontend.Init(engine = 'zippy')
> > 2014-03-31 11:50:17,491 [Main] INFO Smuxi.Frontend.Stfl.Frontend -
> > Smuxi - STFL frontend 0.11.0.0 starting
> > 2014-03-31 11:50:17,510 [Main] FATAL Smuxi.Frontend.Stfl.MainClass -
> > System.DllNotFoundException: libstfl.so.0
> > at (wrapper managed-to-native) Stfl.StflApi:stfl_create (intptr)
> > at Stfl.StflApi.stfl_create (System.String text) [0x00000] in
> > <filename unknown>:0
> > at Stfl.Form..ctor (System.Reflection.Assembly assembly,
System.String
> > resourceName) [0x00000] in <filename unknown>:0
> > at Smuxi.Frontend.Stfl.MainWindow..ctor () [0x00000] in <filename
> > unknown>:0
> > at Smuxi.Frontend.Stfl.Frontend.Init (System.String engine)
[0x00000]
> > in <filename unknown>:0
> > at Smuxi.Frontend.Stfl.MainClass.Main (System.String[] args)
[0x00000]
> > in <filename unknown>:0
> >
> >
> > Can't find stfl library?
> >
> > Strace says it did.
> >
> > open("/usr/lib/smuxi/libstfl.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No
> > such file or directory)
> > open("/usr/lib/smuxi/libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such
> > file or directory)
> > open("/usr/lib/smuxi/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> > (No such file or directory)
> > open("/usr/lib/smuxi/libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No
> > such file or directory)
> > open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
> > access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> > directory)
> > open("/usr/lib/libstfl.so.0", O_RDONLY|O_CLOEXEC) = 9
> > open("libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or
> > directory)
> > open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
> > access("/etc/ld.so.nohwca...

Read more...

Revision history for this message
Chad Miller (cmiller) wrote :
Download full text (17.8 KiB)

So, this bug report should be linked to that package too/instead? Hrm.

On Tue, Apr 1, 2014 at 2:32 PM, Mirco Bauer <email address hidden> wrote:

> On Apr 1, 2014 3:01 PM, "Chad Miller" <email address hidden> wrote:
> >
> > ldd against what? I know nothing of Mono or its dynamic linker.
>
> ldd of libstfl.so.0
>
> >
> >
> > $ ldd /usr/lib/smuxi/smuxi-frontend-stfl.exe
> > not a dynamic executable
> >
> > $ file !$
> > file /usr/lib/smuxi/smuxi-frontend-stfl.exe
> > /usr/lib/smuxi/smuxi-frontend-stfl.exe: PE32 executable (console) Intel
> > 80386 Mono/.Net assembly, for MS Windows
> >
> > $ ldd /usr/lib/libstfl.so.0
> > linux-vdso.so.1 => (0x00007fffa5ff7000)
> > libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> > (0x00007f1b4a5a6000)
> > libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1b4a1e0000)
> > /lib64/ld-linux-x86-64.so.2 (0x00007f1b4a9ef000)
>
> And here is the issue, it doesn't link ncursesw but it needs its symbols.
> Thus smuxi fails using stfl dynamically via dlopen (that is what Mono does)
>
> >
> >
> >
> > On Mon, Mar 31, 2014 at 6:15 PM, Mirco Bauer <email address hidden> wrote:
> >
> > > STFL is probably incorrectly linked, check the output of ldd
> > >
> > > --
> > > You received this bug notification because you are subscribed to the
> bug
> > > report.
> > > https://bugs.launchpad.net/bugs/1300299
> > >
> > > Title:
> > > smuxi stfl hangs on start
> > >
> > > Status in "smuxi" package in Ubuntu:
> > > New
> > >
> > > Bug description:
> > > 2014-03-31 11:50:17,458 [-628353088] INFO
> Smuxi.Frontend.Stfl.MainClass
> > > - Registering signal handlers
> > > 2014-03-31 11:50:17,489 [Main] DEBUG TRACE -
> [smuxi-frontend-stfl.exe]
> > > Frontend.Init(engine = 'zippy')
> > > 2014-03-31 11:50:17,491 [Main] INFO Smuxi.Frontend.Stfl.Frontend -
> > > Smuxi - STFL frontend 0.11.0.0 starting
> > > 2014-03-31 11:50:17,510 [Main] FATAL Smuxi.Frontend.Stfl.MainClass -
> > > System.DllNotFoundException: libstfl.so.0
> > > at (wrapper managed-to-native) Stfl.StflApi:stfl_create (intptr)
> > > at Stfl.StflApi.stfl_create (System.String text) [0x00000] in
> > > <filename unknown>:0
> > > at Stfl.Form..ctor (System.Reflection.Assembly assembly,
> System.String
> > > resourceName) [0x00000] in <filename unknown>:0
> > > at Smuxi.Frontend.Stfl.MainWindow..ctor () [0x00000] in <filename
> > > unknown>:0
> > > at Smuxi.Frontend.Stfl.Frontend.Init (System.String engine)
> [0x00000]
> > > in <filename unknown>:0
> > > at Smuxi.Frontend.Stfl.MainClass.Main (System.String[] args)
> [0x00000]
> > > in <filename unknown>:0
> > >
> > >
> > > Can't find stfl library?
> > >
> > > Strace says it did.
> > >
> > > open("/usr/lib/smuxi/libstfl.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No
> > > such file or directory)
> > > open("/usr/lib/smuxi/libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No
> such
> > > file or directory)
> > > open("/usr/lib/smuxi/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1
> ENOENT
> > > (No such file or directory)
> > > open("/usr/lib/smuxi/libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No
> > > such file or directory)
> > > open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
> > > ac...

Revision history for this message
Chad Miller (cmiller) wrote :

So, stfl needs to be linked against libncursesw5 .

Smuxi needs autopkgtests that fail if it can't run. http://anonscm.debian.org/gitweb/?p=autopkgtest/autopkgtest.git;a=blob_plain;f=doc/README.package-tests;hb=HEAD

Changed in stfl (Ubuntu):
assignee: nobody → Chad Miller (cmiller)
Changed in smuxi (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Changed in stfl (Ubuntu):
status: New → Confirmed
importance: Undecided → High
Revision history for this message
Mirco Bauer (meebey) wrote :

Good idea with autopkgtests, but I have never played with it yet. Are there official docs or examples?

Revision history for this message
Chad Miller (cmiller) wrote :
Download full text (8.4 KiB)

The DEP isn't finished, as far as I know, but Ubuntu's implementation is
well documented, and a lot of Ubuntu packages have good examples. That URL
I mentioned is a good start for docs.

If you can write a program that exits with nonzero when there's a problem
running the installed package and you can list the dependencies of your
program, that's 95% of autopkgtest. Try it with pkg "autopkgtest" .

On Tue, Apr 1, 2014 at 3:51 PM, Mirco Bauer <email address hidden> wrote:

> Good idea with autopkgtests, but I have never played with it yet. Are
> there official docs or examples?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1300299
>
> Title:
> smuxi stfl hangs on start
>
> Status in "smuxi" package in Ubuntu:
> Confirmed
> Status in "stfl" package in Ubuntu:
> Confirmed
>
> Bug description:
> 2014-03-31 11:50:17,458 [-628353088] INFO Smuxi.Frontend.Stfl.MainClass
> - Registering signal handlers
> 2014-03-31 11:50:17,489 [Main] DEBUG TRACE - [smuxi-frontend-stfl.exe]
> Frontend.Init(engine = 'zippy')
> 2014-03-31 11:50:17,491 [Main] INFO Smuxi.Frontend.Stfl.Frontend -
> Smuxi - STFL frontend 0.11.0.0 starting
> 2014-03-31 11:50:17,510 [Main] FATAL Smuxi.Frontend.Stfl.MainClass -
> System.DllNotFoundException: libstfl.so.0
> at (wrapper managed-to-native) Stfl.StflApi:stfl_create (intptr)
> at Stfl.StflApi.stfl_create (System.String text) [0x00000] in
> <filename unknown>:0
> at Stfl.Form..ctor (System.Reflection.Assembly assembly, System.String
> resourceName) [0x00000] in <filename unknown>:0
> at Smuxi.Frontend.Stfl.MainWindow..ctor () [0x00000] in <filename
> unknown>:0
> at Smuxi.Frontend.Stfl.Frontend.Init (System.String engine) [0x00000]
> in <filename unknown>:0
> at Smuxi.Frontend.Stfl.MainClass.Main (System.String[] args) [0x00000]
> in <filename unknown>:0
>
>
> Can't find stfl library?
>
> Strace says it did.
>
> open("/usr/lib/smuxi/libstfl.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No
> such file or directory)
> open("/usr/lib/smuxi/libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> open("/usr/lib/smuxi/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT
> (No such file or directory)
> open("/usr/lib/smuxi/libstfl.so.0.so.la", O_RDONLY) = -1 ENOENT (No
> such file or directory)
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/usr/lib/libstfl.so.0", O_RDONLY|O_CLOEXEC) = 9
> open("libstfl.so.0.la", O_RDONLY) = -1 ENOENT (No such file or
> directory)
> open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 9
> access("/etc/ld.so.nohwcap", F_OK) = -1 ENOENT (No such file or
> directory)
> open("/lib/x86_64-linux-gnu/tls/x86_64/libstfl.so.0.so",
> O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
> stat("/lib/x86_64-linux-gnu/tls/x86_64", 0x7fffe9c7e150) = -1 ENOENT (No
> such file or directory)
> open("/lib/x86_64-linux-gnu/tls/libstfl.so.0.so", O_RDONLY|O_CLOEXEC) =
> -1 ENOENT (No such file or directory)
> stat("/lib/x86_64-linux-gnu/tls", 0x7fffe9c7e150) = -1 EN...

Read more...

Revision history for this message
Chad Miller (cmiller) wrote :

This bug report is getting stale.

I'm not sure the pathway proposed above is right, either.

In src/Frontend-STFL/smuxi-frontend-stfl.exe.config, it looks like smuxi should be explicitly loading ncursesw.

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
    <configSections>
        <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net" />
    </configSections>
    <dllmap dll="stfl" target="libstfl.so.0" />
    <dllmap os="linux" dll="ncurses" target="libncursesw.so.5" />
    <dllmap os="openbsd" dll="ncurses" target="libncursesw.so.12.1" />

Revision history for this message
Chad Miller (cmiller) wrote :

I think a failure should do more than hang, too. No error message, continuing to run forever, is a separate problem that should be fixed at the same time. If smuxi can't depend on libraries, it had best at least crash in an informative way.

Changed in stfl (Ubuntu):
assignee: Chad Miller (cmiller) → nobody
Revision history for this message
Mirco Bauer (meebey) wrote :

Smuxi can't explicitly load libncursesw as it uses dlopen() via Mono, the library must be correctly linked for this to work, there is no way around.

Revision history for this message
Mirco Bauer (meebey) wrote :

On Debian STFL is correctly linked:

<pre>
ldd /usr/lib/libstfl.so.0
 linux-vdso.so.1 (0x00007fffa91da000)
 libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x00007f30ebb71000)
 libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f30eb947000)
 libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f30eb729000)
 libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f30eb380000)
 libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f30eb17c000)
 /lib64/ld-linux-x86-64.so.2 (0x00007f30ebfed000)
</pre>

ii libstfl0 0.22-1.2+b1 amd64 structured terminal forms language/library

Revision history for this message
Mirco Bauer (meebey) wrote :

But yes, I could try to detect a broken STFL, the issue that the console is not working the way it should be... should Smuxi try to fallback to writing to stdout? that could add other issues...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.