How to determine the version of available package for arbitrary Debian/Ubuntu/backports.org release

You can get list of available versions of a specific package using rmadison utility from devscripts suit. It remotely polls packages database to show "official" information for Debian/Ubuntu/Backports, regardless of repositories you have configured on your system.

$ rmadison -u debian,ubuntu,bpo mercurial | cut -d "|" -f 1-3
debian:
 mercurial | 0.9.1-1+etch1 |     etch-m68k 
 mercurial | 0.9.1-1+etch1 |     oldstable 
 mercurial |  1.0.1-5.1 |        stable 
 mercurial |    1.5.1-2 |       testing 
 mercurial |    1.5.2-1 |      unstable 
ubuntu:
 mercurial |      0.7-8 | dapper/universe 
 mercurial |    0.9.5-3 | hardy/universe 
 mercurial | 1.0.1-5.1~hardy1 | hardy-backports/universe 
 mercurial | 1.1.2-2ubuntu1 | jaunty/universe 
 mercurial |    1.3.1-1 | karmic/universe 
 mercurial |    1.4.3-1 | lucid/universe 
 mercurial |    1.5.2-1 | maverick/universe 
bpo:
 mercurial | 1.0.1-5.1~bpo40+1 | etch-backports 
 mercurial | 1.3.1-1~bpo50+2 | lenny-backports 

Probably it's not a big deal to implement such functionality for your own private repos.

I believe it could help developers to choose the right distro version or adjust project/feature requirements on an early project planning stage. So much working hours could be saved for sysadmins working on a "private" backporting, who're responsible for the deployment of those new shiny betas to production systems.

I wish we'd have some alternative for RPM-based distros someday.

UPDATE 22 May 2010:

Of course we have it already :) I've recently found whohas utility, which goes far beyond Debian family. It's able to show versions of available software for other distributions (Arch, openSUSE, Gentoo, FreeBSD and even more - 14 distros/repos at the moment, see list below).

"archlinux", "debian", "fedora", "fink", "freebsd", "gentoo",
"macports", "netbsd", "openbsd", "opensuse", "slackware",
"sourcemage", "ubuntu", "opkg"

Though there are some problems. whohas version 0.23-3 lacks support for CentOS and Fedora 10 reached it's EOL (packages moved to archive), so most valuable piece of information is not available by default.

How to set Wanderlust email client to prefer text email version over HTML-formatted one

I'm going to post some short, simple and probably obvious solutions for some problems I've come across. Lisp code snippets are mostly found on the Internet.

This should be placed to wl configuration file to get usually more desirable plain-text formatted messages (for those of them which are 'Content-Type: multipart/alternative')

;; Make MIME understand HTML while preferring the text version if
;; one is provided.
(require 'mime-w3m)
(setq mime-view-type-subtype-score-alist
  '(((text . plain) . 4)
    ((text . enriched) . 3)
    ((text . html) . 2)
    ((text . richtext) . 1)))

Notes on creating debuginfo packages - RPM

To successfully produce -debuginfo RPM's for your main package, several requirements should be satisfied:

