Please allow shadow in testing

[Christian Perrier <bubulle@debian.org>]

Dear release managers,

The shadow package got a RC bug reported yesterday (299549) and I made
a high urgency upload to fix it. This was a broken woody->sarge
upgrade bug (in some situations) so it deserved of course immediate
attention.

I used this opportunity to finally and officially take over the
package as annouced numerous times.

Could you please hint the package to enter testing as soon as built on
all arches?


I know that the double upload which occurrend yesterday probably made
some of you worry about my mental health and I owe a few
explanations...:-)

Yes, I uploaded the package twice with the followiong changelog:

shadow (1:4.0.3-31sarge1) unstable; urgency=high

  * Urgency set to high because of RC bug fixed. Reuploaded
    because I messed up with the changelog first. Use this occasion
    to start a sarge series just in case. Changes below were made
    in the former version already.
  * Avoid package file conflicts for woody->sarge upgrade:
    - Add manpages-it and manpages-ko to Replaces: for login
    - Remove manpages-de from Replaces: for login (useless)
    - Improve readability of the Replaces line for passwd
    Closes: #299549

 -- Christian Perrier <bubulle@debian.org>  Tue, 15 Mar 2005 13:55:34 +0100

shadow (1:4.0.3-31) unstable; urgency=low

  * New maintainer

 -- Christian Perrier <bubulle@debian.org>  Fri, 11 Mar 2005 19:28:38 +0100


This may sound as a gratuitous upload to bump the package urgency as
pointed recently in a thread, which I read un understood..:-)).

Indeed, I made the upload because I first messed in the 4.0.3-31
release:
  - I want to use a special version numering system for sarge-targeted
    releases and I forgot to do so in my build
  - The -1 release indeed fixed what mentioned above : the RC bug. But
    I forgot to mention it in the changelog
  - the urgency was wrongly set to low

So, technically speaking, the -1 release had all I wanted to put in
it, but its changelog was wrong about it.

I realized that very quickly (a few hours) after uploading and thus I
decided to immediately build and upload a fixed version, with the
reasoning that no buildd would have started to build it. The delay was
a bit longer than expected because I realized this during my paid work
time and I had to first give priority to my paid work of course..:)


I did the double upload because I thought that buildd start working on
packages from the archive and not immediately from packages in
ACCEPTED. Colin corrected me on that point and now I'll be aware of
it.


I think that indeed the buildd probably did not start building the
first version (unchecked), as it was there only for 3-4 hours, so the
real harm was probably not very high.

Of course, I understand this may have sounded strange, or even
braindead, for some people, and I apologize for this.

I really hope this did not trigger extra work for anyone (we have
enough work to do besides silly mistakes) and if it did, please use ++
in your beer count for debconf or our next real life meeting.