Debianzing a Python program to get a .deb [duplicate] - python

This question already has answers here:
Is there a standard way to create Debian packages for distributing Python programs?
(5 answers)
Closed 5 years ago.
Aim
To create an installable .deb file (or package). Which when clicked would install the software on a Linux machine and an icon would be put on the GNOME panel. So as to launch this application from there.
What I have referred to
I referred to two debianizing guides.
Guide 1
Guide 2
The first one had a video which was impossible to understand, partly because of the accent and partly because it was hopelessly outdated.(it was uploaded in 2007)
And the second one was completely text. I got till the 4th Step, Builds the package. But when I did it I got output that did not match what was given in the guide.
What I require
I have a simple python program. It takes your age and then prints back out if the age is below, equal to, or above 18 years. There is just one file and no other dependency for this program. And I want to build this into a .deb.
Specs
-Python 2.7
-Linux Mint
Edit
I followed the exact directory structure as you instructed as you. And replaced all myscript with cowsandbulls. The build completed and I got the Debian. When I installed it and then ran the command cowsandbulls from the terminal I got the following error:
Traceback (most recent call last):
File "/usr/bin/cowsandbulls", line 9, in <module>
load_entry_point('cowsandbulls==1.0', 'gui_scripts', 'cowsandbulls')()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 337, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2311, in load_entry_point
return ep.load()
File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 2017, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
ImportError: No module named cowsandbulls

