Bug#864166: release-notes: proofreading sweep - issues.dbk
On 06/09/2017 06:00 PM, Niels Thykier wrote: > Julien Cristau: >> On 06/05/2017 01:50 PM, Niels Thykier wrote: >>> Hi, >>> >>> CC'ing debian-x, who I hope can help us with some clarification. >>> >>> [...] >> >> This looks wrong, I believe the package name is gdm3, not gdm. >> > > Thanks, corrected. > >> [...] Switching over to lightdm I can get a usable session without -legacy as long as I have -input-libinput. So I'm afraid I have no idea what's going on, or even how many problems there are. >>> >>> As I understand it, lightdm will start X as root unconditionally, so >>> that will work with or without -legacy. You want -legacy when using gdm >>> (or startx) plus have "old drivers". >>> >>> * @debian-x: Is the above correct? >>> >> Yes, any reasonable (read: KMS) setup will work fine without -legacy. >> In the absence of KMS (e.g. virtualbox, or new hardware not supported by >> the drivers we ship), you'll need either -legacy or a DM that hasn't >> been updated to starting X as non-root yet. >> >> Cheers, >> Julien >> > > Thanks for confirming. > > I also noticed that the wiki has some points on this: > https://wiki.debian.org/NewInStretch > > """ > Upgrade issues > > * For many Intel graphics chipsets, the Stretch X server will use the > modeset driver instead of the intel driver. The modeset driver may > require non-free firmware (firmware-misc-nonfree) to activate > features, even on systems which did not use this firmware under > Jessie. > > * For some older graphics chipsets, support has been relegated to > "legacy drivers", which require the old setuid X server to run. > Install xserver-xorg-legacy if you require one of these drivers. > """ > > I believe the release-notes has the latter point, but not the former. I > will add that now. > That doesn't sound correct either. * xserver-xorg-legacy is now installed by default, so I'm not sure we need this * the firmware requirement has nothing to do with the switch from the "intel" to the "modesetting" (not modeset) driver. Cheers, Julien
Bug#864166: release-notes: proofreading sweep - issues.dbk
Julien Cristau: > On 06/05/2017 01:50 PM, Niels Thykier wrote: >> Hi, >> >> CC'ing debian-x, who I hope can help us with some clarification. >> >> [...] > > This looks wrong, I believe the package name is gdm3, not gdm. > Thanks, corrected. > [...] >>> Switching over to lightdm I can get a usable session without -legacy >>> as long as I have -input-libinput. So I'm afraid I have no idea >>> what's going on, or even how many problems there are. >>> >> >> As I understand it, lightdm will start X as root unconditionally, so >> that will work with or without -legacy. You want -legacy when using gdm >> (or startx) plus have "old drivers". >> >> * @debian-x: Is the above correct? >> > Yes, any reasonable (read: KMS) setup will work fine without -legacy. > In the absence of KMS (e.g. virtualbox, or new hardware not supported by > the drivers we ship), you'll need either -legacy or a DM that hasn't > been updated to starting X as non-root yet. > > Cheers, > Julien > Thanks for confirming. I also noticed that the wiki has some points on this: https://wiki.debian.org/NewInStretch """ Upgrade issues * For many Intel graphics chipsets, the Stretch X server will use the modeset driver instead of the intel driver. The modeset driver may require non-free firmware (firmware-misc-nonfree) to activate features, even on systems which did not use this firmware under Jessie. * For some older graphics chipsets, support has been relegated to "legacy drivers", which require the old setuid X server to run. Install xserver-xorg-legacy if you require one of these drivers. """ I believe the release-notes has the latter point, but not the former. I will add that now. Thanks, ~Niels
Bug#864166: release-notes: proofreading sweep - issues.dbk
Niels Thykier wrote on Monday:
>> (It would be nice if the releasenotes *also* mentioned that things
>> have stopped depending on ifupdown, with the result that it runs the
>> risk of being automatically uninstalled by aptitude - a nasty
>> potential upgrade glitch not related to the one that keeps disabling
>> my wifi. But that's a content change, so it should go in a separate
>> bugreport, and maybe not for this page.)
>
> I have added a warning in the section about net-tools being deprecated
> and how to use iproute2.
A warning about ifupdown? I don't see anything in the version in SVN.
I would suggest adding an extra section immediately after the one
about net-tools, saying something like:
Reduced dependencies on ifupdown
The package netbase no
longer recommends ifupdown,
which may therefore be identified as unneeded after the upgrade to
stretch. This may be appropriate if your system uses
network-manager, but if
interfaces are still defined in
/etc/network/interfaces then ifupdown will need to be marked as
manually installed, for instance by running:
apt-mark manual ifupdown
I do see an added warning about evdev being deprecated in favour of
libinput, but it isn't accurate. It claims "This section is only
relevant if you have tweaked or need to change the default Xorg input
configuration", which just isn't true: the change caught me even on a
vanilla lightdm setup with ordinary keyboard and mouse. Until I
discovered and installed xserver-xorg-input-libinput (new in stretch)
my system was crippled. Advice on how to tweak libinput to support
fancy features does nothing to help users avoid this fate! (Also, the
title "Desktops will migrate..." is wrong; this has nothing to do with
desktops.)
Meanwhile my attempts to track down the bugs in networking.service and
startx have come to a dead end, so I'll just have to hope they were
problems with my setup and won't hit everyone else. The networking
one at least was easily fixed by the pending reboot.
However, the new version in SVN does have some new material, with some
new language errors:
Index: issues.dbk
===
--- issues.dbk (revision 11588)
+++ issues.dbk (working copy)
@@ -906,9 +914,10 @@
+
And come to think of it there should be lots more of these throughout
this section. Added in the attached patch.
-Harmeless Unespaced ... in regex is deprecated, ...
warnings during upgrade
+Harmless Unescaped ... in regex is deprecated, ...
warnings during upgrade
Smelling pistakes.
- During the upgrade, you may see some warning like:
+ During the upgrade, you may see some warnings like:
Number agreement.
Unescaped left brace in regex is deprecated, passed through in regex; marked
by -- HERE in m/^(.*?)(\\)?\${ -- HERE ([^{}]+)}(.*)$/ at
/usr/share/perl5/Debconf/Question.pm line 72.
Unescaped left brace in regex is deprecated, passed through in regex; marked
by -- HERE in m/\${ -- HERE ([^}]+)}/ at
/usr/share/perl5/Debconf/Config.pm line 30.
@@ -915,7 +924,7 @@
- These are harmless and happens if perl-base is upgraded before the
debconf package.
Number agreement.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Index: issues.dbk
===
--- issues.dbk (revision 11588)
+++ issues.dbk (working copy)
@@ -192,6 +192,7 @@
+
Behavior changes of PIE for system administrators and developers
@@ -529,6 +530,7 @@
+
Changes to the Xorg graphical environment
This section describes some of the major changes related to the
@@ -622,6 +624,7 @@
+
Upstart removed
Due to the lack of upstream maintainers,
the Upstart init system has been removed from stretch.
@@ -676,6 +679,7 @@
+
The debhelper tool now generates dbgsym packages by default
@@ -707,6 +711,7 @@
+
OpenSSL related changes
The openssl application expects option arguments before
@@ -743,6 +748,7 @@
+
Perl changes that may break third-party software
@@ -802,6 +808,7 @@
+
PostgreSQL PL/Perl incompatibility
The PostgreSQL PL/Perl procedural language package in jessie is
@@ -817,6 +824,7 @@
+
net-tools will be
deprecated in favor of iproute2
@@ -906,9 +914,10 @@
-Harmeless Unespaced ... in regex is deprecated, ... warnings during upgrade
+
+Harmless Unescaped ... in regex is deprecated, ... warnings during upgrade
- During the upgrade, you may see some warning like:
+ During the upgrade, you may see some warnings like:
Unescaped left brace in
Bug#864166: release-notes: proofreading sweep - issues.dbk
Hi, Am Dienstag 6. Juni 2017 schrieb Baptiste Jammet: > Finally, I was only saying that we could keep the entity, > even if it's not used in english. This appears in po files, > and we can translate to . And that's exactly how we do it for German. Holger -- Sent from my Jolla phone http://www.jolla.com/
Bug#864166: release-notes: proofreading sweep - issues.dbk
Hi, Dixit Justin B Rye, le 06/06/2017 : >The real question is why French gets to use capitalised releasenames >if English doesn't I think the idea was that release names are proper nouns (from the toys). And grammatical rules are not the same. > - after all, if the idea is that "stretch" is a >product-name then it should be universally lowercase even in German >(cf. "iPad"). I will discuss it on l10n-french. >Niels Thykier wrote: >> Can translators re-map entities? But we can define our own (in XX/language.ent) if necessary. Finally, I was only saying that we could keep the entity, even if it's not used in english. This appears in po files, and we can translate to . Baptiste pgpyUfCyuRiWe.pgp Description: OpenPGP digital signature
Bug#864166: release-notes: proofreading sweep - issues.dbk
Niels Thykier wrote: > Baptiste Jammet: >> Just for info, french translations (and maybe others ?) use capitalized >> release names. > > Can translators re-map entities? If so, the languages, where this is > necessary, could remap to "Stretch" instead of "stretch". > And then it would be consistently lowercase in English and consistently > title-case in French, etc. No, be careful: in some places means the literal string used in APT sources-list files. The real question is why French gets to use capitalised releasenames if English doesn't - after all, if the idea is that "stretch" is a product-name then it should be universally lowercase even in German (cf. "iPad"). My preferred solution would be to switch over to calling it "Stretch" even in English, but probably not a week before release. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#864166: release-notes: proofreading sweep - issues.dbk
Baptiste Jammet: > Le 05/06/2017 11:00, Niels Thykier a écrit : > >> Justin B Rye: >>> (It's not clear why >>> even exists.) >> >> Ack, we should probably remove (et al). Though that will >> be a post stretch thing. > Just for info, french translations (and maybe others ?) use capitalized > release names. > > Baptiste > Can translators re-map entities? If so, the languages, where this is necessary, could remap to "Stretch" instead of "stretch". And then it would be consistently lowercase in English and consistently title-case in French, etc. Thanks, ~Niels
Bug#864166: release-notes: proofreading sweep - issues.dbk
Le 05/06/2017 11:00, Niels Thykier a écrit : Justin B Rye: (It's not clear why even exists.) Ack, we should probably remove (et al). Though that will be a post stretch thing. Just for info, french translations (and maybe others ?) use capitalized release names. Baptiste
Bug#864166: release-notes: proofreading sweep - issues.dbk
On 06/05/2017 01:50 PM, Niels Thykier wrote: > Hi, > > CC'ing debian-x, who I hope can help us with some clarification. > > Justin B Rye: >> Niels Thykier wrote: This change only applies if your X Display Manager supports -running X as rootless (or if you start X manually via +running X without root privileges (or if you start X manually via startx). Currently the only known display -manager supporting this is gdm. Other display managers simply +manager supporting this is >>> role="package">gdm. +Other display managers simply start X as root regardless of this change. This looks wrong, I believe the package name is gdm3, not gdm. [...] This way of phrasing it makes it really difficult to work out that using startx *does* require the installation of xserver-xorg-legacy. >>> >>> Sadly, then I have confused you. Assuming the system meets the >>> requirements, then the following will *not* require root: >>> >>> * startx (from a virtual terminal "owned" by the current user) >>> * gdm (which knows how to start X without using root) >> >> I was assuming otherwise because the first symptom I ran into was that >> running startx in the absence of xserver-xorg-legacy gave me an X >> session with non-functional mouse and keyboard. >> >> But when I check now, installing every available xserver-xorg-* >> package in main including -legacy as well as -input-libinput makes no >> difference to that. On a testbed stretch machine with functional >> logind and so on but with an old KMS-incapable graphics card, I >> haven't found any way of making startx usable. >> > > Not sure what is going there. But I haven't used startx for years until > I learned of this feature, so I am probably not the right person to ask > what is going on/why it doesn't work. > >> Switching over to lightdm I can get a usable session without -legacy >> as long as I have -input-libinput. So I'm afraid I have no idea >> what's going on, or even how many problems there are. >> > > As I understand it, lightdm will start X as root unconditionally, so > that will work with or without -legacy. You want -legacy when using gdm > (or startx) plus have "old drivers". > > * @debian-x: Is the above correct? > Yes, any reasonable (read: KMS) setup will work fine without -legacy. In the absence of KMS (e.g. virtualbox, or new hardware not supported by the drivers we ship), you'll need either -legacy or a DM that hasn't been updated to starting X as non-root yet. Cheers, Julien
Bug#864166: release-notes: proofreading sweep - issues.dbk
Hi, CC'ing debian-x, who I hope can help us with some clarification. Justin B Rye: > Niels Thykier wrote: >>> >>> >>> This change only applies if your X Display Manager supports >>> -running X as rootless (or if you start X manually via >>> +running X without root privileges (or if you start X manually via >>> startx). Currently the only known display >>> -manager supporting this is gdm. Other display managers simply >>> +manager supporting this is >> role="package">gdm. >>> +Other display managers simply >>> start X as root regardless of this change. >>> >>> >>> >>> [...] >>> >>> This way of phrasing it makes it really difficult to work out that >>> using startx *does* require the installation of xserver-xorg-legacy. >>> >> >> Sadly, then I have confused you. Assuming the system meets the >> requirements, then the following will *not* require root: >> >> * startx (from a virtual terminal "owned" by the current user) >> * gdm (which knows how to start X without using root) > > I was assuming otherwise because the first symptom I ran into was that > running startx in the absence of xserver-xorg-legacy gave me an X > session with non-functional mouse and keyboard. > > But when I check now, installing every available xserver-xorg-* > package in main including -legacy as well as -input-libinput makes no > difference to that. On a testbed stretch machine with functional > logind and so on but with an old KMS-incapable graphics card, I > haven't found any way of making startx usable. > Not sure what is going there. But I haven't used startx for years until I learned of this feature, so I am probably not the right person to ask what is going on/why it doesn't work. > Switching over to lightdm I can get a usable session without -legacy > as long as I have -input-libinput. So I'm afraid I have no idea > what's going on, or even how many problems there are. > As I understand it, lightdm will start X as root unconditionally, so that will work with or without -legacy. You want -legacy when using gdm (or startx) plus have "old drivers". * @debian-x: Is the above correct? Thanks, ~Niels
Bug#864166: release-notes: proofreading sweep - issues.dbk
Niels Thykier wrote: >> >> >> This change only applies if your X Display Manager supports >> -running X as rootless (or if you start X manually via >> +running X without root privileges (or if you start X manually via >> startx). Currently the only known display >> -manager supporting this is gdm. Other display managers simply >> +manager supporting this is > role="package">gdm. >> +Other display managers simply >> start X as root regardless of this change. >> >> >> >> "Rootless" isn't a common way of expressing this even in technical >> jargon, and the word has a distracting non-technical sense (which even >> seems as if it would make sense here: it would mean "without a root >> window"). >> >> This way of phrasing it makes it really difficult to work out that >> using startx *does* require the installation of xserver-xorg-legacy. >> > > Sadly, then I have confused you. Assuming the system meets the > requirements, then the following will *not* require root: > > * startx (from a virtual terminal "owned" by the current user) > * gdm (which knows how to start X without using root) I was assuming otherwise because the first symptom I ran into was that running startx in the absence of xserver-xorg-legacy gave me an X session with non-functional mouse and keyboard. But when I check now, installing every available xserver-xorg-* package in main including -legacy as well as -input-libinput makes no difference to that. On a testbed stretch machine with functional logind and so on but with an old KMS-incapable graphics card, I haven't found any way of making startx usable. Switching over to lightdm I can get a usable session without -legacy as long as I have -input-libinput. So I'm afraid I have no idea what's going on, or even how many problems there are. -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package
Bug#864166: release-notes: proofreading sweep - issues.dbk
Control: tags -1 pending
Justin B Rye:
> Package: release-notes
> Severity: wishlist
>
> All of these are "stylistic", and could thus be put off until after
> the release if we have to; they include some pretty annoying errors,
> but nothing that would stop readers understanding what's intended.
>
Thanks. I have applied almost all of it (except for one case of ""
-> "Text", where there were no content/typographical cases as far as I
could tell - I didn't want unnecessary fuzzy texts for the translators).
> [...]
>
> In all the pages I've reviewed so far the dominant standard is
> lowercase "stretch", even when it appears in an otherwise capitalising
> context such as the start of a sentence. (It's not clear why
> even exists.)
>
Ack, we should probably remove (et al). Though that will
be a post stretch thing.
> [...]
> @@ -91,35 +92,42 @@
> The list of obsolete packages includes:
>
>
> - Most "-dbg" packages have been removed from the main
> - archive. They have been replaced by "-dbgsym" packages that
> - are available from the "debian-debug" archive. Please see
> + Most -dbg packages have been removed
> +from the main archive. They have been replaced by
> +-dbgsym packages that are available from the
> +debian-debug archive. Please see
>
>
>
> Just standardising the use of markup. Or maybe some of them should be
> instead? Anyway, reserve ASCII-quotes for the commandline.
>
I think is more accurate. I have used that.
> [...]
>
> Consistency again. Last time I checked docbook actually supported
> , but maybe that would require some sort of extra setup.
>
If I use , it does compile... but the content is no longer
boldface, so something needs to change at least. But agreed,
would be so much better.
> [...]
>
> (It would be nice if the releasenotes *also* mentioned that things
> have stopped depending on ifupdown, with the result that it runs the
> risk of being automatically uninstalled by aptitude - a nasty
> potential upgrade glitch not related to the one that keeps disabling
> my wifi. But that's a content change, so it should go in a separate
> bugreport, and maybe not for this page.)
>
I have added a warning in the section about net-tools being deprecated
and how to use iproute2.
> [...]
> may affect your system.
>
>
> - APT now fetches files with an unprivileged user
> ("_apt")
> + APT now fetches files as an unprivileged user
> (_apt)
>
>
> This sounded as if it was talking about "files with an unprivileged
> user"; instead make it clear that it's talking about doing the
> fetching as that user.
>
> (Or should user/groupnames be in s or something? At any
> rate, not ASCII quotes.)
>
I went with .
> [...]
>
> @@ -523,9 +532,10 @@
>
>
> This change only applies if your X Display Manager supports
> -running X as rootless (or if you start X manually via
> +running X without root privileges (or if you start X manually via
> startx). Currently the only known display
> -manager supporting this is gdm. Other display managers simply
> +manager supporting this is role="package">gdm.
> +Other display managers simply
> start X as root regardless of this change.
>
>
>
> "Rootless" isn't a common way of expressing this even in technical
> jargon, and the word has a distracting non-technical sense (which even
> seems as if it would make sense here: it would mean "without a root
> window").
>
> This way of phrasing it makes it really difficult to work out that
> using startx *does* require the installation of xserver-xorg-legacy.
>
Sadly, then I have confused you. Assuming the system meets the
requirements, then the following will *not* require root:
* startx (from a virtual terminal "owned" by the current user)
* gdm (which knows how to start X without using root)
> @@ -556,23 +566,25 @@
> ~/.local/share/xorg/.
>
>
> - If these requirements are not possible, please install the
> + If these requirements cannot be met, please install the
> xserver-xorg-legacy
> package to reinstate the setuid Xorg.
>
>
>
> Material that should maybe go in a separate bugreport:
>
> It seems to me that this convoluted phrasing is going to trick a lot
> of users into getting unusable systems. If I have understood
> correctly, it would help enormously if it just gave a couple of
> examples -
>
> If these requirements cannot be met (for instance, if you're
> using startx or an old graphics card),
>
An example would be good. I will try to add one. :)
> And then there's the libinput issue, which turns out to be completely
> separate and needs its own entry in this list.
>
I have done a draft of that and committed it
Bug#864166: release-notes: proofreading sweep - issues.dbk
Package: release-notes Severity: wishlist All of these are "stylistic", and could thus be put off until after the release if we have to; they include some pretty annoying errors, but nothing that would stop readers understanding what's intended. Index: issues.dbk === --- issues.dbk (revision 11524) +++ issues.dbk (working copy) @@ -17,10 +17,10 @@ - Upgrade specific items for + Upgrade specific items for This section covers items related to the upgrade from - to + to @@ -42,7 +42,7 @@ This means that for all systems where /usr is a separate partition need to use an initramfs generator that will mount - /usr. All initramfs generators in do so. + /usr. All initramfs generators in do so. In all the pages I've reviewed so far the dominant standard is lowercase "stretch", even when it appears in an otherwise capitalising context such as the start of a sentence. (It's not clear why even exists.) @@ -50,9 +50,10 @@ FTP access to Debian hosted mirrors will be removed Debian hosted mirrors will stop providing FTP access. If you - have been using the ftp protocol in your sources.list, please - migrate to http. Please consider the following example for - migrating: + have been using the ftp: protocol in your + sources.list, please migrate to + http:. Please consider the following example + for migrating: deb http://deb.debian.org/debian stretch main deb http://deb.debian.org/debian-security stretch/updates main FTP is either a capitalised initialism or a literal string; and the string that needs to go in an APT sources-list file has a colon (we *don't* want people to search-and-replace ftp://ftp.debian.org into http://http.debian.org). Ideally we'd rephrase this not to assume the APT sources-list file is called sources.list, but that's going beyond a stylistic change. @@ -91,35 +92,42 @@ The list of obsolete packages includes: - Most "-dbg" packages have been removed from the main - archive. They have been replaced by "-dbgsym" packages that - are available from the "debian-debug" archive. Please see + Most -dbg packages have been removed + from the main archive. They have been replaced by + -dbgsym packages that are available from the + debian-debug archive. Please see Just standardising the use of markup. Or maybe some of them should be instead? Anyway, reserve ASCII-quotes for the commandline. The password managers fpm2 and kedpm are no longer maintained upstream. Please use another password - manager like pass, keepassx, or keepass2. Make sure that you - extract your passwords from fpm2 and kedpm before removing the packages. + manager like pass, + keepassx, or + keepass2. + Make sure that you extract your passwords from fpm2 and kedpm before removing the packages. Consistency again. Last time I checked docbook actually supported , but maybe that would require some sort of extra setup. The net-tools package - will be deprecated in favor of + is being deprecated in favor of iproute2. See or the https://www.debian.org/doc/manuals/debian-reference/ch05#_the_low_level_network_configuration;> - Debian reference manual for more informations. + Debian reference manual for more information. "Will be deprecated" tells me nothing - I'm pretty sure network-manager *will* one day be deprecated. If we're already moving away from it, it already *is* deprecated. But I'll assume this is just an English usage problem (like the pluralised "information") and classify it in with the stylistic bugs. (It would be nice if the releasenotes *also* mentioned that things have stopped depending on ifupdown, with the result that it runs the risk of being automatically uninstalled by aptitude - a nasty potential upgrade glitch not related to the one that keeps disabling my wifi. But that's a content change, so it should go in a separate bugreport, and maybe not for this page.) @@ -119,10 +123,10 @@ -Deprecated components for +Deprecated components for With the next release of (codenamed - ) some features will be deprecated. Users + ) some features will be deprecated. Users will need to migrate to other alternatives to prevent trouble when updating to . @@ -170,7 +174,7 @@ has an issue that can cause some programs compiled as position independent
