Creating Ubuntu debian pakage


You can check any debian package to get an idea about what goes inside the package.

.deb file can be opened in Linux with Archive manager. Actually .deb is just a zip.

There are two important directories:


and usrin general can have other directories or may not have usr directory.

Screen Shot 2017-07-02 at 5.21.45 PM

myApplication inside /usr/local/bin contains all the executable and .so etc related to my application.

You can literally see into any .deb file and get to know what kind of content is inside each of the files in DEBIAN directory.

control file


Package: myApplication
Version: 1.1.0
Section: admin
Priority: optional
Installed-Size: 415000
Architecture: amd64
Maintainer: Company name <email id>
Description: Blah blah .. blah software..






#This installer installs myApplication

#give permission to startup script for IntelliSpace
chmod 755 /usr/local/bin/myApplication/

#create application entry for IntelliSpace

echo ”
#!/usr/bin/env xdg-open

[Desktop Entry]
Comment=blah blah blah
” > /usr/share/applications/myApplication.desktop

xdg-desktop-menu install –novendor /usr/share/applications/myApplication.desktop

#Creating desktop icons
for user in /home/*
cp /usr/share/applications/myApplication.desktop ${user}/Desktop/
chmod 777 ${user}//Desktop/myApplication.desktop

cd /usr/local/bin/myApplication
chmod -R 777 *




#remove myApplication startup
rm /usr/local/bin/myApplication/

#delete all configurations
#rm -rf ~/.local/share/calibs #wrong folder
#uninstall application entry
xdg-desktop-menu uninstall usr/share/applications/myApplication.desktop


the file names are descriptive I think. prerm this will be run when application will be removed so for cleaning. postinst will run at time of installation when all your files are copied and dependencies installed.

md5sums is created when package is created you do not have to worry for this.


Command to create package:


fakeroot dpkg-deb –build myApplication

where myApplication is the name of folder which has all the content.


You may need to install dpkg-deb


To test either double click and install the .deb file created in above step by Ubuntu Software center or use below command

sudo dpkg -i myApplication.deb



Problem with #define from other libraries

While building a qt project with libxdo xdo.h I faced some strange problems with qt enum names conflicting with X #define macros.

There is no standard way of including headers the one which works is the best. For Qt I think it is recommended to include qt headers first then your files and other library files. This worked for me. To begin with I started to do #undef before include for each terms which was getting really bad as there were many conflicts.



undefined reference to `xdo_new(char*)’

Inline with xdo.h I was including it in C++ project. libxdo is C project and it doesn’t have extern “C” declaration as other libraries have.


extern "C" {
#include <xdo.h>



My Coding Standard

Function declarations, function names, type declarations, and code samples appear in a different font, e.g., #include.
Commands and command variables appear in a different font, e.g., copy a:*.* b:.
Code Conventions in Nutshell

• In an existing file, follow the style and conventions already used in that file.
• Lines should not exceed 85 characters and shall not exceed 125 characters.
• All indents shall be two spaces. Tabs shall not be used
• The source code must compile with 0 warnings (and, of course, 0 errors)
• The warning level is set to Level 3 while using the Microsoft’s Visual C++ Compiler.
• Follow the Hungarian naming convention for naming variables and identifiers
• Minimize the scope of local variables. Declare them at the top of the smallest code block that contains their use
• In an equality test against a constant, place the constant on the left-side. This prevents accidental assignment where equality was desired. Example:

if (SUCCESS = foundError) {
• Non-empty conditional statements and loops must be enclosed in braces. The following statements adhere to this rule:

// a non-empty conditional
if (0 == bufSize)
bufSize = 1;
This is to guard against accidental exclusion of statements meant to be in the block.

• Encapsulate the inputs in a MACRO to protect from unsafe callers.
#define FOO_BAR( x ) (( x ) * BAR )

• Adopt one of the following two styles for placing opening brace for coding blocks.

if ( booleanVal )
func( 123 );


if ( booleanVal ) {
func ( 123 );
testFunc ();
• Follow OOP concepts as much as possible while designing a new project.


Try to minimize the scope of local variables. Declare them at the top of the smallest code block that contains their use. Doing so helps in identifying re-usable pieces of code that can possibly be split out into functions. It also minimizes use of stack with some compilers.

The scope of variables shall be controlled as follows:

 Avoid using global variables. Global variables limit the modularity of code. For example: A module that contains global variables cannot be made a dynamic module.
 Large structures should not be stack-based since stack size is limited. We are working on small device so it is good to check for this. For big struct try using malloc and make them dynamic and on reusable Heap memory.


Names chosen should be descriptive and concise. Create an obvious association between names and the application, the intended usage. Names should be chosen to facilitate readability of code.
a. Variable names shall adhere to the Hungarian Naming Convention philosophy.
b. Use camel case for naming in general (like “StrokeAdapter”).
c. Names should follow a mixed-case form, with the first character of each word or word-abbreviation capitalized. Underscores should not appear in variable names, use mixed case to separate words.
d. New solutions begin with CNX. or CNX_.
c. Projects have the solution name prefix and an identifying name like CNX.OMR.Logic.
d. Classes, global variables, properties and methods start with an uppercase character.
e. Just variables within methods start with a lowercase character.
f. Prefer descriptive names. No names, which are meaningless. The longer the lifetime of a variable, the longer and more descriptive the name should be.
g. Short names (from 1 character length) just where its usual like variables for loops (i, j, k) and coordinates (x and y).
h. Care should be taken to correctly denote(p or ptr should be used) pointers:
char *Buf; // wrong
char *pBuf; // right
char *bufPtr; // right
char pBuf[10]; // wrong
char Buf[10]; // right

File and Directory Names

File naming guidelines are as follows:
1. Select descriptive file names. For files declaring or defining classes, the filename should reflect the name of the class or classes it contains. A file should contain only one class. A small set of tightly related classes can be contained in one file.
2. Header files and source files, wherever paired, must have the exact same name, distinguished only by the file extension.

In general, a file that is to be shared (either as a header or part of a library) should be named in a way that identifies the package from which the file came.
1. Intending:
a. Intend the code, when a structure has a body like in if-, while-, foreach-clauses and in cases like classes, methods and so on.

2. Class structure:
a. Global variables and properties (first)
b. Constructor (second)
c. Methods (third)
d. Construct methods, so that you can nest them into each other. This way the readability can be improved and you immediately know what is happening instead of using a series of parameters. Something like: Transform.Rotate(…).Translate(…).Scale(…);
4. High Cohesion / loose coupling:
a. A high cohesion means the inner elements of the module belong strongly together.
b. Loose coupling means the module is independent from other modules. Use OOP techniques and design patterns to achieve loose coupling.
5. Documentation:
a. Use comments in code. The more complicated something is, the more description is needed. Don’t comment obvious things. Prefer keeping comments short.
b. Use short UML diagrams. At least a class diagram for the crucial or complicated classes (not for the whole project!) and a layer diagram if several layers are used.
6. XAML:
a. While writing XAML code consider readability.
b. Reduce the number of attributes,
c. use styles, templates and resources.
d. Prefer Self-closing tags.
e. No source code, no logic in XAML.
7. If a class suggests that it contains a series of items like a list or a group, provide a) an indexer like Group[0] and implement the IEnumerable interface, so that instances of this class can be used in foreach loops and so that LINQ functions can be applied.
8. Project architecture: Use multi-tier architecture where appropriate. Split the solution in several smaller project if possible like the below:

Coding Conventions

There are two ways to place opening brace for coding blocks. Both are acceptable. Use one of the style and stick to it. For existing file keep existing style intact.

Mehtod 1: The “Ansi” method: Place each brace on its own line, indented with the conditional statement.
if ( booleanFlag )
func( 3 );

Method 2: The “Kernighan and Ritchie” method: Place the opening brace on the line with the conditional statement and the closing brace indented with the body on its own line.
if ( booleanFlag ) {
func( 3 );

Blocks that extend over a significant number of lines should have a comment on the closing brace so that it is easier to figure out which block is being terminated.
Non-empty conditional statements and loops must be enclosed in braces. Example:

// a non-empty conditional
if (0 == counter)
counter = 1;


// a non-empty conditional (not suggested)
if (0 == counter)
counter = 1;

This is to guard against accidental exclusion of statements meant to be in the block and to make clearer to a reader the intended extent of the block.

Conditional expressions

When an equality test is made against a constant, place the constant on the left-side. This is done to prevent accidental assignment where equality was desired. Example:
if (SUCCESS = foundError) {

The above will give a compilation error, thereby catching the logic error.

When a conditional expression spans multiple lines, put the operators on the end of lines rather than the beginning. Example:

if ((MY_CONST == nMyVar) &&
( TRUE == func()) &&
( TRUE == testFunc())

Constants should be on the left-hand side of expressions, as shown in the example above.

Types in a conditional expression should match, e.g., Booleans should not be compared with non-Booleans.
Expressions without a comparison operator should only be used when the expression is Boolean, as in this example:

char *myStr;
boolean boolFlag;
if ( myStr ) /* bad! */

