buster and the release notes

[Paul Gevers]

Dear all,

As I hope you are all aware, we are in the final phase of the Debian 10
'buster' release. This means that we also want to get the release notes
for buster into shape and translated.

This is the first time that *I* am trying to coordinate this a bit, so
help me out. Hinted by some notes, I propose the following, if people
have time to help out.

* l10n-english could do a review of the current text of all chapters,
keeping in mind that especially the issues.dbk file will keep receiving
updates during the releasing process, so the other files make more sense
to check first. The about.dbk, installing.dbk, moreinfo.dbk and
release-notes.dbk have close to zero changed or added text, so if the
previous release notes were acceptable, those files are fine already. I
hope all members that want to contribute to review of proposed changes
can also subscribe to merge request notifications in the salsa interface
[1], such that proposals that *don't* go via the bts still get the
proper attention. Is aiming for a review within two weeks reasonable?

* Translation teams can start making sure translations are up-to-date, I
suggest starting with the about.dbk, installing.dbk, moreinfo.dbk and
release-notes.dbk files. Other files may receive more updates to
existing texts (depending on the answer to the review timing question in
the previous paragraph) resulting in possible unnecessary churn on fuzzy
strings in just translated items. I hope that after two weeks, in
principle only new text will be added.

I have seen updates to translations already, so I guess at least some
teams have direct access [2]. I *guess* I can grant other teams access
if they request it. Since the migration from Alioth to salsa, the
archive is available in git and changes can be submitted with merge
requests as an alternative. The bugs in the bts against the
release-notes package remain a supported option as well.

Please don't hesitate to ask if you have questions or remarks.

Let's get ready for the release.

Paul

[1] https://salsa.debian.org/ddp-team/release-notes hit drop-down menu
next to the bell-sign and select what you find appropriate
[2] https://salsa.debian.org/ddp-team/release-notes

[Justin B Rye]

Post by Paul Gevers
Dear all,

