This skips many one-time steps (like setting up launchpad access), error scenarios or even changed dependencies, but helps in trivial cases. For those more complex scenarios, check official docs.

1. Go to some empty work directory
   

   cd <some dir>

2. Fetch previous version from repository. You will get some files and a directory “packagename-vesion”, called later <old-version-dir>
   

   sudo apt-get source <package-name>

3. Same place, download the new tarball.
   

   wget <url to new source>

4. Enter the old package directory
   

   cd <old-version-dir>

5. Use uupdate to prepare new version’s directory. You may need to specify the new version explicitly
   

   uupdate -v <new-version (just the upstream number)> ../<upstream-tarball>

6. Go there
   

   cd ../<new-version-dir>

7. Update the changelog. The version should be something like <package-name>-<upstream-version>-0ubuntu0ppa0 (increase last 0 for minor ppa upgrades). Remember to set target distro correctly
   

   dch -i

8. Check it builds fine
   

   debuild

9. Build source package
   

   debuild -S

10. Upload it to launchpad
    

    dput ppa:<username>/<ppaname> <long-new-version>.changes

11. You should get an email that the package was accepted. After a while check the build status to make sure there were no problems.

Good luck!

$ sudo lsinput

/dev/input/event5
 bustype : BUS_USB
 vendor : 0x46e
 product : 0x52cb
 version : 272
 name : "BTC USB Multimedia Keyboard"
 phys : "usb-0000:00:06.1-4.3/input1"
 uniq : ""
 bits ev : EV_SYN EV_KEY EV_MSC

/dev/input/event6
 bustype : BUS_USB
 vendor : 0x458
 product : 0x5e
 version : 272
 name : "KYE ADNS6000 Optical Mouse"
 phys : "usb-0000:00:06.1-4.4/input0"
 uniq : ""
 bits ev : EV_SYN EV_KEY EV_REL EV_MSC

Use the name to find system path of the device:

$ udevadm info -q path -n /dev/input/event5
/devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5

Make a test run:

$ udevadm test /devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5
(...)
udev_device_update_db: unable to create temporary db file '/run/udev/data/c13:69.tmp': Permission denied
ACTION=add
DEVLINKS=/dev/input/by-id/usb-BTC_USB_Multimedia_Keyboard-event-if01 /dev/input/by-path/pci-0000:00:06.1-usb-0:4.3:1.1-event
DEVNAME=/dev/input/event5
DEVPATH=/devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5
ID_BUS=usb
ID_INPUT=1
ID_INPUT_KEY=1
ID_MODEL=USB_Multimedia_Keyboard
ID_MODEL_ENC=USB\x20Multimedia\x20Keyboard
ID_MODEL_ID=52cb
ID_PATH=pci-0000:00:06.1-usb-0:4.3:1.1
ID_PATH_TAG=pci-0000_00_06_1-usb-0_4_3_1_1
ID_REVISION=0110
ID_SERIAL=BTC_USB_Multimedia_Keyboard
ID_TYPE=hid
ID_USB_DRIVER=usbhid
ID_USB_INTERFACES=:030101:030000:
ID_USB_INTERFACE_NUM=01
ID_VENDOR=BTC
ID_VENDOR_ENC=BTC
ID_VENDOR_ID=046e
MAJOR=13
MINOR=69
SUBSYSTEM=input
UDEV_LOG=6
USEC_INITIALIZED=4552168
XKBLAYOUT=us
XKBMODEL=pc105
XKBOPTIONS=
XKBVARIANT=

Look data that is specific to device you want to customize. ID_TYPE=hid is too general, but perhaps ID_VENDOR_ID or ID_MODEL_ID. Sometime there is some tip about device type like ID_INPUT_TOUCHPAD=1. If the data seems too general, it may be better to attach to parent device, run the command again without the last “event” part:

$ udevadm test /devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5

Still, try to find something as close to the end of the chain as possible. Another way worth of trying is to run udevadm info:

$ udevadm info -a -p
/devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5

Finding the right filter rules seems to be always most difficult for me… Create a new file in /etc/udev/rules.d starting with 2-digit number (this is rule’s priority, I suggest a large one to keep the rule close to the end of the chain). My rules for detecting a Apple Bluetooth keyboard and  a touchpad are:

ACTION!="add|change", GOTO="apple_kbd_end"
SUBSYSTEM!="input", GOTO="apple_kbd_end"
KERNEL!="event[0-9]*", GOTO="apple_kbd_end"

ATTRS{address}=="60:fb:42:02:12:a9", RUN+="keymap $name apple"
ENV{ID_INPUT_TOUCHPAD}=="1", RUN+="/home/test/bin/send-command hostname slowgestures"

