- About the bot
- Binary package information
- Source package information
- Bugs tracking information
- Hardware information
- Kernel information
About the bot
judd came from the first and most used plugin
that is running in this bot.
The plugin was called
Judd as it is a window into the
Ultimate Debian Database
for providing package and bug tracking information.
The bot is a
supybot running a
number of customised plugins for helping on
- Ultimate Debian Database for package information and bugs
- PCI-Id and other hardware compatibility information
A complete list of the available commands that any plugin provides
may be obtained from the bot by asking it to
list the plugin,
for example using the following commands:
A few extra aliases exist for these commands to handle common typos or to reduce the amount of typing required.
For each of the commands
judd lists as part of a plugin,
on-line help is available:
judd uses comma (
,) as an address
character in the channel.
You can either address it directly by prefixing commands with
, or send the commands by private message
/msg judd). Please talk to
judd in a private message
unless others in the channel really need to see his output.
For the remainder of this examples in this guide,
the details of how the bot is addressed are omitted.
The plugin indexes a number of official repositories as well as
out-of-Debian repositories that are widely used (indexing is not an
endorsement of the out-of-Debian repository).
The repositories indexed by
and the names given to them are as follows:
- Official repositories
- Security updates (
- Pending updates and other updated packages
- Backports from backports.debian.org
- Multimedia packages from deb-multimedia.org
oldstableis kept in the database even after oldstable support finishes. This is only to help people who are tardy in upgrading and not because running an unsupported release is a clever idea.
testing-securitydoes not always contain meaningful updates if the Testing Security team are not currently providing security support for
- the release states (
unstableetc) can be used as well as code names (
#debianthe information supplied by
Judddefaults to the current stable release for the amd64 architecture. In
#debian-nextthe current testing release is used instead.
Many commands take the following options
- a binary package name (not source package name). Prefixing the name
src:will look at source packages instead.
- specify the architecture.
Standard Debian architecture names are used, such as
- select which release should be queried.
Either release codenames (
sid) or release states (
unstable) can be used.
Binary package information
Information about what packages are in the various
is provided by the
The most commonly used commands and some sample output are shown below.
Display the versions of a package that are available in each of the indexed repositories.
Display the architectures for which a package is available and the version that is available for each architecture.
About a package
Searching for packages with
apt-cache search or
aptitude search is always going to be
faster than using
Judd, but it is possible to search
the database for package names.
The packages declared as
for any binary package can be found:
Provides and virtual packages
Packages in Debian can also provide the functionality of another
package (or provide a virtual package);
packages can depend on packages that are only virtual packages (i.e. package names
that only appear in a
Such virtual packages do not have
versions and will not appear in
The packages listed in
Provides can be queried using the
provides command and the packages that declare that they
provide a virtual package can be found using the
It is also possible to trace through a dependency chain (similar to
aptitude why pkg1 pkg2). Note that for very large dependency
trees this process is not fast. Each dependency chain is separated by
a semicolon (;).
A hard dependency (
Depends) is indicated by a filled arrow (▶)
and a soft dependency (
Recommends) is indicated by an open arrow (▷).
The files contained within each package are recorded in the Contents files
on the mirrors. The command line tool
apt-file can be
used to search through these indices, as can
Note that files created by maintainer scripts (such as configuration files)
and files managed by the alternatives system are not necessarily
indexed in Contents. If there are too many matches,
truncate the output. See the alternative
command for a way of searching the alternatives system.
Sets of cooperating packages may arrange to use the
to share a namespace on the filesystem. Examples of this are the
editor command (
/usr/bin/editor) which is provided
as an alternative by 43 packages (at last count).
Alternatives can be queried either by the full path or by the filename.
Note that in the absence of a declarative syntax for alternatives, the list of available alternatives must be created by installing and removing packages and looking at the alternatives installed by the maintainer scripts. The data searched by Judd is a periodic snapshot prepared by Jakub Wilk.
Source package information
The binary packages that are installed on a Debian system are derived from
The versions command shown above for
binary packages can be used to see source package versions by prefixing
the package name with
Obtain information about source packages and their relationships to
is used for the Debian binary package and
the Debian source package.
Debian Reference §7.1
for more information on Debian source packages.
What source package produced
libc6 in lenny? squeeze?
What source package makes the
What other binary packages come out of the
Building source packagesThe build-time dependencies of a source package are listed by the maintainer as being for general package building (
Build-Depends) or only for building the architecture-independent parts of the package (
Build-Depends-Indep). Section 7.7 of the Debian Policy Manual defines these terms in mode detail.
Building backported packages
While pre-compiled backports are available for Debian stable releases already, it is also possible to make your own. It is possible to check if the declared build-dependencies are available in your target release. Note that just because the build-dependencies are satisfied doesn't mean that the package will build and function correctly. Conversely, it is sometimes still possible to backport a package that doesn't have its build-dependencies satisfied by skipping some compilation options.
--verbose is specified, a detailed breakdown of the
build-dependencies and which release they were found in will be provided to you
in a private message.
--fromrelease parameter defaults to
--torelease defaults to the current stable
release. Packages from
stable-backports will automatically
be included if needed.
The output shows the releases that were used to find the build-dependencies.
The presence of build-dependencies that are not required for the specified
architecture is noted with an
archignore pseudo-release in the
Build-dependencies that have been found through virtual packages
Provides relationships cause a
pseudo-release to be reported in the output.
Reliance on virtual build-dependencies can indicate that a backport
is more likely to fail to compile (FTBFS).
This command does not take account of the co-installability of the build-dependencies and does not look at Build-Conflicts.
Information about the maintainers of a package and when versions were uploaded is available. The upload of specific versions of a package can be queried; by default the most recent upload information is returned.
A list of recently uploaded versions and the upload dates can also be seen.
Further details of recent uploads, similar to the
command from the devscripts
package, can also be obtained.
The Ultimate Debian Database imports data from the Debian Bug Tracking System (BTS) on a regular basis. Having a nice database full of bug details can be quite handy, but the delay in importing the information poses some obvious limitations.
Bugs in packages
The status of an individual bug can be seen, an overview of the bugs in a package generated or bugs with titles in a package can be located.
An overview of the release-critical bugs in a package can be seen.
Administrative tasks tracked through bugs
The reason a source package was removed from Debian can be located.
Work-needed and prospective packages (WNPP) bugs can be searched too. WNPP bugs include O (orphaned), RFA (request for adoption), ITA (intent to adopt), ITP (intent to package), RFP (request for packaging).
New versions of packages can be added to the archive at the request of maintainers who do not (yet) have upload permissions. Such requests may be contained within RFS (Request for Sponsorship) bug reports.
Hardware support information
Information about the hardware support provided by the kernels in various
is made available by the
Piccy indexes the kernel config and PCI-Id mappings for the
i686 kernels in all debian releases including the
Additionally, the kernel from the kernel team's build server repository may be
indexed if it is available.
Kernel updates released by the security team are included in this indexing
although these rarely (if ever?) change the data.
The PCI-Id for a device may be obtained with the command
lspci -nn (from the
Further information and other approaches to finding this information
can be found on the
An example output from
lspci -nn is:
which shows that this wireless device has a PCI-Id of
PCI-Id to kernel module
Display the kernel module or modules that claim to support a
The device and its manufacturer are identified based on the
An index of kernel modules is used to see which, if any, modules
will claim that device (based on
A link to kmuto's HCL is provided
for further information about the device.
Links to appropriate pages in the
are also given.
Note that a few modules like
snd-hda-intel are almost always
false-positives from a wildcard match from the driver - unless you were actually
asking about a disk or audio card. (Hints on how to do
this matching more robustly are most welcome.)
Piccy will search through the sid kernel if no matches in the
kernel for the requested release are found.
Device name to PCI-Id
Users frequently know the name of the device but not the actual PCI-Id. Trying to work out the PCI-Id from the name isn't easy, but can sometimes be done. This is usually best done in a private message to save flooding the channel.
The keyword is part of the device name from the pci.ids database. It cannot contain non-alphanumeric characters and has a wildcard added to the beginning and end of the term.
For example, a user claimed to have a
adapter but stated that the PCI-Id was `80086:1082`
(which is malformed and incorrect).
The available kernels and their configuration are also searchable
The kernels indexed to determine PCI-Id support can be interrogated
Kernels configuration options
The Debian kernel packages ship the kernel config that was used to
compile the kernel in
/boot/config-$(uname -r) and
grep OPTION /boot/config-$(uname -r)
can provide useful information.
The i686 kernel configurations for the same releases as for the
pciid command are indexed.
where option is a keyword or part of the config option being searched for. It cannot contain non-alphanumeric characters and has a wildcard added to the beginning and end of the term. CONFIG_ is not required to be added to the term and the search is case-insensitive.
The latest source code for the
plugins can be found in
git clone http://git.nanonanonano.net/projects/judd.git