third line of each of these log entries are "scores": roughly, the more
important a package is, the higher its score should be. The function that
calculates these is `pkgProblemResolver::MakeScores()` in
-[apt-pkg/algorithms.cc](http://bazaar.launchpad.net/+branch/apt/view/1951/apt-pkg/algorithms.cc).
+[apt-pkg/algorithms.cc](http://anonscm.debian.org/cgit/apt/apt.git/tree/apt-pkg/algorithms.cc?id=f23e1e940214c7abbf87c28bc71a5d37d117aa57).
Reading this, I noticed that the various values added up to make each score
are almost all provably positive, for example:
language, and a cute gimmick to make things like `man /usr/bin/time`
display the appropriate manual page rather than the text of the
executable. See the [NEWS
- file](http://bazaar.launchpad.net/~cjwatson/man-db/trunk/annotate/head%3A/NEWS)
- for more details.
+ file](http://git.savannah.gnu.org/cgit/man-db.git/tree/NEWS) for more
+ details.
* binfmt-support now [installs cleanly on non-Linux
systems](http://bugs.debian.org/565109), even if it doesn't do anything
useful yet.
I've released man-db 2.6.0
([announcement](http://lists.nongnu.org/archive/html/man-db-announce/2011-04/msg00000.html),
-[NEWS](http://bazaar.launchpad.net/~cjwatson/man-db/trunk/view/1344/NEWS),
-[ChangeLog](http://bazaar.launchpad.net/~cjwatson/man-db/trunk/view/1344/ChangeLog)),
+[NEWS](http://git.savannah.gnu.org/cgit/man-db.git/tree/NEWS?id=2.6.0),
+[ChangeLog](http://git.savannah.gnu.org/cgit/man-db.git/tree/ChangeLog?id=2.6.0)),
and uploaded it to Debian unstable. Ubuntu is rapidly approaching beta
freeze so I'm not going to try to cram this into 11.04; it'll be in 11.10.
don't feel particularly bad about [giving an advantage to GPLed
programs](http://www.gnu.org/licenses/why-not-lgpl.html). For more details
on the interface, the [header
-file](http://bazaar.launchpad.net/~cjwatson/man-db/trunk/annotate/head%3A/lib/pipeline.h)
+file](http://git.savannah.gnu.org/cgit/man-db.git/tree/lib/pipeline.h?id=017a4c1e639d20e85d92ed11786a728913104953)
is well-commented.
Is there enough interest in this to make the effort of producing a separate
boot process was getting as far as GRUB but still wasn't printing anything.
I removed some Ubuntu patches which quieten down GRUB's startup: still
nothing - so I switched my attentions to
-[grub-core/kern/i386/pc/startup.S](http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/view/head:/grub-core/kern/i386/pc/startup.S),
+[grub-core/kern/i386/pc/startup.S](http://git.savannah.gnu.org/gitweb/?p=grub.git;a=blob;f=grub-core/kern/i386/pc/startup.S;hb=HEAD),
which contains the first code executed from GRUB's core image. Code before
the first call to `real_to_prot` (which switches the processor into
protected mode) succeeded, while code after that point failed. Even more
correctly and jumping to it. The first instruction it jumped to wasn't in
`startup.S`, though, and then I remembered that we prefix the core image
with
-[grub-core/boot/i386/pc/lnxboot.S](http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/view/3095/grub-core/boot/i386/pc/lnxboot.S).
+[grub-core/boot/i386/pc/lnxboot.S](http://git.savannah.gnu.org/gitweb/?p=grub.git;a=blob;f=grub-core/boot/i386/pc/lnxboot.S;hb=edde54e656a3219a6ad5e7118e0212d50af01697).
Stepping through this required a clear head since it copies itself around
and changes segment registers a few times. The interesting part was at
`real_code_2`, where it copies a sector of the kernel to the target load
`lnxboot.S` was checking somewhat further into the core image, after the
first sector. `lnxboot.S` couldn't find it because it hadn't copied it yet!
A bit of
-[adjustment](http://bazaar.launchpad.net/~vcs-imports/grub/grub2-bzr/revision/3096)
+[adjustment](http://git.savannah.gnu.org/gitweb/?p=grub.git;a=commitdiff;h=9b43bf396a61b60a0ee4b8a1591634b1120b8906)
and all was well again.
The lesson for me from all of this has been to try hard to get an