<span style="font-family: 'Courier 10 Pitch', Courier, monospace; font-size: 13px; font-style: normal; line-height: 1.5;">LABEL="apple_kbd_end"</span>

So I’m using Bluetooth address for keyboard and ID_INPUT_TOUCHPAD for the touchpad. When it is added to system, a script “send-command” will be run. After editing the file, save it and run the udevadm test again:

$ udevadm test /devices/pci0000:00/0000:00:06.1/usb2/2-4/2-4.3/2-4.3:1.1/input/input5/event5

USEC_INITIALIZED=150940194993
run: '/home/test/bin/send-command hostname slowgestures'

Check the run command is there. If not, change the rules and try again. If it worked, run one last command to inform the udev daemon about the changes:

sudo udevadm control --reload-rules

That’s it. Now it’s up to you to write the event handlers.

In the examples I will use a simple program calculating Fibonacci numbers

#!/usr/bin/python

import time

def fib(n):
    if n < 0:
        raise ValueError
    if n < 2:
        return n
    return fib(n-1)+fib(n-2)

def fibonacci(n):
    start = time.time()
    res = fib(n)
    end = time.time()
    return res

def main():
    start = time.time()
    for i in range(30, 37):
        res = fibonacci(i)
        print "fib(%3d) = %7d (took %0.3fs)" % ( n, res, (end-start))
    end = time.time() 
    print "Total time: %0.3fs" % (end - start) 

if __name__ == "__main__": main()

main is the main function controlling the program. fib is doing the actual work. fibonacci is a wrapper we will change later to use multiprocessing withouth changing fib. Adjust the numbers in range(30, 37) to match speed of your computer, so the program takes about 10-20 seconds to run. Output should be like this:

fib( 30) = 832040 (took 0.406s)
fib( 31) = 1346269 (took 0.663s)
fib( 32) = 2178309 (took 1.069s)
fib( 33) = 3524578 (took 1.728s)
fib( 34) = 5702887 (took 2.798s)
fib( 35) = 9227465 (took 4.565s)
fib( 36) = 14930352 (took 7.373s)
Total time: 18.603s

We need a way to make it possible to run the program starting fibonacci only once. I will use Queue to prepare the data for it. Add:

import multiprocessing

and change the main and fibonacci functions to look like this:

def fibonacci(in_queue):
    while True:
        n = in_queue.get()
        if n == None: 
            break

        start = time.time()
        res = fib(n)
        end = time.time()
    return res

def main():
    start = time.time()
    in_queue = multiprocessing.Queue()

    for i in range(30, 37):
        in_queue.put(i)
    in_queue.put(None)

    res = fibonacci(in_queue)
    print "fib(%3d) = %7d     (took %0.3fs)" % ( n, res, (end-start))

    end = time.time()
    print "Total time: %0.3fs" % (end - start)

What changed? The fibonacci is now a loop, taking values from queue and processing them one after another. This ends when it receives Null as value (“poison pill” – line 4-5). The data is inserted into the queue in the main function together with the poison pill (lines 16-18).

But wait! Now there is no way to send a reply from fibonacci! So let’s create another queue to receive the results. main and fibonacci change again:

def fibonacci(in_queue, out_queue):
    while True:
        n = in_queue.get()
        if n == None: 
            break

        start = time.time()
        res = fib(n)
        end = time.time()
        out_queue.put((n, res, end-start))

def main():
    start = time.time()
    in_queue = multiprocessing.Queue()
    out_queue = multiprocessing.Queue()

    for i in range(30, 37):
        in_queue.put(i)
    in_queue.put(None)

    fibonacci(in_queue, out_queue)

    while not out_queue.empty():
        n, res, spend_time = out_queue.get()
        print "fib(%3d) = %7d     (took %0.3fs)" % ( n, res, spend_time)
    end = time.time()
    print "Total time: %0.3fs" % (end - start)

What’s going on: main puts requests into the first queue (17-19), calls fibonacci (21), and prints results taken from second queue (23-25). fibonacci gets data from first queue (3) until it encounters Null (4-5), and puts results into second queue (10). Now, as the fibonacci is separated from main using the queues we can put it into separate process.
Change the line that calls fibonacci to:

multiprocessing.Process(target=fibonacci, 
                        args=(in_queue, out_queue)).start()

Now the fibonacci starts after the first queue is full, but the program won’t wait for it to finish, it immediately goes to displaying the results. But it doesn’t work. Why?

Well, fibonacci wasn’t fast enough to compute any result, so the while loop (in line 23) started when results queue was still empty and quit too early. We can use second poison pill sent from fibonacci to solve this.