1. redhat-rpm-config package should be installed
2. %build section should exist in a .spec file (that's clear from the statement that debugging symbols could exist for arch-dependent binaries only)
3. BuildArch header should be defined in a .spec file

Regarding point 3. That's the most common definition:

BuildArch: %{_target_cpu}

If some point from above is missing, your build process will end up without any -debuginfo packages or it could just fail with the following error:

error: Installed (but unpackaged) file(s) found:

Also, one annoying thing could arise if you are maintaining private repository with several versions of the same package in it. When you upgrading/changing version of main package, it's -debuginfo part would not be changed at all, because there are no any strict dependencies defined between those packages by default.

In Debian this is usually solved by using the following definition in debian/control file:

Package: somepackage-dbg
Architecture: all
Depends: ..., somepackage (=${binary:Version})

Possible solutions found so far for RPM:

1. You can try to use debuginfo-install utility from yum-utils package, it showed that it's able to figure out which version is actually required
2. This could be fixed by adding the following macro re-definition to ~/.rpmmacros or /etc/rpm/marcos and rebuilding your RPM:

%debug_package \
%ifnarch noarch\
%global __debug_package 1\
%package debuginfo \
Summary: Debug information for package %{name}\
Group: Development/Debug\
Requires: %{?!debug_package_requires:%{name} = %{version}-%{release}}%{?debug_package_requires}\
%description debuginfo\
This package provides debug information for package %{name}.\
Debug information is useful when developing applications that use this\
package or when debugging this package.\
%files debuginfo -f debugfiles.list\
%defattr(-,root,root)\
%endif\
%{nil}

Good luck with your packaging!

.

Some useful APT tips reminded

Downgrading Debian system to stable release

It's very cool to have pre-production environments. Entire system could be passed to developers hands to play with unreleased code, QA work or … unplanned OS upgrade from stable to testing distribution! :)

I'm not sure what's the best way to deal with such situations (except full re-installation) on non-Debian systems. Fortunately we have wonderful APT around, so the answer is 'downgrading'.

This could be done by pinning all packages to stable release archive with priority 1001. You need to edit /etc/apt/preferences and add the following content:

Package: *
Pin: release a=stable
Pin-Priority: 1001

Of course, some conflicts are possible during downgrade, but resolution is quite straightforward. To make long story short - affected system has been successfully downgraded (even libc and so on) and came online after reboot.

It's better to place the following definition into /etc/apt/apt.conf configuration file to prevent system from being upgraded to unwanted release in a mixed environments:

APT::Default-Release stable;

Note that defined Default-Release option overrides pinning settings (sets priority of target release to 990).

More on package pinning on Debian official site.

Examine installation candidates and available versions

There is a way to predict apt-get or aptitude behavior during package installation or upgrade - examine apt policy. Just use the following to check system-wide setup:

zail@debbie:~$ apt-cache policy
Package files:
 100 /var/lib/dpkg/status
     release a=now
 500 http://security.debian.org lenny/updates/non-free Packages
     release v=5.0,o=Debian,a=stable,l=Debian-Security,c=non-free
     origin security.debian.org
 500 http://security.debian.org lenny/updates/contrib Packages
     release v=5.0,o=Debian,a=stable,l=Debian-Security,c=contrib
     origin security.debian.org
 500 http://security.debian.org lenny/updates/main Packages
     release v=5.0,o=Debian,a=stable,l=Debian-Security,c=main
     origin security.debian.org
 500 http://ftp.us.debian.org lenny/non-free Packages
     release v=5.0.4,o=Debian,a=stable,l=Debian,c=non-free
     origin ftp.us.debian.org
 500 http://ftp.us.debian.org lenny/contrib Packages
     release v=5.0.4,o=Debian,a=stable,l=Debian,c=contrib
     origin ftp.us.debian.org
 500 http://ftp.us.debian.org lenny/main Packages
     release v=5.0.4,o=Debian,a=stable,l=Debian,c=main
     origin ftp.us.debian.org
Pinned packages:

or with package name supplied as additional argument:

zail@debbie:~$ apt-cache policy openoffice.org
openoffice.org:
  Installed: (none)
  Candidate: 1:2.4.1+dfsg-1+lenny3
  Version table:
     1:3.1.1-11~bpo50+1 0
        200 http://gw lenny-backports/main Packages
     1:2.4.1+dfsg-1+lenny3 0
        990 http://gw lenny/main Packages
        990 http://gw lenny/updates/main Packages

To check packages versions available for installation in your particular case, apt-cache madison could be used:

zail@debbie:~$ apt-cache madison openoffice.org
openoffice.org | 1:3.1.1-11~bpo50+1 | http://gw lenny-backports/main Packages
openoffice.org | 1:2.4.1+dfsg-1+lenny3 | http://gw lenny/main Packages
openoffice.org | 1:2.4.1+dfsg-1+lenny3 | http://gw lenny/updates/main Packages

To check what version of a package is available from official archives, use rmadison tool from devscripts tool-set:

zail@debbie:~$ rmadison openoffice.org
openoffice.org | 2.0.4.dfsg.2-5etch1 |     etch-m68k | source
openoffice.org | 2.0.4.dfsg.2-7etch6 |     oldstable | source, amd64, i386, powerpc, sparc
openoffice.org | 1:2.4.1+dfsg-1+lenny3 |        stable | source, amd64, armel, i386, ia64, mips, mipsel, powerpc, s390, sparc
openoffice.org | 1:3.1.1-14 |       testing | source, amd64, i386, ia64, mips, mipsel, powerpc, s390, sparc
openoffice.org | 1:3.1.1-14 |      unstable | source, ia64, mips, mipsel
openoffice.org | 1:3.1.1-15 |      unstable | source, amd64, i386, powerpc, s390, sparc
openoffice.org | 1:3.2.0~rc1-1 |  experimental | source, armel
openoffice.org | 1:3.2.0~rc5-2 |  experimental | source, amd64, i386, s390

Make aptitude command line output more informative

When upgrading/migrating any system, it's good to know about what is going to happen with the host. I prefer to set the following settings in /etc/apt/apt.conf to see how versions of packages are being changed, how much disk space will be used or freed. Also it's nice to be sure that you'll be prompted for confirmation before any actual upgrade activity :).

Aptitude::CmdLine::Always-Prompt true;
Aptitude::CmdLine::Show-Versions true;
Aptitude::CmdLine::Show-Size-Changes true;

For example:

zail@debbie:~$ sudo aptitude install parcellite/stable
[sudo] password for zail: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
Reading extended state information      
Initializing package states... Done
Reading task descriptions... Done  
The following packages will be DOWNGRADED:
  parcellite [0.9.1-1~bpo50+1 -> 0.7-1] <-143kB>  
0 packages upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
Need to get 26.3kB of archives. After unpacking 143kB will be freed.
Do you want to continue? [Y/n/?] 

More on aptitude configuration options could be found on Daniel Burrow's (aptitude author) site here.

Handy way to choose release of a package to install

There is a more convenient way to choose non-default archive then using -t switch for apt-get or aptitude when installing packages. Default method:

zail@debbie:~$ sudo aptitude -t unstable install parcellite 

Or method which has been employed in the previous section:

zail@debbie:~$ sudo aptitude install parcellite/stable

That's all so far.

.

Simple GPRS Internet connection setup via Bluetooth on Debian Lenny

This how-to may look a bit outdated, but currently I'm forced to use such kind of Internet access as GPRS via cell-phone, thanks to my home ISP. I've created this note to not waste time on setup in case I need it again.

I was always a bit concerned about the way of getting things to work in common GPRS setups: pppd, chat-scripts, *-secrets files and other ancient stuff in 21 century? No, thanks. Let's use NAP-enabled SonyEricsson K320 cell-phone to achieve the same goal in a more convenient way, but without all those Gnome or KDE bells and whistles.

First of all, edit file /etc/bluetooth/hcid.conf and change passkey setting to your favorite pass and security to auto:

--- hcid.conf   2009-11-13 21:45:04.000000000 +0200
+++ hcid.conf   2009-11-13 22:32:16.000000000 +0200
@@ -12,7 +12,7 @@
        #   auto - Use local PIN for incoming connections
        #   user - Always ask user for a PIN
        #
-       security user;
+       security auto;
 
        # Pairing mode
        #   none  - Pairing disabled
@@ -21,7 +21,7 @@
        pairing multi;
 
        # Default PIN code for incoming connections
-       passkey "1234";
+       passkey "super-secret-passkey";
 }