(I'm dropping just debian-i18n)

[...]

Post by Paul Gevers
* l10n-english could do a review of the current text of all chapters,
keeping in mind that especially the issues.dbk file will keep receiving
updates during the releasing process, so the other files make more sense
to check first.

I had noticed some paragraphs of issues.dbk that could be improved,
but nothing very dramatic.

Post by Paul Gevers
The about.dbk, installing.dbk, moreinfo.dbk and
release-notes.dbk have close to zero changed or added text, so if the
previous release notes were acceptable, those files are fine already.

As long as (for instance) the material about ports in installing.dbk
is up to date, yes, the "perennial" sections seem to be in good shape.

How about upgrading.dbk and whatsnew.dbk?

Post by Paul Gevers
I
hope all members that want to contribute to review of proposed changes
can also subscribe to merge request notifications in the salsa interface
[1],

Ah, thanks, I hadn't spotted that.

Post by Paul Gevers
such that proposals that *don't* go via the bts still get the
proper attention. Is aiming for a review within two weeks reasonable?

Sounds good to me. As it happens I was just looking at whats-new.dbk
and trying to decide whether to make it one diff for each of the
sections that need work. Instead of fiddling around any more with
that, here it is as one diff for the whole .dbk file:

(Inline commented version, plus attachment.)

diff --git a/en/whats-new.dbk b/en/whats-new.dbk
index 9965419f..f1bfcb5f 100644
--- a/en/whats-new.dbk
+++ b/en/whats-new.dbk
@@ -412,16 +412,16 @@ code.

<section id="de-manpages">
<!-- stretch to buster -->
- <title>Substantial improved man pages for German speaking users</title>
+ <title>Substantially improved man pages for German speaking users</title>
<para>
The documentation (<literal>man</literal>-pages) for several projects like
<systemitem role="package">systemd</systemitem>, <systemitem
role="package">util-linux</systemitem> and <systemitem
- role="package">mutt</systemitem> have been substantially extended and
- added. Please install <systemitem role="package">manpages-de</systemitem>
+ role="package">mutt</systemitem> has been substantially extended.
+ Please install <systemitem role="package">manpages-de</systemitem>

Is this trying to say that it has been extended and material has been
added? Instead of trying to fix it I've treated it as redundant.

to benefit from the improvements. During the lifetime of &releasename;
- backports of further improvements / translations will be provided within
- the <literal>backports</literal> archive.
+ further new/improved translations will be provided within the
+ <literal>backports</literal> archive.
</para>
</section>

"Improvements / translations" seems to be saying that some of the
improvements aren't translations. No, those wouldn't belong in
de-manpages! The alternatives are improvements and *new*
translations.

(And then I've left out the mention of the fact that the things in the
backports archive are backports.)

In section id="nftables":

@@ -433,8 +433,8 @@ code.
binary package includes <literal>iptables-nft</literal> and
<literal>iptables-legacy</literal>, two variants of the
<literal>iptables</literal> command line interface. The nftables-based
- variant is the default in buster and works with the
- <literal>nf_tables</literal> Linux kernel subsystem. The legacy one uses
+ variant, using the <literal>nf_tables</literal> Linux kernel
+ subsystem, is the default in buster. The legacy variant uses
the <literal>x_tables</literal> Linux kernel subsystem. Users can use the
update-alternatives system to select one variant or the other.
</para>

This whole thing is really longwinded, so I'm trying to trim it down
unobtrusively as I smooth out the English.

@@ -456,12 +456,12 @@ code.
</itemizedlist>
</para>
<para>
- All these gained the <literal>-nft</literal> and <literal>-legacy</literal>
- variants as well. The -nft option is for users that don't want -or can't-
- migrate to the native <literal>nftables</literal> command line

("Don't want -or can't- migrate" is at least missing a "to".)

- interface. However users are really enouraged to switch to
- <literal>nftables</literal> interface rather than using the old
- <literal>iptables</literal> interface.
+ All these have also gained <literal>-nft</literal> and <literal>-legacy</literal>
+ variants. The -nft option is for users who can't or don't want
+ to migrate to the native <literal>nftables</literal> command line
+ interface. However, users are strongly enouraged to switch to the
+ <literal>nftables</literal> interface rather than using
+ <literal>iptables</literal>.
</para>
<para>
<literal>nftables</literal> provides a full replacement for
@@ -474,7 +474,7 @@ code.
</para>
<para>
This movement is in line with what other major Linux distributions are
- doing, like RedHat, that now uses <literal>nftables</literal> as <ulink
+ doing, such as RedHat, which now uses <literal>nftables</literal> as its <ulink
url="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8-beta/html-single/8.0_beta_release_notes/index#networking_2">default
firewalling tool</ulink>.
</para>
@@ -482,11 +482,11 @@ code.
Also, please note that all <literal>iptables</literal> binaries are now
installed in <literal>/usr/sbin</literal> instead of
<literal>/sbin</literal>. A compatibility symlink is in place, but will be
- dropped after the buster release cycle. Please, don't use hardcoded binary
- paths in scripts or update them manually for the new location.

"Don't do X or Y" implies "don't do Y".

+ dropped after the buster release cycle, so hardcoded binary paths
+ in scripts will need to be corrected and are worth avoiding.
</para>
<para>
- Extensive documentation is available in package's README and NEWS files and
+ Extensive documentation is available in the package's README and NEWS files and
on the <ulink url="&url-wiki;nftables">Debian Wiki</ulink>.
</para>
</section>

(One of several missing definite articles.)

In section id="cryptsetup-luks2":

@@ -495,16 +495,16 @@ code.
<!-- stretch to buster -->
<title>Cryptsetup defaults to on-disk LUKS2 format</title>
<para>
- Debian buster ships with <systemitem role="package">cryptsetup</systemitem>
- which brings the new on-disk <literal>LUKS2</literal> format per default.

This makes it sound as if stretch used some other package, but in fact
even Debian sarge shipped with cryptsetup.

- New <literal>LUKS</literal> volumes will use the <literal>LUKS2</literal>
- format per default.
+ The <systemitem role="package">cryptsetup</systemitem> version
+ shipped with Debian buster uses the new on-disk
+ <literal>LUKS2</literal> format. New <literal>LUKS</literal>
+ volumes will use this format by default.
</para>
<para>
- Other than the previous <literal>LUKS1</literal> format,
+ Unlike the previous <literal>LUKS1</literal> format,

"Other than" usually means "except".

<literal>LUKS2</literal> provides redundancy of metadata, detection of
- metadata corruption and configurable <literal>PBKDF</literal> algorithms.
- Authenticated encryption is supported as well but still marked as
+ metadata corruption, and configurable <literal>PBKDF</literal> algorithms.
+ Authenticated encryption is supported as well, but still marked as
experimental.
</para>
<para>

Just nitpicking the punctuation.

[Justin B Rye]

Post by Justin B Rye
How about upgrading.dbk and whatsnew.dbk?

Hi,
The "upgrading.dbk" historically had release-specific content "hidden"
deeply within selected sections. In stretch we took an effort to
extract that to "issues.dbk" so the "routined" administrator would only
have to read "issues.dbk" for potential problems.
IOW: upgrading.dbk should be in a state where we can close it (assuming
we got all the release specific issues moved to issues - I do not
remember and I did not have time to check).

If the content's settled, now would be a good time to review the
English. Issues in issues.dbk:

diff --git a/en/issues.dbk b/en/issues.dbk
index 8ddb32d3..69054251 100644
--- a/en/issues.dbk
+++ b/en/issues.dbk
@@ -76,7 +76,7 @@ information mentioned in <xref linkend="morereading"/>.

In "deprecated-components":

<listitem>
<para>
The package <systemitem
role="package">mcelog</systemitem> is no
- longer supported in kernels above 4.12. <systemitem

Drivers might be "in" a kernel, but packages are usually "under" it!
As a compromise:

+ longer supported with kernel versions above 4.12. <systemitem
role="package">rasdaemon</systemitem> can be used as its
replacement.
</para>
@@ -126,7 +126,7 @@ information mentioned in <xref linkend="morereading"/>.

Still in "deprecated-components":

</listitem>
<listitem>
<para>
- Icinga 1.x is EOL upstream since 2018-12-31, while the
+ Icinga 1.x is EOL upstream since 2018-12-31; while the

I would have said something like "has reached EOL", but Google tells
me plenty of people say "is EOL", so I'll just fix the comma-splice.

<systemitem role="package">icinga</systemitem> package
- is still present, users should use the buster lifetime
+ is still available, users should use the buster lifetime

On second thoughts this isn't really necessary, so I'll take it out of
the attached version of the patch.

to migrate to Icinga 2
(<systemitem role="package">icinga2</systemitem> package)
and Icinga Web 2

@@ -200,7 +200,7 @@ information mentioned in <xref linkend="morereading"/>.

Under "obsolete-sysvinit-packages":

<title>SysV init related packages no longer required</title>
<note>
<para>
- This section does not apply if you decided to stick with sysvinit-core.
+ This section does not apply if you have decided to stick with sysvinit-core.
</para>

A nice demonstration of a subtle aspectual difference. "I decided" is
just a finished event; "I have decided" means the effects are still
relevant - i.e. I haven't changed my mind again since.

</note>
<para>
@@ -238,7 +238,7 @@ information mentioned in <xref linkend="morereading"/>.

Under "browser-security":

releases. Therefore, browsers built upon e.g. the webkit and khtml
engines<footnote><para>These engines are shipped in a number of different
source packages and the concern applies to all packages shipping
- them. The concern also extends to web rendering engines not explicitely
+ them. The concern also extends to web rendering engines not explicitly

Spelling. (Also: if we're going to expect users to know that, e.g.,
Konqueror is built on khtml, it would be nice if browsers could be
relied on to mention this sort of thing in their package descriptions.
But that's not a release-notes bug.)

mentioned here.</para></footnote> are included in &releasename;, but not
covered by security support. These browsers should not be used against
untrusted websites.
@@ -309,11 +309,11 @@ information mentioned in <xref linkend="morereading"/>.

Under "su-environment-variables":

<!-- stretch to buster-->
<title>Semantics for using environment variables for su changed</title>
<para>
- <literal>su</literal> changed semantics in &releasename; and no longer copies

This needs another tense/aspect tweak (because for a start buster
isn't in the past yet).

- over <literal>DISPLAY</literal> and <literal>XAUTHORITY</literal>

"Copies over X" is unclear - does it copy something over them, or does
it copy them over to somewhere? Besides, the idea of "copying" is a
bit of an implementation detail; the most that's apparent to the user
is that the variables are no longer set in root's environment.

- environment variables. You need to explicitly set them and allow
- explicitly access to your display if you need to run graphical

"Allow explicitly access" is scrambled word order. But it doesn't
really need to repeat "explicitly" (explicitly).

- applications with <literal>su</literal>. See <ulink
+ <literal>su</literal> has changed semantics in &releasename; and no longer
+ preserves the user environment variables <literal>DISPLAY</literal> and
+ <literal>XAUTHORITY</literal>. If you need to run graphical applications
+ with <literal>su</literal>, you will have to explicitly set them to allow
+ access to your display. See <ulink

"You need to X and Y if Z" might in principle mean that you always
need to do X, but Y is only necessary if Z. Putting the if-clause
first avoids this, with the bonus that non-Z readers can finish early.

url="&url-bts;905409">bug #905409</ulink> for an extensive discussion.
</para>
</section>

(Didn't I hear something about problems for users who are running "su"
when they ought to be using "su -"? Oh, yes, I heard about it from
the NEWS.Debian file, so never mind.)

[Paul Gevers]

Hi Justin,

Post by Justin B Rye
If the content's settled, now would be a good time to review the

I expect issues.dbk to be the file that will see most updates the coming
time. That said...

I have pushed your proposed changes:
https://salsa.debian.org/ddp-team/release-notes/commit/a113aa

Thanks.

Paul

[Paul Gevers]

Dear all,

As we're getting closer to the buster release, I'd like to discuss some
open items in the release notes. There are currently 12 items in the
condition="fixme" state, of which 5 I need help with right now (I'll
remove some of the other fixme's as they are either double or not
"fixable").

1) in issues.dbk there is a choice to be made about if there are actions
to do after running $(apt full-upgrade) before the next reboot. I don't
know of any issues, but I don't dare to choose yet without feedback.

2) in issues.dbk there is a list of removed packages. However, the
instructions aren't clear to me of how to create such a list. The
alternative lists too many packages that also weren't in the stretch, so
that makes spotting the right ones rather tedious. And how to spot the
"known and noteworthy" ones? Does anybody know "the proper way"?

3) in upgrading.dbk there is a section about aptitude. It feels really
outdated as since 2010 we recommend updating with apt(-get). I never
used aptitude, is this section still relevant and up-to-date?

