Tales from the Gryphon/ categories/ software/

Tales from the Gryphon

Blog postings about Debian software

Manoj's hackergotchi
RSS Atom Add a new post titled:
Monday 04 May
2009
Link: Reflections on streetcars

Posted terribly early Monday morning, May 4th, 2009

License: GPL

Reflections on streetcars

#+TITLE: Reflections on streetcars #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ Recently, I have made fairly major changes to #+BEGIN_HTML kernel-package, #+END_HTML and there were some reports that I had managed to mess up cross compilation. And, not having a cross-compilation tool chain handy, I had to depend on the kindness of strangers to address that issue. And, given that I am much less personable than Ms Vivien Leigh, this is not something I particularly look forward to repeating. At the onset, building a cross compiling tool chain seems a daunting task. This is not an activity one does frequently, and so one may be pardoned for being non-plussed by this. However, I have done this before, the most recent effort being creating one to compile [[http://www.rockbox.org][rockbox]] binaries, so I had some idea where to start. Of course, since it is usually years between attempts to create cross-compiling tool chains, I generally forget how it is all done, and have to go hunting for details. Thank god for google. Well, I am not the only one in the same pickle, apparently, for there are gobs of articles and HOWTOs out there, including some pretty comprehensive (and intimidating) general tool sets to designed to create cross compilers in the most generic fashion possible. Using them was not really an option, since I would forget how to drive them in a few months, and have a miniature version of the current problem again. Also, you know, I don't feel comfortable using scripts that are too complex for me to understand -- I mean, without understanding, how can there be trust? Also, this time around, I could not decide whether to cross compile for ~arm-elf~, as I did the last time, or for the newfangled ~armel~ target. A need for quickly changing the target for the cross compiler build mechanism would be nice. Manually building the tool chain makes a wrong decision here expensive, and I _hate_ that. I am also getting fed up with having to root around on the internet every time I wanted to build a cross compiler. I came across a script by *Uwe Hermann*, which started me down the path of creating a script, with a help option, to store the instructions, without trying to be /too/ general and thus getting overly complex. However, Uwe's script hard coded too many things like version numbers and upstream source locations, and I know I would rapidly find updating the script irritating. Using Debian source packages would fix both of these issues. I also wanted to use Debian sources as far as I could, to ensure that my cross compiler was as compatible as I could make it, though I did want to use [[http://sources.redhat.com/ml/newlib/][newlib]] (I don't know why, except that I can, and the docs sound cool). And of course the script should have a help option and do proper command line parsing, so that editing the script would be unnecessary. Anyway, all this effort culminated in the following script: #+BEGIN_HTML build cross toolchain, #+END_HTML surprisingly compact. So I am now all set to try and cross compile a kernel the next time a /kernel-package/ bug comes around. I thought that I would share this with the lazy web, while I was at it. Enjoy. The next thing, of course, is to get my script to create a #+BEGIN_HTML qemu #+END_HTML base image every week so I can move from user mode Linux to the much more nifty #+BEGIN_HTML kvm, #+END_HTML which is what all the cool kids use. And then I can even create an /arm/ virtual machine to test my kernels with, something that user mode linux can't easily do.

Manoj

Tuesday 14 April
2009
Link: Yet another kernel hook script

Posted terribly early Tuesday morning, April 14th, 2009

License: GPL

Yet another kernel hook script

#+TITLE: Yet another kernel hook script #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ With tonight's upload of ~kernel-package~, the recent flurry of activity on this package (8 uploads in 6 days) is drawing to a close. I think most of the functionality I started to put into place is now in place, and all reported regressions and bugs in the new 12.XX version have been fixed. The only known deficiency is in the support of Xen dom0 images, and for that I am waiting for kernel version =2.6.30=, where Linus has reportedly incorporated Xen patches. In the meanwhile, ~kernel-package~ seems to be working well, and I am turning my attention to other things. But, before I go, here is another example kernel postinst hook script (which, BTW, looks way better with syntax highlighting CSS on my blog than it does in a rss feed or an aggregator site). #+BEGIN_HTML [[!syntax language=Bash linenumbers=1 bars=1 text=""" #! /bin/sh set -e if [ -n "$INITRD" ] && [ "$INITRD" = 'No' ]; then exit 0 fi version="$1" vmlinuz_location="$2" if [ -n "$DEB_MAINT_PARAMS" ]; then eval set -- "$DEB_MAINT_PARAMS" if [ -z "$1" ] || [ "$1" != "configure" ]; then exit 0; fi fi # passing the kernel version is required [ -z "$version" ] && exit 1 if [ -n "$vmlinuz_location" ]; then # Where is the image located? We'll place the initrd there. boot=$(dirname "$vmlinuz_location") bootarg="-b $boot" fi # Update the initramfs update-initramfs -c -t -k "$version" $bootarg exit 0 """]] #+END_HTML

