PPA: Create package with minor version upgrade

I used this before to remember all the necessary commands, without reading the whole guide again and again. As I don’t upload many packages, it’s easy to forget the details…

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
  2. Fetch previous version from repository. You will get some files and a directory “packagename-vesion”, called later <old-version-dir>
  3. Same place, download the new tarball.
  4. Enter the old package directory
  5. Use uupdate to prepare new version’s directory. You may need to specify the new version explicitly
  6. Go there
  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
  8. Check it builds fine
  9. Build source package
  10. Upload it to launchpad
  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!

Using udev to trigger events in example

Find device (this works only with input devices):

Use the name to find system path of the device:

Make a test run:

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:

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:

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:

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:

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:

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

Python multiprocessing HOWTO

Using python multiprocessing module is quite simple, even though it has some pitfalls. But remembering how to avoid them it can help to really speed up some tasks.

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

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:

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:

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

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:

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:

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:

and change the loop in main to:

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:

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.

Using SSH without password

Using SSH often to login to remote systems? Sick of entering your password every few minutes? Consider logging using public key authentication.

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:

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:

Enter the password once more, and try:

Congratulations! And remember to protect the key!

Python profiling

Introduction

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:

Where (change as appropriate):

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

Visualizing results

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

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.