4) in upgrading.dbk there was a note saying "need to be reviewed with
information from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571255" in the section
about kernel upgrades. That bug was about udev issues in squeeze. Does
that bug still use interesting knowledge to improve the notes of that
section?

5) in whats-new.dbk there isn't much exiting for buster. Don't we have
nice new things?

Paul

[Andrei POPESCU]

Post by Paul Gevers
3) in upgrading.dbk there is a section about aptitude. It feels really
outdated as since 2010 we recommend updating with apt(-get). I never
used aptitude, is this section still relevant and up-to-date?

As a previous heavy user of aptitude (before the apt command-line tool
was introduced) I'll have a look at that.

Post by Paul Gevers
5) in whats-new.dbk there isn't much exiting for buster. Don't we have
nice new things?

I intend to submit a section about partial (but usable) Pine64+ support.

Kind regards,
Andrei

[Brian Potkin]

Post by Paul Gevers
5) in whats-new.dbk there isn't much exiting for buster. Don't we have
nice new things?

Developments in CUPs and cups-filters bring easy and trouble-free setup
for modern IPP printers. Non-free printer drivers and plugins bite the
dust!

https://wiki.debian.org/QuickPrintQueuesCUPS

[Brian Potkin]

Post by Brian Potkin

Post by Paul Gevers
5) in whats-new.dbk there isn't much exiting for buster. Don't we have
nice new things?