Manoj

Sunday 12 April
2009
Link: Sample kernel symlink postinst hook script

Posted in the wee hours of Saturday night, April 12th, 2009

License: GPL

Sample kernel symlink postinst hook script

#+TITLE: Sample kernel symlink postinst hook script #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ With the new kernel-package hitting Sid today, and the fact that it no longer does symlink handling by default, I thought it was time that we had an example script that shows how to do that. This is a fairly full featured script, feel free to cull down to use just what you want. I'll post a couple of ther scripts, if there is interest in this. BTW, this script does far more than the old ~kernel-package~ =postisnt= script ever did. Have fun. #+BEGIN_HTML [[!syntax language=Bash linenumbers=1 bars=1 text=""" #!/bin/sh - # -*- Mode: Sh -*- # # This is an example of a script that can be run as a postinst hook, # and manages the symbolic links in a manner similar to the kernel # image default behaviour, except that the latest two versions (as # determined by ls -lct) are kept. You can modify this script # # Copyright 2003, 2004, 2005, 2006, 2007, 2008, 2009 Manoj Srivastava # Copyright 2009 Darren Salt set -e # The dir where symlinks are managed SYMLINKDIR=/ if [ $# -ne 2 ]; then echo Usage: $0 version location exit 2 fi version="$1" vmlinuz_location="$2" vmlinuz_dir="$(dirname "$2")" cd $SYMLINKDIR || exit 1 if [ -n "$DEB_MAINT_PARAMS" ]; then eval set -- "$DEB_MAINT_PARAMS" fi if [ -z "$1" ] || [ "$1" != "configure" ]; then exit 0; fi rm -f vmlinuz vmlinuz.old vmlinuz-rd vmlinuz-rd.old initrd.img initrd.img.old # Create a temporary file safely if [ -x /bin/tempfile ]; then outfile=$(tempfile -p outp -m 0600); else set -e mkdir /tmp/kernel-image-$version-$$ outfile=/tmp/kernel-image-$version-$$/output fi (cd "$vmlinuz_dir" && ls -ct vmlinuz-*) > $outfile STD="$(head -n 1 $outfile | sed 's/vmlinuz-//')" OLD="$(head -n 2 $outfile | tail -n 1 | sed 's/vmlinuz-//')" if [ "X$STD" = "X" ]; then exit 0; fi # If you want version-specific links, here's how to start STD24="$(grep vmlinuz-2.4 $outfile | head -n 1 | sed 's/vmlinuz-//')" || true OLD24="$(grep vmlinuz-2.4 $outfile | head -n 1 | tail -n 1 | sed 's/vmlinuz-//')" || true STD25="$(grep vmlinuz-2.5 $outfile | head -n 1 | sed 's/vmlinuz-//')" || true OLD25="$(grep vmlinuz-2.5 $outfile | head -n 1 | tail -n 1 | sed 's/vmlinuz-//')" || true echo Booting $STD, old is $OLD if [ -f "$vmlinuz_dir/"initrd.img-$STD ] ; then ln -s "$vmlinuz_dir/"initrd.img-$STD initrd.img ln -s "$vmlinuz_dir/"vmlinuz-$STD vmlinuz-rd else ln -s "$vmlinuz_dir/"vmlinuz-$STD vmlinuz fi if [ "X$OLD" != "X" ]; then if [ -f "$vmlinuz_dir/"initrd.img-$OLD ] ; then ln -s "$vmlinuz_dir/"initrd.img-$OLD initrd.img.old ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz-rd.old else ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz.old fi fi # if [ "X$STD24" != "X" ]; then # if [ -f "$vmlinuz_dir/"initrd.img-$STD24 ] ; then # ln -s "$vmlinuz_dir/"initrd.img-$STD24 initrd24.img # ln -s "$vmlinuz_dir/"vmlinuz-$STD24 vmlinuz24-rd # else # ln -s "$vmlinuz_dir/"vmlinuz-$STD24 vmlinuz24 # fi # fi # if [ "X$OLD24" != "X" ]; then # if [ -f "$vmlinuz_dir/"initrd.img-$OLD24 ] ; then # ln -s "$vmlinuz_dir/"initrd.img-$OLD24 initrd24.img.old # ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz24-rd.old # else # ln -s "$vmlinuz_dir/"vmlinuz-$OLD vmlinuz24.old # fi # fi # Run boot loaders here. #lilo rm -f $outfile if [ -d /tmp/kernel-image-$version-$$ ]; then rmdir /tmp/kernel-image-$version-$$ fi exit 0 """]] #+END_HTML

