ConnectionClosed when joining a room

[soywod]

I have a issue when I try to join a room, I get this error:

thock: /usr/lib/libtinfo.so.6: no version information available (required by thock)
thock: ConnectionClosed

Awesome project dude anyway!

[soywod]

I was able to join a local instance of your server, so it must come from Heroku! Maybe a port issue?

[rmehri01]

@soywod Hi, thanks for the report! For some reason I can create a room but not join it now either so it must be with Heroku. Also I'm not that familiar with Linux but do you think libtinfo.so.6 could be the problem?

[soywod]

I'm not so sure, since me and me friend tried from different OS, and I guess you are also on a different OS. It must come from Heroku. Did you tried to restart the server somehow? Maybe you reached a quota?

[rmehri01]

I did restart the server but I don't think it was due to the quota since the metrics looked fine at the time. I tried it with macOS and my friend on WSL Ubuntu so I thought that it was working fine. I'm assuming you're on Ubuntu so could you try installing that library and see if anything changes?

[soywod]

I did a link from v6 to v5 and it works! sudo link /lib/libtinfo.so.6 /lib/libtinfo.so.5. So I guess it's really a lib issue. The error message is not so clear tho, it does not reflect the real problem, maybe it could be improved? It could be good IMO to also add an entry in the README about that.

[rmehri01]

Awesome! Yeah I can definitely mention it in the README and I still don't really know why the server crashed because of it so I'll have to look into that.

[dedifferentiator]

Linux: 5.9.14-arch1-1
Stack: 2.5.1
GHC: 8.8.4

I run into the similar issue with v0.2.1.0 linux binary, it throws thock: /usr/lib/libtinfo.so.6: no version information available (required by thock) in stdout, but thock still works fine and making a libtinfo.so.5 link didn't change anything. Also thock binary built from source with stack install && upx -9 ~/.local/bin/thock doesn't have this issue.

Seems like it comes somewhere from the github CD, this might be a clue. Also looks like ubuntu-20.04 is updating across the github actions, so maybe this binary bug will self-repair itself soon?

Or we might build a binary somewhere else.

[rmehri01]

Hmm interesting, under the github action for the last release I see that it is ubuntu 20 though:

I'm not really sure how to fix it, is there a better alternative than just building it somewhere else? Maybe installing libtinfo.so on the CD, although I saw online people said that ubuntu 20 shipped with libtinfo.so.6?

[dedifferentiator]

We might try to update stack's resolver from lts-16.20 to lts-17.2, which uses ghc-8.10.3 as well as github's ubuntu-20 does. I'm not sure how it's going to help, but we might give it a try.

[dedifferentiator]

@rmehri01 Can we test it without creating an actual release somehow?

[rmehri01]

@dedifferentiator I haven't actually tried this but maybe something like https://github.com/nektos/act would work? Or maybe I could try making a pre-release and you could try it out?

[dedifferentiator]

Nope, act seems to be suitable for running simple tests, but it almost immediately becomes unusable when complexity of actions grows, considering github-dependent links on steps in jobs. Pre-release sounds like exactly what we need, let's try it!

[rmehri01]

Nope, act seems to be suitable for running simple tests, but it almost immediately becomes unusable when complexity of actions grows, considering github-dependent links on steps in jobs. Pre-release sounds like exactly what we need, let's try it!

Ah okay, I didn't know that. I'll setup a pre-release right now!

[dedifferentiator]

Thanks, I checked pre-release, but it still has the same error, after all that must a problem of distros :(

Let's compare binary built on my local machine 5.9.14-arch1-1 and released bin of thock-0.1.0.0 (it's not stripped).

1. $ readelf -d <binary> (dynamic-libs)

Arch:

Ubuntu:

Arch build links towards libncurses, whilst ubuntu links towards libtinfo

2. $ readelf -V <binary> (version section)

Arch:

Ubuntu:

Ubuntu has thes ncurses version in the section, but arch doesn't specify something about ncurses version at all.

3. In Arch libtinfo.so.6 is just symlinked libncurses, whilst in ubuntu it's libtinfo itself.
   $ ll /usr/lib/ | grep libtinfo
   

[rmehri01]

Thanks for the detailed report! That's a bit unfortunate, I am not that familiar with linux so I'm not quite sure what to do about it :(

I did some searching and maybe doing static linking instead of dynamic linking is an option? Or maybe building an arch version somewhere else?

[dedifferentiator]

Hey, sorry for delay! Yes, static build should have worked, but it seems like it doesn't :(

Static binary still throws the similar warning ./thock: /usr/lib/libtinfo.so.5: no version information available (required by ./thock) , so apparently the problem is in something else. Maybe ubuntu doesn't have certain library, or specific version of that library, I played with packages for a bit, but everything, including libtinfo5, is up to date and it still doesn't work properly.

We may try to build a binary in circleCI, using something like this orb (although it doesn't seem to support download of binary, but we may come up with how to download it ourselves) with any arch docker image, and see how it differs from the github build, but I've never worked with circleCI before, so I'm not quite sure how it really works. I guess I'll take a look in a week or so.

[rmehri01]

Hmm that is strange, I haven't used CircleCI either so I could check it out! Also, do you know if using something like nix would help? (again, I haven't used it before)

[dedifferentiator]

Thanks, that would be great!

It might help, or most likely it might not :) but what I know for sure is that it'll bring a lot of undesirable pain together with it (imo). I think there should be other ways to figure it out without nix. Eventually it shouldn't be a big problem for arch user, it's just having stack installed, maybe a couple of other libs, and thock is ready to be built from source.

Also as an alternative we might create a script which would discard all stderr, like thock 2> /dev/null, but I don't feel like it's a good solution, maybe it's worth to redirect it to log, like /tmp/thock-32893.log or something.