Developments in CUPs and cups-filters bring easy and trouble-free setup
for modern IPP printers. Non-free printer drivers and plugins bite the
dust!
https://wiki.debian.org/QuickPrintQueuesCUPS

Text for the Release Notes, if it helps:

------------------------------------------------------------------------

Debian 10.x.x provides CUPS 2.2.10 and cups-filters 1.21.6. Both give a
user everything that is needed to take advantage of driverless printing
(https://wiki.debian.org/DriverlessPrinting). The principal requirement
is that a network print queue or printer offers an AirPrint service. A
modern IPP printer is highly likely to be AirPrint-capable; a Debian
CUPS print queue is always AirPrint-enabled.

In essence, the DNS-SD (Bonjour) broadcasts done by a CUPS server
advertising a queue, or those from IPP printers, are capable of being
displayed in the print dialogs of applications without any action being
required on the part of a user. An additional benefit is that the use
of non-free vendor printing drivers and plugins can be dispensed with.

A default installation of the cups package also installs the package
cups-browsed; print queues and IPP printers will now be automatically
set up and managed by this utility. This is the recommended way
(https://wiki.debian.org/QuickPrintQueuesCUPS) for a user to experience
seamless and trouble-free driverless printing.

------------------------------------------------------------------------

NOTE: cups-browsed isn't actually needed; CUPS should be sufficient. But
bugs in GTK and Qt applications foul things up. Hence the recommendation.

[Justin B Rye]

Here's a version with markup - patch attached.

Post by Brian Potkin
------------------------------------------------------------------------
Debian 10.x.x provides CUPS 2.2.10 and cups-filters 1.21.6. Both give a

"Debian 10", and/or just "buster".

When you say "both", presumably you don't mean that either on its own
would provide this; so say "Together these give the user..."

Post by Brian Potkin
user everything that is needed to take advantage of driverless printing
(https://wiki.debian.org/DriverlessPrinting). The principal requirement
is that a network print queue or printer offers an AirPrint service. A
modern IPP printer is highly likely to be AirPrint-capable; a Debian
CUPS print queue is always AirPrint-enabled.
In essence, the DNS-SD (Bonjour) broadcasts done by a CUPS server

It sounds a bit odd to talk about doing broadcasts - just say "the...
broadcasts from a [...] or those from [...]"

Post by Brian Potkin
advertising a queue, or those from IPP printers, are capable of being
displayed in the print dialogs of applications without any action being
required on the part of a user. An additional benefit is that the use
of non-free vendor printing drivers and plugins can be dispensed with.
A default installation of the cups package also installs the package
cups-browsed; print queues and IPP printers will now be automatically
set up and managed by this utility. This is the recommended way
(https://wiki.debian.org/QuickPrintQueuesCUPS) for a user to experience
seamless and trouble-free driverless printing.
------------------------------------------------------------------------

<section id=driverless-printing>
<!-- stretch to buster -->
<title>driverless printing with CUPS 2.2.10</title>
<para>
Debian 10 provides CUPS 2.2.10 and cups-filters 1.21.6. Together
these give a user everything that is needed to take advantage of
<ulink url="&url-wiki;DriverlessPrinting">driverless printing</ulink>.
The principal requirement is that a network print queue or printer
offers an AirPrint service. A modern IPP printer is highly likely to
be AirPrint-capable; a Debian CUPS print queue is always AirPrint-enabled.
</para>
<para>
In essence, the DNS-SD (Bonjour) broadcasts from a CUPS server
advertising a queue, or those from IPP printers, are capable of being
displayed in the print dialogs of applications without any action being
required on the part of a user. An additional benefit is that the use
of non-free vendor printing drivers and plugins can be dispensed with.
</para>
<para>
A default installation of the <systemitem role="package">cups</systemitem>
package also installs the package <systemitem
role="package">cups-browsed</systemitem>; print queues and IPP printers
will now be automatically set up and managed by this utility. This is the
<ulink url="&url-wiki;QuickPrintQueuesCUPS">recommended way</ulink>
for a user to experience seamless and trouble-free driverless printing.
</para>
</section>

(I hadn't noticed that "&url-wiki" format. If it works we should be
using it in various other places too.)

[Justin B Rye]

Post by Paul Gevers
As we're getting closer to the buster release, I'd like to discuss some
open items in the release notes. There are currently 12 items in the
condition="fixme" state, of which 5 I need help with right now (I'll
remove some of the other fixme's as they are either double or not
"fixable").
1) in issues.dbk there is a choice to be made about if there are actions
to do after running $(apt full-upgrade) before the next reboot. I don't
know of any issues, but I don't dare to choose yet without feedback.

My own test runs haven't needed anything special beyond re-customising
config-files. There might be a crossreference for people switching
from legacy interface names, but I'd recommend finishing that switch
*before* the dist-upgrade.

Post by Paul Gevers
2) in issues.dbk there is a list of removed packages. However, the
instructions aren't clear to me of how to create such a list. The
alternative lists too many packages that also weren't in the stretch, so
that makes spotting the right ones rather tedious. And how to spot the
"known and noteworthy" ones? Does anybody know "the proper way"?

Looking at that https://udd.debian.org/bapase.cgi?t=testing list and
sorting it by popcon offers a starting point. Skipping the libraries,
virtual packages, and dummy transitional packages, the top few hits
are
mysql-5.7 - wasn't in Stretch
phpmyadmin - ?
flashplugin-nonfree - long dead
checkinstall - ?
mongodb - ?
mysql-connector-python - ?
firefox - deprecated in favour of firefox-esr
kdepim4 -?
pyside - ?
mysql-utilities - ?
ssmtp - ?
kernel-package - deprecated in favour of "make deb-pkg"?
amarok - ?
...

Post by Paul Gevers
3) in upgrading.dbk there is a section about aptitude. It feels really
outdated as since 2010 we recommend updating with apt(-get). I never
used aptitude, is this section still relevant and up-to-date?

I do my test dist-upgrades under aptitude; for Buster they've been
utterly uneventful, so on the one hand I can vouch for it being a
working option but on the other for it not needing special coverage.

Post by Paul Gevers
4) in upgrading.dbk there was a note saying "need to be reviewed with
information from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=571255" in the section
about kernel upgrades. That bug was about udev issues in squeeze. Does
that bug still use interesting knowledge to improve the notes of that
section?