Manoj

Thursday 09 April
2009
Link: kernel-package: Add support for kernel image debug package

Posted Thursday night, April 9th, 2009

License: GPL

kernel-package: Add support for kernel image debug package

#+TITLE: kernel-package: Add support for kernel image debug package #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ A new version of ~kernel-package~ in Incoming at the time of writing adds support for creating a package which contains the Linux kernel debug image. This means the debugging information for the modules in the kernel image package, and the uncompressed vmlinux image. This builds on suggestions and code from Troy Heber, Theodore Y. Ts'o, and Dann Frazier. As support for kexec/kdump support becomes more real, it will be very useful to be able to build kernels that have debugging information available, but not necessarily to install the debugging information on every single client system. The =.ko= object files are stripped of the debugging information before they are placed in the standard /linux-image/ installation package. However, before that, a copy of the vmlinux and unstripped =.ko= files are saved in a "/debuginfo/" package, and everything except for the debugging information is removed from them using ~objcopy --keep-only-debug~. This means that if someone ends up with a crash dump, they can send it to a support engineer and only the support engineer needs to install the debuginfo package and use the "/crash/" utility to debug the crash dump. It's also useful for developers, since the debuginfo information can be stored somewhere outside of ~/lib~ for storing its debug information, for example. This is useful for keeping the size of the root partition small, for those who keep ~/~ separate from ~/usr~. The locations used are compatible also with *SystemTap*, which provides free software infrastructure to simplify the gathering of information about the running Linux system. This assists diagnosis of a performance or functional problem. *SystemTap* eliminates the need for the developer to go through the tedious and disruptive instrument, recompile, install, and reboot sequence that may be otherwise required to collect data. Also, I had to clear out some FUD about kernel-package from the /ircbot/ *dpkg* on the OFTC Debian IRC channel, since someone had implied that ~kernel-package~ was some how obsolete. As can be seen, it is being actively developed, and features are being added apace.

Manoj

Tuesday 07 April
2009
Link: Not your father's kernel-package

Posted at teatime on Tuesday, April 7th, 2009

License: GPL

Not your father's kernel-package

