where are the sources for libvosk.so?

[Cyborgscode]

Hi,

i'm currently exploring the files, source, licenses of vosk to package it for Fedora Linux.

As the major license ASL2 is fine, i stumpled across the missing sourcecode of libvosk.so . As we can't ship binblops, we did not compile, i need the sources for it to build libvosk.so and to remove the dependency for your libatomic build, as Fedora has it's own libatomic.so build in a matching version.

[nshmyrev]

Sources are in src folder:

https://github.com/alphacep/vosk-api/tree/master/src

Build process better handled by Docker:

https://github.com/alphacep/vosk-api/blob/master/travis/Dockerfile.manylinux

[Cyborgscode]

I have some doubts, that Fedora will run a build process in a docker container, but we check it ;)

thank you.

[nshmyrev]

I have some doubts, that Fedora will run a build process in a docker container, but we check it ;)

You can run the same process without docker

[Cyborgscode]

I involved a more experienced maintainer into the process. We will check the situation and see, that we can build the lib without the included libatomic.

[Cyborgscode]

Just to go a bit ahead of the rebuild process, as i understand it, by giving a ASP 2 license on github, you have allowed contributing this app and the models to i.e. Linux distros like Fedora(where ASP2 is a valid license for a contribution). Any rejections to this? I just wane get sure, my first package job doesn't end in a desaster ;)

[nshmyrev]

you have allowed contributing this app and the models to i.e. Linux distros like Fedora(where ASP2 is a valid license for a contribution). Any rejections to this?

Yes, sure, it would be amazing to see Vosk packaged for Fedora! On the other side, it is not the easiest thing to package, you need to package Kaldi first I suppose which is not trivial. Relevant discussion is here:

https://bugzilla.redhat.com/show_bug.cgi?id=1577404

[Cyborgscode]

it's ago old. Question is, if we really need to build a Kaldi package, just to build libvosk.

I have my doubts, that we have results to report, before next year. There are so many aspects to clear, before I can even start to try ;) It would be so much easier, if we could use pypi as a source, but as it ships binblobs in form of libs, it's out of the question.

[Cyborgscode]

I tried to compile kaldi and it refers to PYTHON2.7 .. which had it's EOL early 2020.

As it looks, it is happily compiling with python 3.9.9 .. I suggest to autoadd the "you need to create an empty file" to your repo, to make life easier for others ;)

also, the systemwide installed libfst.so is ignored and unnecessarily build with kaldi.

[nshmyrev]

I tried to compile kaldi and it refers to PYTHON2.7 .. which had it's EOL early 2020.

We do not support 2.7, sorry

As it looks, it is happily compiling with python 3.9.9 .. I suggest to autoadd the "you need to create an empty file" to your repo, to make life easier for others ;)

Sorry, not sure about the purpose of empty file. Python 3.9 should work, yes.

also, the systemwide installed libfst.so is ignored and unnecessarily build with kaldi.

Yes, moreover, we demand our own fst branch

[Cyborgscode]

maybe that was missleading.. i'm excatly on your side, thats the reason I wrote it.

when the kaldi clone in your repo is build, the dependency check script says, that python27 is missing and that the user shall create an named empty file in the tree to pass the python27 checks. This could be avoided by adding that file to your kaldi repo straight ahead ;)

year, the fst issue has been resolved already.

[Cyborgscode]

your fst branch is newer and working. If you try to use the osversion at /usr/lib64/libfst.so this happens:

./configure --mathlib=OPENBLAS --shared --openblas-root=/usr --fst-root=/usr --fst-version=1.6.9 Configuring KALDI to use OPENBLAS. Backing up kaldi.mk to kaldi.mk.bak ... Checking compiler c++ ... Checking OpenFst library in /usr ... Checking cub library in /usr/src/kaldi/kaldi/tools/cub-1.8.0 ... Performing OS specific configuration ... On Linux: Checking for linear algebra header files ... Your math library seems to be OpenBLAS from /usr. Configuring appropriately. Configuring dynamically loaded OpenBlas since --static-math=no (the default) Successfully configured for Linux with OpenBLAS from /usr WARNING: CUDA will not be used! If you have already installed cuda drivers and CUDA toolkit, try using the --cudatk-dir= option. A GPU and CUDA are required to run neural net experiments in a realistic time. INFO: Configuring Kaldi not to link with Speex. Don't worry, it's only needed if you intend to use 'compress-uncompress-speex', which is very unlikely. In Datei, eingebunden von /usr/include/c++/11/ext/string_conversions.h:41, von /usr/include/c++/11/bits/basic_string.h:6607, von /usr/include/c++/11/string:55, von /usr/include/c++/11/bits/locale_classes.h:40, von /usr/include/c++/11/bits/ios_base.h:41, von /usr/include/c++/11/ios:42, von /usr/include/c++/11/ostream:38, von /usr/include/c++/11/iostream:39, von exp-test.cc:22: /usr/include/c++/11/cstdlib:75:15: schwerwiegender Fehler: stdlib.h: Datei oder Verzeichnis nicht gefunden 75 | #include_next | ^~~~~~ Kompilierung beendet. make: *** [: exp-test] Fehler 1 ./configure: Zeile 239: ./exp-test: Datei oder Verzeichnis nicht gefunden ...

whatever one is doing, the stdlib.h include fails, CXXFLAGS=-I/usr/include doesn't change this.

Also the configure script lags an architecture check, because: Line 1346: original: OPENFSTLIBS="$FSTROOT/lib/libfst.so" 64bitpatch: OPENFSTLIBS="$FSTROOT/lib64/libfst.so"

which means, the configure script checks at the 32bit location on a 64bit system with a 64bit openfst lib => fails .