What *is* the minimum Debian kernel required for the Testing versions
of udev/systemd? Can we assume that if it isn't obvious from looking
in the udev/systemd changelogs etc, that they're saying it isn't
something we need to worry about?

Post by Paul Gevers
5) in whats-new.dbk there isn't much exiting for buster. Don't we have
nice new things?

The biggest recent change in Debian is probably the shift to Salsa,
but that's not something that users will notice. I'm mainly looking
forward to Bash 5 and integrated apt-transport-https, but shouldn't
more normal users with less antiquated graphics hardware be expecting
benefits of some sort from Wayland?

There's no mention in the release-notes of usrmerge, which isn't a
problem unless we want to give people advance notice that it might be
coming in Bullseye.

[Joost van Baal-Ilić]

On Fri, May 03, 2019 at 10:01:23PM +0200, Paul Gevers wrote:
<snip>

Post by Paul Gevers
5) in whats-new.dbk there isn't much exiting for buster. Don't we have
nice new things?

inspired by https://itsfoss.com/debian-10-buster/ by Shirish:

AppArmor Enabled by Default https://wiki.debian.org/AppArmor/HowToUse

NFtables replaces iptables https://wiki.debian.org/nftables

usrmerge (allready mentioned in this thread)

Secure-boot support https://wiki.debian.org/SecureBoot