#+TITLE: Not your father's kernel-package #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ A few hours ago, a new version of kernel-package was uploaded to ~experimental~. This is a major change,and I would appreciate it if folks took it out for a spin, kicked the tires, and provide feedback about where this version is lacking. This is only part of the way along in this development cycle. I would like to add a debug-info separation, either in a different directory than / in the image packages, or a separate package by itself. I would also like to create an overlay directory for =/usr/share/kernel-package/=, so people can inject code or override the defaults for kernel-package easily. I am also willing to make any changes to standardize the handling of hook scripts for kernel packages in Debian. ** =./debian/= is ephemeral =make-kpkg= removes and re-creates =./debian= on every invocation. This started as an exercise to protect ourselves from the upstream builddep functionality, that randomly cleaned out ~./debian~ whether or not it had created it, effectively making it impossible to run ~dpkg-buildpackage~ easily (which is ok, if all you care about is the image package) This does make the ~kernel-package~ far more nimble; we now offer less surprise to users who did not expect stampts that the kernel-packagge used to not do duplicate work. Now, if you edit a couple of files in the kernel source, and run ~make-kpkg~, the kernel will build as expected. There are no more "version mismatch" errors, and the kernel version can be modified using ~localconfig~ as one desires. With this, kernel-package can routinely be used to build kernels out of the git tree. The con is that we no longer cater to official kernels, or to anyone who expected content in ./debian to persist. At some point, there are plans to implement an overlay directory that will shadow =/usr/share/kernel-package/ruleset=, but that is not yet implemented. In any case, the kernel team in Debian regards ~kernel-package~ to be broken, and have been bad mouthing it and deprecating it for a few years now, so this will not be a loss for them. ** Get rid of the facility to patch kernel sources The patch the kernel facility was adding complexity, and failing to provide the flexibility required for a generic patching facility. It used to be useful at one point, but in the modern parlance, witht he widespread use of distribute version control systems, and various facilities to manage source and patch them, the built in version was clunky. This means the ~--added-patches~ option of =make-kpkg= is gone, the work-around is to prepare the kernel sources _before_ calling =make-kpkg=. ** Remove special case code for official kernels For the longest tine (well, ever since Herbert Xu too over building kernel images from me), ~kernel-package~ has carried specal case code for official images. This has caused some problems, recently, since the need to preserve ~./debian~ has caused no end of problems when the version changed out from under ~./debian~, or when people wanted to edit a file and expected kernel-package to do a minimal recompile. However, sometime in the Etch release cycle, the kernel team deprecated ~kernel-package~ as the means of building official kernels. They have recently started saying they think ~kernel-package~ is broken, and have their own recommendation for how to build kernel packages. Therefore, a full release cycle later, we can get rid of the special case rules used for official packages. Also, this allows us to drop ~./debian~ at the drop of a hat, and recreate it with an version that reflects the current state of the kernel sources. ** Header package no longer create symbolic links in =/usr/src= Instead, ship an example shell script that replicates the old behaviour. This script can then be deployed on the target machines, and could be a part of a locally created kernel configuration package, if one needs to deploy the same behavior across a cluster of machines. ** The postinst no longer manipulates symlinks This is a shift from previous behaviour. Any symbolic link manipulation must now be done with hook scripts in ~/etc/kernel/*.d~ directories. Firstly, modern boot loaders scan the boot directory for kernel images, and the user no longer has to code in the path to the symbolic links that the kernel image package used to manipulate. Secondly, hardcoding the behaviour into the postinst made for a very rigid policy; and user wanted more flexibility than that. There is an example shipped with the package that shows a more flexible scheme that kept two symbolic links for version 2.4 kernels, and two symbolic links for 2.6 kernels; it can be easily modified to keep two links for 2.9 kernels and two links for 2.8 kernels, or one of each, or whatever the user wants. ** Image postinst no longer runs a boot loader Please note that this was already the case for grub, one of the more popular boot loaders. Now that we have a mechanism for running arbitrary scripts when the image packages are manipulated, we can stop embedding the boot loader actions in the package itself. This means that lilo, elilo, etc will no longer be run directly by the post install script, and all the code related to detecting the boot loader, managing the configuration, and adding bits about bootloader documentation is all removed from the postinst. This allows the image package to be more flexible, since the end user is no longer restricted to the actions encoded in the image package. This is a fairly large change. It also opens the door for the user to easily use non-standard bootloaders, if they so desire. ** The image postinst no longer creates an initramfs Instead, there are example scripts provided that will perform the task. These scripts will work for official kernel images as well. The initramfs scripts provided work with the =make-kpkg= images as well as the official images, and are thus better than the script shipped with =initramfs-tools= themselves, as they offer a super set of functionality. This also demonstrates how the posts install script communicates with the initramfs creation scripts so that no initramfs is generated in case you do not want it.

Manoj

Sunday 01 March
2009
Link: Rethinking ucf redux

Posted late Sunday evening, March 1st, 2009

License: GPL

Rethinking ucf redux

#+TITLE: Rethinking ucf redux #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta@debian.org #+DATE: #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ I have been thinking some more about how to improve ucf. One of the things that struck me was that based on my earlier #+BEGIN_HTML analysis #+END_HTML there are only five actions that ucf can take, and the decision about the actions depends on the state it finds the configuration file in on the target machine, and there are only eight of those. Now, thinking back to my days as a VLSI designer back in the halcyon days of electrical engineering, This is a pretty simple state machine. It is not as neat as it could be (where just three variables would be needed to keep track of things, but still, it bears investigation. This would be a way for converting the current procedural /ucf/ into a functional programming model. Hop over #+BEGIN_HTML here #+END_HTML for a look at how that went --- it was fun, and afforded me an opportunity to demonstrate how well /org/ handles #+BEGIN_HTML LaTeX.png #+END_HTML snippets.

Manoj

Tuesday 24 February
2009
Link: Rethinking ucf

Posted Tuesday night, February 24th, 2009

License: GPL

Rethinking ucf

