Bug#716880: apache2 upgrade failed

2014-02-11 Thread Heiko Fiergolla { xmachina
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello,

I have the same problem on two different wheezy hosts with aptitude
safe-upgrade (both fresh installed wheezys and no distupgrade from
squeeze) and the package libapache2-svn was, and is, not installed on
both hosts.
But I have other fresh installed Wheezy Hosts without upgrade Problems.


i.e. the mistaken safe-upgrade
(...)
Setting up apache2-utils (2.2.22-13+deb7u1) ...
Setting up apache2.2-bin (2.2.22-13+deb7u1) ...
Setting up apache2.2-common (2.2.22-13+deb7u1) ...
insserv: Service slapd has to be enabled to start service apache2
insserv: exiting now!
update-rc.d: error: insserv rejected the script header
dpkg: error processing apache2.2-common (--configure):
 subprocess installed post-installation script returned error exit
status 1
dpkg: dependency problems prevent configuration of apache2-mpm-itk:
 apache2-mpm-itk depends on apache2.2-common (= 2.2.22-13+deb7u1);
however:
  Package apache2.2-common is not configured yet.

dpkg: error processing apache2-mpm-itk (--configure):
 dependency problems - leaving unconfigured
Setting up openssl (1.0.1e-2+deb7u4) ...
Errors were encountered while processing:
 apache2.2-common
 apache2-mpm-itk
E: Sub-process /usr/bin/dpkg returned an error code (1)


# aptitude reinstall apache2.2-common
Die folgenden Pakete werden ERNEUT INSTALLIERT:
  apache2.2-common
Die folgenden teilweise installierten Pakete werden konfiguriert:
  apache2-mpm-itk
0 Pakete aktualisiert, 0 zusätzlich installiert, 1 erneut installiert,
0 werden entfernt und 0 nicht aktualisiert.
0 B an Archiven müssen heruntergeladen werden. Nach dem Entpacken
werden 0 B zusätzlich belegt sein.
E: Internal Error, No file name for apache2.2-common:i386

# apache2ctl fullstatus
(...)
   Server Version: Apache/2.2.22 (Debian) mod_ssl/2.2.22 OpenSSL/1.0.1e
   Server Built: Jan 31 2014 18:55:42
(...)


- -- System Information:
Debian Release: 7.4
  APT prefers stable-updates
  APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2.2-common depends on:
ii  apache2-utils  2.2.22-13+deb7u1
ii  apache2.2-bin  2.2.22-13+deb7u1
ii  lsb-base   4.1+Debian8+deb7u1
ii  mime-support   3.52-1
ii  perl   5.14.2-21+deb7u1
ii  procps 1:3.3.3-3

Versions of packages apache2.2-common recommends:
ii  ssl-cert  1.0.32

Versions of packages apache2.2-common suggests:
pn  apache2-doc none
pn  apache2-suexec | apache2-suexec-custom  none
ii  lynx-cur [www-browser]  2.8.8dev.12-2
ii  w3m [www-browser]   0.5.3-8

Versions of packages apache2.2-common is related to:
pn  apache2-mpm-eventnone
iu  apache2-mpm-itk  2.2.22-13+deb7u1
pn  apache2-mpm-prefork  none
pn  apache2-mpm-worker   none


And a system where the upgrade runs fine.

   Server Version: Apache/2.2.22 (Debian) DAV/2 mod_ssl/2.2.22
  OpenSSL/1.0.1e
   Server Built: Jan 31 2014 18:55:42

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

Kernel: Linux 3.2.0-4-686-pae (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages apache2.2-common depends on:
ii  apache2-utils  2.2.22-13+deb7u1
ii  apache2.2-bin  2.2.22-13+deb7u1
ii  lsb-base   4.1+Debian8+deb7u1
ii  mime-support   3.52-1
ii  perl   5.14.2-21+deb7u1
ii  procps 1:3.3.3-3

Versions of packages apache2.2-common recommends:
ii  ssl-cert  1.0.32

Versions of packages apache2.2-common suggests:
pn  apache2-doc none
pn  apache2-suexec | apache2-suexec-custom  none
ii  lynx-cur [www-browser]  2.8.8dev.12-2
ii  w3m [www-browser]   0.5.3-8

Versions of packages apache2.2-common is related to:
pn  apache2-mpm-eventnone
ii  apache2-mpm-itk  2.2.22-13+deb7u1
pn  apache2-mpm-prefork  none
pn  apache2-mpm-worker   none

Regards,
Heiko
- -- 
   {
  { Heiko Fiergolla, Systembetrieb
  { E-Mail heiko.fiergo...@xmachina.de
  { Telefon +49-6221-8220-48 Fax +49-8220-40
  { xmachina GmbH advancing e-business

  { Maaßstraße 24 D-69123 Heidelberg
  { http://www.xmachina.de
  { Registergericht Mannheim 335935
  { Geschäftsführer: Klaus Mueller, Michael Grüterich
   {
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iEYEARECAAYFAlL6B9gACgkQYX7URpS5/quN7gCfdYHI1T0achr9OqGhUzYyQLYs
rncAoIK1CP3hLxj/pqvaiYV9mTj8owMg
=KKhM
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-08-11 Thread Stefan Fritsch
Am Mittwoch, 7. August 2013, 20:39:25 schrieb Julian Gilbey:
 Or are you saying that a Breaks would be needed on every depending
 package in stable?

We would also need to add breaks for all packages depending on 
apache2.2-common that have been in Debian since Debian etch and have 
been removed in the mean-time. Users may still have those packages 
installed and they need to be removed on upgrade.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-08-11 Thread Julian Gilbey
On Sun, Aug 11, 2013 at 11:50:09AM +0200, Stefan Fritsch wrote:
 Am Mittwoch, 7. August 2013, 20:39:25 schrieb Julian Gilbey:
  Or are you saying that a Breaks would be needed on every depending
  package in stable?
 
 We would also need to add breaks for all packages depending on 
 apache2.2-common that have been in Debian since Debian etch and have 
 been removed in the mean-time. Users may still have those packages 
 installed and they need to be removed on upgrade.

Interesting.  That may take a little bit more effort to locate.  We
should also ideally go through contrib and non-free.

   Julian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-08-07 Thread Julian Gilbey
On Sun, Jul 14, 2013 at 02:39:41PM +0200, Arno Töll wrote:
   * The only way to ship a package named apache2.2-common is to add a
 Breaks header listing every single reverse dependency with correct
 version information.
 
 That would be 100+ Breaks. I do not think that is feasible but that may
 need a wider discussion.

How did you reach that conclusion?  I looked at the current testing
distribution, and the only direct dependency on apache2.2-common is
libapache2-svn, which may go away when subversion is able to
transition to testing.

Or are you saying that a Breaks would be needed on every depending
package in stable?  That is a larger number (66 in main), consisting
only of libapache2-* modules.  It seems a bit of a hassle to have to
list almost all of these as Breaks (7 have precisely versioned Depends
so won't need it), but it's a one-off hassle; one could simply take
the current versions of these packages in testing (where they exist)
or specify that they break all versions (where they have been removed
from unstable/testing).  The hard cases are the five packages which
have still not been fixed to deal with apache2.4 but are still in
unstable.

A list of all of these is below.

Also, it is important to realise that without a dependency from
apache2.4 on apache2.2-common, apache2.2-common could be purged by
apt(itude) before the first apache2.4 package is even unpacked:
looking at my dpkg log, this is exactly what happened.  So the
mechanism in apache2.2-common.postrm of checking for
/etc/apache2/upgrade-to-2.4-in-progress doesn't provide any benefit in
this case :-(

So it seems like having a dependency on a dummy apache2.2-common would
be the sensible (if annoying) thing to do.


Anyhow, here's that list of packages which apache2.2-common
could/should Break:

apache2-suexec ( 2.4.6-2)
apache2-suexec-custom ( 2.4.6-2)
libapache2-mod-apparmor ( 2.8.0-1+b1)
libapache2-mod-apreq2 ( 2.13-2.1)
libapache2-mod-auth-cas ( 1.0.9.1-4)
libapache2-mod-auth-kerb ( 5.4-2.1)
libapache2-mod-auth-memcookie ( 1.0.2-8)
libapache2-mod-auth-ntlm-winbind ( 0.0.0.lorikeet+svn+801-4)
libapache2-mod-auth-openid ( 0.7-1)
libapache2-mod-auth-plain ( 2.0.52)
libapache2-mod-auth-pubtkt ( 0.8-3)
libapache2-mod-auth-radius ( 1.5.8-1.2)
libapache2-mod-auth-tkt ( 2.1.0-8)
libapache2-mod-authnz-external ( 3.3.1-0.1)
libapache2-mod-authz-unixgroup ( 1.1.0-0.1)
libapache2-mod-bw ( 0.92-9)
libapache2-mod-dacs ( 1.4.28b-3)
libapache2-mod-defensible ( 1.4-3.1)
libapache2-mod-encoding ( 20040616-5.2)
libapache2-mod-evasive ( 1.10.1-2)
libapache2-mod-fcgid ( 1:2.3.7-0.1)
libapache2-mod-geoip ( 1.2.8-2)
libapache2-mod-jk ( 1:1.2.37-2)
libapache2-mod-ldap-userdir ( 1.1.19-2.1)
libapache2-mod-lisp ( 1.3.1-1.3)
libapache2-mod-macro ( 1:2.4.6-2)
libapache2-mod-mono ( 2.11+git20130708.6b73e85-2)
libapache2-mod-nss ( 1.0.8-3)
libapache2-mod-ocamlnet ( 3.5.1-2)
libapache2-mod-parser3 ( 3.4.2-7)
libapache2-mod-perl2 ( 2.0.8+httpd24-r1449661-5)
libapache2-mod-php5 ( 5.5.1+dfsg-1)
libapache2-mod-php5filter ( 5.5.1+dfsg-1)
libapache2-mod-proxy-html ( 1:2.4.6-2)
libapache2-mod-python ( 3.3.1-11)
libapache2-mod-qos ( 10.16-1)
libapache2-mod-removeip ( 1.0b-5.1)
libapache2-mod-scgi ( 1.13-1.1)
libapache2-mod-spamhaus ( 0.7-1.1)
libapache2-mod-suphp ( 0.7.1-3.1)
libapache2-mod-upload-progress ( 0.2-2)
libapache2-mod-vhost-ldap ( 2.4.0-1)
libapache2-mod-wsgi ( 3.4-3+b1)
libapache2-mod-wsgi-py3 ( 3.4-3+b1)
libapache2-mod-xsendfile ( 0.12-2)
libapache2-modsecurity ( 2.7.4-1)
libapache2-webauth ( 4.5.3-5)
libapache2-webkdc ( 4.5.3-5)


The following have been removed from unstable, so we can Break all
versions:

libapache2-mod-auth-pam
libapache2-mod-auth-sys-group
libapache2-mod-layout
libapache2-mod-random
libapache2-mod-speedycgi 
libapache2-mod-vhost-hash-alias


Packages still in unstable but not yet ready for apache 2.4:

The version for libapache-svn is assuming that no future version will
reintroduce the dependency on apache2.2-common;
the version for libapache2-mod-ruby assumes that the bugs will
actually be fixed and that it won't be dropped from Debian completely;
the versions for the others are for the version beyond the one
currently in unstable, assuming that the next version will close the
bug (though that may be overly hopeful).

libapache2-mod-musicindex ( 1.3.7-3)
libapache2-svn ( 1.7.9-1+nmu3)
libapache2-mod-auth-pgsql ( 2.0.3-6)
libapache2-mod-auth-mysql ( 4.3.9-13.2)
libapache2-mod-ruby ( 1.2.6-3)


   Julian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-08-07 Thread Arno Töll
On 07.08.2013 21:39, Julian Gilbey wrote:
 On Sun, Jul 14, 2013 at 02:39:41PM +0200, Arno Töll wrote:
  * The only way to ship a package named apache2.2-common is to add a
Breaks header listing every single reverse dependency with correct
version information.

 That would be 100+ Breaks. I do not think that is feasible but that may
 need a wider discussion.
 
 How did you reach that conclusion?  I looked at the current testing
 distribution, and the only direct dependency on apache2.2-common is
 libapache2-svn, which may go away when subversion is able to
 transition to testing.

It's one now. :)

It was the state as of Squeeze at the time I wrote this as we were in
the middle of the transition. Now we can seriously consider doing the
transition package approach.

 Also, it is important to realise that without a dependency from
 apache2.4 on apache2.2-common, apache2.2-common could be purged by
 apt(itude) before the first apache2.4 package is even unpacked:
 looking at my dpkg log, this is exactly what happened.  So the
 mechanism in apache2.2-common.postrm of checking for
 /etc/apache2/upgrade-to-2.4-in-progress doesn't provide any benefit in
 this case :-(

Right. That's also why we do not use this trapdoor in maintainer scripts.

 So it seems like having a dependency on a dummy apache2.2-common would
 be the sensible (if annoying) thing to do.

Thanks for this list. I'm short of time for the next 2-4 weeks, and
unless sf beats me with it I will address all the outstanding Apache
packaging issues then (or try to find a feasible solution at least).

-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature


Bug#716880: apache2 upgrade failed

2013-08-07 Thread Julian Gilbey
On Wed, Aug 07, 2013 at 10:07:28PM +0200, Arno Töll wrote:
  That would be 100+ Breaks. I do not think that is feasible but that may
  need a wider discussion.
  
  How did you reach that conclusion?  I looked at the current testing
  distribution, and the only direct dependency on apache2.2-common is
  libapache2-svn, which may go away when subversion is able to
  transition to testing.
 
 It's one now. :)
 
 It was the state as of Squeeze at the time I wrote this as we were in
 the middle of the transition. Now we can seriously consider doing the
 transition package approach.

Ah ;-)

  So it seems like having a dependency on a dummy apache2.2-common would
  be the sensible (if annoying) thing to do.
 
 Thanks for this list. I'm short of time for the next 2-4 weeks, and
 unless sf beats me with it I will address all the outstanding Apache
 packaging issues then (or try to find a feasible solution at least).

Pleasure!  It will help others not suffer the (minor) losses which I
had, which might be more major for them (I was on a non-server
machine which only used apache for local use).

   Julian


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-07-14 Thread Helmut Grohne
Control: severity -1 important

Thanks for the detailed log, because it highlights the cause.

On Sun, Jul 14, 2013 at 01:51:55AM +0200, Vincent Lefevre wrote:
 Purging configuration files for apache2.2-common ...
 dpkg: warning: while removing apache2.2-common, directory '/usr/lib/cgi-bin' 
 not empty so not removed
 dpkg: warning: while removing apache2.2-common, directory '/var/log/apache2' 
 not empty so not removed
 dpkg: warning: while removing apache2.2-common, directory '/var/www' not 
 empty so not removed

You are likely using --purge-unused something similar causing the no
longer needed package apache2.2-common to be purged. It is removed and
purged very early during the upgrade. Unfortunately this package
contains your apache configuration. At the time apache2 is upgraded, it
notices there is no configuration left and fails. The issue here is not
that the upgrade fails, but that your configuration vanishes. Papering
over purged configuration in apache2's postinst is not a solution. As a
first measure don't upgrade with --purge-unused. I am downgrading the
severity, because it only happens when you purge packages during
upgrade.

As far as I can tell the only way to fix this issue is to introduce a
transitional apache2.2-common package containing no files. apache2 would
need to depend on apache2.2-common for one release (skipping a release
is not supported). This would ensure that apache2.2-common is not purged
during upgrades. After one release the transitional package can be
dropped.

Helmut


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-07-14 Thread Arno Töll
Hi,

On 14.07.2013 09:47, Helmut Grohne wrote:
 As far as I can tell the only way to fix this issue is to introduce a
 transitional apache2.2-common package containing no files. apache2 would
 need to depend on apache2.2-common for one release (skipping a release
 is not supported). 

we cannot do this as long as the transition is ongoing. Sadly lots of
packages reverse-depends on on apache2.2-common. Satisfying this
dependency would create (even more) havoc on such systems as apt would
not force a removal of packages depending ob not provided ABIs.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-07-14 Thread Helmut Grohne
On Sun, Jul 14, 2013 at 11:50:55AM +0200, Arno Töll wrote:
 we cannot do this as long as the transition is ongoing. Sadly lots of
 packages reverse-depends on on apache2.2-common. Satisfying this
 dependency would create (even more) havoc on such systems as apt would
 not force a removal of packages depending ob not provided ABIs.

I do not see how the transition is affecting this option. If it breaks
during the transition, it can also break a partial upgrade. Introducing
apache2.2-common later can cause a broken wheezy-jessie upgrade when a
user fails to upgrade the corresponding apache module. Is this correct
or am I missing something?

So as far as I can tell the only way to reintroduce apache2.2-common
would be to add a huge pile for Breaks. I am not claiming that this is
feasible. Long breaks headers tend to confuse apt/aptitude during large
upgrades and might make things worse. Updating release notes to tell
people not to purge apache2.2-common might simply be the best option.

Helmut


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-07-14 Thread Arno Töll
On 14.07.2013 12:08, Helmut Grohne wrote:
 I do not see how the transition is affecting this option. If it breaks
 during the transition, it can also break a partial upgrade. Introducing
 apache2.2-common later can cause a broken wheezy-jessie upgrade when a
 user fails to upgrade the corresponding apache module. Is this correct
 or am I missing something?

Pretending we provided apache2.2-common, modules depending on the 2.2
version of the server had their depdencies satisfied. Thus, they would
be co-installable with Apache 2.4, they would migrate to Testing and so on.

However, if you try to enable such a module, it breaks the whole server
which fails to start as there will be symbol lookup errors at runtime.

We could possibly discuss your suggestion as soon as nothing in Debian
depends on apache2.2-common anymore, but for now that just adds more havoc.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature


Bug#716880: apache2 upgrade failed

2013-07-14 Thread Helmut Grohne
On Sun, Jul 14, 2013 at 12:14:04PM +0200, Arno Töll wrote:
 Pretending we provided apache2.2-common, modules depending on the 2.2
 version of the server had their depdencies satisfied. Thus, they would
 be co-installable with Apache 2.4, they would migrate to Testing and so on.

My point was that if modules had their dependencies satisfied in such a
way, then dependencies are wrong even for a wheezy - jessie upgrade,
because as you later point out it would break the whole server.

Following this reasoning the only way to reintroduce apache2.2-common
would be to add tons of Breaks. Since britney honours Breaks, it would
keep blocking the transition. This assumes that all Breaks are correct
and we all know how easy it is to get them wrong. So again I am not
claiming it to be feasible, but I am claiming that there is no other way
to solve the matter reported on a technical level.

In summary I claim the following two assertions:
 * The only way to prevent apache2 configuration from being purged
   during upgrade is to keep shipping a package named apache2.2-common
   and to have apache2 depend on it.
 * The only way to ship a package named apache2.2-common is to add a
   Breaks header listing every single reverse dependency with correct
   version information.

 We could possibly discuss your suggestion as soon as nothing in Debian
 depends on apache2.2-common anymore, but for now that just adds more havoc.

Sure, you are in charge of apache2, so it is your call to decide on how
to work things out. I am just presenting technical arguments. Weighting
those arguments is your job.

Helmut


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-07-14 Thread Vincent Lefevre
Control: retitle -1 apache2 upgrade fails when apache2.2-common is purged in 
the process

On 2013-07-14 09:47:04 +0200, Helmut Grohne wrote:
 You are likely using --purge-unused something similar causing the no
 longer needed package apache2.2-common to be purged.

Yes, actually I marked it as purged instead of deleted from the
aptitude UI. Note that apt-get dist-upgrade --purge has the
same problem (as I can see with the -s option).

 It is removed and purged very early during the upgrade.
 Unfortunately this package contains your apache configuration. At
 the time apache2 is upgraded, it notices there is no configuration
 left and fails. The issue here is not that the upgrade fails, but
 that your configuration vanishes. Papering over purged configuration
 in apache2's postinst is not a solution. As a first measure don't
 upgrade with --purge-unused. I am downgrading the severity, because
 it only happens when you purge packages during upgrade.

I now understand why some config files have disappeared. I thought
that this was done on purpose since AFAIK, these were the default
files. But if I understand correctly, even if the user had made
changes, they would be lost, which is even worse.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-07-14 Thread Arno Töll
On 14.07.2013 12:38, Helmut Grohne wrote:
 My point was that if modules had their dependencies satisfied in such a
 way, then dependencies are wrong even for a wheezy - jessie upgrade,
 because as you later point out it would break the whole server.

They are wrong and this can get really nasty. I don't know who
introduced them this way back then but they hurt us now.

  * The only way to prevent apache2 configuration from being purged
during upgrade is to keep shipping a package named apache2.2-common
and to have apache2 depend on it.

I am not sure this is the only way. Possibly it could be the other way
around and transition from apache2.2-common to apache2 through a
transitional package.

  * The only way to ship a package named apache2.2-common is to add a
Breaks header listing every single reverse dependency with correct
version information.

That would be 100+ Breaks. I do not think that is feasible but that may
need a wider discussion.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D



signature.asc
Description: OpenPGP digital signature


Bug#716880: apache2 upgrade failed

2013-07-14 Thread Stefan Fritsch
clone 716880 -1
retitle -1 apache2 package upgrade fails if the configuration is inconsistent
thanks

Am Sonntag, 14. Juli 2013, 01:51:55 schrieb Vincent Lefevre:
 Purging configuration files for apache2.2-common ...


 The problem seems to come from the following
 /var/lib/dpkg/info/apache2.postinst line in:
 
 invoke-rc.d apache2 $_dh_action || exit $?
 
 It may be normal that apache2 can't be restarted, e.g. if the
 configuration files need to be updated like here. So, a failure
 to restart apache2 is not a reason to leave the system in an
 inconsistent state (possibly affecting other packages).

I agree that a failed restart should not make package installation fail. We can 
expect that every configuration with manual modifications needs to be updated 
in order to work with 2.4. Leaving the system in a half-upgraded state because 
of that is wrong. Even worse is failing to remove the package because the 
config test failed. I am cloning this bug for this issue.

The problem that apt-get dist-upgrade --purge will remove some conf files is a 
separate issue. Because of the discussion in this report, let's keep #716880 
for this issue.


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org



Bug#716880: apache2 upgrade failed

2013-07-13 Thread Vincent Lefevre
Package: apache2
Version: 2.4.4-6
Severity: grave
Justification: renders package unusable

The apache2 upgrade failed:

(Reading database ... 475293 files and directories currently installed.)
Removing libapache2-svn ...
Module authz_svn already disabled
Module dav_svn already disabled
Purging configuration files for libapache2-svn ...
(Reading database ... 475280 files and directories currently installed.)
Preparing to replace libapache2-mod-perl2 2.0.8-1 (using 
.../libapache2-mod-perl2_2.0.8+httpd24-r1449661-5_amd64.deb) ...
Unpacking replacement libapache2-mod-perl2 ...
Processing triggers for man-db ...
dpkg: apache2.2-common: dependency problems, but removing anyway as you 
requested:
 apache2-mpm-worker depends on apache2.2-common (= 2.2.22-13).
 apache2 depends on apache2.2-common (= 2.2.22-13).

(Reading database ... 475286 files and directories currently installed.)
Removing apache2.2-common ...
Purging configuration files for apache2.2-common ...
dpkg: warning: while removing apache2.2-common, directory '/usr/lib/cgi-bin' 
not empty so not removed
dpkg: warning: while removing apache2.2-common, directory '/var/log/apache2' 
not empty so not removed
dpkg: warning: while removing apache2.2-common, directory '/var/www' not empty 
so not removed
Processing triggers for man-db ...
(Reading database ... 474859 files and directories currently installed.)
Preparing to replace apache2 2.2.22-13 (using .../apache2_2.4.4-6_amd64.deb) ...
Unpacking replacement apache2 ...
Preparing to replace apache2-mpm-worker 2.2.22-13 (using 
.../apache2-mpm-worker_2.4.4-6_amd64.deb) ...
Unpacking replacement apache2-mpm-worker ...
Preparing to replace apache2.2-bin 2.2.22-13 (using 
.../apache2.2-bin_2.4.4-6_amd64.deb) ...
Unpacking replacement apache2.2-bin ...
Selecting previously unselected package apache2-bin.
Unpacking apache2-bin (from .../apache2-bin_2.4.4-6_amd64.deb) ...
Selecting previously unselected package apache2-data.
Unpacking apache2-data (from .../apache2-data_2.4.4-6_all.deb) ...
Preparing to replace apache2-doc 2.2.22-13 (using 
.../apache2-doc_2.4.4-6_all.deb) ...
Unpacking replacement apache2-doc ...
dpkg: warning: unable to delete old directory '/etc/apache2/conf.d': Directory 
not empty
Preparing to replace apache2-utils 2.2.22-13 (using 
.../apache2-utils_2.4.4-6_amd64.deb) ...
Unpacking replacement apache2-utils ...
Processing triggers for man-db ...
Processing triggers for doc-base ...
Processing 1 changed doc-base file...
Registering documents with scrollkeeper...
Setting up apache2-bin (2.4.4-6) ...
Setting up libapache2-mod-perl2 (2.0.8+httpd24-r1449661-5) ...
apache2_invoke: Enable module perl
Action 'configtest' failed.
The Apache error log may have more information.
apache2_reload: Your configuration is broken. Not restarting Apache 2
Setting up apache2-data (2.4.4-6) ...
Setting up apache2 (2.4.4-6) ...
Directory /etc/apache2/conf.d is not empty - leaving as is
Please note, that directory is considered obsolete and not read anymore by 
default
apache2-doc.dpkg-remove  javascript-common.conf
Enabling module mpm_worker.
Enabling module authn_core.
Enabling module authz_core.
Enabling module filter.
Enabling module access_compat.
Enabling conf charset.
Enabling conf localized-error-pages.
Enabling conf other-vhosts-access-log.
Enabling conf security.
Enabling conf serve-cgi-bin.
[FAIL] Restarting web server: apache2 failed!
invoke-rc.d: initscript apache2, action restart failed.
dpkg: error processing apache2 (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of apache2-mpm-worker:
 apache2-mpm-worker depends on apache2 (= 2.4.4-6); however:
  Package apache2 is not configured yet.

dpkg: error processing apache2-mpm-worker (--configure):
 dependency problems - leaving unconfigured
Setting up apache2.2-bin (2.4.4-6) ...
Setting up apache2-doc (2.4.4-6) ...
apache2_invoke: Enable configuration apache2-doc
Action 'configtest' failed.
The Apache error log may have more information.
apache2_reload: Your configuration is broken. Not reloading Apache 2
Setting up apache2-utils (2.4.4-6) ...
Errors were encountered while processing:
 apache2
 apache2-mpm-worker
E: Sub-process /usr/bin/dpkg returned an error code (1)
A package failed to install.  Trying to recover:
Setting up apache2 (2.4.4-6) ...
Directory /etc/apache2/conf.d is not empty - leaving as is
Please note, that directory is considered obsolete and not read anymore by 
default
javascript-common.conf
[FAIL] Restarting web server: apache2 failed!
invoke-rc.d: initscript apache2, action restart failed.
dpkg: error processing apache2 (--configure):
 subprocess installed post-installation script returned error exit status 1
dpkg: dependency problems prevent configuration of apache2-mpm-worker:
 apache2-mpm-worker depends on apache2 (= 2.4.4-6); however:
  Package apache2 is not configured yet.

dpkg: error processing apache2-mpm-worker (--configure):
 

Bug#716880: apache2 upgrade failed

2013-07-13 Thread Vincent Lefevre
On 2013-07-14 01:51:55 +0200, Vincent Lefevre wrote:
 Package: apache2
 Version: 2.4.4-6
 Severity: grave
 Justification: renders package unusable
 
 The apache2 upgrade failed:
[...]

And when I tried to remove it, this failed:

The following packages will be REMOVED:
  apache2* apache2-bin* apache2-data* apache2-doc* apache2-mpm-worker*
  apache2-utils* apache2.2-bin* libapache2-mod-perl2* libapache2-reload-perl*
0 upgraded, 0 newly installed, 9 to remove and 6 not upgraded.
2 not fully installed or removed.
After this operation, 27.1 MB disk space will be freed.
Do you want to continue [Y/n]? 
(Reading database ... 476048 files and directories currently installed.)
Removing libapache2-reload-perl ...
Removing libapache2-mod-perl2 ...
Module perl disabled.
apache2_invoke prerm: Disable module perl
Action 'configtest' failed.
The Apache error log may have more information.
apache2_reload: Your configuration is broken. Not restarting Apache 2
Purging configuration files for libapache2-mod-perl2 ...
apache2_invoke postrm: Purging state for perl
Removing apache2 ...
[FAIL] Stopping web server: apache2 failed!
invoke-rc.d: initscript apache2, action stop failed.
dpkg: error processing apache2 (--purge):
 subprocess installed pre-removal script returned error exit status 1
[FAIL] Starting web server: apache2 failed!
The apache2 configtest failed. Please run 'env -i LANG=C 
PATH=/usr/local/bin:/usr/bin:/bin /usr/sbin/apache2ctl configtest' manually and 
read the log file to discover problems
 failed!
invoke-rc.d: initscript apache2, action start failed.
dpkg: error while cleaning up:
 subprocess installed post-installation script returned error exit status 1
Removing apache2-mpm-worker ...
Removing apache2.2-bin ...
Removing apache2-bin ...
Removing apache2-data ...
Removing apache2-doc ...
Purging configuration files for apache2-doc ...
apache2_invoke postrm: Purging configuration apache2-doc
Action 'configtest' failed.
The Apache error log may have more information.
apache2_reload: Your configuration is broken. Not reloading Apache 2
Removing apache2-utils ...
Processing triggers for man-db ...
Processing triggers for doc-base ...
Processing 1 removed doc-base file...
Registering documents with scrollkeeper...
Errors were encountered while processing:
 apache2
E: Sub-process /usr/bin/dpkg returned an error code (1)

It's stupid to want to reload the configuration when the package
is going to be removed!

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/
100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org