I am working on an application which uses Vosk for speech recognition. I would like to create a dictionary for the application which contains only the trigger words and spoken numbers needed by the application. Using command line instructions found here: www.alphacephei.com/vosk/adaptation I was able to install Kaldi on my laptop. These are,
export KALDI_ROOT=`pwd`/kaldi
git clone https://github.com/kaldi-asr/kaldi
cd kaldi/tools
make
extras/install_opengrm.sh
However, I am having a problem building a dictionary using the provided commands. These are,
export PATH=$KALDI_ROOT/tools/openfst/bin:$PATH
export LD_LIBRARY_PATH=$KALDI_ROOT/tools/openfst/lib/fst
cd model
fstsymbols --save_osymbols=words.txt Gr.fst > /dev/null
farcompilestrings --fst_type=compact --symbols=words.txt --keep_symbols text.txt | \
ngramcount | ngrammake | \
fstconvert --fst_type=ngram > Gr.new.fst
mv Gr.new.fst Gr.fst
The problem occurs at "cd model" because there is no /model directory in the directory structure created during the Kaldi installation. Checking in my Vosk project, I find /models, but no /model directory either.
I have tried creating /model in /kaldi/tools and then running the above commands with no success. Please let me know what I am missing here. Thanks in advance.
The command cd model in the docs is actually incomplete. To run this you have to cd into the directory where Gr.fst exists. This file usually exists in the directory <any model with dynamic graph>/graph.
Head to https://alphacephei.com/vosk/models, download a model that supports dynamic vocabulary reconfiguration (usually small models do, big models don't).
Unzip the folder
Prepare a .txt file with words that your project relates to.
Proceed with the steps mentioned in your second code snippet (with a slight modification to the cd model part)
Related
I am trying to deploy a python Lambda package with watson_developer_cloud sdk. Cryptography is one of many dependencies this package have. I have build this package on Linux machine. My package includes .libffi-d78936b1.so.6.0.4 hidden file too. But it is still not accessible to my lambda function. I am still getting 'libffi-d78936b1.so.6.0.4: cannot open shared object file' Error.
I have built my packages on Vagrant server, using instructions from here: https://docs.aws.amazon.com/lambda/latest/dg/with-s3-example-deployment-pkg.html#with-s3-example-deployment-pkg-python
Exact error:
Unable to import module 'test_translation': libffi-d78936b1.so.6.0.4: cannot open shared object file: No such file or directory
On a note, as explained in this solution, I have already created my package using zip -r9 $DIR/lambda_function.zip . instead of *. But it is still not working for me.
Any direction is highly appreciable.
The libffi-d78936b1.so.6.0.4 is in a hidden folder named .libs_cffi_backend.
So to add this hidden folder in your lambda zip, you should do something like:
zip -r ../lambda_function.zip * .[^.]*
That will create a zip file in the directory above with the name lambda_function.zip, containing all files in the current directory (first *) and every thing starting with .* but not ..* ([^.])
In a situation like this, I would invest some time setting up a local SAM environment so you can:
1 - Debug your Lambda
2 - Check what is being packaged and the files hierarchy
https://docs.aws.amazon.com/lambda/latest/dg/test-sam-cli.html
Alternatively you can remove this import and instrument your lambda function to print some of the files and directories it "sees".
I strongly recommend you giving SAM a try though, since it will make not only this debugging way easier but any further test you need to perform down the road. Lambdas are tricky to debug.
A little late, and I would comment on Frank's answer but not enough reputation.
I was including the the hidden directory .libs_cffi_backend in my deployment package, but for some reason Lambda could not find the libffi-d78936b1.so.6.0.4 file located within.
After copying this file into the same 'root' level directory as my lambda handler it was able to load the dependency and execute.
Also, make sure all the files in the deployment package are readable chmod -R 644 .
I am a total newbie to programming and Ubuntu and Swift is my first language to learn.
I am learning with a book but I encountered a problem when I was supposed to build an application. Here is what I had to do:
Make a new directory called PMExample so that's easy mkdir PMExample
and then go to this directory cd PMExample.
Then I had to use ~/swift package init and got 2 directories called Sources and Tests and a file Package.swift.
So in the Sources folder there was one text file and I had to create another one to build an application.
And I did all those steps correctly, but now there is a problem. The book tells me to use swift build command. The book says that this will build the application and if all is well, I will have an executable application in the
PMExample/.build/debug directory named PMExample...
But after ~/swift build while being in the PMExample dir, there isn't any new directory called .build or anything. There are no errors popping up after using that ~/swift build command. Just nothing happens and I can't understand what am I doing wrong.
Thanks in advance.
But after ~/swift build while being in the PMExample dir, there isn't any new directory called .build or anything.
How do you know that? It is likely that you are not seeing the directory because it starts with a dot (it is called .build), therefore it is not shown by default with ls. You have to pass the -a argument to ls, such as in:
ls -a PMExample
I have been working on building customized kernel image using Yocto build system.Now I wanted to change a file /etc/limits/ before I start my build but when I try to find this file "limits",could not find any file name limits and come to know this file is generated after build.
I was expecting to find this file(before build) somewhere in meta directory just like file named "profile" is there in poky directory.
Now my question is how yocto build system generates this file /etc/limits file ,where can I find this file before build
I have checke both the Danny branch (Yocto 1.3) and Dylan branch (Yocto 1.4) and in both of those versions, the file /etc/limits is generated by the shadow package. So I'm not sure why you say that the file is generated after the build. In general, when I need to find out where a file comes from, I search the generated binary packages. In your case, after building core-image-base, I performed this quick search:
$ cd tmp/deploy/rpm
$ find . -name '*.rpm' | while read A; do $RPM -qpl $A | grep etc/limits; \
if [ $? -eq 0 ]; then echo $A; fi; done
/etc/limits
./armv7a_vfp_neon/shadow-4.1.4.3-r13.armv7a_vfp_neon.rpm
This tells me that the limits file comes from the shadow package. When bitbake executes the do_install() task for that package, the package's own Makefile installs that file from a template contained in the shadow package.
There are two easy ways to change the contents of this file on your file root file system. The correct way is to add a layer with your custom changes: create a bbappend for the shadow package, add your own limits file using SRC_URI = "file://limits", and add a do_install_append() method to install your customized file after the package's own install method. There are plenty of examples of using this technique in poky.
The other method is to use a post process command.
ROOTFS_POSTPROCESS_COMMAND += "use_my_limits_file; "
where use_my_limits_file is simply a bash shell function that installs your custom limits file. See poky's insserv.bbclass for an example of the structure for using ROOTFS_POSTPROCESS_COMMAND.
Hope this helps. Happy hacking!
I am little confused on how to create a complete binary package using rpmbuild from a project I just created (already compiled binary).
my current project contain similar format as this user (Packaging proprietary software for Linux)
Where I have
foo (binary)
data
libs
foo.sh
libs will contain all the shared libraries the project requires, and foo.sh is a script that sets LD_LIBRARY_PATH to include libs. Therefore, the user will execute foo.sh and the program should start.
I am looking at the tutorial from this site (rpm tutorial)
I understand to create a rpm I create a build area use rpmdev-setuptree
I can create a spec file use cd ~/rpmbuild/SPECS; rpmdev-newspec foo and if I got a good SOURCES folder I can build it with rpmbuild -ba foo.spec
But I have no idea how to setup the SOURCES directory. The tutorial stated (here) that I should create a tarball and place all my source file in it and put in SOURCE directory. What would be the source file in my case?
You are trying to create a RPM from binary files you have already? In that case, you can just leave the whole building stuff out of the SPEC file, and you need a SOURCE directory to keep the bundles you've got, the %prep step described below will take them from here.
In a binary package I built a while back from zip files, I did:
Heading, with name, version, description written by me/cribbed from the originals
Sources: The original places to download the Linux packages, official documentation, ...
%prep: Just unpack the different pieces, delete some redundant files, ...
%build: Nothing to do
%install: Create the relevant directories under $RPM_BUILD_ROOT by hand, copy files there by install, copy/create configuration files, ...
%clean: Blow away $RPM_BUILD_ROOT
%files: An exhaustive list of all files installed.
This required a few iterations to get right. Afterwards I followed the upstream package by rebuilding my RPM (conveniently I had everything packaged up in a SRPM, where the Source part was kind of a misnomer...)
I made a perl script that creates a deb binary package from scratch.
I created the data, control, etc.
But when I run dpkg -i on my deb package it complains that it is unable to files from data.
Example:
unable to create '.dpkg-new'(while processing ''): No such file or directory.
I have downloaded some .deb packages to look at and they do not use the preinst script to create the directory structure.
I am thinking I am doing something wrong, I consider having to create my own directories in preinst but it does not seem right... perhaps I am missing something?
Do I have to create directories where my files from data will be copied in the preinst sh, or should dpkg do it and I am doing something wrong?
I had the same problem in a Ruby script I wrote.
I was generating a list of files to pass to tar when building the data.tar.gz archive. When I ungzip and untared the archive manually it would deflate fine, but dpkg would fail.
It turns out that the list of files must also include each directory to create as well.
Note that when I created data.tar.gz I built it with nearly the same options as dpkg-deb/build.c does in the dpkg-1.15.8.11 source.
execlp(TAR, "tar", "-cf", "-", "--format=gnu", "--null", "-T", "-", "--no-recursion", NULL);
Instead I used
IO.popen("gnutar -czf - --format=gnu -T - --no-recursion", "r+")
In addition to what #Arrowmaster said, check the http://www.debian.org/doc/debian-policy/ for some detailed explanation of the files. After you build the package itself, you can check it with lintian tool to see if there is anything obvious you might have missed.
If any one looks for a solution to the problem:
"Build a deb package from an rpm spec file."
Look here http://www.deepnet.cx/debbuild/
I have made my own perl build script much simple then the mentioned one so I can easily maintain it.
Some useful knowledge gained in the process:
0. the deb is an ar archive that contains 3 files, the order of the files is important.
1. the scripts from control.tar.gz must be made executable.
2. it is good to have a preinstall script to make directories if dirs do not exist.
3. sometimes dpkg decides to unzip your zips (this happened if the zip was the only file in the data.tar.gz) so check for that in an postinstall script.
4. when you tar.gz some files be sure to chmod to the dir that contains the directory structure for your tar.
You should not attempt to manually create a .deb binary package by hand. The Debian New Maintainers' Guide covers how to get started creating a Debian package using the correct tools.
Your hand created package may look correct to you but because it is not installing it is obviously flawed in either a minor way that you have not noticed or in a more serious way that is not visible to you (for example most people don't realize a .deb is actually an ar archive).
There are lots of reasons for this. You really need to run:
dpkg -i -D1110 mydeb.deb
And post the result to have any hope of someone being able to solve the problem.