chiark / gitweb /
Update links to code now hosted in git rather than bzr
authorColin Watson <cjwatson@debian.org>
Thu, 12 Mar 2015 10:27:16 +0000 (10:27 +0000)
committerColin Watson <cjwatson@debian.org>
Thu, 12 Mar 2015 10:27:16 +0000 (10:27 +0000)
content/apt-resolver-bugs.md
content/catching-up.md
content/man-db-2.6.0.md
content/pipeline-library.md
content/wubi-bug-693671.md

index 0299201c4b6c1bcacda8caf14c9af933d154ea05..198c678f7cd519e2ccc3783881b11f3c379dc6af 100644 (file)
@@ -131,7 +131,7 @@ Eventually I noticed something.  The numbers after the package names in the
 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:
 
index 9c2dec89c411e94b03f8812d79cb848d178371e3..2b08fdb160b15c63b308ba1e4ff348b26bbde120 100644 (file)
@@ -16,8 +16,8 @@ Among the things I got round to:
    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.
index 70cd323ef2fd1321210c9fcf001652c058a5e020..e6d9560b9d3a4e6208251c89c1b5f01ce30501c6 100644 (file)
@@ -6,7 +6,7 @@ Tags: man-db, planet-debian, planet-ubuntu
 
 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.
index ae727a74a9816d53fb5582d80ac12688a3595dda..bd45ae061bf2d5aaa8dd512b2e3a557bb8f89759 100644 (file)
@@ -130,7 +130,7 @@ negotiable since some of the original code wasn't mine and in any case I
 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
index 8914229f93789e5785571dea8ea98bacb37b8066..a76a8c5c2144fb2c7d1248e72bdc426b225dd779 100644 (file)
@@ -111,7 +111,7 @@ these, and corrected a simple one.  Testing at this point suggested that the
 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
@@ -149,7 +149,7 @@ Single-stepping showed that GRLDR was loading the entirety of `wubildr`
 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
@@ -161,7 +161,7 @@ writing over sectors in the boot track.  This moved the magic number
 `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