#+TITLE: Rethinking UCF #+AUTHOR: Manoj Srivastava #+EMAIL: srivasta\@debian.org #+DATE: <2009-02-24 Tue> #+LANGUAGE: en #+OPTIONS: H:0 num:nil toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t TeX:t LaTeX:t skip:nil d:nil tags:not-in-toc #+INFOJS_OPT: view:showall toc:nil ltoc:nil mouse:underline buttons:nil path:http://orgmode.org/org-info.js #+LINK_UP: http://www.golden-gryphon.com/blog/manoj/ #+LINK_HOME: http://www.golden-gryphon.com/ There has been some discussion on the Debian development mailing list #+BEGIN_HTML Tortured activity diagram #+END_HTML about adding hooks into ucf, to allow people to do things like committing files into different SCM branches. So, I thought I would help people out by letting them tell me where hooks would be useful, and so decided to do an activity diagram for ucf. Gawd, what a mess. I mean, I wrote this thing, and it boggles even my mind. See the figure for how horrendous code can get when it grows organically. So, I decided to re-factor/redesign ucf, see if I could create a less complex activity diagram. On analysis, it turns out that ucf has just five actions it may perform, and which action it takes depends on which of eight possible states the configuration file is in. #+BEGIN_HTML Gory details follow #+END_HTML

Manoj

Monday 02 January
2006
Link: A test suite for Devotee

Posted early Monday morning, January 2nd, 2006

License: GPL

A test suite for Devotee

I have been thinking about informally going through NM (perhaps with an AM who wants some practice) for a while now (and have been procrastinating about it like many real-life DD candidates :-). I have planned on using Devotee (DEbian VOTe EnginE) as the package I use to get through NM. So, pursuant to packaging Devotee, I am trying to add a test suite to the package. In order to run a decent test, I need a set of ballots -- signed ballots -- at least some of which are signed by keys in the Debian key-ring. I have put together a dummy vote on my own box, with the topic being voted upon being What is your favorite color of the rainbow?. Here is the ballot. Please note that any emailed ballot is likely to end up in a GPL'd package, open for all the world to see, so please consider that before voting. Oh, and the interesting stats are here.

So, why am I embarking on this strange course of going through NM even though I am already a Debian developer? Well, I've been in the project since well before there was a new maintainer process. I just felt like contributing, and, one day, just emailed the devel list, and I was in. No checks, no key signatures required (not even a key was needed, unless my memory is failing me). I have a theoretical knowledge of what NM entails, but no real gut feeling for what the various stages feel like, nor how hard they are to get through.

I have always wanted to contribute to the NM effort, but I have never felt comfortable with trying to change -- or even participate as an account manager -- with so little understanding of what an applicant is going through.

One of the concerns with me trying to go through NM is that I would be taking valuable resources away from the list of real candidates who are stuck in the queue, and mostly for my own selfish reasons. However, I have been assured by current AM's that adding another candidate to their list would not significantly alter their workload, so I have decided to proceed.

So please, do help develop a test suite for Devotee by voting for your favorite color. Pretty soon I shall be looking for a sponsor for Devotee, and an advocate.

Manoj

Monday 02 January
2006
Link: Moving policy to arch.debian.org

Posted early Monday morning, January 2nd, 2006

License: GPL

Moving policy to arch.debian.org

I have long been interested in moving the debian-policy package away from CVS, but had never quite managed to gather enough motivation to do the switch. Debian policy has long had an Alioth project, but I finally managed to file a support ticket, and nag Wichert into creating the arch project for policy.

The first step was to convert the CVS version into an arch repository, and this is where cscvs comes in. cscvs is nice, but I am told that Canonical has a better, private version, and helpful folks there offered to do a managed conversion to arch for me using these cutting edge tools. I declined, being persnickety enough to want to convert Debian technical policy using tools in Debian itself. And, apart from two change-sets (numbers 117 and 125), cscvs managed to do the conversion to arch (the bazaar flavour) nicely on its own (well, after a few false starts as I climbed the learning curve). Came to 283 change-sets. Have a look at my Debian policy branch. It can be registered at http://arch.debian.org/arch/private/srivasta/archive-etch/.

The next step was to create a baz archive on arch.debian.org, and use Clint's ACL recipe to allow people in the dbnpolicy group to have write access. And then, since I wanted this branch to also have the full set of distinct patch logs, I cycled through all 286 patches in my local branch, replayed and committed them into the remote branch one by one. You may browse the public, or release, branch as well. This version can be registered at http://arch.debian.org/arch/dbnpolicy/etch/.

Manoj


Webmaster <webmaster@golden-gryphon.com>
Last commit: in the wee hours of Friday night, May 31st, 2014
Last edited in the wee hours of Friday night, May 31st, 2014