Bug#143307: triggers-related dependtry assertion fix

[Ian Jackson]

tags 143307 + patch
thanks

I've reproduced the problem from #143307 and attached is a fix.

The core of the problem was that if dpkg is interrupted, you can have
the following situation:

    Package: a
    Triggers-Awaited: b

    Package: b
    Status: ... installed

This is as expected but I obviously hadn't properly tested the
recovery, which is to do a no-op trigger processing step for b.  The
machinery in packages.c would be unimpressed by b's appearance in
progress_bytrigproc.

In the patch below I also fix --no-act for trigger processing, which
was previously broken.  This was somewhat more complex than ideal
because the triggers arrangements leak somewhat more into dbmodify
than previously existing functionality.  I decided to create a new
msdbrw_... value `simulate' and change the various places to use it
and treat it appropriately.  After calling modstatdb_init with
msdbrw_simulate it is permitted to call modstatdb_note.

Ian.


diff --exclude='*~' -bru orig/dpkg-1.14.20/lib/dbmodify.c dpkg-1.14.20/lib/dbmodify.c
--- orig/dpkg-1.14.20/lib/dbmodify.c 2008-06-18 08:33:27.000000000 +0100
+++ dpkg-1.14.20/lib/dbmodify.c 2008-06-28 15:41:17.000000000 +0100
@@ -170,8 +170,8 @@
                 msdbrw_write);
     }
     break;
-  case msdbrw_readonly:
-    cstatus= msdbrw_readonly; break;
+  case msdbrw_readonly: case msdbrw_simulate:
+    cstatus= readwritereq; break;
   default:
     internerr("unknown readwritereq");
   }
@@ -204,6 +204,7 @@
 void modstatdb_checkpoint(void) {
   int i;
 
+  if (cstatus == msdbrw_simulate) return;
   assert(cstatus >= msdbrw_write);
   writedb(statusfile,0,1);
   
@@ -249,7 +250,7 @@
 void modstatdb_note(struct pkginfo *pkg) {
   struct trigaw *ta;
 
-  assert(cstatus >= msdbrw_write);
+  assert(cstatus >= msdbrw_simulate);
 
   onerr_abort++;
 
@@ -267,6 +268,8 @@
       versiondescribe(&pkg->installed.version, vdew_nonambig));
   statusfd_send("status: %s: %s", pkg->name, statusinfos[pkg->status].name);
 
+  if (cstatus >= msdbrw_write) {
+
   varbufreset(&uvb);
   varbufrecord(&uvb, pkg, &pkg->installed);
   if (fwrite(uvb.buf, 1, uvb.used, importanttmp) != uvb.used)
@@ -274,7 +277,8 @@
   if (fflush(importanttmp))
     ohshite(_("unable to flush updated status of `%.250s'"), pkg->name);
   if (ftruncate(fileno(importanttmp), uvb.used))
-    ohshite(_("unable to truncate for updated status of `%.250s'"), pkg->name);
+      ohshite(_("unable to truncate for updated status of `%.250s'"),
+      pkg->name);
   if (fsync(fileno(importanttmp)))
     ohshite(_("unable to fsync updated status of `%.250s'"), pkg->name);
   if (fclose(importanttmp))
@@ -282,7 +286,8 @@
   sprintf(updatefnrest, IMPORTANTFMT, nextupdate);
   if (rename(importanttmpfile, updatefnbuf))
     ohshite(_("unable to install updated status of `%.250s'"), pkg->name);
-  assert(strlen(updatefnrest)<=IMPORTANTMAXLEN); /* or we've made a real mess */
+    assert(strlen(updatefnrest)<=IMPORTANTMAXLEN);
+      /* ... or we've made a real mess */
 
   nextupdate++;  
 
@@ -293,6 +298,8 @@
 
   createimptmp();
 