Bye,

Joost

[Paul Gevers]

Hi Joost,

Post by Joost van Baal-Ilić
<snip>

Post by Paul Gevers
5) in whats-new.dbk there isn't much exiting for buster. Don't we have
nice new things?

AppArmor Enabled by Default https://wiki.debian.org/AppArmor/HowToUse

https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#apparmor

Post by Joost van Baal-Ilić
NFtables replaces iptables https://wiki.debian.org/nftables

https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#nftables

Post by Joost van Baal-Ilić
usrmerge (allready mentioned in this thread)

Still missing. Text anybody?

Post by Joost van Baal-Ilić
Secure-boot support https://wiki.debian.org/SecureBoot

https://www.debian.org/releases/buster/amd64/release-notes/ch-whats-new.en.html#secure-boot

:)

Thanks for thinking along.

Paul

[Andrei POPESCU]

Post by Paul Gevers
3) in upgrading.dbk there is a section about aptitude. It feels really
outdated as since 2010 we recommend updating with apt(-get). I never
used aptitude, is this section still relevant and up-to-date?

I'm assuming you are referring to <section id="review actions">.


Background
----------

This section was important many years ago when:

a) aptitude was the recommended package manager for dist-upgrades.
At the time aptitude had a better resolver than APT.

b) APT did not keep track of manually/automatically installed packages.
AFAIK aptitude was the first to introduce this.

In the meantime APT's resolver was much improved and is preferred in
many scenarios because it's more predictable. APT now also has the
concept of manual/automatic packages and can change the states with
apt-mark.

AFAIK the database is actually shared with aptitude, so mixing apt(-get)
and aptitude for typical package management should not be an issue
anymore (I would avoid it *during* the dist-upgrade, unless apt would
get stuck somewhere and I would possibly use aptitude's interactive mode
to fix it).

"Pending actions" is a feature of the aptitude interactive mode, where
one can schedule several actions (install/remove/etc.) and then instruct
aptitude to perform them all at once (same as synaptic).

Since APT doesn't know or care about aptitude's pending actions, in my
opinion there is minimal chance for an impact on the dist-upgrade
performed with apt, except maybe in some convoluted scenario (e.g. the
user was about to replace some third-party packages with Debian's
version, possibly in preparation for the dist-upgrade, but stops before
applying and then forgets about it.)


Suggestions
-----------

1. At a minimum the sentence about mixing apt and aptitude should be
removed as it's not applicable anymore.

2. The general recommendation to make sure the system is up-to-date and
"clean" (including checking for pending actions in aptitude, synaptic
and other package managers) should be kept.[*]

3. The detailed instructions on how to check for pending actions can
probably be removed as aptitude users will be familiar with that and apt
users don't need to care.


[*] I seem to remember a section recommending to upgrade the system to
the latest point release/security updates before the dist-upgrade. It
would probably make more sense to have it there instead, if that section
still exists.

Hope this helps,
Andrei

[Paul Gevers]

Hi Andrei,

Post by Andrei POPESCU

Post by Paul Gevers
3) in upgrading.dbk there is a section about aptitude. It feels really
outdated as since 2010 we recommend updating with apt(-get). I never
used aptitude, is this section still relevant and up-to-date?

I'm assuming you are referring to <section id="review actions">.

Yes, that.

[...]

Post by Andrei POPESCU
Suggestions
-----------
1. At a minimum the sentence about mixing apt and aptitude should be
removed as it's not applicable anymore.
2. The general recommendation to make sure the system is up-to-date and
"clean" (including checking for pending actions in aptitude, synaptic
and other package managers) should be kept.[*]
3. The detailed instructions on how to check for pending actions can
probably be removed as aptitude users will be familiar with that and apt
users don't need to care.
[*] I seem to remember a section recommending to upgrade the system to
the latest point release/security updates before the dist-upgrade. It
would probably make more sense to have it there instead, if that section
still exists.

I gave it a shot, but it looks clumsy. Any ideas for a better text (or
location)?

Post by Andrei POPESCU
Hope this helps,

It did.

Paul

[Andrei POPESCU]

Post by Paul Gevers

Post by Andrei POPESCU
[*] I seem to remember a section recommending to upgrade the system to
the latest point release/security updates before the dist-upgrade. It
would probably make more sense to have it there instead, if that section
still exists.