Another thing to keep in mind is that the main program waits for the worker to end. Luckily fibonacci ends (thank to the poison pill), but nobody is waiting any more for the results, so they don’t show up. This will be also solved with the poison pill. At the end of fibonacci add:

out_queue.put((None, None, None))

and change the loop in main to:

while True:
        n, res, spend_time = out_queue.get()
        if n == None:
            break
        print "fib(%3d) = %7d     (took %0.3fs)" % ( n, res, spend_time)

It works again! Now that is needed to have several processes work in parallel is to start them. Remember to add the necessary poison pills! Complete final version looks like this:

#!/usr/bin/python

import time
import multiprocessing

def fib(n):
    if n < 0:
        raise ValueError
    if n < 2:
        return n
    return fib(n-1)+fib(n-2)

def fibonacci(in_queue, out_queue):
    while True:
        n = in_queue.get()
        if n == None: 
            break
        start = time.time()
        res = fib(n)
        end = time.time()
        out_queue.put((n, res, end-start))
    out_queue.put((None, None, None))

def main():
    start = time.time()
    in_queue = multiprocessing.Queue()
    out_queue = multiprocessing.Queue()

    process_num = multiprocessing.cpu_count()
    for _ in range(process_num):
        multiprocessing.Process(target=fibonacci, 
                                args=(in_queue, out_queue)).start()

    for i in range(30, 37):
        in_queue.put(i)
    for _ in range(process_num):
        in_queue.put(None)

    while True:
        n, res, spend_time = out_queue.get()
        if n == None: 
            process_num -= 1
            if process_num == 0: break
        else:
            print "fib(%3d) = %7d   (took %0.3fs)" % ( n, res, spend_time)

    end = time.time()
    print "Total time: %0.3fs" % (end - start)

if __name__ == "__main__":
    main()

Line 22 adds the poison pill to notify main that a fibonacci process has ended. Lines 30-32 start as many processes as we have cpus (determined in line 29). Lines 36-37 add poison pills for all fibonacci processes. Lines 41-43 keep track of how many processes are still running.

Remember, this is not the only solution. For example the results loop could simply count how many results it received. The optimal processes number depends on problem. If it’s just calculating data (like here) then CPU count is good bet. If there is substantial time spend on waiting for network operations, then more may be better. But if the slowdown is caused by some slow resource (like slow disk), then more processes can actually slow down performance. Usually it’s easiest to just try it out.

One more tip: when using multiple processes it is important to remember that one of them could raise exception when it encounters a problem. Always wrap all risky parts in except, and handle the exceptions. Also think of ways of terminating the program early when necessary. Remember: the program ends only, when all processes end.

What is this?

This authentication method uses 2 keys: private and public. Let’s use example:

• S is some remote server
• C is your laptop

The public key is put on server. It can be shared with anyone, it is of no use to anyone except the owner of the private key.

The private key is kept in safe place on laptop. During authentication server S verifies whether the secret key from C matches the public key on S. If so, user is allowed to log in. It is important to remember, keeping the private key secret is just as important as guarding your password.

Preparation

Simpler than it used to be… To generate the new key pair:

ssh-keygen

and follow defaults. There will be a warning if the key already exists. For simplicity don’t specify a password (I will write how to use a password protected key without having to type too much another time).

Now, to copy the public key to remote sever run:

ssh-copy-id server

Enter the password once more, and try:

ssh server

Congratulations! And remember to protect the key!

Is your python script running slow? Fear no more! Just follow these few steps, and you should be able to pinpoint the culprit.

There are many ways to do this, this is the setup I use for quick profiling.

Prerequisites

• pyprof2calltree: pip install pyprof2calltree
• kcachegrind:
  • Debian/Ubuntu: apt-get install kcachegrind
  • Redhat/Centos: yum install kcachegrind

Collecting profiling data

The test run of the script should be with not too small, not too large amount of data. In my test runs I usually aim for about 10-20 seconds: it’s usually enough to get useful data without waiting too much. Make sure this is appropriate for you. It’s easiest if the script is runnable without any user interaction, then just:

python -m cProfile -o profile.dat test.py

Where (change as appropriate):

• profile.dat will store the execution profile
• test.py is the python script

Visualizing results

pyprof2calltree -i profile.dat -k

Sometimes it does not work (I saw it on a centos system), then try to do it in 2 steps:

pyprof2calltree -i profile.dat
kcachegrind profile.dat.log

It may be overwhelming at first, but there are enough views to finally figure out what is what. Just play a bit with it!

Tips

1. When using libraries the graphs will quickly get too detailed (as they show the internal library details). There are options to limit this if it get’s too distracting
2. Too complex code may get confusing for kcachegrind. If so, try to profile a simpler script with just just as little of the bottleneck code as necessary.