Bug#229027: apache-common: Notes changed config file format on fresh install
Package: apache-common Version: 1.3.29.0.1-3 Severity: minor A fresh install of apache-common causes the apache-common/confignotes template to be displayed. Given that this is documenting a change in the configuration scheme it would seem sensible to only display this note while upgrading from a version that had the old scheme. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux loki 2.4.22-1-686 #6 Sat Oct 4 14:09:08 EST 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages apache-common depends on: ii apache-utils1.3.29.0.1-3 Utility programs for webservers ii debconf 1.3.22 Debian configuration management sy ii libc6 2.3.2.ds1-10 GNU C Library: Shared libraries an ii libdb4.14.1.25-16Berkeley v4.1 Database Libraries [ ii libexpat1 1.95.6-6 XML parsing C library - runtime li ii mime-support3.23-1 MIME files 'mime.types' & 'mailcap ii perl [perl5]5.8.2-2 Larry Wall's Practical Extraction ii sed 4.0.7-3 The GNU sed stream editor -- debconf information excluded
Bug#230391: ssl-cert: Configuration confusing
Package: ssl-cert Version: 1.0-7 Severity: normal The Debconf templates for ssl-cert don't mention what is being configured or otherwise provide context when prompting for information. This makes them rather more confusing than they need to be - sudden questions about things that may not have immediately obvious values appear. Things would probably be a lot more comprehensible if the templates were changed to say something along the lines of 'Which X should be used by default to generate SSL certificates'. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux shenandoah 2.4.23-1-k7 #1 Mon Dec 1 00:05:09 EST 2003 i686 Locale: LANG=en_GB, LC_CTYPE=en_GB (ignored: LC_ALL set to en_GB) Versions of packages ssl-cert depends on: ii debconf 1.4.7 Debian configuration management sy -- debconf information excluded
Bug#280871: Problems with apache, PHP, MM and UML.
On Sat, Nov 13, 2004 at 02:58:55AM +1000, Adam Conrad wrote: > Mark: Can you think of any reason why forcing MMFILE might lead to the > symptoms described in the two bug reports CCd? Well, the MMFILE implementation is a mmapped file. This will cause it to allocate backing store for the shared memory segment when it is used. If this is only showing up on UML systems my first guess would be that sending the process a signal (as a configuration reload does) causes the UML kernel to allocate backing store for the entire memory mapping. Otherwise the reload probably just causes PHP to walk over the entire shared memoy segment. I'd guess that the old build would've been using System V shared memory which wouldn't have the backing store - it could be figured out readily although the mirror I use doesn't seem to have the old stable mm binary package and I managed to loose my archive a while ago. If it had ended up doing that then there would be no such issues with backing store. MMFILE was chosen because it's the most conservative mechanism in terms of kernel compatibility and when System V shared memory did get used it caused problems for PHP since the default system limit on shared memory is 32Mb with 2.6 kernels - PHP tries to allocate 64Mb and fails. -- "You grabbed my hand and we fell into it, like a daydream - or a fever."
