search

sccn / liblsl

C++ lsl library for multi-modal time-synched data transmission over the local network
Other
107 stars 63 forks source link

Your deb package for ubuntu 18.04 from release v1.14.0 cannot be installed on ubuntu 18.04 #129

Closed tobiasherzke closed 3 years ago

tobiasherzke commented 3 years ago

Your deb package from release https://github.com/sccn/liblsl/releases/tag/v1.14.0 for ubuntu 18.04 depends on libgcc-s1 (>= 3.0). A libgcc-s1 package is not available in the ubuntu package sources for 18.04. This unresolvable dependency is probably introduced into your 18.04 deb package because the github actions runner for 18.04 (you use github actions to create this deb) has some non-standard packages installed, which find their way into the dependency list of debs that you create on this system.

I think you have investigated this problem before in issue #93 and found it (incorrectly) invalid: please note that you accidentally analyzed deb package liblsl-1.14.0-xenial_amd64.deb in your closing response. XENIAL is 16.04, not 18.04.

To enable our openMHA users to install liblsl for ubuntu 18.04, we provide our own build which does not have this problem here: https://github.com/HoerTech-gGmbH/liblsl/releases/tag/v1.14.0-htch.

Building an ubuntu 18.04 package on github actions with https://github.com/sccn/liblsl/blob/master/.github/workflows/cppcmake.yml still creates the same unresolvable dependency on libgcc-s1 for us, meaning Github has not fixed the problem in the last 6 months.

To support our users, we need to build liblsl deb packages for ARM CPUs (in addition to the architectures that you provide installers for) anyway. We do this in encapsulated docker containers, see https://github.com/HoerTech-gGmbH/liblsl/blob/main/.github/workflows/bionic.yml. I have extended this build file to not only build for ARM CPUs, but also build for 64-bit PC (x86_64) in an encapsulated container. Building in a docker container means that we control exactly which packages are installed on the build system.

This results in resolvable dependencies in the deb package for 18.04 (all CPU architectures): Our deb package depends on libgcc1 (>= 1:3.0), which can be resolved from standard ubuntu package repositories, not on libgcc-s1, which cannot be resolved. You can find the my Dockerfile defining the build environment here if you are interested: https://github.com/HoerTech-gGmbH/docker-buildenv/blob/master/liblsl_x86_64-linux-gcc-7/Dockerfile

Having said all of this, I'm not sure what to recommend. We do not need you to fix the issue because we have our own fix. I want to be helpful and tell you about the problem that we have detected, and how we fixed it, so that you may fix it yourselves. And I notice from your v1.14.1b* tags that you are probably close to your next, 1.14.1 release. I suggest that you test your deb package for ubuntu 18.04 for the next release on a real ubuntu 18.04 computer for a smoke test before releasing it, and not e.g. on a github actions runner. If the problem is still there in your next release, you may want to decide to discontinue your builds for 18.04 alltogether, or to build releases in a controlled docker container as we do, or find an even better solution. Your choice.

cboulay commented 3 years ago

@tobiasherzke , thank you for the thorough report. This is very helpful.

Even though we've been making 1.14.1b* tags, I don't know if we're actually going to release another 1.14 version, and we might jump ahead to 1.15. A major goal for 1.15 is to use more convenient distribution channels. I recently setup a labstreaminglayer homebrew tap and formulae for liblsl and LabRecorder for MacOS users (side note: turns out that homebrew has a linux version that I only became aware of when the test bot failed my formula).

For Ubuntu users, we intend to try to get liblsl on NeuroDebian, or at worst host our own ppa. I presume this entails setting up a separate build system, in which case our GH Actions integration will devolve to being nothing more than a CI & Test runner, but not used for distribution (at least in the Linux case).

I say this so you understand why we're unlikely to fix the current situation: our goal is to make it possible for users to do a sudo apt-get install lsl (assuming they have the repository installed) and I'd rather we spend time on that than on remembering how to use docker.

However, with your information, it might end up that the docker integration is straightforward. Mabye @tstenner (primarily Linux user) wants to try?

tobiasherzke commented 3 years ago

Release 1.15.0 fixes this. Thank you!