Restart bluetooth service:

sudo invoke-rc.d bluetooth restart

Now you should be able to pair your phone and workstation (I've started this process from phone's menu).

Ensure, that your device is capable of Network Access Point (NAP) feature:

zail@debbie:~$ sdptool search nap
Inquiring ...
Searching for nap on 00:1D:28:F4:BF:46 ...
Service Name: NAP service
Service Description: NAP description
Service RecHandle: 0x10009
Service Class ID List:
  "Network Access Point" (0x1116)
Protocol Descriptor List:
  "L2CAP" (0x0100)
    PSM: 15
  "BNEP" (0x000f)
    Version: 0x0100
    SEQ8: 0 6 dd
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100
Profile Descriptor List:
  "Network Access Point" (0x1116)
    Version: 0x0100

Copy device MAC-address and add the following section to /etc/network/interfaces:

allow-hotplug bnep0
iface bnep0 inet dhcp
        pre-up pand -n -c 00:1D:28:F4:BF:46 -z
        post-down pand -K

Now you are ready to use your connection. Just ifup new interface and start surfing!

zail@debbie:~$ sudo ifup bnep0 
pand[2558]: Bluetooth PAN daemon version 3.36
pand[2558]: Connecting to 00:1D:28:F4:BF:46
pand[2558]: bnep0 connected
Internet Systems Consortium DHCP Client V3.1.1
Copyright 2004-2008 Internet Systems Consortium.
All rights reserved.
For info, please visit http://www.isc.org/sw/dhcp/

Listening on LPF/bnep0/00:1d:92:c8:eb:5d
Sending on   LPF/bnep0/00:1d:92:c8:eb:5d
Sending on   Socket/fallback
DHCPDISCOVER on bnep0 to 255.255.255.255 port 67 interval 5
DHCPOFFER from 10.24.10.82
DHCPREQUEST on bnep0 to 255.255.255.255 port 67
DHCPACK from 10.24.10.82
bound to 10.24.10.81 -- renewal in 142 seconds.
zail@debbie:~$ ping www.eu
PING www.eu (85.214.77.236) 56(84) bytes of data.
64 bytes from h1088616.serverkompetenz.net (85.214.77.236): icmp_seq=1 ttl=48 time=537 ms
64 bytes from h1088616.serverkompetenz.net (85.214.77.236): icmp_seq=2 ttl=48 time=384 ms
^C
--- www.eu ping statistics ---
3 packets transmitted, 2 received, 33% packet loss, time 2002ms
rtt min/avg/max/mdev = 384.639/461.286/537.933/76.647 ms

That's it! Say goodbye to pppd et al.

.