I gave it a shot, but it looks clumsy. Any ideas for a better text (or
location)?

LGTM FWIW, I'll let Justin do his magic :)

Kind regards,
Andrei

[Justin B Rye]

Post by Andrei POPESCU

Post by Paul Gevers

Post by Andrei POPESCU
[*] I seem to remember a section recommending to upgrade the system to
the latest point release/security updates before the dist-upgrade. It
would probably make more sense to have it there instead, if that section
still exists.

I gave it a shot, but it looks clumsy. Any ideas for a better text (or
location)?

LGTM FWIW, I'll let Justin do his magic :)

LGTM too. Hang on, I'll set my nitpicker to Turbo mode.

# You should also make sure the system is <quote>clean</quote> before

This is "clean" in a rather nerdy sense (cf. the way an "unclean"
filesystem may require ritual purification via fsck); and APT also has
a technical meaning of its own for "apt clean". What we're really
trying to say here is something more like "stable"... but we can't use
that word either.

# proceeding with the upgrade. If you are a user of another package manager
# like <systemitem role="package">aptitude</systemitem> or <systemitem
# role="package">synaptic</systemitem>, review any pending actions. If a
# package is scheduled for removal or update in the package manager, it might

Is it possible for a scheduled *update* (or I think it means
"upgrade") to cause trouble? After all, as soon as I call for a
dist-upgrade they're *all* going to be scheduled for an upgrade.
There can be problems if the pending upgrade pulls in extra packages,
but then the real issue is that a package is scheduled for
installation. In fact maybe it should be:

If a package is scheduled in the package manager for installation or removal,

Or am I missing possibilities?

# negatively impact the upgrade procedure. Note that correcting this is only
# possible if your APT source-list files still point to
# <emphasis>&oldreleasename;</emphasis> and not to
# <emphasis>stable</emphasis> or <emphasis>&releasename;</emphasis>; see
# <xref linkend="old-sources"/>.

