Pavol Rusnak #cypherpunk #hacker #openhw #privacy #bitcoin #newmediaart

Scout: bash-completion, documentation, python indexes and Java demo

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:


Scout demonstration video

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


Scout released

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 scout
zypper ar scout-data

(change openSUSE_11.0 to your distribution if necessary)

  1. install scout:
zypper in scout
  1. 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. :(

Scout project introduction

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! :)

Games in the openSUSE Build Service

We decided to restructure and cleanup the games projects in the openSUSE Build Service. Before the change we had 8 projects for each game genre (action, adventure, arcade, board, puzzle, roleplay, strategy/realtime, strategy/turn-based) and one separate project for game libraries (so you can play games even on older distributions with obsoleted libraries).

This situation was causing more harm than good, so now we will only have one “games” repository with all game genres together. If you have already added old game repositories, please remove them and add the brand new one located here and then the directory of your distribution. The old URLs for the individual games repositories will no longer work.

If your favorite game is not yet packaged you can add it to the Games Wishlist at openSUSE wiki. Or even better, you can try to package it by yourself and when you are finished contact me and we will add the game to the repository. You can also ask on the (subscribe) mailing list you have any troubles with the packaging.

Game On!