Setting up gpm (1.20.4-3.1) ...
invoke-rc.d: ----------------------------------------------------
invoke-rc.d: WARNING: invoke-rc.d called during shutdown sequence
invoke-rc.d: enabling safe mode: initscript policy layer disabled
invoke-rc.d: ----------------------------------------------------
 * Stopping mouse interface server gpm
O0o.oops(): [daemon/check_kill.c(42)]: Problem reading from /var/run/gpm.pid
[fail]
 * Starting mouse interface server gpm
[fail]
invoke-rc.d: initscript gpm, action "restart" failed.
dpkg: error processing gpm (--configure):
 subprocess post-installation script returned error exit status 1
Errors were encountered while processing:
 gpm
E: Sub-process /usr/bin/dpkg returned an error code (1)

*****

As the above shows, even though GPM's init script correctly calls invoke-rc.d,
the source code itself insists upon seeing a real usable pid number in the file,
even though this is not something that's gonna appear when unpacking packages in
a chroot, such as when preparing a filesystem image for copying to JFFS2.

- -- System Information:
Debian Release: 5.0.2
  APT prefers stable
  APT policy: (990, 'stable')
Architecture: i386 (i686)

Kernel: Linux 2.6.26-2-686 (SMP w/1 CPU core)
Locale: LANG=fi_FI.UTF-8, LC_CTYPE=fi_FI.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages gpm depends on:
ii  debconf [debconf-2.0]         1.5.24     Debian configuration management sy
ii  debianutils                   2.30       Miscellaneous utilities specific t
ii  libc6                         2.7-18     GNU C Library: Shared libraries
ii  libgpm2                       1.20.4-3.1 General Purpose Mouse - shared lib
ii  lsb-base                      3.2-20     Linux Standard Base 3.2 init scrip
ii  ucf                           3.0016     Update Configuration File: preserv

gpm recommends no packages.

gpm suggests no packages.

- -- debconf information:
* gpm/responsiveness:
* gpm/repeat_type: none
* gpm/append:
* gpm/restart: true
* gpm/sample_rate:
* gpm/device: /dev/input/mice
* gpm/type: exps2
iEYEARECAAYFAkp8NrsACgkQeXr56x4Muc2JnQCfdo5k1PI0am/7MGSlbNYEwwvu
vT8An0ygJigtLgOU5I0hgOoEIFQk1lnI
=1wkN
-----END PGP SIGNATURE-----

Good morning,

Martin-Éric Racine [Fri, Aug 07, 2009 at 05:14:21PM +0300]:

Sure it does. How should gpm be able to see whether it's running or not else?

I guess alot other daemons also do this, so I'm a bit wondering why
this problem with Debian comes up now.

I'm a bit tired, but way more confused about this bug in general:

Why should a any software care about that problem?

And why is gpm started in this environment at el?

Maybe I'm missing some Debian magic, but for an installation there's
no requirement to start it.

Greetings from the airport,

Nico

Good morning,

Martin-Éric Racine [Fri, Aug 07, 2009 at 05:14:21PM +0300]:

Sure it does. How should gpm be able to see whether it's running or not else?

I guess alot other daemons also do this, so I'm a bit wondering why
this problem with Debian comes up now.

I'm a bit tired, but way more confused about this bug in general:

Why should a any software care about that problem?

And why is gpm started in this environment at el?

Maybe I'm missing some Debian magic, but for an installation there's
no requirement to start it.

Greetings from the airport,

Nico

A policy-rc.d preventing invoke-rc.d to act on the service while
preparing the chroot would likely be useful, but the fallback code in
https://anonscm.debian.org/git/collab-maint/gpm.git/tree/debian/gpm.prerm
will likely end up using the fallbacks and thus causing warnings/errors
to occur. Possibly this could be improved to not use the fallback
if policy-rc.d says if service actions are disabled.

Regards,
Andreas Henriksson