[bts-link] source package apache2

2013-02-28 Thread bts-link-upstream
#
# bts-link upstream status pull for source package apache2
# see http://lists.debian.org/debian-devel-announce/2006/05/msg1.html
#

user bts-link-upstr...@lists.alioth.debian.org

# remote status report for #701117 (http://bugs.debian.org/701117)
# Bug title: Should respond with HTTP/1.x when talking http to a https port
#  * http://issues.apache.org/bugzilla/show_bug.cgi?id=50823
#  * remote status changed: (?) - NEW
usertags 701117 + status-NEW

thanks


--
To UNSUBSCRIBE, email to debian-apache-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/20130228164029.11077.64253.btsl...@sonntag.debian.org



Bug#681545: apache2-dev: dh_apache2 postinst action should run during more actions

2013-02-28 Thread Arno Töll
Hi Russ,


I'm finally coming back to the dh_apache issues you filed long ago.


 I believe you should therefore just remove this conditional and run this
 code in postinst unconditionally.

Your explanation sounds right to me. However, we do not unconditionally
disable the module either. We only do so in case of postrm purge|remove
to ensure the web server is not reloaded without need. This makes the
abort-upgrade|abort-remove|abort-deconfigure operations a no op with
respect to Apache maintainer scripts.

Our goal should be to minimize the impact of an upgrade. Many people
tend to be annoyed when the web server is restarted during upgrades.
Hence, I do believe configure is correct, but I might try some of the
abort/failure cases you mentioned before deciding what to do eventually
with your bug.

Does my explanation make sense to you?


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



signature.asc
Description: OpenPGP digital signature


Bug#681544: apache2-dev: provide dh_apache2 option to avoid enabling module by default

2013-02-28 Thread Arno Töll
Hi Russ,

On 14.07.2012 05:06, Russ Allbery wrote:
 A nicer mechanism would be to allow the *.apache2 configuration file
 have an option for mod *.load lines saying not to enable the module
 by default.

I think, we should rather stick with a specialized dh_apache command
line argument, say dh_apache2 --no-start-by-default or whatever instead
of adding even more complexity to .load files. Does that sound
acceptable to you?

Moreover, we planned to let the maintainer give a local policy on that
regard. I could imagine a variable in /etc/default/apache2 determining
the web server reload behavior. In fact, that's quite the point to
abstract the module load behavior through our wrapper script, although
such policies are not implemented yet.

 If the module is enabled, then Apache should still be restarted on
 upgrade (or other configuration actions).  If the module is not
 enabled or wasn't previously installed, nothing should be done by
 default in postinst.  The postrm handling would remain the same.

We do so, don't we? At least we wrote code which should do right that,
but it might have bugs of course :



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



signature.asc
Description: OpenPGP digital signature