Hiya,
I've just gone through the release notes for a general review and
especially to review all the recent commits by Andreas.
BTW: many thanks for processing all the open BRs!
Attached a patch with proposed spelling/gramatical fixes. Please check.
Below a number of suggestions for changes.
- Rename chapter 1 from "What's new in the Release Notes" to
"Introduction". After all, there is very little actual news about the
release notes in that (short) chapter.
I feel that the changelog for post-release changes still fits under
that heading.
- 2.1.1 debian-volatile now an official service
I see that volatile.d.o is still not up. What is the status for that?
- 2.2 What's new in the installation system?
Next on my TODO list.
- 4.4.2 Upgrading aptitude
I propose to drop this section. Bill Allombert has shown [1] that
upgrading aptitude on its own can lead to a number of removals due
to the C++ transition.
Steinar has stated that Etch's aptitude is much better at dependency
resolution though [2]. I've asked him to elaborate.
- 4.4.5 Possible issues during upgrade
"Please check also in Issues to be aware of for etch, Chapter 5 about
issues explicitly listed there."
I don't feel that this comment should be included in this section.
Moving it to "4.1 Preparing for the upgrade" seems more logical to me.
- 4.5 Upgrading your kernel and related packages
- There is no explanation _why_ the kernel should be upgraded
separately.
- My feeling is that this section is currently very messy. It contains
some info that is general in nature and belongs in Chapter 2 instead,
along with some info (e.g. devfs) that should be mentioned much
earlier in chapter 4 as it needs to be done _before_ starting the
actual upgrade. There are also some issues that belong more in
chapter 5 (device numeration).
- Also, the current text will leave any user in confusion as to what he
should actually do: upgrade the kernel first and reboot before
upgrading the reset of the system; just upgrade the meta package as
part of the main upgrade (which is implied in "4.5.6 upgrading the
kernel", but totally contradicts "4.5 Upgrading your kernel and
related packages".
- The command
# apt-cache search linux-image-2.6- | grep -v transition
will also list vserver and xen kernels, which may confuse users.
The added support of vserver and xen should probably be mentioned
in chapter 2.
If you agree with these general points I'll try to come up with a
patch to improve things.
- 5.1.1 Certain networking site cannot be reached by TCP
This heading is not correct English. At least it needs s/site/sites/,
but I have some doubts if the term "networking sites" is correct at
all.
- 5.1.3 Apt downloads small files with update
I feel this is not so much an "issue" as a "change in the distribution"
and should therefore be mentioned in chapter 2 instead of here.
- 5.4 Upgrading from exim 3 to exim4
The use of 'exim 3' and exim4 seems inconsistent. I'd suggest using
plain 'exim' in the heading and 'exim (version 3.xx)' in the main text.
[1] http://lists.debian.org/debian-release/2006/11/msg00345.html
[2] http://lists.debian.org/debian-release/2006/11/msg00206.html
? ~release-notes.patch
Index: release-notes.en.sgml
===================================================================
RCS file: /cvs/debian-doc/ddp/manuals.sgml/release-notes/en/release-notes.en.sgml,v
retrieving revision 1.107
diff -u -r1.107 release-notes.en.sgml
--- release-notes.en.sgml 26 Nov 2006 13:59:01 -0000 1.107
+++ release-notes.en.sgml 28 Nov 2006 17:47:03 -0000
@@ -871,43 +871,46 @@
<sect id="newkernel"><heading>Upgrading your kernel and related
packages</heading>
- <p>You should upgrade the linux kernel separate from the rest of
+ <p>You should upgrade the Linux kernel separately from the rest of
your packages.
<!-- TODO: add something in "before you upgrade", and get the order right -->
You may wish to do so yourself, either by installing one
of the <package/linux-image-*/ packages or by compiling a customized
kernel from sources.
- Please read the information in this section about possible issues
+ Please read the information in this section about potential issues
with kernel upgrades.</p>
- <p>The linux kernel packages have been renamed to linux-* (from kernel-*)
- to clean up the namespace.</p>
+ <p>All Linux kernel packages have been renamed from <tt/kernel-*/ to
+ <tt/linux-*/ to clean up the namespace.</p>
+<![ %defaulted-2.4 [
<p>If you are currently using a kernel from the 2.4 series,
the older stable Linux kernel series, you should upgrade to a 2.6
- series kernel, as 2.4 is no longer supported in Etch.
+ series kernel, as 2.4 is no longer supported in %releasename;.
If you are currently using a kernel from the 2.2 series, you
must upgrade to (at least) the 2.4 series, better to a 2.6 series
kernel prior to upgrading your packages.
<!-- TODO: incoporate this part in this section -->
- Some issues associated with an upgrade to 2.6 are documented in
- (FIXME - the link is partly broken)
- <!--
- <ref id="upgrade-to-2.6">. --></p>
+ Some general issues associated with an upgrade to 2.6 are documented
+ in <ref id="upgrade-to-2.6">.</p>
+]]>
<sect1><heading>initrd-tools deprecated</heading>
- <p><prgn>initrd-tools</prgn> is no longer supported and has been
- superseded by <prgn>initramfs-tools</prgn> and <prgn>yaird</prgn>.
+ <p><package/initrd-tools/ is no longer supported and has been
+ superseded by <package/initramfs-tools/ and <package/yaird/.
Upgrading to an etch kernel will cause
- <prgn>initramfs-tools</prgn> to be installed by default. If you
- are upgrading from a 2.4 kernel to a 2.6 kernel for the first
- time, you must use <prgn>initramfs-tools</prgn>.
- <prgn>yaird</prgn> will cause linux-image-2.6 installations to
- fail when running on a 2.2 or 2.4 kernel.</p>
+ <package/initramfs-tools/ to be installed by default.
+<![ %defaulted-2.4 [
+ If you are upgrading from a 2.4 kernel to a 2.6 kernel for the
+ first time, you must use <package/initramfs-tools/. Using
+ <package/yaird/ will cause linux-image-2.6 installations to
+ fail if you are running a 2.2 or 2.4 kernel.
+]]>
+ </p>
</sect1>
<sect1><heading>devfs deprecated</heading>
- <p>Etch no longer provides support for <prgn>devfs</prgn>.
+ <p>&releasename; no longer provides support for <prgn>devfs</prgn>.
It is recommended that users switch to udev for dynamic
<file>/dev</file> management.
Debian kernels no longer include support for <prgn>devfs</prgn>,
@@ -921,30 +924,28 @@
refer to devfs style device names include <file>/etc/fstab</file>,
<file>/etc/lilo.conf</file>, <file>/boot/grub/menu.lst</file>, etc.</p>
- <p>More information about possible issues are in the bug report
- <url id="http://bugs.debian.org/341152"; name="#351152">.
- </p>
+ <p>More information about potential issues is available in bug report
+ <url id="http://bugs.debian.org/341152"; name="#351152">.</p>
</sect1>
<![ %i386-amd64-ia64 [
- <sect1><heading>standard kernels contain SMP abilities</heading>
+ <sect1><heading>Standard kernels contain SMP abilities</heading>
<p>Multiprocessor systems no longer require a *-smp flavour of the
- Linux kernel. linux-image packages without the -smp suffix
- have gained support for multiprocessor systems
- on amd64, i386 and ia64 since Etch.
- </p></sect1>
+ Linux kernel. For &arch-title; linux-image packages without the -smp
+ suffix support both uniprocessor and multiprocessor systems.</p>
+ </sect1>
]]>
<![ %i386 [
<sect1><heading>386 kernel flavour deprecated</heading>
- <p>Support for the 80386 sub-archicture for i386 has been dropped in
- etch. The 386 kernel flavor is no longer supported and has been
- replaced by the new 486 flavour.
- </p></sect1>
+ <p>Support for the 80386 sub-archicture for &arch-title; has been dropped
+ in &releasename;. The 386 kernel flavor is no longer supported and has been
+ replaced by the new 486 flavour.</p>
+ </sect1>
]]>
<sect1><heading>Device enumeration reordering</heading>
- <p>Etch features a more robust mechanism for hardware discovery
+ <p>&releasename; features a more robust mechanism for hardware discovery
than previous releases. However, this may cause changes in the
order devices are discovered on your system affecting the order
in which device names are assigned.
@@ -967,12 +968,11 @@
*** by what I remember, and haven't tested this recently
-->
<p>For storage devices, you can avoid this reordering by using
- <prgn>initramfs-tools</prgn> and configuring
- <prgn>initramfs-tools</prgn> to load storage device driver modules in the same
- order they are currently loaded.
+ <package/initramfs-tools/ and configuring it to load storage device
+ driver modules in the same order they are currently loaded.
To do this, identify the order the storage modules on your system
- were loaded by looking at the output of lsmod.
- lsmod lists modules in the reverse order that they were loaded
+ were loaded by looking at the output of <prgn/lsmod/.
+ <prgn/lsmod/ lists modules in the reverse order that they were loaded
in, i.e., the first module in the list was the last one
loaded.</p>
@@ -990,9 +990,9 @@
example, sym53c8xx_2 has become sym53c8xx.</p>
<p>You will then need to regenerate your initramfs image(s) by
- executing <prgn>update-initramfs -k all</prgn>.</p>
+ executing <tt>update-initramfs -k all</tt>.</p>
- <p>Once you are running an etch kernel and udev, you may
+ <p>Once you are running an &releasename; kernel and <prgn/udev/, you may
reconfigure your system to access disks by an alias that is not
dependent upon driver load order. These aliases reside in the
<file>/dev/disk/</file> hierarchy.</p>
@@ -1020,12 +1020,13 @@
<item><p>Leave the existing <file>ttyS0</file> entries in
<file>/etc/inittab</file> and <file>/etc/securetty</file> so
you can still boot old kernels.</p></item>
- </list></p></item>
+ </list>
+ </p></item>
<item><p>Edit <file>/etc/elilo.conf</file> to remove any "console="
arguments.</p></item>
- <item><p>Run elilo to install the bootloader with new
+ <item><p>Run <prgn/elilo/ to install the bootloader with new
configuration.</p></item>
<item><p>Reboot and use the EFI boot option maintenance menu to
@@ -1044,11 +1045,11 @@
</sect1>
]]>
- <sect1><heading>upgrading the kernel</heading>
+ <sect1><heading>Upgrading the kernel</heading>
<p>When you dist-upgrade from &oldreleasename; to &releasename;,
it is strongly recommended that you install a new
linux-image-2.6-* metapackage.
- This package may automatically be installed by the dist-upgrade
+ This package may be installed automatically by the dist-upgrade
process. You can verify this by running:
<example>
# dpkg -l | grep '^ii linux-image'
@@ -1062,9 +1063,9 @@
</example></p>
<p>If you are unsure about which package to select, run
- <prgn>uname -r</prgn> and look for a package with a similar name.
+ <tt>uname -r</tt> and look for a package with a similar name.
For example, if you see '2.4.27-3-686', it is recommended that you
- install linux-image-2.6-686.
+ install <package/linux-image-2.6-686/.
You may also use apt-cache to see a long description of each
package in order to help choose the best one available.
For example:
@@ -1228,13 +1229,13 @@
<sect1 id="poweroff"><heading>Automatic poweroff stops working</heading>
<p>
- On some older systems, <prgn>shutdown -h</prgn> will not poweroff anymore
- (but just stop the system). This happens because apm needs to be used there.
- Adding <tt>acpi=off apm=power_off</tt> to the kernels command line, e.g.
- via grub or lilo configurations file will fix this issue.
- Please see the bug
+ On some older systems, <prgn>shutdown -h</prgn> may not power off the system
+ anymore (but just stop it). This happens because apm needs to be used there.
+ Adding <tt>acpi=off apm=power_off</tt> to the kernel's command line, e.g.
+ in <package/grub/ or <package/lilo/ configuration files should fix this issue.
+ Please see bug
<url id="http://bugs.debian.org/390547"; name="#390547">
- for more information.
+ for additional information.
</p>
</sect1>
@@ -1433,28 +1434,27 @@
<sect id="xorg"> <heading>XFree86 to X.Org transition</heading>
- <p>The transition to X.Org contained structural changes. In case
- all installed packages are from Debian and also contained in Etch,
- the upgrade should work by its own.
- Experience has however shown there are typical issues to be aware
- of.</p>
+ <p>The transition to X.Org involves some structural changes. In case
+ all installed packages are from Debian and also included in &releasename;,
+ the upgrade should work without problems.
+ Experience has however shown there are a few changes to be aware of as
+ they can potentially cause issues during the upgrade.</p>
- <p>The most important issue is that <file>/usr/X11R6/bin</file> has
+ <p>The most important change is that <file>/usr/X11R6/bin</file> has
been dropped and only remains as a symlink to <file>/usr/bin</file>.
- This means it has to be empty at the time of the upgrade.
+ This means this directory has to be empty at the time of the upgrade.
The new packages conflict with most packages that used
<file>/usr/X11R6/bin</file>,
but in some cases manual interaction is needed.
Please remember to not run upgrades within an X session.</p>
- <p>In case the upgrade aborts during X.Org installation, you have
- to find which file(s) are still left in
- <file>/usr/X11R6/bin</file>.
- You can use <prgn>dpkg -S</prgn> to find out which Debian package
+ <p>In case the upgrade aborts during X.Org installation, you should
+ check if any files are still left in <file>/usr/X11R6/bin</file>.
+ You can then use <tt>dpkg -S</tt> to find out which Debian package
installed that file (if any), and remove such packages with
- <prgn>dpkg --remove</prgn>. Please note down which packages you
- remove, so that you can install substituting packages later on.
- Before continueing with the installation, all files in
+ <tt>dpkg --remove</tt>. Please make a note which packages you
+ remove, so that you can install substitute packages later on.
+ Before continuing with the upgrade, all files in
<file>/usr/X11R6/bin</file> need to be removed.
<p>Please read <url id="http://wiki.debian.org/Xorg69To7";>
@@ -1491,15 +1491,15 @@
<sect id="apache2"> <heading>Upgrading apache2</heading>
<p>Apache has been upgraded to the new version 2.2.
- Though this shouldn't have impact on the average user,
- there are some issues to be aware of.</p>
+ Although this shouldn't impact the average user,
+ there are some potential issues to be aware of.</p>
<p><url id="http://httpd.apache.org/docs/2.2/upgrading.html";> contains
the upstream changes. Please read this page, and remember that especially:
<list>
<item><p>all modules need to be recompiled</p></item>
<item><p>authorization modules have been resorted and renamed</p></item>
- <item><p>some configuration options changed name</p></item>
+ <item><p>some configuration options have been renamed</p></item>
</list></p>
<p>Debian-specific changes include that the string SSL is no longer defined,
@@ -1508,19 +1508,19 @@
</sect>
<sect id="php-globals"> <heading>Deprecated insecure php configurations</heading>
- <p>For many years, turning on the register_globals settings in PHP
- has been known to be insecure and dangerous, and has defaulted to
+ <p>For many years, turning on the <tt/register_globals/ settings in PHP
+ has been known to be insecure and dangerous, and this option has defaulted to
off for some time now. This configuration is
now finally deprecated on Debian systems as too dangerous.
- The same applies to flaws in safe_mode and open_basedir, which
+ The same applies to flaws in <tt/safe_mode/ and <tt/open_basedir/, which
have also been unmaintained for some time.</p>
<p>Starting with this release, the Debian security team does not provide
security support for a number of PHP configurations which are known to
- be insecure. Most importantly, issues that make use of the
- register_globals setting being turned on are not addressed.</p>
+ be insecure. Most importantly, issues resulting from
+ <tt/register_globals/ being turned on will no longer be addressed.</p>
- <p>If you run legacy applications that require register_globals,
+ <p>If you run legacy applications that require <tt/register_globals/,
enable it for the respective paths only, e.g. through the Apache
configuration file. More information is available in the
<file>README.Debian.security</file> file in the PHP
@@ -1530,16 +1530,16 @@
<sect id="mozilla-security"> <heading>Security status of mozilla products</heading>
<p>The Mozilla programs are important tools for many users.
- Unfortunately their security policy is to urge users to update to
- new upstream versions, which collides with our policy to not ship
- large functional changes in a security update.
- We cannot predict it today, but during &releasename; lifetime the
- Debian Security Team might come to a point where supporting
- Mozilla products is no longer feasible and, and would then announce
+ Unfortunately the upstream security policy is to urge users to update to
+ new upstream versions, which conflicts with Debian's policy not to ship
+ large functional changes in security updates.
+ We cannot predict it today, but during lifetime of &releasename; the
+ Debian Security Team may come to a point where supporting
+ Mozilla products is no longer feasible and announce
the end of security support for Mozilla products.
- You should take this into account when deploying Mozilla and
- consider alternatives inside Debian if that poses a problem to
- you.</p>
+ You should take this into account when deploying Mozilla and consider
+ alternatives available in Debian if the absence of security support would
+ pose a problem for you.</p>
</sect>
</chapt>
Attachment:
pgpPoSAYyJ7Vd.pgp
Description: PGP signature