stick's corner

Due to some requests on mailing lists and Feature #305803 I decided to change the default behavior of command-not-found handler (in openSUSE 11.2 and SLE11).

Now it prints this info immediately:

$ blender
If 'blender' is not a typo you can use command-not-found to lookup the package
that contains it, like this:
    command-not-found blender
bash: blender: command not found

$ ifconfig
Absolute path to 'ifconfig' is '/sbin/ifconfig', so running it may require
superuser privileges (eg. root).
bash: ifconfig: command not found

instead of directly performing the search.

If you want the old behaviour back (i.e. search invoked automatically), just add

export COMMAND_NOT_FOUND_AUTO=1

to your bash profile. (This is also documented in command-not-found man page).

You can install the updated packages from home:prusnak:scout BuildService repository as usual.

I finally implemented very important feature of scout: It is now able to search for binaries in all enabled zypp repositories. SAT-solver files are used for this, so user does not have to install any external index files. I really would like to thank Klaus Kaempf for his exhaustive help with python bindings for satsolver. Another great news are that Werner Fink applied command-not-found patch for bash package, so 11.1 will probably contain this feature working out of the box! Current early implementation has one problem though: it is pretty slow comparing to older use-own-sqlite-database approach (2 seconds compared to 0.2 seconds). But it indexes more repositories at once (I have 14 enabled) and I believe the code could more optimized and thus whole search faster in the (near) future.

Feel free to test the packages from BuildService (follow the instructions on wiki) and tell me what you think of it !

A lot has happened since the public release of scout. Blogpost registered more than 400 hits, Marek Stopka created bash-completion, Thomas Schraitle wrote docbook documentation and Michal Vyskocil prepared module for python and its indexes. Thank you all! I started a wikipage like Thomas suggested and indexed Packman repositories for their binaries.

Michal also prepared small demonstration video about using scout in java wrapper. The wrapper runs java application and greps stderr for exceptions. When NoClassDefFoundError/ClassNotFoundException is detected, the classname is taken to scout, which resolves it to package name, installs the package with zypper and tries to run application again! I like this idea pretty much. Michal is currently working on perl indexes and we will probably index also ruby and pkgconfig files.

Watch mentioned java demonstration video here:

or download it …

I created the demonstration video for scout like I promised in previous post. Here you are:

direct download

Hooray! The first public version of Scout was just released. It is a simple tool which allows user to look for (not yet installed) packages using simple queries (e.g. which autoconf macros does the package contain, which Java classes are present inside or what binaries does the package provide). Scout is available in openSUSE BuildService in home:prusnak:scout project. If you would like to install and test it, follow these three steps:

1. add the following repositories:

   zypper ar http://download.opensuse.org/repositories/home:/prusnak:/scout/openSUSE_11.0 scout
   zypper ar http://download.opensuse.org/repositories/home:/prusnak:/scout/data scout-data

   (change openSUSE_11.0 to your distribution if necessary)

2. install scout:

   zypper in scout

3. add any of the index data you find attractive (only example – see scout wiki page for the whole list)

   zypper in scout-bin-suse110
   zypper in scout-java-suse110

   Data package names are in format scout-module-repo. Indexes for autoconf macros are in autoconf packages, bin are indexed binaries and java are indexed java classes. Repository names are either distributions (sle10, suse101, suse102, suse103, suse110) or BuildService projects (jpackage17 for Java:jpackage1.7). Simple, isn’t it?

   (Warning: Java indexes are pretty large – 5MB RPMs and around 30MB when installed.)

When you are ready, run scout without parameters to see the help. I think that the usage is pretty straightforward (nevertheless, I will try to create demonstration video soon). You can also try running scoutcsv or scoutxml – they are only symlinks, but they produce CSV or XML output, instead of table output.

I hope you will like it!

The next thing to do is to add support for ZYPP repositories (sat-solver files) in module for binaries, so user could query packages (even in the BuildService repositories) without installing any external index data. When this is done, it would be a piece of cake to replace the earlier implementation of command-not-found with the new one using scout as its backend. Unfortunately, this is not going to happen before the ZYPP bindings for Python (python-zypp) are fixed. (API has changed and it seems that only Ruby bindings are maintained.) I tried to fiddle with it (bugzilla), but I’m not a SWIG expert.

You might have heard about my older project called command-not-found. Right now it is implemented as SQLite database which contains only table(binary, path, package). (I’m going to rewrite it, so that it makes use of the new SAT solver files, but this is not the topic of this blogpost).

In the meantime, my colleague and Java packager Michal Vyskocil encountered a problem: it is very hard to find out which package installs particular Java class. Standa Brabec suggested that we could also process autoconf macros stored in m4 files. So we decided to merge these ideas together and we started the “Scout” project.

It will be a command line utility which will index various attributes of the packages and will allow the users to search in them. Each functionality will have its own module, so implementation could differ (we wanted the binary module to use SAT solver files and the others SQlite). I think that you’ll get the idea from the following picture:

Michal and I started development by creating a GIT repository (not much to see there, yet). Obviously this program will not appear in openSUSE 11.0, but we’d like to see it in 11.1 (and my plan is that command-not-found will use scout as its helper). At start, we will create 3 modules (binaries, java and autoconf), but later we’ll extend the support for python/ruby programmers.

If you have any ideas, do not hesitate and contact me!