+  }
+
   if (!pkg->trigpend_head && pkg->othertrigaw_head) {
     /* Automatically remove us from other packages' Triggers-Awaited.
      * We do this last because we want to maximise our chances of
diff --exclude='*~' -bru orig/dpkg-1.14.20/lib/dpkg-db.h dpkg-1.14.20/lib/dpkg-db.h
--- orig/dpkg-1.14.20/lib/dpkg-db.h 2008-06-18 08:33:27.000000000 +0100
+++ dpkg-1.14.20/lib/dpkg-db.h 2008-06-28 15:41:17.000000000 +0100
@@ -189,6 +189,7 @@
   /* Those marked with \*s*\ are possible returns from modstatdb_init. */
   msdbrw_readonly/*s*/, msdbrw_needsuperuserlockonly/*s*/,
   msdbrw_writeifposs,
+  msdbrw_simulate/*s*/, /* read only, but writes ignored not asserted */
   msdbrw_write/*s*/, msdbrw_needsuperuser,
   /* Now some optional flags: */
   msdbrw_flagsmask= ~077,
diff --exclude='*~' -bru orig/dpkg-1.14.20/lib/triglib.c dpkg-1.14.20/lib/triglib.c
--- orig/dpkg-1.14.20/lib/triglib.c 2008-06-18 08:33:27.000000000 +0100
+++ dpkg-1.14.20/lib/triglib.c 2008-06-28 15:45:23.000000000 +0100
@@ -664,9 +664,17 @@
 void
 trig_incorporate(enum modstatdb_rw cstatus, const char *admindir)
 {
+ static int simulation_done;
+
  int ur;
  enum trigdef_updateflags tduf;
 
+ if (cstatus == msdbrw_simulate) {
+ /* only incorporate once, as we're supposed to fold it into status */
+ if (simulation_done) return;
+ simulation_done= 1;
+ }
+
  trigdef = &tdm_incorp;
  trig_file_interests_ensure();
 
diff --exclude='*~' -bru orig/dpkg-1.14.20/src/archives.c dpkg-1.14.20/src/archives.c
--- orig/dpkg-1.14.20/src/archives.c 2008-06-18 08:33:31.000000000 +0100
+++ dpkg-1.14.20/src/archives.c 2008-06-28 15:41:17.000000000 +0100
@@ -1087,7 +1087,7 @@
   trigproc_install_hooks();
 
   modstatdb_init(admindir,
-                 f_noact ?                     msdbrw_readonly
+                 f_noact ?                     msdbrw_simulate
                : cipaction->arg == act_avail ? msdbrw_write
                : fc_nonroot ?                  msdbrw_write
                :                               msdbrw_needsuperuser);
diff --exclude='*~' -bru orig/dpkg-1.14.20/src/packages.c dpkg-1.14.20/src/packages.c
--- orig/dpkg-1.14.20/src/packages.c 2008-06-18 08:33:31.000000000 +0100
+++ dpkg-1.14.20/src/packages.c 2008-06-28 15:54:24.000000000 +0100
@@ -93,7 +93,7 @@
   trigproc_install_hooks();
 
   modstatdb_init(admindir,
-                 f_noact ?    msdbrw_readonly
+                 f_noact ?    msdbrw_simulate
                : fc_nonroot ? msdbrw_write
                :              msdbrw_needsuperuser);
   checkpath();
@@ -211,7 +211,12 @@
     action_todo = cipaction->arg;
 
     if (sincenothing++ > queue.length * 2 + 2) {
-      if (progress_bytrigproc && progress_bytrigproc->trigpend_head) {
+      if (progress_bytrigproc &&
+  (progress_bytrigproc->trigpend_head ||
+   (progress_bytrigproc->status >= stat_triggersawaited &&
+    progress_bytrigproc->othertrigaw_head))) {
+ debug(dbg_depcon, "using progress_bytrigproc %s instead of %s",
+      progress_bytrigproc->name, pkg->name);
         add_to_queue(pkg);
         pkg = progress_bytrigproc;
         action_todo = act_configure;
@@ -246,7 +251,8 @@
       /* Fall through. */
     case act_configure:
       /* Do whatever is most needed. */
-      if (pkg->trigpend_head)
+      if (pkg->trigpend_head ||
+  (pkg->status >= stat_triggersawaited && pkg->othertrigaw_head))
         trigproc(pkg);
       else
         deferred_configure(pkg);
@@ -389,7 +395,7 @@
        * anyway, and that trigger processing will be a noop except for
        * sorting out all of the packages which name it in T-Awaited.
        *
-       * (This situation can only arise if modstatdb_note success in
+       * (This situation can only arise if modstatdb_note succeeds in
        * clearing the triggers-pending status of the pending package
        * but then fails to go on to update the awaiters.)
        */
@@ -609,8 +615,13 @@
   }
   if (ok == 0 && (pkg->clientdata && pkg->clientdata->istobe == itb_remove))
     ok= 1;
-  if (!anycannotfixbytrig && canfixbytrig)
+
+  if (!anycannotfixbytrig && canfixbytrig) {
+    debug(dbg_depcon, "progress_bytrigproc %s (was %s)",
+  canfixbytrig->name,
+  progress_bytrigproc ? progress_bytrigproc->name : "<none>");
     progress_bytrigproc = canfixbytrig;
+  }
   
   varbuffree(&oemsgs);
   debug(dbg_depcon,"ok %d msgs >>%.*s<<", ok, (int)aemsgs->used, aemsgs->buf);
diff --exclude='*~' -bru orig/dpkg-1.14.20/src/trigproc.c dpkg-1.14.20/src/trigproc.c
--- orig/dpkg-1.14.20/src/trigproc.c 2008-05-05 18:07:01.000000000 +0100
+++ dpkg-1.14.20/src/trigproc.c 2008-06-28 15:47:05.000000000 +0100
@@ -288,6 +288,7 @@
  printf(_("Processing triggers for %s ...\n"), pkg->name);
  log_action("trigproc", pkg);
 
+ if (!f_noact) {
  varbufreset(&namesarg);
  for (tp = pkg->trigpend_head; tp; tp = tp->next) {
  varbufaddc(&namesarg, ' ');
@@ -301,6 +302,7 @@
  sincenothing = 0;
  maintainer_script_postinst(pkg, "triggered",
                            namesarg.buf + 1, NULL);
+ }
 
  /* This is to cope if the package triggers itself: */
  pkg->status = pkg->trigaw.head ? stat_triggersawaited :
diff --exclude='*~' -bru orig/dpkg-1.14.20/src/update.c dpkg-1.14.20/src/update.c
--- orig/dpkg-1.14.20/src/update.c 2008-05-05 18:07:01.000000000 +0100
+++ dpkg-1.14.20/src/update.c 2008-06-28 15:41:17.000000000 +0100
@@ -101,7 +101,7 @@
 
   if (*argv) badusage(_("--forget-old-unavail takes no arguments"));
 
-  modstatdb_init(admindir, f_noact ? msdbrw_readonly : msdbrw_write);
+  modstatdb_init(admindir, f_noact ? msdbrw_simulate : msdbrw_write);
 
   it= iterpkgstart();
   while ((pkg= iterpkgnext(it))) {
Only in dpkg-1.14.20: x.gdb



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Wed, 02 Jul 2008, Ian Jackson wrote:
> I've reproduced the problem from #143307 and attached is a fix.

Thanks!

> The core of the problem was that if dpkg is interrupted, you can have
> the following situation:
>
>     Package: a
>     Triggers-Awaited: b
>
>     Package: b
>     Status: ... installed

So it's exactly the same situation as in #487637, #489068. Looks like both
are correlated after all.

> In the patch below I also fix --no-act for trigger processing, which
> was previously broken.  This was somewhat more complex than ideal

Well, I have split the patch in two:
http://git.debian.org/?p=users/hertzog/dpkg.git;a=shortlog;h=refs/heads/pu/bug143307-triggers-and-dependtry

First the fix itself:
http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;h=0b8fcd1bb166e75a8016030ca7625f8c899afc71
I intent to push this to lenny (1.14.21) after some tests.

Then the --no-act fix which should probably only go in master.
http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;h=4073a72477be5fac51125ab1474f91d6b98654b3

I added the indenting that you didn't add when adding new enclosing
if (!f_noact)  (or similar).

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Thu, 03 Jul 2008, Raphael Hertzog wrote:
> >     Package: a
> >     Triggers-Awaited: b
> >
> >     Package: b
> >     Status: ... installed
>
> So it's exactly the same situation as in #487637, #489068. Looks like both
> are correlated after all.

But I confirm that the patch doesn't fix those bugs. Supplementary changes
are needed in packages() to add the package in triggerawaited status to
the process queue. But deferred_configure() probably also needs to be
changed.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

(Switching from bug 143307 to 487637)

On Thu, 03 Jul 2008, Raphael Hertzog wrote:

> On Thu, 03 Jul 2008, Raphael Hertzog wrote:
> > >     Package: a
> > >     Triggers-Awaited: b
> > >
> > >     Package: b
> > >     Status: ... installed
> >
> > So it's exactly the same situation as in #487637, #489068. Looks like both
> > are correlated after all.
>
> But I confirm that the patch doesn't fix those bugs. Supplementary changes
> are needed in packages() to add the package in triggerawaited status to
> the process queue. But deferred_configure() probably also needs to be
> changed.

I tried to come up with a patch, see below. The nicest solution I found
was to detect packages in triggerawaited status if we were asked to
configure them, and to add to the process queue the packages that are
providing the triggers (those listed in pkg->trigaw.head->pend). The
changes you made, let process_queue() call trigproc() which will call
trig_clear_awaiters() and resolve the situation.

There are two problems where I'd welcome your input:
- if we have an explicit list of packages to configure, I'm not respecting
  --force-configure-any and will blindly add the packages providing the
  triggers to the queue
- there's no feedback to the user that something has been done, it just
  silently fixes the status of the packages, I'm not sure where that
  feedback could/should be added.

I tested the patch here and it successfully resolves the situation
above with dpkg --configure -a.

diff --git a/src/packages.c b/src/packages.c
index 25395c4..ef72e96 100644
--- a/src/packages.c
+++ b/src/packages.c
@@ -108,6 +108,16 @@ void packages(const char *const *argv) {
     while ((pkg = iterpkgnext(it)) != NULL) {
       switch (cipaction->arg) {
       case act_configure:
+        if (pkg->status == stat_triggersawaited) {
+  /* The only way to configure packages in this status is by
+   * processing the trigger of the corresponding package */
+          struct trigaw *ta = pkg->trigaw.head;
+  while(ta) {
+    add_to_queue(ta->pend);
+    ta = ta->sameaw.next;
+  }
+  continue;
+ }
         if (!(pkg->status == stat_unpacked ||
               pkg->status == stat_halfconfigured ||
               pkg->trigpend_head))
@@ -150,6 +160,18 @@ void packages(const char *const *argv) {
           badusage(_("you must specify packages by their own names,"
                    " not by quoting the names of the files they come in"));
       }
+      if ((cipaction->arg == act_configure) &&
+  (pkg->status == stat_triggersawaited)) {
+ /* The only way to configure packages in this status is by
+ * processing the trigger of the corresponding package */
+ /* TODO: shall we respect --force-configure-any here ? */
+ struct trigaw *ta = pkg->trigaw.head;
+ while(ta) {
+  add_to_queue(ta->pend);
+  ta = ta->sameaw.next;
+ }
+ continue;
+      }
       add_to_queue(pkg);
     }
 
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

Raphael Hertzog writes ("Re: Bug#143307: triggers-related dependtry assertion fix"):
> So it's exactly the same situation as in #487637, #489068. Looks like both
> are correlated after all.

I think #487637 is something else, as I said.

Do you have a /var/lib/dpkg/ for #489068 ?

> Then the --no-act fix which should probably only go in master.
> http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;h=4073a72477be5fac51125ab1474f91d6b98654b3

I think the --no-act fix should go in lenny.  Failing that we need at
the very least a safety catch which stops it actually trying to do
things.  It will currently fail assertions and might even actually try
to execute something.

> I added the indenting that you didn't add when adding new enclosing
> if (!f_noact)  (or similar).

Oh, perhaps I gave you the output of diff -b.  Sorry.

Ian.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

Raphael Hertzog writes ("Re: Bug#487637: config of triggers-awaited packages"):
> (Switching from bug 143307 to 487637)
> There are two problems where I'd welcome your input:

Thanks for looking at this.  I don't have time to do anything in
detail now but will take a look at the weekend.

> - there's no feedback to the user that something has been done, it just
>   silently fixes the status of the packages, I'm not sure where that
>   feedback could/should be added.

I think it's OK to fix up triggers-awaited packages silently.
triggers-awaited is just bookkeeping.

Re your other question about explicit lists --force-trigger-any, etc.,
I will have to reread the spec and think about it.

Ian.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Thu, 03 Jul 2008, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: Bug#143307: triggers-related dependtry assertion fix"):
> > So it's exactly the same situation as in #487637, #489068. Looks like both
> > are correlated after all.
>
> I think #487637 is something else, as I said.

It could be explained by this scenario:
- dpkg installed and is triggers-awaited on man-db
- man-db trigger runs and fills up the few remaining bytes
- status file is synchronized and drops the triggers-pending from man-db
- dpkg aborts on some other operations due to lack of space

> Do you have a /var/lib/dpkg/ for #489068 ?

I kept a copy of the status file, yes. It's attached. Right now the sid
chroot of casals.d.o is still in the same state.
/var/lib/dpkg/triggers/Unincorp is empty, as is /var/lib/dpkg/updates/.

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/

[Raphael Hertzog-3]

On Thu, 03 Jul 2008, Ian Jackson wrote:
> > Then the --no-act fix which should probably only go in master.
> > http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;h=4073a72477be5fac51125ab1474f91d6b98654b3
>
> I think the --no-act fix should go in lenny.  Failing that we need at
> the very least a safety catch which stops it actually trying to do
> things.  It will currently fail assertions and might even actually try
> to execute something.

Can you expand on why you decided to create a msdbrw_simulate status then
as opposed to using modstatdb_note_ifwrite() in the problematic cases
in the trigger code ?

And why didn't you update the check in modstatdb_note_ifwrite() as well ?

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

On Thu, 03 Jul 2008, Ian Jackson wrote:

> Raphael Hertzog writes ("Re: Bug#487637: config of triggers-awaited packages"):
> > (Switching from bug 143307 to 487637)
> > There are two problems where I'd welcome your input:
>
> Thanks for looking at this.  I don't have time to do anything in
> detail now but will take a look at the weekend.
>
> > - there's no feedback to the user that something has been done, it just
> >   silently fixes the status of the packages, I'm not sure where that
> >   feedback could/should be added.
>
> I think it's OK to fix up triggers-awaited packages silently.
> triggers-awaited is just bookkeeping.
>
> Re your other question about explicit lists --force-trigger-any, etc.,
> I will have to reread the spec and think about it.

Ping ?

Cheers,
--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Raphael Hertzog-3]

Hi Ian,

you also forgot to reply to this mail:

On Fri, 04 Jul 2008, Raphael Hertzog wrote:

> On Thu, 03 Jul 2008, Ian Jackson wrote:
> > > Then the --no-act fix which should probably only go in master.
> > > http://git.debian.org/?p=users/hertzog/dpkg.git;a=commitdiff;h=4073a72477be5fac51125ab1474f91d6b98654b3
> >
> > I think the --no-act fix should go in lenny.  Failing that we need at
> > the very least a safety catch which stops it actually trying to do
> > things.  It will currently fail assertions and might even actually try
> > to execute something.
>
> Can you expand on why you decided to create a msdbrw_simulate status then
> as opposed to using modstatdb_note_ifwrite() in the problematic cases
> in the trigger code ?
>
> And why didn't you update the check in modstatdb_note_ifwrite() as well ?
>
> Cheers,
> --
> Raphaël Hertzog
>
> Le best-seller français mis à jour pour Debian Etch :
> http://www.ouaza.com/livre/admin-debian/
>
>
>

--
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

Raphael Hertzog writes ("Re: Bug#143307: triggers-related dependtry assertion fix"):
> Can you expand on why you decided to create a msdbrw_simulate status then
> as opposed to using modstatdb_note_ifwrite() in the problematic cases
> in the trigger code ?

Various other bits of the code need to know the simulation status too
- for example, the triggers code mustn't think it has incorporated
triggers permanently and remove them from Deferred.  This was most
easily achieved by encoding it in the msdbrw.

Also, to be honest, I think I didn't like the way I had done it
before.  Having an explicitly simulating mode for the dbmodify
machinery seems to make more sense, particularly as that machinery has
gained more semantic knowledge and its data is spread across more
files.

> And why didn't you update the check in modstatdb_note_ifwrite() as well ?

This was a mistake.

For the two calls in question, in triglib.c, there is no actual
difference in the current code except that _ifwrite won't do the
logging and status fd reporting, which we _do_ want done.

So _ifwrite should say
   if (cstatus >= msdbrw_simulate)

(I don't think this is a particularly important case but it's also
pretty harmless to push into a stable tree now.)

Ian.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...

[Ian Jackson]

Raphael Hertzog writes ("Re: Bug#487637: config of triggers-awaited packages"):
> (Switching from bug 143307 to 487637)
...
> I tried to come up with a patch, see below. The nicest solution I found
> was to detect packages in triggerawaited status if we were asked to
> configure them, and to add to the process queue the packages that are
> providing the triggers (those listed in pkg->trigaw.head->pend). The
> changes you made, let process_queue() call trigproc() which will call
> trig_clear_awaiters() and resolve the situation.

I can see what you're doing here but I think your patch has convinced
me that we should take a different approach than the one I took in my
previous patch for 143307 (sorry!).

As I previously commented, the problem was this state:
> > >     Package: a
> > >     Triggers-Awaited: b
> > >
> > >     Package: b
> > >     Status: ... installed

This can only arise due to incompletely written changes to the on-disk
status databases, because for the brief moments it is like this in
dpkg's core itself onerr_abort is set.

So instead of doing a null trigger processing step for b, why not
simply forget about the triggers-awaited for a ?  After all b's
trigger processing must have succeeded earlier.

This should probably be done in trig_incorporate.

On the plus side this would be much less code than my previous patch
and your fixup to it.

Ian.



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...