I just tested stdeb (see https://pypi.python.org/pypi/stdeb), a Python package for turning any other Python package into a Debian package.
First I installed stdeb:
apt-get install python-stdeb
Then I made a simple script called myscript.py with the following contents:
def main():
print "Hello world, says myscript!"
# wait for input from the user
raw_input()
if __name__ == '__main__':
main()
Importantly, your directory structure should be:
somewhere/myscript/
setup.py
myscript/
__init__.py
myscript.py
In the setup.py file, you do something like:
import os
from setuptools import setup
from nvpy import nvpy
setup(
name = "myscript",
version = "1.0",
author = "Charl P. Botha",
author_email = "cpbotha#vxlabs.com",
description = "Demo of packaging a Python script as DEB",
license = "BSD",
url = "https://github.com/cpbotha/nvpy",
packages=['myscript'],
entry_points = {
'console_scripts' : ['myscript = myscript.myscript:main']
},
data_files = [
('share/applications/', ['vxlabs-myscript.desktop'])
],
classifiers=[
"License :: OSI Approved :: BSD License",
],
)
The console_scripts directive is important, and it'll create an executable script called my_script, which will be available system-wide after you install the resultant DEB. If your script uses something like tkinter or wxpython and has a graphical user interface, you should use gui_scripts instead of console_scripts.
The data_files directive will install a suitable desktop file into /usr/share/applications, so that you can also start myscript from your desktop environment. vxlabs-myscript.desktop looks like this:
[Desktop Entry]
Version=1.0
Type=Application
Name=myscript
Comment=Minimal stdeb example
# myscript should wait for user input at the end, else the terminal
# window will disappear immediately.
Exec=myscript
Icon=/usr/share/icons/gnome/48x48/apps/file-manager.png
Categories=Utility;
# desktop should run this in a terminal application
Terminal=true
StartupNotify=true
StartupWMClass=myscript
To build the DEB, you do the following in the top-level myscript:
python setup.py --command-packages=stdeb.command bdist_deb
Which will create a .deb in the deb_dist directory.
After having installed the DEB I created like this, I could run myscript from the command-line, and I could also invoke it from my desktop environment.
Here's a GitHub repository with the example code above: https://github.com/cpbotha/stdeb-minimal-example

The right way of building a deb package is using dpkg-buildpackage, but sometimes it is a little bit complicated. Instead you can use dpkg -b <folder> and it will create your Debian package.
These are the basics for creating a Debian package with dpkg -b <folder> with any binary or with any kind of script that runs automatically without needing manual compilation (Python, Bash, Pearl, and Ruby):
Create the files and folders in order to recreate the following structure:
ProgramName-Version/
ProgramName-Version/DEBIAN
ProgramName-Version/DEBIAN/control
ProgramName-Version/usr/
ProgramName-Version/usr/bin/
ProgramName-Version/usr/bin/your_script
The scripts placed at /usr/bin/ are directly called from the terminal. Note that I didn't add an extension to the script.
Also, you can notice that the structure of the deb package will be the structure of the program once it's installed. So if you follow this logic if your program has a single file, you can directly place it under ProgramName-Version/usr/bin/your_script, but if you have multiple files, you should place them under ProgramName-Version/usr/share/ProgramName/all your files and place only one file under /usr/bin/ that will call your scripts from /usr/share/ProgramName/.
Change all the folder permission to root:
chown root:root -R /path/to/ProgramName-Version
Change the script's permissions:
chmod 0755 /path/to/the/script
Finally, you can run: dpkg -b /path/to/the/ProgramName-Version and your deb package will be created! (You can also add the post/pre inst scripts and everything you want; it works like a normal Debian package.)
Here is an example of the control file. You only need to copy-paste it in to an empty file called "control" and put it in the DEBIAN folder.
Package: ProgramName
Version: VERSION
Architecture: all
Maintainer: YOUR NAME <EMAIL>
Depends: python2.7, etc , etc,
Installed-Size: in_kb
Homepage: http://foo.com
Description: Here you can put a one line description. This is the short Description.
Here you put the long description, indented by 1 space.
If you want to build using dpkg -b <folder> you can use this program that will do everything with one command. If you regularly build packages, it is a pain to do all the stuff that I mentioned!
*The guide was taken from Basics of Debian Packages.

Related

failed to create executable with pyinstaller and cefpython on Linux (Invalid file descriptor to ICU data)

I have some simple cefpython code opening a url and am trying to create a stand alone executable with pyinstaller:
I copied files from https://github.com/cztomczak/cefpython/tree/master/examples/pyinstaller to a a directry named pyinstaller
I made following minor changes to pyinstaller.spec
+SECRET_CIPHER = ""
...
- ["../wxpython.py"],
+ ["../hello.py"],
...
- icon="../resources/wxpython.ico")
+ )
I can successfully compile my application on windows with python
On the same machine with python 3.5.4 64 bit and following virtualenv:
cefpython3==66.0
future==0.18.2
PyInstaller==3.2.1
pypiwin32==223
pywin32==228
I can also compile windows with python 3.6.4 64 and following virtualenv:
altgraph==0.17
cefpython3==66.0
future==0.18.2
macholib==1.14
pefile==2019.4.18
PyInstaller==3.3.1
pyinstaller-hooks-contrib==2020.9
pypiwin32==223
pywin32==228
pywin32-ctypes==0.2.0
On Linux compilation works as well, but the executable is not operational.
I get following output and error:
CEF Python 66.0
Chromium 66.0.3359.181
CEF 3.3359.1774.gd49d25f
Python 3.5.2 64bit
[1013/180954.001980:ERROR:icu_util.cc(133)] Invalid file descriptor to ICU data received.
Trace/breakpoint trap (core dumped)
version is python 3.5.2 64bit and the virtualenv is:
cefpython3==66.0
pkg-resources==0.0.0
PyInstaller==3.2.1
What could be the cause?
The code, that I try to compile is below:
import platform
import sys
from cefpython3 import cefpython as cef
def check_versions():
ver = cef.GetVersion()
print("CEF Python {ver}".format(ver=ver["version"]))
print("Chromium {ver}".format(ver=ver["chrome_version"]))
print("CEF {ver}".format(ver=ver["cef_version"]))
print("Python {ver} {arch}".format(
ver=platform.python_version(),
arch=platform.architecture()[0]))
assert cef.__version__ >= "57.0", "CEF Python v57.0+ required to run this"
def main(url="https://www.stackoverflow.com"):
sys.excepthook = cef.ExceptHook
check_versions()
settings = {}
switches = {}
browser_settings = {}
cef.Initialize(settings=settings, switches=switches)
cef.CreateBrowserSync(
url=url,
window_title="CEF_HELLO: ",
settings=browser_settings,
)
cef.MessageLoop()
cef.Shutdown()
if __name__ == "__main__":
main()
Addendum: 2020-10-14:
same error on linux with other versions:
so far I tried python 3.5 and 3.7
Is there anybody who successfully created an executable?
I could be, that this just an issue with the example project and its configuration?
As alternative, a solution could be found in PyInstaller bug 5400
Here the steps:
1- download the PyInstaller helper in CEFpython named hook-cefpython3.py from:
https://github.com/cztomczak/cefpython/tree/master/examples/pyinstaller and put in the root directory of your project
2- In that file, replace the line:
from PyInstaller.compat import is_win, is_darwin, is_linux, is_py2
with:
from PyInstaller.compat import is_win, is_darwin, is_linux
is_py2 = False
3- in your PyInstaller .spec file, add the '.' to the hookspath, e.g. hookspath=['.']. I think it is also possible to add it as PyInstaller command line option.
These steps should solve the problem, until CEFPython deliver a correct version of the hook file.
This is not really the answer I would like to accept, but it is at least one solution and contains information, that might lead to a better fix, a better answer.
After debugging with strace I found out, that the executable searches many files like for example icudtl.dat, v8_context_snapshot.bin, locales/* were searched in
'dist/cefapp/cefpython3but were copied todist/cefapp/`
An ugly work around is to do following after compilation
cd dist/cefapp/cefpython3
ln -s ../* .
and the executable works.
I'm sure there is also a nicer non-brute-force solution, but for the time being I wanted to answer in case others are stuck as well
Probably this can be fixed in the spec file but would we need one spec file for linux and one for windows then?
Perhaps there's also an option to tell the excutable to search for these files one level higer?
To solve this, you need to set this in your spec file:
hookspath=[r'YOUR_ENV_SITE_PACKAGES\cefpython3\examples\pyinstaller\']
And then rebuild, you will have things in the right place.
The following steps solved the issue for me on Windows 10, Python 3.9.5 32-bit, PyInstaller 4.3, and CEFPython 66.1:
Download the hook-cefpython3.py file from here and put it into your project root directory.
Run the pyinstaller command as usual but add the --additional-hooks-dir . command line option, so the command will look like this:
pyinstaller --additional-hooks-dir . <main-file.py>
As opposed to other answers here, this anser neither requires changes of hookspath directive in pyinstaller's spec file and, as of now, nor any changes to the downloaded hook-cefpython3.py file.

How to "hide" some .py files into .exe with cx_Freeze?

Env:
Windows 10
python 3.6.6
cx-Freeze 5.0.2
Git hub example
It contails .msi for installing
Example project structure:
/package_name
/some_packet
/__init.py
/module_name.py # for an example contains valiable in code "module_1"
/main.py
/setup.py
/some_module.py # for an example contains valiable "module_2"
/some_other_module.py # for an example contains valiable "module_3"
Example of setup.py(simplified)
import cx_Freeze
cx_Freeze.setup(
name="example",
options={
"build_exe": {
"packages": ["asyncio"],
"include_files": ["static\some_static_file.png"]
},
"bdist_msi": {
"upgrade_code": "{492de237-1853-4599-a707-c283d567699f}"
}
},
executables=[cx_Freeze.Executable("main.py")]
)
Current behavior
For creating .msi install file -> run command python setup.py bdist_msi. It will generate .msi files for installing application.
After installing this application: directory(where application is installed) will contain:
main.exe
lib\some_packet directory
lib\some_packet\module_name.pyc file
other files
There are following statements:
1) From root directory(where application is installed) i start search(via grep -Rna command under Ubuntu guest system, it's just more convenient for me) and valiable module_1 could be found in directories(in lib\some_packet\module_name.pyc) and module_2/module_3 couldn't be found. Details:
(v_decompile) any#any-pc:/mnt/hgfs/shar/example_installed$ grep -Rna "module_1"
lib/some_packet/module_name.pyc:2:B�!]�#dZdS)module_1N)r�rr�PG:\heroes\installer-with-cx_Freeze\sources_of_project\some_packet\module_name.py<module>s
(v_decompile) any#any-pc:/mnt/hgfs/shar/example_installed$ grep -Rna -a "module_2"
(v_decompile) any#any-pc:/mnt/hgfs/shar/example_installed$ grep -Rna -a "module_3"
2) File lib\some_packet\module_name.pyc could be easily converted to original file(without comments) by e.g. python-uncompyle6.
Details:
(v_decompile) any#any-pc:/mnt/hgfs/shar/example_installed$ uncompyle6 lib/some_packet/module_name.pyc
# uncompyle6 version 3.3.3
# Python bytecode 3.6 (3379)
# Decompiled from: Python 3.6.6 (default, Jul 20 2018, 15:39:05)
# [GCC 4.8.4]
# Embedded file name: G:\heroes\installer-with-cx_Freeze\sources_of_project\some_packet\module_name.py
# Compiled at: 2019-07-07 11:28:50
module_1 = 'module_1'
# okay decompiling lib/some_packet/module_name.pyc
3) (solved with this question) In both points: file contains source path G:\heroes\installer-with-cx_Freeze\sources_of_project\some_packet\module_name.py It confuses me a bit. Application was installed from .msi and (as I understand) should not know about source directories (regarding path) which was used for creating last one.
Questions:
Is there any way to recover some_module.py and some_other_module.py to original files from main.exe?(like it could be done with lib\some_packet\module_name.pyc)
How to "hide" some other files in application into main.exe or somehow avoid converting .pyc to original files.(maybe some properties in cx_Freeze?)
Note:
It should be done with cx_Freeze.
PS: I don't want to create single .exe. I try to find convenient way for specifying which files should be stored in main.exe like it was done with some_module.py and some_other_module.py
PSS: At this moment I see only I way: put all files on main.py level :) But it will look weird for big project.
Quoting How to obfuscate Python source code:
These two methods [using pyobfuscate and distributing bytecode] are really just a deterrent, not a secure way of hiding the code.
If you want something a bit more robust, you should take a look at Nuitka, which compiles Python code to C++, so you can compile that and just distribute the executable. It seems to be broadly compatible with different libraries and different versions of Python.
See also Python Code Obfuscation
This video might help.
It talks about cxfreeze and how you can use cxfreeze to make a excutable, and I know it works for 3.4+ because the video uses python 3.4, but really your method should be fine...
If I understand Your question correctly, this could be answer You want - Python cx_Freeze for two or more python files (modules)

Suggestion to do close source my python project

I am new in python and pyqt5. I wrote a simple project by python and pyqt5 and now i want to close source code to not seen my source code. I think by obfuscate i can do this so i have installed pyminifier.
sudo apt install python-setuptools
pip3 install pyminifier
In my project i have a few class. By this command i can obfuscate one class of my project:
pyminifier --obfuscate --gzip MainWindow.py
import zlib, base64
exec(zlib.decompress(base64.b64decode('eJytVU1v2zAMvftXaLnUGQJtl10G+NAmHbAObfPRIAWGwVBtylZrS64k56PYj59oO46dpNtlh8QW+UQ9PlI01yonS3HLhF.....
The above output is shown in my terminal after running pyminifier --obfuscate.
Does it commend must be run for each class and copy output code to other new file?
If i do, I think these class's that imported together properly do not known each other and finally application do not be run!!! I am right?
Edit
I obfuscate entrypoint of my project by this command:
pyminifier --obfuscate --gzip Main.py
import zlib, base64
exec(zlib.decompress(base64.b64decode('eJzLzC3ILypRKK4s5sqyBZJ6qRWZJVzuYGZiUXoZV1pRfq5CQGVgialeYEl4Zkp6akmxQiZEV6BjQUFOZnJiSWZ+HkShb2JmXnhmXkp+OUwNQgSomMvHFlmPhrsmV6UtigoNTa4sDR+gK1KTNTQ1uQAalDgb')))
# Created by pyminifier (https://github.com/liftoff/pyminifier)
and i copied this codes into other file.py and i run app but i got Error:
python new.py
Traceback (most recent call last):
File "new.py", line 2, in <module>
exec(zlib.decompress(base64.b64decode('eJzLzC3ILypRKK4s5sqyBZJ6qRWZJVzuYGZiUXoZV1pRfq5CQGVgialeYEl4Zkp6akmxQiZEV6BjQUFOZnJiSWZ+HkShb2JmXnhmXkp+OUwNQgSomMvHFlmPhrsmV6UtigoNTa4sDR+gK1KTNTQ1uQAalDgb')))
File "<string>", line 8
j(L.exec())
^
SyntaxError: invalid syntax
Are you running a Python 3 program with Python 2? The error message only makes sense if you are using Python 2, where exec was a keyword.
For obfuscating multiple files, see http://liftoff.github.io/pyminifier/pyminifier.html:
Pyminifier can now minify/obfuscate an arbitrary number of Python scripts in one go. For example, ./pyminifier.py -O *.py will minify and obfuscate all files in the current directory ending in .py. To prevent issues with using differentiated obfuscated identifiers across multiple files, pyminifier will keep track of what replaces what via a lookup table to ensure foo_module.whatever is gets the same replacement across all source files. Added in version 2.0

shebang not working for python script

I've been looking over many answers here on stackoverflow. I've tried absolutely everything. I have this at the top of my AddressConversion.py python script.
#!/usr/bin/env python
import argparse
The objective is to run this as a command utility, meaning I could type
AddressConversion [options][address]
As of now I would settle for being able to type
./AddressConversion [options][address]
I have done the chmod so the file is executable
I've ran dos2unix on the file to eliminate any random windows characters(which wouldn't seem possible because the file has only been used on Ubuntu.
I've checked the python install with which python with the results
/usr/bin/python
I've also checked which env and get a similar path
The script will work fine when I use the traditional python command. It also works fine when I type:
usr/bin/env python
It will open up the python interpreter.
These steps seem to be the solutions suggested anytime someone asks this question. I am getting this error:
./AddressConversion.py: line 1: import: command not found
./AddressConversion.py: line 3: syntax error near unexpected token `('
./AddressConversion.py: line 3: `def init_parser():'
which seems like it is trying to run it as a shell script or something.
Any suggestions?
created one file executeme.py
#!/usr/bin/env python
print("hello")
make it as executable (optional)
chmod a+x executeme.py
reanme the file
mv executeme.py executeme
Execute now
./executeme
OUTPUT
hello
Another option to create one setup.py file, for more you can read here
in entry_points a key name console_script in which you can give the name of executor and target module in format
'name=target'
from setuptools import setup, find_packages
setup(
name='executor',
packages=find_packages(),
install_requires=[,
],
entry_points = {
'console_scripts': [
'executeme=executeme:main',
],
},
)
then run the command
pip install -e /path/to/setup.py
Installing from local src in Development Mode, i.e. in such a way that
the project appears to be installed, but yet is still editable from
the src tree.
pipdoc
I had a similar issue and it ended being because of the CRLF at the end of lines. These were added when the script was created on a windows machine. To check if this is the case use the file command.
file script.py
It will give you an output like this. "Python script, ASCII text executable, with CRLF line terminators"
To remove the CRLF line terminators do the following.
dos2unix script.py

problem compiling libjingle

I downloaded and installed libjingle-0.5.2.zip, and according to the README also downloaded and installed swtoolkit.0.9.1.zip, scons-local-2.1.0.alpha.20101125.tar.gz, and expat-2.0.1.tar.gz, and got nrtp by cvs download. After overwriting my Makefile twice, attempting to follow the rather poorly-written README, I came up with the following Makefile that almost works:
# First, make sure the SCONS_DIR environment variable is set correctly.
SCONS_DIR ?= /usr/src/scons-local/scons-local-2.1.0.alpha.20101125/
#SCONS_DIR ?= /usr/src/scons-local/
export
default: build
# Second, run talk/third_party/expat-2.0.1/configure...
talk/third_party/expat-2.0.1/Makefile:
cd talk/third_party/expat-2.0.1 && ./configure
# ...and talk/third_party/srtp/configure.
talk/third_party/srtp/Makefile:
cd talk/third_party/srtp && ./configure
# Third, go to the talk/ directory and run $path_to_swtoolkit/hammer.sh. Run
# $path_to_swtoolkit/hammer.sh --help for information on how to build for
# different modes.
build: talk/third_party/expat-2.0.1/Makefile talk/third_party/srtp/Makefile
cd talk && ../../swtoolkit/hammer.sh
help:
../swtoolkit/hammer.sh --help
However, make gives me the following errors:
jcomeau#intrepid:/usr/src/libjingle-0.5.2$ make
cd talk && ../../swtoolkit/hammer.sh
*** Error loading site_init file './../../swtoolkit/site_scons/site_init.py':
AttributeError: 'Dir' object has no attribute 'endswith':
File "/usr/src/scons-local/scons-local-2.1.0.alpha.20101125/SCons/Script/Main.py", line 1338:
_exec_main(parser, values)
File "/usr/src/scons-local/scons-local-2.1.0.alpha.20101125/SCons/Script/Main.py", line 1302:
_main(parser)
File "/usr/src/scons-local/scons-local-2.1.0.alpha.20101125/SCons/Script/Main.py", line 929:
_load_site_scons_dir(d.path, options.site_dir)
File "/usr/src/scons-local/scons-local-2.1.0.alpha.20101125/SCons/Script/Main.py", line 719:
exec fp in site_m
File "./../../swtoolkit/site_scons/site_init.py", line 455:
SiteInitMain()
File "./../../swtoolkit/site_scons/site_init.py", line 451:
SCons.Node.FS.get_default_fs().SConstruct_dir, None)
File "/usr/src/scons-local/scons-local-2.1.0.alpha.20101125/SCons/Script/Main.py", line 677:
site_dir = os.path.join(topdir, site_dir_name)
File "/usr/lib/python2.6/posixpath.py", line 67:
elif path == '' or path.endswith('/'):
make: *** [build] Error 2
I'm guessing that something new (a 'Dir' object being where a POSIX path string is expected) in one of the packages is breaking the build process, but which one? There are just too many layers of cruft here for me to follow. For sure I could just keep trying older packages, particularly for swtoolkit and scons, but if anyone here has successfully compiled libjingle and could prod me in the right direction, I'd appreciate it.
I'm not familiar with the project, but think I have a fix to get you past that point. You need to cast those Dir instances using str() in swtoolkit/site_scons/site_init.py. That way they can safely be evaluated by path.endswith('/'). Odd that such an issue would exist for very long in the main part of the build infrastructure:
Line 330:
SCons.Script.Main._load_site_scons_dir(
str(SCons.Node.FS.get_default_fs().SConstruct_dir), site_dir)
Line 450:
SCons.Script.Main._load_site_scons_dir(
str(SCons.Node.FS.get_default_fs().SConstruct_dir), None)
I did following to build libjingle :
Building LibJingle for Linux
How to Build
Libjingle is built with swtoolkit ( http://code.google.com/p/swtoolkit/), which
is a set of extensions to the open-source SCons build tool ( http://www.scons.org).
First, install Python 2.4 or later from http://www.python.org/.
Please note that since swtoolkit only works with Python 2.x, you will
not be able to use Python 3.x.
Second, install the stand alone scons-local package 2.0.0 or later from
http://www.scons.org/download.php and set an environment variable,
SCONS_DIR, to point to the directory containing SCons, for example,
/src/libjingle/scons-local/scons-local-2.0.0.final.0/.
Third, install swtoolkit from http://code.google.com/p/swtoolkit/.
Finally, Libjingle depends on two open-source projects, expat and srtp.
Download expat from http://sourceforge.net/projects/expat/ to
talk/third_party/expat-2.0.1/. Follow the instructions at
http://sourceforge.net/projects/srtp/develop to download latest srtp to
talk/third_party/srtp. Note that srtp-1.4.4 does not work since it misses
the extensions used by Libjingle.
If you put expat or srtp in a different directory, you need to edit
talk/libjingle.scons correspondingly.
2.1 Build Libjingle under Linux or OS X
First, make sure the SCONS_DIR environment variable is set correctly.
Second, run talk/third_party/expat-2.0.1/configure and
talk/third_party/srtp/configure.
Third, go to the talk/ directory and run $path_to_swtoolkit/hammer.sh. Run
$path_to_swtoolkit/hammer.sh --help for information on how to build for
different modes.
Other than above given steps, See following as reference
Set SCONS_DIR Path
export SCONS_DIR=/home/esumit/libjingle/libjingle-0.5.2/talk/third_party/scons-local/scons-local-2.0.1
Install libasound2-dev Lib to compile libJingle, otherwise you will encounter errors.
sudo apt-get install libasound2-dev
Download SRTP using the following command. If it asks for a passowrd, just hit Enter.
cvs -z3 -d:pserver:anonymous#srtp.cvs.sourceforge.net:/cvsroot/srtp co -P srtp
Possible components in LibJingle Directory
libjingle-0.5.2/talk/third_party$ ls
expat-2.0.1 libudev scons-local srtp swtoolkit
Execute following command to build LibJingle
libjingle-0.5.2/talk$ ./third_party/swtoolkit/hammer.sh

Categories