("Negatively impact" makes me think of "rapid unscheduled
disassembly".)

[Andrei POPESCU]

Post by Justin B Rye

Post by Andrei POPESCU
LGTM FWIW, I'll let Justin do his magic :)

LGTM too. Hang on, I'll set my nitpicker to Turbo mode.
# You should also make sure the system is <quote>clean</quote> before
This is "clean" in a rather nerdy sense (cf. the way an "unclean"
filesystem may require ritual purification via fsck); and APT also has
a technical meaning of its own for "apt clean". What we're really
trying to say here is something more like "stable"... but we can't use
that word either.

s|<quote>clean</quote>|consistent| ?

Post by Justin B Rye
# proceeding with the upgrade. If you are a user of another package manager
# like <systemitem role="package">aptitude</systemitem> or <systemitem
# role="package">synaptic</systemitem>, review any pending actions. If a
# package is scheduled for removal or update in the package manager, it might
Is it possible for a scheduled *update* (or I think it means
"upgrade") to cause trouble? After all, as soon as I call for a
dist-upgrade they're *all* going to be scheduled for an upgrade.
There can be problems if the pending upgrade pulls in extra packages,
but then the real issue is that a package is scheduled for
If a package is scheduled in the package manager for installation or removal,

Agreed.

Post by Justin B Rye
Or am I missing possibilities?
# negatively impact the upgrade procedure. Note that correcting this is only
# possible if your APT source-list files still point to
# <emphasis>&oldreleasename;</emphasis> and not to
# <emphasis>stable</emphasis> or <emphasis>&releasename;</emphasis>; see
# <xref linkend="old-sources"/>.
("Negatively impact" makes me think of "rapid unscheduled
disassembly".)

s/it might negatively impact/it might interfere in unexpected ways with/ ?

Kind regards,
Andrei

[Justin B Rye]

Post by Andrei POPESCU

Post by Justin B Rye
# You should also make sure the system is <quote>clean</quote> before
This is "clean" in a rather nerdy sense (cf. the way an "unclean"
filesystem may require ritual purification via fsck); and APT also has
a technical meaning of its own for "apt clean". What we're really
trying to say here is something more like "stable"... but we can't use
that word either.

s|<quote>clean</quote>|consistent| ?

Well, having package-installs pending isn't exactly inconsistent... or
indeed unclean. Maybe if it didn't vaguely talk about "the system" we
could use something simpler:

You should also make sure the package database is ready before

Post by Andrei POPESCU

Post by Justin B Rye
# proceeding with the upgrade. If you are a user of another package manager
# like <systemitem role="package">aptitude</systemitem> or <systemitem
# role="package">synaptic</systemitem>, review any pending actions. If a
# package is scheduled for removal or update in the package manager, it might
Is it possible for a scheduled *update* (or I think it means
"upgrade") to cause trouble? After all, as soon as I call for a
dist-upgrade they're *all* going to be scheduled for an upgrade.
There can be problems if the pending upgrade pulls in extra packages,
but then the real issue is that a package is scheduled for
If a package is scheduled in the package manager for installation or removal,

Agreed.

Post by Justin B Rye
Or am I missing possibilities?
# negatively impact the upgrade procedure. Note that correcting this is only
# possible if your APT source-list files still point to
# <emphasis>&oldreleasename;</emphasis> and not to
# <emphasis>stable</emphasis> or <emphasis>&releasename;</emphasis>; see
# <xref linkend="old-sources"/>.
("Negatively impact" makes me think of "rapid unscheduled
disassembly".)

s/it might negatively impact/it might interfere in unexpected ways with/ ?

Possibly even just "it might interfere with", given that we're having
to tell them about it.

[Paul Gevers]

Hi all,

We're a bit further than last time.

On 31-03-2019 21:34, Paul Gevers wrote:

[...]

Post by Paul Gevers
This is the first time that *I* am trying to coordinate this a bit, so
help me out. Hinted by some notes, I propose the following, if people
have time to help out.

Thanks for all of you that already have helped so far.

Post by Paul Gevers
* l10n-english could do a review of the current text of all chapters,
keeping in mind that especially the issues.dbk file will keep receiving
updates during the releasing process, so the other files make more sense
to check first. The about.dbk, installing.dbk, moreinfo.dbk and
release-notes.dbk have close to zero changed or added text, so if the
previous release notes were acceptable, those files are fine already.

[...]

Minor changes have been done in installing.dbk (mostly dropping text)
and one addition in release-notes.dbk. I think we can consider this
frozen now.

Post by Paul Gevers
* Translation teams can start making sure translations are up-to-date, I
suggest starting with the about.dbk, installing.dbk, moreinfo.dbk and
release-notes.dbk files. Other files may receive more updates to
existing texts (depending on the answer to the review timing question in
the previous paragraph) resulting in possible unnecessary churn on fuzzy
strings in just translated items.

[...]

Please, if you haven't already started on translating, full steam ahead.
Expect, however, incoming changes (mostly additions, we'll try to avoid
other changes) to issues.dbk and whats-new.dbk.

Post by Paul Gevers
I have seen updates to translations already, so I guess at least some
teams have direct access [2]. I *guess* I can grant other teams access
if they request it. Since the migration from Alioth to salsa, the
archive is available in git and changes can be submitted with merge
requests as an alternative. The bugs in the bts against the
release-notes package remain a supported option as well.
Please don't hesitate to ask if you have questions or remarks.

This holds. For lots of languages I haven't seen any activity yet.
Volunteers?

[...]

Paul

Post by Paul Gevers
[1] https://salsa.debian.org/ddp-team/release-notes hit drop-down menu
next to the bell-sign and select what you find appropriate
[2] https://salsa.debian.org/ddp-team/release-notes

[Justin B Rye]

Post by Paul Gevers
Minor changes have been done in installing.dbk (mostly dropping text)
and one addition in release-notes.dbk. I think we can consider this
frozen now.

I was going to say "wait, a couple more things" - but it looks as if
all the low-priority checks I had on my TODO-list have been taken care
of, except for...

One trivial consistency fix (assuming this shortcut can cope with
fragment-IDs):

--- a/en/issues.dbk
+++ b/en/issues.dbk
disable it before the upgrade, to ensure login sessions work on
&releasename;. (A possible route to re-enabling it is outlined on the
wiki's <ulink
- url="https://wiki.debian.org/Hardening#Mounting_.2Fproc_with_hidepid">Hardening</ulink>
+ url="&url-wiki;Hardening#Mounting_.2Fproc_with_hidepid">Hardening</ulink>
page.)
</para>

And one pair of URLs I failed to check properly:

@@ -571,10 +571,10 @@ $ sudo update-initramfs -u
<para>
In stretch, the package <systemitem role="package">mutt</systemitem>
had patches applied from the sources at <ulink
- url="https://www.neomutt.org">https://www.neomutt.org</ulink>. Starting
+ url="https://neomutt.org">https://neomutt.org</ulink>. Starting
from buster, the package providing <literal>/usr/bin/mutt</literal> will
instead be purely based on the original sources from <ulink
- url="https://www.mutt.org">https://www.mutt.org</ulink>, and a separate
+ url="http://www.mutt.org">http://www.mutt.org</ulink>, and a separate
<systemitem role="package">neomutt</systemitem> package is available
providing <literal>/usr/bin/neomutt</literal>.
</para>