if ( NULL != myStr ) /* better */

if ( boolFlag ) /* allowed, as boolFlag is boolean */


Comment verbosely as though future readers have no clue as to what you are doing.
Use one of the following commenting styles:
• C++ style (//)
• C style (/* …. */)

Here are some rules to keep in mind when adding comments:
Comments shall never be wrong or out of date. Comments should be added with the sole intention to improve the readability and understanding of the code. Comments should be professional.
Multiline comments may have any of the following formats:

/* A big comment to show how multi line comment
* is to be done. */

/* We can also break a line and then put the closing
* mark of the comment. Use per your choice.
Line length
Lines should not exceed 85 characters and shall not exceed 125 characters.
All indents shall be two spaces. Tabs shall not be used. Different editors vary in their representation of the tabs. Tabs are discouraged to use anywhere in source files.
White space
Use white space to enhance readability, and use it consistently.
Spaces should appear after semicolons in a ‘for’ loop. Examples:

for (i = 0; i < 100; i++) {

do {
} while (TRUE != completed);

Spaces should appear after commas in function calls:

testFunc(arg1, arg2, arg3);
Spaces should appear around mathematical operators and assignments:

i = (i * 3) + 2;

/* Not readable so bad */

Use consistent style throughout a file.
Preprocessor directives
#ifdefs should be aligned with the block of code they are conditionally compiling out.

if ( booleanFlag)
//some processing

#ifdef WIN
//some more processing
#elif /* WIN */
//some other processing
#endif /* WIN */

Note that the ending #endif should have a closing comment, much the same as if it were a block of code.
Compilation Warnings
The source code must compile with 0 warnings (and, of course, 0 errors).
Files Format:
Header file format
Header files should contain the following fields and should be in the order listed below:
• Multiple Includes Protection
• Header file description
• Copyright / Author name.
• Include files
• Definitions and Constants
• Type Declarations
• Class definitions
• Public or External Function prototypes.
Note: Header files should contain all the information needed to use the code. A person using the code not necessarily have to look into source file.

Project/Module header file
We encourage to divide each of the project component in loosely coupled smaller module. This is good for maintenance and understanding. It is also helpful while reusing the code for separate purpose.
Each module/project should have an external header file. This external header file defines the external interface to the module and exports only the information required by other modules.
An external header file shall not include any internal header files or other unnecessary header files.
Header files should not include other header files without specific reason. If a header file is required by a .c file, it should be placed in the .c file and not in the .h file.

Source file format
C/C++ files should contain the following fields and should be in the order listed below:
• Multiple Includes Protection
• Source file description
• Copyright / Author name.
• Include files
• Definitions and Declarations for module
• Constant and Macros
• Global Variables
• Functions Declaration
• State init cleanup functions
• Rest of the source code

Saving Money (Lean startup)

Alternative of slack:

Today I met a friend of mine and he showed me this software hosted on his companies server. This is a great alternative for paid slack. We are using unpaid version of slack and some restriction like search limit no search functionality in archived history chat. Limitation on files shared are annoying. I don’t mean to say that I want all this free it is just that for us (trying not to pay for this) mattermost will be more suitable option.

Github on your own server

OrangePi Power button

on orangepi it works as below

orangepi@orangepi:/dev/input$ sudo cat event1
orangepi@orangepi:/sys/devices/virtual/input/input1$ cat uevent
KEY=100000 0 0 0

Disable driver signature enforcement in Windows

Not sure why it is not working now .. bcedit should disable it permanently

bcdedit /set testsigning on

Taking screenshot on just vanilla X11 system


scrot 1.png


Can’t open X display. It *is* running, yeah?

mine was

startx ./application — :0 vt8 &

So it was not coming

Then I started with simple

startx ./application
and scrot worked as a charm

I didn’t find a way to specify display and virtual terminal in scrot that is why it didn’t work out in the first try. I didn’t experiment a lot on this.



Another way is by using xwd command


xwd -root -display :0 > good_image.xwd

Then you need to convert xwd image to png or jpeg

OS in sdcard boots but file system is read-only

The problem occurs sometime when image get corrupted. I think only inode structure become incorrect.

If the reason is only this you can easily correct it via

After copying the image to sdcard you will need to correct the file checksum which somehow is failing and results in root partition mounted as read-only mode.
Use any linux machine and run below command
sudo fsck -y /dev/sdb2

where /dev/sdb2 is the linux partition