Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
> IMO Having the 'password/passphrase' throughout makes it awkward to
> read, and actually we've got one place where it still just says
> password, and fixing that would make it slightly worse IMO.
> 
> How about dropping the passphrase stuff?
> 
>   
> https://salsa.debian.org/philh/user-setup/-/commit/7c8dd1bd9d5c8596e7b8f82a19a075e0a5572ed7
> &
>   https://openqa.debian.net/tests/240582#step/passwords/1
> 
> which I think is more readable (and is probably fine now that we've
> dropped the stuff about password selection which could be read as
> suggesting that a password is expected to be a single word).

It all looks fine to me; as the screenshot shows, we use "password" as
a general cover-term all over the user interface anyway.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
>> Maybe instead of saying "use the system's initial user account to
>> become root" it should say "allow the system's initial user account
>> to gain administrative privileges"?  I'm not sure.  Oh, and we might
>> even want to mention the word "superuser", or then again we might not.
> 
> I think Diederik's suggestion of using 'root' for the account and
> 'super-user' for the privileges might be the way to go.

Looking at what I end up with after another couple of rounds of
fiddling with it I'm not sure if it's doing quite what you asked for,
but you still might want it so here it is:

-   Some account needs to have system administrative privileges. The
-   password/passphrase for that account should be something that
-   cannot be guessed.
+   Some account needs to be available with administrative super-user
+   privileges. The password/passphrase for that account should be
+   something that cannot be guessed.
.
To allow direct password-based access via the 'root' account, you
can set the password/passphrase for that account here.
.
-   Alternatively, you can lock root's password
+   Alternatively, you can lock the root account's password
by leaving this setting empty, and
instead use the system's initial user account
(which will be set up in the next step)
-   to become root. This will be enabled for you
-   by adding that user to the 'sudo' group.
+   to gain administrative privileges. This will be enabled for you by
+   adding that initial user to the 'sudo' group.
.
Note: what you type here will be hidden (unless you select to show it).

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
>> https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7
>>
>>   Template: passwd/root-password
>>   Type: password
>>   # :sl1:
>>   _Description: Root password/passphrase:
>>One needs a password/passphrase that grants
>>access to the 'root' (system administrative) account.
>>Be aware that a malicious or unqualified user
>>that obtains root access can have disastrous results,
>>so you should choose a password/passphrase that cannot be guessed.
>>It should not be a word found in dictionaries,
>>or something that could be easily associated with you.
>>
>> (Summary: You DO need a root password.)
> 
> No, as I said, what that's trying to say is that there needs to exist a
> password that one way or the other will let one get access to the root
> account (since otherwise one is not going to be able to admin the
> machine), but that is not neccesarily the same thing as a "root
> password", 
> 
> If it comes across as meaning that there needs to be a "root password",
> then it's not succeeding in expressing the nuance of the situation
> correctly, and we probably need to fix that (assuming that we can come
> up with a better wording that still fits in the space available).

Yes; even reading it suspecting that that might be what it was meant
to be saying I found it hard to read that interpretation into it.  The
line starting "One needs a password..." implies that this dialogue
deals with the need for the particular *password* that gives access to
the root *account* - the obvious interpretation is that it's talking
about the "Root password/passphrase" in the Description.  It takes some
mental contortions to see that my own login password might also be
thought of as doing that, and further, that this dialogue can be seen
as creating (or no, I mean causing the existence of) such a password.

But I notice now that the way I've phrased it means users aren't
implicitly warned that a sudo-privileged user account needs a good
password, so maybe I need another coffee and a think...

>>.
>>To allow direct password-based access to root,
>>you should set the 'root' password/passphrase here.
>>.
>>Alternatively, you can lock root's password
>>by leaving this setting empty, and
>>instead use the system's initial user account
>>(which will be set up in the next step)
>>to become root. This will be enabled for you
>>by adding that user to the 'sudo' group.
>>.
>>Note: what you type here will be hidden (unless you select to show it).
>>
>> (Summary: You DON'T need a root password.)
>>
>> Suggested rewrite (short version):
>>
>>  _Description: Root password/passphrase:
>>   To allow direct password/passphrase-based access to the 'root'
>>   (system administrative) account you can set it up here.
>>   To protect your system you should not use one that can be guessed.
>>   .
>>   Alternatively, you can lock root's password
>>by leaving this setting empty, and
>>instead use the system's initial user account
>>(which will be set up in the next step)
>>to become root. This will be enabled for you
>>by adding that user to the 'sudo' group.
>>.
>>Note: what you type here will be hidden (unless you select to show it).
> 
> This is certainly better than good enough, so I'd be fine with this too.

Post-coffee (also fixing that wobbly indent):

   Some account needs to have system administrative privileges. The
   password/passphrase for that account should be something that
   cannot be guessed.
   .
   To allow direct password-based access via the 'root' account, you
   can set the password/passphrase for that account here.
   .
   Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

Maybe instead of saying "use the system's initial user account to
become root" it should say "allow the system's initial user account
to gain administrative privileges"?  I'm not sure.  Oh, and we might
even want to mention the word "superuser", or then again we might not.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
> Justin B Rye  writes:
>> Philip Hands wrote:
>>> Justin B Rye  writes:> ...
>>> The reason behind that structure was supposed to be that one definitely
>>> needs _a_ password, but not necessarily a root password, so the password
>>> advice applies to whichever password you'll decide to grant root access
>>> to, which might not be set here.
>>
>> This template is specifically about the "Root password/passphrase";
> 
> Well, sort-of, except that the user's response (whether to leave this
> blank or not) modifies what happens with the user account's permissions,
> so it's also about explaining the way that logic works in the installer
> and what that will do to the target system.
>
>> probably I should have quoted the patch I was looking at, which starts
>> with "One needs a password/passphrase that grants access to the 'root'
>> (system administrative) account" but goes on to say "Alternatively,
>> you can lock root's password by leaving this setting empty".
> 
> I'm intimately familiar with the patches you're reading, so I feel like
> this comment suggests that we may be talking past one another somehow.

Yes, this is a common problem: you're so familiar with what we need
it to say that you aren't noticing what the text currently does say.

https://salsa.debian.org/installer-team/user-setup/-/commit/77c1517fade367bc465da2a5908c5ac47dd8bba7

  Template: passwd/root-password
  Type: password
  # :sl1:
  _Description: Root password/passphrase:
   One needs a password/passphrase that grants
   access to the 'root' (system administrative) account.
   Be aware that a malicious or unqualified user
   that obtains root access can have disastrous results,
   so you should choose a password/passphrase that cannot be guessed.
   It should not be a word found in dictionaries,
   or something that could be easily associated with you.

(Summary: You DO need a root password.)
   .
   To allow direct password-based access to root,
   you should set the 'root' password/passphrase here.
   .
   Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

(Summary: You DON'T need a root password.)

Suggested rewrite (short version):

 _Description: Root password/passphrase:
  To allow direct password/passphrase-based access to the 'root'
  (system administrative) account you can set it up here.
  To protect your system you should not use one that can be guessed.
  .
  Alternatively, you can lock root's password
   by leaving this setting empty, and
   instead use the system's initial user account
   (which will be set up in the next step)
   to become root. This will be enabled for you
   by adding that user to the 'sudo' group.
   .
   Note: what you type here will be hidden (unless you select to show it).

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Philip Hands wrote:
> Justin B Rye  writes:
>> It needs a small amount of rephrasing, but the most important problem
>> is that it starts by saying you need to set a password and then goes
>> on to suggest that you might not need to set a password.  Maybe that
>> can be fixed by rearranging things slightly...
>>
>>  Template: passwd/root-password
>>  Type: password
>>  # :sl1:
>>  _Description: Root password/passphrase:
>>   To allow direct password/passphrase-based access to the 'root'
>>   (system administrative) account you can set it up here.
>>   The results can be disastrous if a malicious or incompetent user
>>   obtains root access, so you should not set one that can be guessed,
>>   found in dictionaries, or easily associated with you.
>>   .
>>   Alternatively, you can lock root's password
>>   by leaving this setting empty, and
>>   instead use the system's initial user account
>>   (which will be set up in the next step)
>>   to become root. This will be enabled for you
>>   by adding that user to the 'sudo' group.
>>   .
>>   Note: what you type here will be hidden (unless you select to show it).
>>
>> Does this still feel like the same advice?
> 
> The reason behind that structure was supposed to be that one definitely
> needs _a_ password, but not necessarily a root password, so the password
> advice applies to whichever password you'll decide to grant root access
> to, which might not be set here.

This template is specifically about the "Root password/passphrase";
probably I should have quoted the patch I was looking at, which starts
with "One needs a password/passphrase that grants access to the 'root'
(system administrative) account" but goes on to say "Alternatively,
you can lock root's password by leaving this setting empty".

> I'm OK with the way you've phrased it, although my personal preference
> would be to simply drop the "disastrous" sentence if we use this
> version, because I think it breaks the straightforward flow of the text
> laying out the choice we're trying to get the user to make between the
> two available options. (I also rather doubt that anything we say at this
> point in the install will have the slightest influence on people's
> choice of password).

I can imagine people might be more likely to heed something shorter;
maybe it could be boiled down to

To allow direct password/passphrase-based access to the 'root'
(system administrative) account you can set it up here.
To protect your system you should not use one that can be guessed.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#1064617: Passwords should not be changed frequently

[Justin B Rye]

Holger Wansing wrote:
> @d-l10n-english: hey guys, we would like to get a proposal reviewed, 
> which aims to improve the root/user password screens in the installer.
> 
> Please find the related merge request at
> 

It needs a small amount of rephrasing, but the most important problem
is that it starts by saying you need to set a password and then goes
on to suggest that you might not need to set a password.  Maybe that
can be fixed by rearranging things slightly...

 Template: passwd/root-password
 Type: password
 # :sl1:
 _Description: Root password/passphrase:
  To allow direct password/passphrase-based access to the 'root'
  (system administrative) account you can set it up here.
  The results can be disastrous if a malicious or incompetent user
  obtains root access, so you should not set one that can be guessed,
  found in dictionaries, or easily associated with you.
  .
  Alternatively, you can lock root's password
  by leaving this setting empty, and
  instead use the system's initial user account
  (which will be set up in the next step)
  to become root. This will be enabled for you
  by adding that user to the 'sudo' group.
  .
  Note: what you type here will be hidden (unless you select to show it).

Does this still feel like the same advice?

Otherwise the only thing I see is:

 Template: passwd/user-password
 Type: password
 # :sl1:
 _Description: Choose a password/passphrase for the new user:
  Make sure to select a strong password/passphrase, that cannot be guessed.
  ^
No comma needed there.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#684128: src:debian-installer: allow use of binary units in disk partitioner

[Justin B Rye]

Holger Wansing wrote:
> Thorsten Glaser :
>> Could this information (valid unit sufficēs) be added to the dialogue
>> where the size is entered? Screen space should suffice.
[...]
> CC'ing debian-l10n-english for template review (three identical additions
> in two packages).
[...]
>   Hint: "max" can be used as a shortcut to specify the maximum size, or
>   enter a percentage (e.g. "20%") to use that percentage of the maximum size.
> + You can specify partition sizes in decimal units (like MB or GB) as well as
> + in binary units (like GiB or TiB).

Looks good to me.  Mind you, this makes the passive voice in the first
line a bit more of a stylistic and syntactic mismatch, so I might
suggest changing it to

Hint: you can use "max" as a shortcut to specify the maximum size, or

throughout...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Review for the non-free-firmware template in apt-setup

[Justin B Rye]

Philip Hands wrote:
>>> _Description: Use non-free firmware?
>>>  Some non-free firmware has been made to work with Debian. Though this
>>
>> The phrasing "made to work with" has always struck me as poor, since
>> there are two obvious misinterpretations - "created in order to work
>> on" or "forced to work on" Debian.  All we mean is things are
>> organised so that it's made *available* for use on Debian.  But is
>> there a better short way of saying that?  At any rate I don't think
>> it's worth slowing down this update.
> 
> How about "packaged alongside"?
> 
> Some non-free firmware has been packaged alongside Debian. Though this
> [...]

That's is a more straightforward way of saying it if our audience is
already familiar with all the terminology of developers "packaging"
software for distributions, but the existing phrasing seems to be
going to some lengths to avoid that jargon.  If we're going to change
that then the whole thing would need to be rethought.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Review for the non-free-firmware template in apt-setup

[Justin B Rye]

Cyril Brulebois wrote:
> (I seem to remember d-l-e is where people could ask for some review,
> making sure original strings are fine before asking people to translate
> anything, hence the copy; plus Holger for the sublevel stuff towards the
> end.)

tldr: looks good to me.
 
> Quick update: I think I have hw-detect and debian-cd mostly ready at
> this point (and selected packages are currently being moved from
> non-free to non-free-firwmare by their maintainers), and I'm moving on
> to polishing apt-setup.
> 
> At the moment we have the following templates, only used at priority low
> (expert mode), asking whether contrib and/or non-free should be enabled:
> 
> Template: apt-setup/contrib
> Type: boolean
> Default: false
> # :sl1:
> _Description: Use contrib software?
>  Some additional software has been made to work with Debian. Though this
>  software is free, it depends on non-free software for its operation. This
>  software is not a part of Debian, but standard Debian tools can be
>  used to install it.
>  .
>  Please choose whether you want this software to be made available to you.
> 
> Template: apt-setup/non-free
> Type: boolean
> Default: false
> # :sl1:
> _Description: Use non-free software?
>  Some non-free software has been made to work with Debian. Though this
>  software is not at all a part of Debian, standard Debian tools can be 
> used
>  to install it. This software has varying licenses which may prevent you
>  from using, modifying, or sharing it.
>  .
>  Please choose whether you want to have it available anyway.
> 
> Therefore I've drafted the following for apt-setup/non-free-firmware:
> 
> Template: apt-setup/non-free-firmware
> Type: boolean
> Default: false
> # :sl5:
> _Description: Use non-free firmware?
>  Some non-free firmware has been made to work with Debian. Though this

The phrasing "made to work with" has always struck me as poor, since
there are two obvious misinterpretations - "created in order to work
on" or "forced to work on" Debian.  All we mean is things are
organised so that it's made *available* for use on Debian.  But is
there a better short way of saying that?  At any rate I don't think
it's worth slowing down this update.

>  firmware is not at all a part of Debian, standard Debian tools can be 
> used
>  to install it. This firmware has varying licenses which may prevent you
>  from using, modifying, or sharing it.
>  .
>  Please choose whether you want to have it available anyway.
> 
> Differences:
>  - non-free → non-free-firmware
>  - software → firmware
>  - :sl1: → :sl5:
> 
> I don't think we need to go into more details about why there are
> different components, why non-free-firmware was split out of non-free,
> etc. After all, those questions are only asked in expert mode, and
> I'd hope expert users to have heard about our move to supporting this
> new non-free-firmware component… Hopefully we'll have some release notes
> about it, possibly installation guide updates, etc.

In theory users might even think "well, if it's possible that I'm not
allowed to *use* them I'd better read the licenses first", in which
case they'll need to go through some awkward contortions, and if we
aren't going into *those* details... (As far as I know it's only ever
stuff along the lines of "you aren't licensed to use this firmware on
hardware that it has no chance of working with", but I suppose there
*could* be firmware under a JSON-style "may only be used for good,
not evil" license.  Tough luck, lawful evil d-i users.)

> I've selected sublevel 5 instead of sublevel 1, to make sure this isn't
> going to hurt the translation status (which localechooser uses to warn
> against incomplete translations at the very beginning of the
> installation process). Since that template is only shown in expert mode,
> and since we're adding /pretty late/ in the release cycle, I'd be happy
> to have translations if translators jump on it, and “sed” the non-free
> on into non-free-firmware, but we shouldn't block on this… I'll let
> Holger comment about that part and possibly propose different plans.

Fortunately most translators should have a fairly easy job rendering
the English word "firmware" into their own language!
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#992034: installation-guide: Include a note on how to change init system during install

[Justin B Rye]

Holger Wansing wrote:
> Trying to integrate your suggestions, would then have

Thanks for making sense of it...
 
> + 
> + Customization
> + 
> + Using the shell (see ), the installation process
> + can be carefully customized, to fit exceptional use cases:
> + 
> + 
> +   Installing an alternative init system
> + 
> +  uses systemd as its default init system. However, other init
> + systems (such as sysvinit and OpenRC) are supported, and the
> + easiest time to select an alternative init system is during the
> + installation process. For detailed instructions on how to do so,
> + please see the  + 
> url="https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time;>Init
> + page on the Debian wiki.
> + 
> + 
> +   
> +  

Yes, that looks okay to me!
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#992034: installation-guide: Include a note on how to change init system during install

[Justin B Rye]

Justin B Rye wrote:
> Hmm.  That may have been boiled down *too* far, since there's no
> hint that it works by going to a shell.  So maybe that should have
> been in the intro?  (Sorry, can't remember the ulink syntax)
> 
>   As well as troubleshooting, the [[6.3.9.2|link]] also allows

Oops - what I intended to say here was [[6.3.9.2|shell]], i.e.
shell

>   further customization of the installation process to fit your
>   needs:
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#992034: installation-guide: Include a note on how to change init system during install

[Justin B Rye]

Holger Wansing wrote:
>> The more I look at the way the sections are organised the more I think
>> that the real problem is that "6.3.9 Troubleshooting" is already a
>> misfit.  There needs to be some clearer mention in 6.1 of the fact
>> that jumping to VT2 lets you issue commands behind d-i's back; the
>> only place that's explained is the "Troubleshooting" section, which
>> has been included in the list of d-i components where it doesn't
>> really belong.  If that was fixed, maybe there would be a natural
>> place to put a section on custom variations in the installation
>> process.
>> 
>> It clearly is permitted to promote things out of that list of
>> components into separate sections, since after all that's what has
>> been done with section 6.4 "Loading Missing Firmware", which has been
>> promoted out of 6.3.1 "Setting up Debian Installer and Hardware
>> Configuration".  So maybe a 6.5 "Troubleshooting and Customization"?
>> 
>> Unfortunately this would necessarily be a long way from the sort of
>> minimal patch that people were hoping for...
> 
> I'm not that unlucky with the Troubleshooting section, it in fact talks
> about existing d-i modules for such job (save-logs, start a shell and
> view debug info). And also the ordering of the sections looks more
> logically to me that way.

The only way I'm likely to make any progress towards fixing this bug
is by persuading myself I agree with you here!
 
> So, I tend to go with a 6.5 section like
> 
>+ 
>+ Customization
>+ 
>+ The installation process can be further customized to fit your needs:
>+ 
> 
> What do you think?

It might work.  Then it goes on:

  Installing an alternative init system
   
 uses systemd as its default init system. However, other
init systems (such as sysvinit and OpenRC) are supported, and the
easiest time to select an alternative init system is during the
installation process. For detailed instructions on how to do so,
please see the
https://wiki.debian.org/Init#Changing_the_init_system_-_at_installation_time;>Init
page on the Debian wiki.
   
  
 

Hmm.  That may have been boiled down *too* far, since there's no
hint that it works by going to a shell.  So maybe that should have
been in the intro?  (Sorry, can't remember the ulink syntax)

  As well as troubleshooting, the [[6.3.9.2|link]] also allows
  further customization of the installation process to fit your
  needs:

People might also want some echo of the Troubleshooting section's
cautionary note wedged in there; the minimal version would be to say
something like "careful customization" and/or "in exceptional cases".
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#992034: installation-guide: Include a note on how to change init system during install

[Justin B Rye]

Holger Wansing wrote:
>> @Justin?
> 
> Hmm, debian-l10n-english has vanished from the loop somehow.
> Therefore, I fear you lost track of this thread in the meantime ...

Thanks for spotting that.
 
> Maybe you could try to catch up starting from
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=992034#90
> and the follow-ups in the bug and give some feedback? 
> Thanks

In fact I'd also lost track of the fact that this particular thread is
about changes to the *installer* guide rather than the release notes.

 + 
 + Miscellaneous adaptions
 +
 +You may make custom adaptions of the installation process, to make it fit
 +your needs:
 +

Another vote against "adaption" (I've heard people use it, but usually
because they're confusing "adapt" and "adopt").  You've also got an
odd use of "may", and a slightly clunky repetition of "make" where all
you really need to say is something like "The installation process can
be adapted to fit your needs".  Except that this doesn't really feel
to me like a good way to try to fit the section into its context.

Philip Hands suggested the section would fit with its neighbours
better as

   Variations requiring manual intervention

which may be true, but this brings to my attention the point that it
seems to be promising to list plural variationS whereas in fact we've
only got this one.  Another problem with "manual intervention" is that
the installer guide tends to use the word "manual" to mean just "less
automated" - as in "manual" versus "guided" partitioning.

The more I look at the way the sections are organised the more I think
that the real problem is that "6.3.9 Troubleshooting" is already a
misfit.  There needs to be some clearer mention in 6.1 of the fact
that jumping to VT2 lets you issue commands behind d-i's back; the
only place that's explained is the "Troubleshooting" section, which
has been included in the list of d-i components where it doesn't
really belong.  If that was fixed, maybe there would be a natural
place to put a section on custom variations in the installation
process.

It clearly is permitted to promote things out of that list of
components into separate sections, since after all that's what has
been done with section 6.4 "Loading Missing Firmware", which has been
promoted out of 6.3.1 "Setting up Debian Installer and Hardware
Configuration".  So maybe a 6.5 "Troubleshooting and Customization"?

Unfortunately this would necessarily be a long way from the sort of
minimal patch that people were hoping for...
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)

Re: Bug#991969: D-I: news for Bullseye: help with firmware installation

[Justin B Rye]

Paul Gevers wrote:
> Before pushing, I hope to see comments from Justin.
> 
> Paul

> +Help with installation of firmware
> +
> +  More and more, peripheral devices require firmware to be loaded as
> +  part of the hardware initialization. To help deal with this problem,
> +  the installer has been improved. Based on a hardware ID to firmware
> +  file mapping, if some of the installed hardware requires firmware
> +  files to be installed, the code installs them automatically.
> +
> +
> +  Please note, that this new functionality is restricted to the

Only one minor comment: I'd drop the comma in "note, that".

> +  unofficial installer images with firmware included (see  +  
> url="#firmware_nonfree">#firmware_nonfree).
> +  The firmware is usually not DFSG compliant, so it is not possible to
> +  distribute it in Debian's main repository.
> +
> +
> +  If you experience problems related to (missing) firmware, you might
> +  want to read  +  
> url="https://www.debian.org/releases/bullseye/amd64/ch06s04.en.html#completing-installed-system;>the
> +  dedicated chapter of the installation-guide.
> +
> +

(I'm surprised that we can't link to ch06s04.html without the .en and
have it automatically handle translations.  Anyone know a way of doing
that?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Manually add firmware (or other) packages for installation?

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
> On 2/27/21 11:46 AM, Holger Wansing wrote:
>> John Paul Adrian Glaubitz  wrote (Sat, 27 Feb 
>> 2021 11:21:58 +0100):
>>> The point is: We separate free and non-free images for a very reason and if
>>> you add a mechanism that just silently enables non-free on a system that
>>> was installed with the free installer, you are defeating this separation.
>> 
>> 1. *I* do not do or change anything here. It's the case like this for ages!
> 
> Of course, you are. You are sending in a patch.

But is that patch one that "silently enables non-free" and "taints"
the official installer?  All I see it doing is giving expert users
more convenient access to the mechanism they can already use on the
console to get their hardware working properly.
 
If only we knew of a plausible use case for a kind of "additional
package" that someone might install this way *other* than firmware, I
suspect that would make this more palatable.  The nearest I can think
of is that I hear tales of people setting up a local repo with a
"LAN-standard package-set" metapackage.  Any takers?

>> 2. non-free does *NOT* be *silently* activated! The user is prompted for 
>> this,
>>and he needs to explicitly say YES to this option! 
>>And this question is only be asked in expert installation mode.
> 
> You are contradicting yourself. Earlier in the discussion you claim that the
> user just enters the name of the firmware packages and the installer does
> the rest of the work.

*If* the user has configured apt appropriately, it's already possible
to do this via a console.  Holger's idea is that if people often need
to do that, the installer could just offer a dialog.

>>> The firmware issue isn't new and the stance has always been that we separate
>>> free and non-free installers for a very reason. People that use the free 
>>> installers
>>> expect that the system installed contains DFSG-compatible components only.
>> 
>> Firmware issues are not new, that's correct.
>> But with latest kernels, it seems that missing firmware for graphics cards 
>> more often than in the past leads to a completely dark or garbled screen
>> (given the amount of user reports, I already mentioned).
>> I guess this is a result of some "policy changing" in the kernel, how to 
>> act with firmware blobs and what to do, if firmware is missing (?).
> 
> Well, people need to use the firmware installer in this case and looking 
> through
> the on debian-devel, I'm not the only DD who takes this stance [1].

It has always been possible to use the official installer on a system
that's eventually going to need firmware, as long as you're willing to
fetch that firmware from the network, or a thumbdrive, or whatever.
It may be that we'd prefer such users to use the tainted installer (in
which case the signposts in that direction should really be more
prominent), but it isn't *compulsory*.  After all, the user might have
already used the official installer on any number of workstations that
didn't need firmware.  Oh, but here's one that has annoyingly ended up
with a different graphics card!  So they can either go and get a whole
new set of CDs... or just use the tried-and-tested official installer
again but with a short detour via expert mode.
 
>>> A user wants all firmware to be available after installation, they are 
>>> advised
>>> to use the non-free firmware installers.
>> 
>> Again:
>> even if they decide to use this non-free installer with the graphics-card
>> firmware included, this installer *does*not* install the firmware for
>> graphics cards!
>> (leaving users with a unusable system at first boot.)
> 
> Then you don't need to change debian-installer for that. Just adjust the 
> package
> lists for the non-free CD.

I think Holger is saying that the process for detecting the need for
firmware is less effective than you're assuming.  If so, putting more
non-free firmware on CDs won't help with this.

If the user installing Debian is going to have to install firmware at
some point, and you'd be willing to let them use a non-free installer,
I don't follow why you're so offended by the possibility that they'd
prefer to get as far as possible via the route that's less tainted
with non-freeness.  They can use the official installer, but then add
that one graphics firmware package via apt.  If your policy is that
the official installer should never make it possible to install any
software from outside main, even via expert mode, it seems odd that it
even *has* a package source configuration stage...
 
>> Only the "switch-to-second-console-and-install-there-by-hand" solution, you
>> mentioned already, can do this.
>> 
>> This patch should only be a user-friendly variant of the above 
>> second-console 
>> solution.
> 
> I don't think we need this particular solution and I prefer to keep the free
> images untainted. We can adjust the package lists for the non-free CDs and
> have the firmware packages installed automatically.

The 

Re: Manually add firmware (or other) packages for installation?

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
>>> Wouldn't that be a policy violation? If the regular installer enables 
>>> non-free
>>> sources, I would consider those installer images to be not DFSG-compliant.
>> 
>> Don't know. Not a lawyer/policy specialist here.
>> Functionality exists for ages in the installer though...
> 
> The point is: We separate free and non-free images for a very reason and if
> you add a mechanism that just silently enables non-free on a system that
> was installed with the free installer, you are defeating this separation.

If the plan was for the free installer to make the APT sources
unconfigurable, I'm sorry to have to inform you that it doesn't work.

The normal way I use the Debian installer is to install an utterly
minimal system from a netinst image, reboot, and "apt install" from
there.  If I had a graphics card that required nonfree firmware, I
wouldn't be pulling that package off the installer anyway, so you
aren't entitled to assume anything from the fact I picked the Official
version.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Manually add firmware (or other) packages for installation?

[Justin B Rye]

Justin B Rye wrote:
> So we could add some extra hint about this in the intro:
> 
> This
> may already have been dealt with, but if the installer does not include
> non-free firmware packages, or could not detect the need for them, it
> may be necessary to fetch them manually at this stage.

On second thoughts, s/fetch/add/, since they *could* be on the
installer, just not detected-as-needed.  So

   Modern hardware (especially graphics cards or network devices) often needs
   to have nonfree firmware installed in order to be (fully) functional. This
   may already have been dealt with, but if the installer does not include
   non-free firmware packages, or could not detect the need for them, it may
   be necessary to add them manually at this stage.
   .
   If you know your hardware requires this, and you have enabled "non-free"
   package sources, you can list firmware packages here to have them installed.
   For AMD/ATI graphics cards you might want to install "firmware-amd-graphics";
   for Intel or Nvidia, "firmware-misc-nonfree".
   .
   Please note, that you can also use this dialog for installation of any other
   additional packages you want to have installed, not just firmware. Package
   names need to be space-separated.
   .
   If you don't know what to enter, just leave it blank to not install any
   additional packages.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Manually add firmware (or other) packages for installation?

[Justin B Rye]

Holger Wansing wrote:
>>Modern hardware (especially graphics cards or network devices) often needs
>>to have nonfree firmware installed in order to be (fully) functional. This
>>may already have been dealt with, but if not the firmware can be installed
>>at this stage.
> 
> Yes, a bit shorter and clearer.
[...]

>>If you know your hardware requires this, and you have enabled "non-free"
>>package sources, you can list firmware packages here to have them 
>> installed.
>>For AMD/ATI graphics cards you might want to install 
>> "firmware-amd-graphics";
>>for Intel or Nvidia, "firmware-misc-nonfree".
> 
> Ok.
> 
>> But what exactly is the context here?  If it hasn't happened already, does
>> that imply they weren't available on the installer itself and need to be
>> downloaded?  If the user has already had a chance to configure network APT
>> sources, it no longer matters whether the installer itself includes
>> non-free, unless of course they were hoping to download wifi firmware...
> 
> The point is:
> the current installer is unable to detect, if you have a graphics card, which
> driver requires nonfree firmware! So, even if you use some of the non-free 
> installation images with included firmware packages, the installer - as it is
> now - will NOT install firmware for your graphics card.
> In the worst case, the system will then be unable to display anything in X,
> no login screen, nothing. 
> What will users assume then, what happened? 
> "My system hangs when booting!" or "My system cannot display anything via
> my graphics card. Is the graphics driver broken?" or similar...

So we could add some extra hint about this in the intro:

This
may already have been dealt with, but if the installer does not include
non-free firmware packages, or could not detect the need for them, it
may be necessary to fetch them manually at this stage.

I'm assuming there's no point adding anything about wifi firmware on a
thumbdrive, since that needs to happen *before* the APT setup stage...

>>> + .
>>> + Please note, that you can also use this dialog for installation of any 
>>> other
>>> + additional packages you want to have installed, not just firmware. Package
>>> + names need to be space-separated.
>>> + .
>>> + If you don't know what to enter, just leave it blank to not install any
>>> + additional packages.
>>> +
>> 
>> Or just:
>> 
>> This dialog can also be used to install non-firmware packages, or left
>> blank to do nothing. Package names must be space-separated.
> 
> It's not clear enough to me, what's meant here with such formulation. It's 
> much
> shorter, but this way it tends to confuse the user, I fear.

Fair enough, your version doesn't have anything much wrong with it
apart from being longer.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Manually add firmware (or other) packages for installation?

[Justin B Rye]

Holger Wansing wrote:
> There have been no complains, so I'm asking debian-l10n-english for a string
> review of the attached strings now (in CC), and will push the result then 
> soon.

(I don't mind if this is wasted effort for text that won't be used.)

> index c413e88e..fece0893 100644
> --- a/debian/hw-detect.templates
> +++ b/debian/hw-detect.templates
> @@ -96,6 +96,29 @@ Type: text
>  # :sl1:
>  _Description: Checking for firmware...
>  
> +Template: hw-detect/firmware_packages_to_install
> +Type: string
> +# :sl2:
> +Description: Additional/firmware packages to be installed:
> + Modern devices (like graphics cards or network devices) tend to need 
> firmware
> + blobs to be loaded onto the device, to be (fully) functional. Probably such
> + firmware has already been installed during this installation, but there is
> + a chance (especially for graphics cards) that this did not happen yet.

There is such a thing as *free* firmware, but I'm going to assume that if
that was what we were dealing with it wouldn't need any special handling,
so you mean:

   Modern hardware (especially graphics cards or network devices) often needs
   to have nonfree firmware installed in order to be (fully) functional. This
   may already have been dealt with, but if not the firmware can be installed
   at this stage.

> + .
> + If you know you have such hardware in your system, you can enter the needed
> + firmware packages here for installation.
> + .
> + For AMD/ATI cards you might want to install "firmware-amd-graphics", for
> + Intel or Nvidia "firmware-misc-nonfree". Be aware that you will need to have
> + "non-free" package sources activated for this!

Wouldn't it be clearer to put that last part in with the "if"?

If you know your hardware requires this, and you have enabled "non-free"
package sources, you can list firmware packages here to have them installed.
For AMD/ATI graphics cards you might want to install 
"firmware-amd-graphics";
for Intel or Nvidia, "firmware-misc-nonfree".

But what exactly is the context here?  If it hasn't happened already, does
that imply they weren't available on the installer itself and need to be
downloaded?  If the user has already had a chance to configure network APT
sources, it no longer matters whether the installer itself includes
non-free, unless of course they were hoping to download wifi firmware...

> + .
> + Please note, that you can also use this dialog for installation of any other
> + additional packages you want to have installed, not just firmware. Package
> + names need to be space-separated.
> + .
> + If you don't know what to enter, just leave it blank to not install any
> + additional packages.
> +

Or just:

This dialog can also be used to install non-firmware packages, or left
blank to do nothing. Package names must be space-separated.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Install the GRUB boot loader on a hard disk

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
> On 3/18/20 3:26 PM, Justin B Rye wrote:
>> Sure, and indeed I nearly mentioned "floppy" disk.  But "hard disk"
>> isn't a case where the new thing has taken over the old meaning;
>> people don't generally say "pass me the hard disk" when they mean an
>> SD card.
> 
> That's because you are comparing apples and oranges. Despite most computers
> shipping with SSDs these days, people will still say "I'll install that
> the software onto hard-disk" simply because that has become a synonym
> for a disk built into your computer.

Possibly... Google mostly finds people using "install to hard disk"
used in contrast to "run as liveCD", which is mostly evidence that the
phrase occurs in old installer texts like this one, and we knew that.
 
> An SD card is considered a removable storage medium, hence you wouldn't
> use it in this context.

Good point, I was wandering off into scenarios that wouldn't go
through this dialogue anyway.

>> And when things change, we don't *have* to change the
>> definitions of our words to match the new things; we don't *have* to
>> redefine "floppy disk" to mean "USB thumbdrive" - and indeed we
>> didn't.  There are often alternative options.
> 
> In particular, the development of language doesn't follow logic
> and even science because the average Joe usually doesn't have
> the expert knowledge to use the correct terminology.
> 
>> What do you think of the options suggested so far?
>> 
>>>> I don't know what I'd suggest instead, but possibilities include:
>>>>  "Install the GRUB boot loader to hardware"
>>>>  "Install the GRUB boot loader on this system"
>>>>  "Install the GRUB boot loader on the system disk"
>>>>  "Install the GRUB boot loader to disk"
>>>>  "Install the GRUB boot loader to a non-volatile storage device"
>> 
>> And a new suggestion:
>> "Install the GRUB boot loader"
> 
> Well, the thing is that I think it's more important what the commonly
> used language is and if you use your Google-fu to check how common
> the sentence "install GRUB to hard disk" and ""install GRUB to SSD"
> is, you will understand what I mean.

That certainly proves that these strings occur in texts that google
indexes.  It doesn't tell us anything about whether the alternatives
that *aren't* used in those texts would communicate more effectively.
 
> While I understand the reasoning of this change, I don't think it
> actually helps improving the user experience.
> 
> I again have the impression that this is a change that is made
> for the sake of making a change and now we're searching for arguments
> to justify the change.

Personally I'm still only looking for opinions about the merits of the
various options.
 
> Normally, you make changes because you have identified a problem
> from user reports. But this is basically backwards, you see the
> need for a change and you're now trying to find a justification
> for it.

In the case of my nitpick about "install", I just went for the
strategy of documenting it as ambiguous-in-principle on
 https://wiki.debian.org/Glossary#install 
 
>>> You also have to keep in mind that this needs to be translated
>>> into other languages. I have the impression that a lot of these
>>> discussions about deprecating apparently older terms revolve
>>> around the English language only.
>> 
>> Well, that's good news, isn't it?  If it turns out it's only the
>> English version that has the problem and the translations are
>> futureproof, the translators won't need to do any work here.
> 
> For German:
> 
> - hardware - Hardware
> - this system - dieses System
> - hard disk - Festplatte
> - system disk - Systemplatte
> - storage medium - Speichermedium
> - disk - Platte (so a platter)
> - non-volatile storage device - nicht-fluechtiges Speichergeraet
> 
> So, if I asked my dad which one he finds easiest to understand, I can
> assure you that "Festplatte" is the term he would use for the built-in
> disk, independent of whether it's an SSD, an HDD, an MO-drive, a ZIP
> drive, an SD card, an NMVE card and so on, simply because he doesn't
> understand the difference of most of these and doesn't care.

Interesting - a "Platte" isn't necessarily circular (compare
"Tischplatte"), so maybe it's natural for it to cover solid-state 
devices.  Of course, English stopped really caring about that when we
started calling rigid squares "floppy disks".
 
>>>>> When are we going to rep

Re: Install the GRUB boot loader on a hard disk

[Justin B Rye]

Ben Hutchings wrote:
> On Wed, 2020-03-18 at 10:11 +0100, John Paul Adrian Glaubitz wrote:
>> According to that logic you would have to replace the save icon in every
>> desktop application because we're no longer using floppy disks.
> 
> That has already happened to many (most?) applications.

One alternative I've seen used is a piggy-bank icon, which is already
an example of the same sort of long-dead symbolism!  How many children
these days see the analogy between a piggy-bank and a piglet?  A few
centuries ago, you threw your leftovers to the family pig in the
expectation of eventually "cashing in" the investment...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Install the GRUB boot loader on a hard disk

[Justin B Rye]

John Paul Adrian Glaubitz:> 
> On 3/18/20 11:43 AM, Justin B Rye wrote:
>>> The majority of all users is able to perform the cognitive process to 
>>> that "hard disk" means "installation device" and "storage medium" here
>>> is very confusing since that normally refers to a data disk and not
>>> the system disk.
>> 
>> The trouble with "hard disk" is that it refers to one particular kind
>> of hardware, and users have no reason to expect debian-installer to be
>> using the kind of metaphorical language that requires a special
>> cognitive leap in the first place; so how are they going to know that
>> it will in fact work on an SSD?
> 
> Yes, why shouldn't it? Most people still call it BIOS, despite EFI being
> standard long time ago, fir example.
> 
> Our cars also don't have any dashboards anymore, TVs don't have screens,
> radio isn't necessarily transmitted using "radiation" anymore and so
> on and so forth.
> 
> I bet, if you do some research, you will find a large number of words
> that are being used in contexts where they don't make much sense
> anymore. Yet we keep using them for convenience purposes.

Sure, and indeed I nearly mentioned "floppy" disk.  But "hard disk"
isn't a case where the new thing has taken over the old meaning;
people don't generally say "pass me the hard disk" when they mean an
SD card.  And when things change, we don't *have* to change the
definitions of our words to match the new things; we don't *have* to
redefine "floppy disk" to mean "USB thumbdrive" - and indeed we
didn't.  There are often alternative options.

What do you think of the options suggested so far?

>> I don't know what I'd suggest instead, but possibilities include:
>>  "Install the GRUB boot loader to hardware"
>>  "Install the GRUB boot loader on this system"
>>  "Install the GRUB boot loader on the system disk"
>>  "Install the GRUB boot loader to disk"
>>  "Install the GRUB boot loader to a non-volatile storage device"

And a new suggestion:
"Install the GRUB boot loader"
 
> You also have to keep in mind that this needs to be translated
> into other languages. I have the impression that a lot of these
> discussions about deprecating apparently older terms revolve
> around the English language only.

Well, that's good news, isn't it?  If it turns out it's only the
English version that has the problem and the translations are
futureproof, the translators won't need to do any work here.

>>> When are we going to replace "REWIND", "PAUSE", F. FWD", "PLAY" and
>>> "RECORD" on playback devices since we are no longer dealing with tapes
>>> and "re-cording" and "re-winding" does not actually reflect anymore
>>> what's happening?
>> 
>> "Record" and "cord" are etymologically unconnected, so the only dead
>> metaphor in that list is "REWIND" - and why use that when you could
>> use the self-explanatory standard ideogram "⏪"?
> 
> I don't think that's the case. Sony used to call their tape recorders
> "tape corder" which is why all cassette decks started with a model
> number "TC-".

Would you like to make a bet?  *My* guess is that it's from "cor"
meaning "heart".

(I always assumed those were Sony tape *cassette* recorders...)

>> (Mind you, when I was first using a GNU/Linux desktop back in the
>> nineties it took me *ages* to discover that the only way of getting a
>> simple volume control knob was to pretend I was a professional DJ and
>> search for a "mixer" application.  Nobody *starts* as an expert!)
> 
> Exactly. Terminology doesn't necessarily have to be self-explaining
> but consistent. Don't forget that people also want to be able to
> do some Google search when they have problems and unusual terminology
> in Debian doesn't necessarily make it simpler.

That was an example where developers standardised on an unintelligible
piece of terminology and are *still* using it for no better reason
than tradition; I'm standing up and saying that *I'm* one of the
people this adversely affected, back in the days before google.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Install the GRUB boot loader on a hard disk

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
> On 3/18/20 9:58 AM, Holger Wansing wrote:
>> while investigating a grub installation failure, I came across the main menu
>> entry of grub-installer: 
>>  "Install the GRUB boot loader on a hard disk"
>> 
>> This is no longer optimal, since we have flash/SSD drives, SD cards etc. 
>> where
>> OS'es are installed on.
>> 
>> So this should be changed, similar to the "rename 'CD/CD-ROM' into 
>> 'installation media' approach".
> 
> According to that logic you would have to replace the save icon in every
> desktop application because we're no longer using floppy disks.

As far as I'm aware, that persists because there's no obvious better
option; if one ever turns up, I certainly hope that developers will
switch over to it.  Not that I think "storage medium" is much of an
improvement in this case.

> The majority of all users is able to perform the cognitive process to 
> that "hard disk" means "installation device" and "storage medium" here
> is very confusing since that normally refers to a data disk and not
> the system disk.

The trouble with "hard disk" is that it refers to one particular kind
of hardware, and users have no reason to expect debian-installer to be
using the kind of metaphorical language that requires a special
cognitive leap in the first place; so how are they going to know that
it will in fact work on an SSD?

I don't know what I'd suggest instead, but possibilities include:
 "Install the GRUB boot loader to hardware"
 "Install the GRUB boot loader on this system"
 "Install the GRUB boot loader on the system disk"
 "Install the GRUB boot loader to disk"
 "Install the GRUB boot loader to a non-volatile storage device"

(As it happens I've never much liked "install" here, either; usually
an "install" on Debian means something like "apt install grub2" (which
installs a grub boot loader package on my system).  What I'm doing
here is directly overwriting my boot sector with the GRUB boot loader
code.  But to get anywhere with this nitpick I'd probably need to
persuade the GRUB developers, which seems unlikely.)

> When are we going to replace "REWIND", "PAUSE", F. FWD", "PLAY" and
> "RECORD" on playback devices since we are no longer dealing with tapes
> and "re-cording" and "re-winding" does not actually reflect anymore
> what's happening?

"Record" and "cord" are etymologically unconnected, so the only dead
metaphor in that list is "REWIND" - and why use that when you could
use the self-explanatory standard ideogram "⏪"?

(Mind you, when I was first using a GNU/Linux desktop back in the
nineties it took me *ages* to discover that the only way of getting a
simple volume control knob was to pretend I was a professional DJ and
search for a "mixer" application.  Nobody *starts* as an expert!)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [installer] One more template change?

[Justin B Rye]

Holger Wansing wrote:
> With the changings applied like shown above, "low" means "all questions
> having low set in their preferences" plus all mentioned before in the
> list (this is, what the newly added "also" says. Or at least this is how
> I would understand it and what I had in mind).
> 
> As you wrote above: 
>   a) only X
>   b) also Y
>   c) also Z
> 
> That would mean:
>   a = X
>   b = Y + X
>   c = Z + Y + X
> 
> That would work, right?
> 
> But apparently this seems to make everything more and more complicated, and 
> thus 
> is not easier as we have it now?
> And changing the whole system might totally confuse people, who have learned
> to live with the status quo?
> So it's not an improvement, but a worsening?

Well, the problem (or one aspect of it) is that when we say "low
priority" we effectively mean "maximum verbosity".  "Low" doesn't mean
that we're asking to do anything less, it means that the filtering
ignores anything with a priority lower than low (i.e. "never filter
out any questions").

Thanks for mentioning the word "threshold", though, because it *might*
be useful to to describe it as setting a low threshold.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [installer] One more template change?

[Justin B Rye]

Holger Wansing wrote:
> Furthermore, I have to advance this whole review a bit, since I noticed that
> I did not included all relevant terms. I'm sorry for this!

Another of the disadvantages of working from the message strings
rather than the template file.

> 
> The complete dialog looks like this:
> 
> snip--
[...]
> snap---
> 
> Applying the already suggested changings, and adding some more changings
> to the other strings, that would lead to something like:
> 
> 
> snip---
> 
> Change debconf priority

One of the old rules we tried to apply in debconf dialogue reviews
was that debconf should never refer to itself, since users have no
reason to care how the dialogues are being implemented.  Here it does
at least help to convey the fact that this isn't setting the priority
of the *installer*.  (Mind you, it isn't setting the priority of
debconf, either - it's setting the priority-cutoff for package
configuration dialogues.)

> 
> Packages that use debconf for configuration prioritize the questions they
> might ask you. Only questions with a certain priority are
> actually shown to you; all less important questions are skipped.

Is "packages that use debconf for configuration" a fossil from the
days when some packages didn't?  The Debian configuration management
interface specification is solidly enshrined in policy, so any
hypothetical alternative to debconf would have to be indistinguishable
from a user's point of view anyway (and might as well be referred to
as an implementation of debconf).

I'd suggest:

  Change debconf priority

  Debconf is the system used for handling any questions that packages might
  ask during configuration. These questions are given priorities, and
  debconf can be told to skip the ones below a given level of importance.

What I'd really like to do is get rid of the "debconf priority"
terminology entirely, but unfortunately that's used all over the place,
and if it they aren't introduced to it here, users are unlikley to be
able to guess what it means.

> 
> Please select the questions you want to be shown by priority level:
>   - 'critical': only show questions that are essential for a successful 
> installation;
>   - 'high': additionally to 'critical', show questions for which the default 
> often 
> needs to be changed;

By "additionally to 'critical'" here you mean "as an additive change to
the effect you'd get from selecting 'critical'"; I can't find a
phrasing that conveys this smoothly without breaking the back of the
series.  The closer we can get to "a) only X; b) also Y; c) also Z"
the easier it is to follow.

>   - 'medium': also show questions for which the default sometimes needs to be 
> changed;
>   - 'low': show all questions, even if the default only rarely needs to be 
> changed.
   ^
By the way, we want just one space before the bullet.
 
> For example, this question is of 'medium' priority, so if you had chosen to 
> see
> only questions of 'high' or 'critical' priority, it wouldn't be shown.
> 
> Only show questions with priority level:
>   critical
>   high
>   medium
>   low
> 
> snap-
> 
> 
> 
> The most relevant change here is the last line before the choices.
> I would rephrase that from "Ignore questions ..." into the "Show questions 
> ..."
> system we have in the other part, for consistency and easy understanding.

Unfortunately you end up with something that isn't true.  Picking
"low" *doesn't* mean that debconf will only show questions with
priority level "low"!  It means that debconf will show questions with
priority level "low" *or* anything higher - meaning *all* questions.
So it needs to keep the definition in terms of "less than".

(But thankyou for the further evidence that this whole thing is
horribly confusing!)
 
> And I thought about expanding the description part of the levels a bit, to
> hightlight how the concept works. Means to use this for 'high':
> (that's important to get rid of the " and higher" or "less than
> " parts)
> 
>   - "high": additionally to 'critical', show questions for which the default 
> often 
> needs to be changed;

(I've answered this above, but if anyone can find a middle way I'd
like to see it.)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [installer] One more template change?

[Justin B Rye]

Holger Wansing wrote:
> Justin B Rye  wrote:
>> In other words 
>> 
>>   You can select the priority of question you want to see:
>>- 'critical': only questions that are essential for a successful 
>> installation
>>- 'high': also questions for which the default often needs to be changed
>>- 'medium': also questions for which the default sometimes needs to be 
>> changed
>>- 'low': all questions, even if the default only rarely needs to be 
>> changed
>> 
>> Or perhaps putting some words back in:
>> 
>>   Please select the questions you want to be shown by priority level:
>>* "critical": only show questions that are essential for a successful 
>> installation;
>>* "high": also show questions for which the default often needs to be 
>> changed;
>>* "medium": also show questions for which the default sometimes needs to 
>> be changed;
>>* "low": show all questions, even if the default only rarely needs to be 
>> changed.
> 
> What worries me here is, that the description for high, medium and low only 
> differs
> in just ONE word/term ("often", "sometimes", "only rarely").
> 
> I fear that users might get overstrained with finding the difference within 
> the
> lines... ?

I don't know about you, but for me it's easier to find important
differences when everything else stays constant than when they're
hidden among various unimportant differences.
 
>> Some alternatives that people might like more than I do:
>> 
>>   Please select the cutoff level for questions that you want to be asked:
>>* "critical": only show questions that always require user attention;
>>* "high": also show ones for which the default often needs changing;
>>* "medium": also show ones for which the default sometimes needs changing;
>>* "low": show all questions, even if the default only rarely needs 
>> changing.
>> 
>>>> "For example, this question is of medium priority, and if your priority 
>>>> were "
>>>> "already 'high' or 'critical', you wouldn't see this question."
>>>>
>> [...]
>>>> For example, this question is of medium priority, and if your actual 
>>>> priority
>>>> would be 'high' or 'critical', you wouldn't see this question.
>> 
>> (I think that's a false-friend use of "actual". and it's definitely an
>> unidiomatic "would", though personally I wouldn't use "were" either.)
>> 
>> I don't like this idea that it's "my" priority that's "high".  It
>> isn't even the installer's priority - it's the degree of filtering
>> applied to questions in *terms* of priority, and that's a horrible
>> thing to have to explain concisely.  Maybe we can just say:
>> 
>> For example, this question is of medium priority, so if you had chosen 
>> to see
>> only questions of 'high' or 'critical' priority, it wouldn't be shown.
> 
> That sounds good to me.

(Oh, would it be more consistent to put "medium" in quotes too?  How
are translators going to handle this?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [installer] One more template change?

[Justin B Rye]

I'm on the record as wishing we could rip out this whole terminology
of "low priority installs" and start again with something else
(Bug#796662), but at least here it is in principle possible for it to
make sense...

Ben Hutchings wrote:
> Holger Wansing wrote:
>> I would propose to simplify/improve that like this:
> 
> I would suggest using consistently "question" instead of "item", and
> avoiding "reasonable default" as I'm not sure how widely that term is
> understood:
> 
>> You can select the priority of question you want to see:
>> - 'critical': you will only see items that will probably break the system
>>without user intervention.
> 
> "only questions that are essential for a successful installation"
 
>> - 'high': items are shown, that don't have reasonable defaults, additionally
>>   to those from critical.
> 
> "also questions for which the default often needs to be changed"
> 
>> - 'medium': also show normal items that have reasonable defaults.
> 
> "also questions for which the default sometimes needs to be changed"
> 
> > - 'low': even show trivial items that have defaults which will work in
> >   the vast majority of cases.
> [...]
> 
> "all questions, even if the default only rarely needs to be changed"

In other words 

  You can select the priority of question you want to see:
   - 'critical': only questions that are essential for a successful installation
   - 'high': also questions for which the default often needs to be changed
   - 'medium': also questions for which the default sometimes needs to be 
changed
   - 'low': all questions, even if the default only rarely needs to be changed

Or perhaps putting some words back in:

  Please select the questions you want to be shown by priority level:
   * "critical": only show questions that are essential for a successful 
installation;
   * "high": also show questions for which the default often needs to be 
changed;
   * "medium": also show questions for which the default sometimes needs to be 
changed;
   * "low": show all questions, even if the default only rarely needs to be 
changed.

Some alternatives that people might like more than I do:

  Please select the cutoff level for questions that you want to be asked:
   * "critical": only show questions that always require user attention;
   * "high": also show ones for which the default often needs changing;
   * "medium": also show ones for which the default sometimes needs changing;
   * "low": show all questions, even if the default only rarely needs changing.

>> "For example, this question is of medium priority, and if your priority were 
>> "
>> "already 'high' or 'critical', you wouldn't see this question."
>>
[...]
>> For example, this question is of medium priority, and if your actual priority
>> would be 'high' or 'critical', you wouldn't see this question.

(I think that's a false-friend use of "actual". and it's definitely an
unidiomatic "would", though personally I wouldn't use "were" either.)

I don't like this idea that it's "my" priority that's "high".  It
isn't even the installer's priority - it's the degree of filtering
applied to questions in *terms* of priority, and that's a horrible
thing to have to explain concisely.  Maybe we can just say:

For example, this question is of medium priority, so if you had chosen to 
see
only questions of 'high' or 'critical' priority, it wouldn't be shown.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [partman-target] proposal to change template to fix bad wording

[Justin B Rye]

Holger Wansing wrote:
> I have one more proposal on my agenda for template changes.
> 
> "Two file systems are assigned the same label (${LABEL}): ${PART1} and 
> ${PART2}.
> resp.

(This, by the way, is one of those uses of "respectively" that doesn't
work in English!)

> "Two file systems are assigned the same mount point (${MOUNTPOINT}): ${PART1} 
> and ${PART2}."
> 
> I am of course not a native English speaker, but I believe there is some bad 
> wording here? 

No, that *is* acceptable English, though it might nonetheless be worth
avoiding - it's effectively saying "two file systems are in a state of
having been assigned the same X" (remember that English verbs like
"give/assign" can passivise in either of two ways: "I was given a
name" or "a name was given to me").

Your suggested revised versions begin to feel a bit longwinded.  If
this bit is going to cause any trouble it might be better to throw it
out completely and just say something like:

  "Two file systems have the same label (${LABEL}): ${PART1} and ${PART2}."

  "Two file systems have the same mount point (${MOUNTPOINT}): ${PART1} and 
${PART2}."

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: netcfg: proposal for template change

[Justin B Rye]

Ben Hutchings wrote:
> On Fri, 2020-01-10 at 22:01 +0100, Holger Wansing wrote:
>> I would like to propose a change on a template in netcfg:
> [...]
>>  _Description: Malformed IP address
>>   The IP address you provided is malformed. It should be in the form
>> - x.x.x.x where each 'x' is no larger than 255 (an IPv4 address), or a
>> - sequence of blocks of hexadecimal digits separated by colons (an IPv6
>> + x.x.x.x where each 'x' is an integer not larger than 255 (for an IPv4 
>> address), or
>> + ::::::: each '' being a block of 
>> hexadecimal digits (for an IPv6
>>   address). Please try again.
> [...]
> 
> But IPv6 addresses do not have to look like that: leading zeroes in
> each group can be omitted and a run of all-zero groups in the middle
> can be omitted.
> 
> And really I think the tiny proportion of users who need to enter
> static network configuration will already know what an IP address looks
> like.

In fact it might be more likely to be helpful if it said:

   The value you provided is not a usable IPv4 or IPv6 address. Please
   try again; for instance when setting up an IPv4 local area network
   you might use an address such as "192.168.0.1".

On the other hand if they specifically want to configure an IPv6
address, they've probably just typed it in wrong (again).
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: netcfg: proposal for template change

[Justin B Rye]

Holger Wansing wrote:
> I would like to propose a change on a template in netcfg:
[...]
>  _Description: Malformed IP address
>   The IP address you provided is malformed. It should be in the form
> - x.x.x.x where each 'x' is no larger than 255 (an IPv4 address), or a
> - sequence of blocks of hexadecimal digits separated by colons (an IPv6
> + x.x.x.x where each 'x' is an integer not larger than 255 (for an IPv4 
> address), or
> + ::::::: each '' being a block of 
> hexadecimal digits (for an IPv6
>   address). Please try again.

Pedantically I think there ought to be commas around

   , each '' being a block of 
hexadecimal digits,

- or you could repeat the phrasing as "where each '' is a block of
hexadecimal digits".
 
> I would like to make the description of the format more clearer, especially
> the IPv6 variant does not give much detailed information.
> If you typed a malformed IPv6 address, that message does not give you much
> help, how it should look like ...
> 
> Any comments/objections?
> 
> debian-l10n-english in CC for review, too.

I can see why you might want to make the descriptions of dotted quads
and colonic octopoids more closely parallel, but is it really useful
to give this much advice and no more?  Users have already been warned
"if you don't know what to use here, consult your network
administrator"; if they're seeing this error because they tried typing
in "0.0.0.0", the rules given won't help them find an address they can
use.  It might be better to simplify in the general direction of

The value you provided is not a usable IPv4 or IPv6 address.
Please consult your network administrator and try again.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [cdrom-detect] Change template proposal

[Justin B Rye]

Holger Wansing wrote:
> Summarizing your comments into one patch, would this be ok?
> 
> diff --git a/debian/cdrom-detect.templates b/debian/cdrom-detect.templates
> index 2058b0b..ba50e89 100644
> --- a/debian/cdrom-detect.templates
> +++ b/debian/cdrom-detect.templates
> @@ -55,9 +55,10 @@ _Description: Device file for accessing the installation 
> media:
>   the device file that should be used. Non-standard CD-ROM drives use
>   non-standard device files (such as /dev/mcdx).
>   .
> - You may switch to the shell on the second terminal (ALT+F2) to check the
> + You may want switch to the shell on the second terminal (CTRL+ALT+F2 in the

You've dropped a word - "You may want to switch..."

> + graphical installer, ALT+F2 for the text-based variant) to check the
>   available devices in /dev with "ls /dev". You can return to this screen
> - by pressing ALT+F1.
> + by pressing CTRL+ALT+F5 or ALT+F1 respectively.

I wasn't even going to bother with the "respectively" - all it means
is "and I haven't maliciously sorted this list into a different order
from the last one", and I take that as a default assumption.  But it
doesn't hurt to include it.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [cdrom-detect] Change template proposal

[Justin B Rye]

Holger Wansing wrote:
> 
> Template: cdrom-detect/cdrom_device
> Type: string
> Default: /dev/cdrom
> # :sl2:
> _Description: Device file for accessing the installation media:
>  In order to access your installation media (like your CD-ROM), please enter
>  the device file that should be used. Non-standard CD-ROM drives use
>  non-standard device files (such as /dev/mcdx).
>  .
>  You may switch to the shell on the second terminal (ALT+F2) to check the
>  available devices in /dev with "ls /dev". You can return to this screen
>  by pressing ALT+F1.
> 
> 
> 
> This template is from the time where we only had the text-based installer, 
> and it does not work exactly for the graphical one.
> Therefore, I would like to change the second part like this:
> 
> 
> "You may want to switch to the shell on the second terminal (CLTR+ALT+F2 in 
> the "
> "graphical installer, ALT+F2 for the text-based variant) to check the "
> "available devices in /dev with \"ls /dev\". You can return to this screen "
> "by pressing CLTR+ALT+F5 respective ALT+F1."
   ^^
> 
> 
> Comments?

"Respective" is never ever a conjunction in English.  Just say "or".

And it's CTRL, not CLTR.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: [partman-base] template correction

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
> >   Template: partman/text/there_is_detected
> >   Type: text
> >   # :sl2:
> > - _Description: This partition is formatted with the ${FILESYSTEM}.
> > + _Description: This partition is formatted with the ${FILESYSTEM} 
> > filesystem.
> > 
> > 
> > Adding debian-l10n-english for review.
> 
> Did you check whether the string actually just contains the filesystem 
> descriptor,
> i.e. "ext3" and not "ext3 filesystem"?

That's what I was about to say, though it would be a l10n bug if true.
Otherwise this is an improvement even if ${FILESYSTEM} is something
like "ext3fs".
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Debian-installer/grub-installer: proposal for template change

[Justin B Rye]

Holger Wansing wrote:
>> Yes; "system" is one of those words that's rarely wrong to use, but
>> also rarely pulls its weight in making it clear what you're talking
>> about.
> 
> @Justin: may I interpret your comment in the meaning of "string review passed,
> all fine" ?

Yes, it looks good to me.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Debian-installer/grub-installer: proposal for template change

[Justin B Rye]

Holger Wansing wrote:
> John Paul Adrian Glaubitz  wrote:
>> On 11/19/19 8:06 PM, Holger Wansing wrote:
>>> It's unclear, what the "new system" is supposed to be.
>>> So above patch to clarity.
>> 
>> Why would that be unclear? When you just finished an installation, I
>> think the term "your new system" is pretty unambiguous in the context.
> 
> 'The new xyz' tends to be error-prone IMO, since what is 'new' today, gets
> older every day and some day it's the 'old' one.
> Of course, this picture does not fully apply to the above situation, I know,
> but I would like to avoid such phrasing if possible.

In this case we know it's brand-new, in that the user has just
finished creating it.  But a reader *could* misinterpret it this way -
"after the machine boots, from then on you'll always be able to choose
whether to boot one of those other operating systems or whatever thing
you've installed most recently at that point".
 
> Also, 'system' is a term which is used for different instances, like the
> real hardware PC (like in 'PC system'), the operating system (like Debian,
> Windows ...) or virtual operating systems...

And don't forget the EFI "system partition", which might be "new" if
the user has only previously used legacy BIOS.

> Thus, users might get confused, and in fact I read an installation report
> (not in the Debian BTS), where this was mentioned.

Yes; "system" is one of those words that's rarely wrong to use, but
also rarely pulls its weight in making it clear what you're talking
about.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Debian-installer/clock-setup: proposal for template change

[Justin B Rye]

Holger Wansing wrote:
> = snip 
> diff --git a/debian/clock-setup.templates b/debian/clock-setup.templates
> index 2ef0502..3ee2f1e 100644
> --- a/debian/clock-setup.templates
> +++ b/debian/clock-setup.templates
> @@ -32,7 +32,7 @@ Default: true
>  # :sl2:
>  _Description: Set the clock using NTP?
>   The Network Time Protocol (NTP) can be used to set the system's clock.
> - The installation process works best with a correctly set clock.
> + Your system works best with a correctly set clock.
>  
>  Template: clock-setup/ntp-server
>  Type: string
> 
> = snap 
> 
> 
> It's not only the installation, but the operation of the Debian system
> afterwards, which should have a proper system time.
> 
> Any objections?

Looks good to me.  It would be better if we had a word we could use
instead of repeating "system" all the time, but it's not worth losing
any sleep over.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change template: add hint about the integrity check item in main menu

[Justin B Rye]

Holger Wansing wrote:
>  _Description: Failed to copy file from installation media. Retry?
>   There was a problem reading data. Please make sure you have inserted the
>   installation media correctly. If retrying does not work, you should check
> - the integrity of your installation media.
> + the integrity of your installation media (there is an associated entry in
> + the main menu for that).

Looks okay to me!
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - final patch

[Justin B Rye]

John Paul Adrian Glaubitz wrot:
> On 9/22/19 8:52 PM, Justin B Rye wrote:
>>> The origin of the word is Latin. The word is grammatically
>>> neutrum, for which the singular is "-um", the plural is "-a". It's
>>> not a mess at all.
>> 
>> Etymology does not determine current grammatical behaviour.
> 
> Official dictionaries do, again, look it up:

This is a widespread misunderstanding.  Dictionaries do not determine
how languages work - they attempt to document it, and if there's
divergence between what they say and what the community of native
speakers says, that's a problem with the dictionary.  If you don't
believe me, ask the people who write the dictionaries!  For instance,
a couple of links away from the page you're pointing at:

 https://languages.oup.com/our-story/creating-dictionaries

>> https://www.lexico.com/en/definition/media
> 
> the mediatreated as singular or plural The main means of mass
> communication (broadcasting, publishing, and the Internet) regarded
> collectively.
> ‘their demands were publicized by the media’

Why are you still obsessing over this completely irrelevant usage?
Nobody is suggesting that debian-installer should talk about the news
media.  (Though it would be nice if you could take in the fact that
the Usage article on that page goes further than I did in explicitly
recognising "the media is" as standard English.)
 
> 2
> plural form of medium
> 
> Then click on "medium" and you get the definition of what we are talking 
> about,
> a storage medium and plural, storage media.

Yup: a *category* of propagation medium - they go on to specify

 3 A particular form of storage material for computer files, such as
   magnetic tape or discs.

"Discs", plural, are *a medium*; that's the *category* sense - "a
particular form".

>>> It's "the media", because that's a plural word, like "the news".
>> 
>> That's not the sense of "media" that's relevant.
> 
> That's the only case where media is a plural-word.

Wait, so now you're *insisting* that there's only one sense of the
word "media" that's plural?

> Again, look it up: https://www.lexico.com/en/definition/media

Yup, lots of different senses,  How can you say there's only one case
where it's plural *while actively pointing at* a list of different
senses for which "media" is the plural, *none* of which is the
relevant sense "individual chunks of some data storage substrate"?
 
>>> Both languages have imported the word from Latin. I cited renowned 
>>> dictionaries,
>>> you are basically citing your own and are being condescending because
>>> you are a native speaker and I'm not.
>> 
>> Well, as it happens I also have a Masters degree in linguistics, so I
>> probably use unhelpful technical terms without noticing, but more
>> importantly I know the limitations of dictionaries.  The first step is
>> to get straight what it is that you're trying to look up.  Looking up
>> "medium" in the category sense is no more useful than looking up the
>> word that means "spiritualist".  And unfortunately, itemisable chunks
>> of data-storage media are a new thing that people have only started
>> talking about in the past few decades (even now, people rarely need to
>> talk in terms of the generic cover-term "media"), and it's a new idea
>> that doesn't add a new headword for the dictionaries to define - it's
>> a new usage of the *plural* word "media", so it tends to fall between
>> the cracks.
> 
> If you have a master's degree in linguistics, you should be able to provide
> sources as every scientist does.

The dictionary that you've brought as evidence will do very nicely as
a source, thanks.  Again:

 3 A particular form of storage material for computer files, such as
   magnetic tape or discs.

That's the definition of medium as in "all my DVD backups used the
same medium".  Where is the definition of medium that could be used
for "all my DVD backups are on different individual DVDs"?  There
isn't one.  And why's that?  Simple: because that isn't an idiomatic
sense of the English word.

> If I'm trying to convince someone in
> a physics argument, I also just don't say "I have a Diploma in Physics,
> so you are wrong", but I'm actually providing sources.

When people pick arguments with physicists, it usually turns out to be
because they've misunderstood what the sources are saying - they're
assuming a Newtonian absolute frame of reference, or assuming they
know what "entropy" means, or something.  I try not to argue physics
with physicists, because I strongly suspect I don't understand what

Re: installation guide [Was: Re: Change templates: CD -> installation medium - proposal #2 ]

[Justin B Rye]

Holger Wansing wrote:
> Thus we could change that to:
> "If you are installing from DVD, any packages needed 
> during the installation should be present on the first DVD image. Use
> of a network mirror is optional."

Oh, so it turns out I should have simplified it *more*!  Yes, that
looks fine.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: installation guide [Was: Re: Change templates: CD -> installation medium - proposal #2 ]

[Justin B Rye]

Justin B Rye wrote:
> I was planning to carry on and find all the other places where fixes
> are needed, but I'll have to come back to it.

I had got as far as:
 (en/using-d-i/modules/apt-setup.xml:)
 - If you do scan multiple CDs or DVDs, the installer will prompt you to
 - exchange them when it needs packages from another CD/DVD than the one
 - currently in the drive. Note that only CDs or DVDs that belong to the
 + If you do scan multiple installation media, the installer will prompt you to
 + exchange them when it needs packages from another media than the one
 + currently in the drive. Note that only discs that belong to the

No, "another media than [this] one" is the singular usage that doesn't
work.  But most of this is redundant anyway - just say

   If you do scan multiple installation media, the installer will prompt you
   to exchange them when it needs packages from one that isn't
   currently in the drive. Note that only discs that belong to the

 (en/using-d-i/modules/apt-setup.xml:)
   If you are not installing from a full CD or DVD or
 - using a full CD/DVD image, you really should use a network mirror as
 + a corresponding image, you really should use a network mirror as

Here and later, what's the point of distinguishing these two cases?
If you're installing from a "full" CD or DVD, doesn't that
automatically mean you're using "a full CD/DVD image"?  If so, that's
the only case that needs to be mentioned - it could be just

   If you are not installing from a full CD/DVD
   image, you really should use a network mirror as

 [...]
 - If you are installing from a DVD or using a DVD image, any packages needed
 - during the installation should be present on the first DVD. The same is true
 - if you have scanned multiple CDs as explained in the previous section. Use
 + If you are installing from a DVD or the corresponding image, any packages 
needed
 + during the installation should be present on the first DVD (image). The same 
is true
 + if you have scanned multiple CD (images) as explained in the previous 
section. Use
   of a network mirror is optional.

This seems incoherent.  If you're installing from *a* DVD, singular,
those packages had better be on the first DVD, because there isn't a
second one!  For this to make any sense it has to be talking about DVD
images, plural.  And then the phrasing "multiple CD (images)" doesn't
work; but why is it repeating itself like this anyway?  Why isn't this
whole paragraph just:

   If you are using CD/DVD images, the packages needed during installation
   should be on the first one. Use of a network mirror is optional.

 (en/using-d-i/modules/network-console.xml:)
   otherwise invoke the main installation menu and choose Load
 - installer components from CD and from the list of
 + installer components from installation media and from the list 
of

I hope you've checked that the menu will offer this changed phrasing...

  (en/using-d-i/using-d-i.xml:)
   Anna's Not Nearly APT. Installs packages which have been retrieved
 - from the chosen mirror or CD.
 + from the chosen mirror or installation medium.

If by "CD" it means "individual chunk of storage space" then that
isn't "medium", it's "item of media".  Could it be in fact be "media",
plural, or would it be simpler to move in the direction of vagueness:

   from the chosen source,



Don't forget if all this gets dealt with you can close bug #794936,
leaving only #795944 and #796662 in the set of major problems to be
got out of the way first before it's worth thinking about doing a
general proofreading sweep...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: installation guide [Was: Re: Change templates: CD -> installation medium - proposal #2 ]

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
> Justin B Rye wrote:
>> In English, "a medium" means a *category* of information-propagating
>> mechanism (such as radio or print), not one individual USB thumbdrive
>> or whatever.
> 
> Not, it doesn't:
> 
>> https://www.sciencedirect.com/topics/engineering/recording-medium
>> https://en.wikipedia.org/wiki/Medium#Other_uses_in_science_and_technology

These say nothing that disagrees with me.  The problem here is that
you're not taking in just what it is I'm saying.

>> I'd recommend just "Detect media:" - after all, the question is
>> whether it *ever* succeeded on *any* try, right?
> 
> No, "detect medi**um**", it's one installation medium. Not multiple 
> installation media.

"One medium", in English, means one *category* of storage/transmission
system, like radio or newsprint or optical storage, not one individual
data-storage *product*.  Unless of course they come in three sizes,
and you're talking about the middle one - that's another grammatically
valid sense of "the medium"!

It's possible to talk about "making a backup using a rewritable DVD as
the medium", but that's still "medium" as an approximate synonym for
"method" - if I make a new backup the next day on a different DVD,
it's the same medium!
 
> The language is very concise.

I expect that language has nice regular words like "agendum" and
"spaghetto", too - but alas, it isn't the language we're trying to
write the documentation in.

>> (en/howto/installation-howto.xml:)
>>Now sit back while debian-installer detects some of your hardware, and
>>  - loads the rest of itself from CD, USB, etc.
>>  + loads the rest of itself from the installation medium.
>> 
>> "Medium" is the wrong thing, "item of media" would be very clunky, and
>> we can't get away with plural "media" because you can't sit back if
>> you're swapping discs, so this is a tricky one.  Maybe it could say:
> 
> Again, could you please quote a dictionary here. Please don't assume that
> being native speaker alone is sufficient. Lots of native speakers don't
> use proper grammar. Just think of "they're, their and there".

Look at the entry in *any* dictionary, and look at how they define the
word: a "medium" is a *type* of storage or transmission mechanism.
This is easy to miss when you're looking at something like a wikipedia
article, since its lists tend to be implicitly categorising things.
But English doesn't have a neat, simple cover-term referring to a
single, individual *piece* of media; there's only "piece of media".
That's why there's no entry for it in the dictionaries: because
there's no such headword for them to define!

>>  [...]
>>  - If you don't have a CD set, then you will need to download the
>>  + If you don't have a installation media set, then you will need to 
>> download the
>> 
>> A nice easy-to-fix one here: that's *an* installation media set.
> 
> It both sounds very awkward. The sentence should be rephrased.

Quite possibly; the whole document needs a huge amount of work, but
you're not going to get much help from English-speakers if they all
get this sort of welcome.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - final patch

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
> Justin B Rye wrote:
>> There are several related nouns here, which behave differently:
>>   * "(broadcast) medium/media" (and "meejuh", treated as singular);
>>   * "item of (removable storage) media/some media";
>>   * "(spirit) medium/mediums".
>> Frankly it's a mess, but it won't get better if you mix them up.
> 
> Not really.

Yes, really: it won't.  Mind you, I can't promise you it'll get better
whatever we do.

> The origin of the word is Latin. The word is grammatically
> neutrum, for which the singular is "-um", the plural is "-a". It's
> not a mess at all.

Etymology does not determine current grammatical behaviour.  All words
come from somewhere, and if we could trace their origins back far
enough, most of them (apart from recent inventions like "thumbdrive")
would turn out to have once meant something different, or had
different inflectional morphology, or both.  Think of "agenda",
"stamina", or "opera" (all plural in Latin, but uncontroversially
singular in English).  Germanic languages also have a habit of
borrowing Italian names for foodstuffs as grammatically singular:
"spaghetti", "ravioli", "panini", "zucchini".  They're plural in
Italian, but "seven spaghetti" is just bad English.

> It's "the media", because that's a plural word, like "the news".

That's not the sense of "media" that's relevant.

>>> Using "media" for a singular word just sounds weird for anyone knowing
>>> Latin. And FWIW it's also "Medium" in German when talking about one disk.
>> 
>> Unfortunately it turns out that Deutschlish sounds weird to anyone
>> who knows English.
> 
> Both languages have imported the word from Latin. I cited renowned 
> dictionaries,
> you are basically citing your own and are being condescending because
> you are a native speaker and I'm not.

Well, as it happens I also have a Masters degree in linguistics, so I
probably use unhelpful technical terms without noticing, but more
importantly I know the limitations of dictionaries.  The first step is
to get straight what it is that you're trying to look up.  Looking up
"medium" in the category sense is no more useful than looking up the
word that means "spiritualist".  And unfortunately, itemisable chunks
of data-storage media are a new thing that people have only started
talking about in the past few decades (even now, people rarely need to
talk in terms of the generic cover-term "media"), and it's a new idea
that doesn't add a new headword for the dictionaries to define - it's
a new usage of the *plural* word "media", so it tends to fall between
the cracks.

> Please cite a dictionary where "media" is used as a singular word
> not being in the context of "news".

Again, your problem is that that isn't the right question.  The only
sense of "media" that's commonly treated as singular is the
*colloquial* usage of "the news media", and that's the wrong one.  The
sense that's relevant here is "storage media", which *has* no simple
singular form better than "item of media".

It isn't even a proper mass noun - words like "spaghetti" are
singulars without (itemising) plurals, while "media" is a plural with
no itemising singular.  The bad news is, words like this usually end
up reinterpreting their plural form as a singular (cf. "data"), so as
far as conformance with Latin grammatical rules is concerned things
are only likely to get worse.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: installation guide [Was: Re: Change templates: CD -> installation medium - proposal #2 ]

[Justin B Rye]

Holger Wansing wrote:
>> This is a good solution for a problem that also affects the
>> Installation Guide, since it also lets you leapfrog over the old
>> problem of what cover-term to use for "CD/DVD/BluRay media" (the
>> Guide says that it's going to use "CD-ROM", then doesn't - #794936).
> 
> I have applied similar changes to the installation-guide now, at
> https://salsa.debian.org/installer-team/installation-guide/commit/64ccfd502a27181f3f1b9cf2254fdc9836710493

Unfortunately it has a good few unidiomatic uses of "medium".

(In en/appendix/chroot-install.xml:)
  - If you have a   CD mounted at
  + If you have a   installation medium mounted at
/cdrom, you could substitute a file URL instead
of the http URL: file:/cdrom/debian/

In English, "a medium" means a *category* of information-propagating
mechanism (such as radio or print), not one individual USB thumbdrive
or whatever.  That would have to be an "item of media" or similar; but
then again isn't it also true to say that the *image* is mounted on
the /cdrom mountpoint?

In en/boot-installer/parameters.xml:
   By default, before rebooting,  automatically ejects the optical
   media used during the installation. This can be unnecessary if the system
 - does not automatically boot off the CD. In some cases it may even be
 + does not automatically boot off such disc. In some cases it may even be
   undesirable, for example if the optical drive cannot reinsert the media
   itself and the user is not there to do it manually. Many slot loading,
   slim-line, and caddy style drives cannot reload media automatically.

"Such" plus singular doesn't work like that in English.  Here I'd
rephrase it as just "if the system will not automatically boot off
it", but in other cases you need "such a...".  "Such media" is okay,
though!

(in en/boot-installer/trouble.xml:)
 - Configure network:  [ ]
 - Detect CD:
 - Load installer modules: [ ]
[...]
 + Configure network:  [ ]
 + Detect installation medium: [ ]
 + Load installer modules: [ ]

I'd recommend just "Detect media:" - after all, the question is
whether it *ever* succeeded on *any* try, right?

(in en/boot-installer/x86.xml:)
 - obtain CD-ROM/DVD-ROM or USB memory
 - stick installation media as described in
 + obtain installation media as described in
respective
or

Not a flaw in your patch, but that use of "respective" is horribly
ungrammatical in English... it's hard to tell what it *should* be here
without more context, but usually the answer is either "or" or
nothing.

(en/howto/installation-howto.xml:)
   Now sit back while debian-installer detects some of your hardware, and
 - loads the rest of itself from CD, USB, etc.
 + loads the rest of itself from the installation medium.

"Medium" is the wrong thing, "item of media" would be very clunky, and
we can't get away with plural "media" because you can't sit back if
you're swapping discs, so this is a tricky one.  Maybe it could say:

   loads the rest of the installation image.

(en/install-methods/official-cdrom.xml:)
 - By far the easiest way to install  is from an Official
 -  CD/DVD-ROM Set. You can buy a set from a vendor (see the
 + By far the easiest way to install  is from a set of official
 +  installation images. You can buy a set of CD/DVD from a vendor (see 
the

A new and different number-agreement glitch: "set of CDs/DVDs".

 [...]
 - detailed instructions). If you have a  CD/DVD set and CDs/DVDs are
 + detailed instructions). If you have such optical installation media and 
those media are
   bootable on your machine, which is the case on all

"Such" works here, but "those media" is a bit wobbly.  I'd shorten it to

   detailed instructions). If you have such optical installation media, and 
they are

 [...]
 - If you don't have a CD set, then you will need to download the
 + If you don't have a installation media set, then you will need to download 
the

A nice easy-to-fix one here: that's *an* installation media set.

I was planning to carry on and find all the other places where fixes
are needed, but I'll have to come back to it.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - final patch

[Justin B Rye]

John Paul Adrian Glaubitz wrote:
> Justin B Rye wrote:
>>> But "media" is a plural word, it should be "medium". It's a Latin word.
>> 
>> Like "agenda"?  It doesn't matter whether it was plural in Latin; it
>> only matters how it behaves in modern English.  But as it happens, the
>> patch doesn't use "media" to refer to a singular CD - it uses "some
>> media" and "an item of media", the way English-speakers normally do.
> 
> At least this dictionary still considers it "media" plural:

Yes, and if you can find a case where the patch talks about putting a
singular "media" in the drive, please point that out, because it'll be
a mistake that needs to be fixed.
 
> https://dict.leo.org/german-english/media

There are several related nouns here, which behave differently:
  * "(broadcast) medium/media" (and "meejuh", treated as singular);
  * "item of (removable storage) media/some media";
  * "(spirit) medium/mediums".
Frankly it's a mess, but it won't get better if you mix them up.

> Using "media" for a singular word just sounds weird for anyone knowing
> Latin. And FWIW it's also "Medium" in German when talking about one disk.

Unfortunately it turns out that Deutschlish sounds weird to anyone
who knows English.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - final patch

[Justin B Rye]

John Paul Adrian Glaubitz
>> I will move back to "installation media" and to Justins review from
>> https://lists.debian.org/debian-boot/2019/09/msg00082.html
> 
> But "media" is a plural word, it should be "medium". It's a Latin word.

Like "agenda"?  It doesn't matter whether it was plural in Latin; it
only matters how it behaves in modern English.  But as it happens, the
patch doesn't use "media" to refer to a singular CD - it uses "some
media" and "an item of media", the way English-speakers normally do.

(There's a different sense of "media" that *is* colloquially used as a
singular: "the Meejuh is full of fake news".  But that has nothing to
do with CDs.)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - proposal #2

[Justin B Rye]

Justin B Rye wrote:
> How about if I go ahead and try producing a patch that uses both
> "installation image" and "installation disk", just to see how that
> looks?

Well, I can't for the life of me work out how to get "git diff" to
work on debian-installer, so here's a bodged version.  It probably
needs more work, but what do people think about the general idea?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ur d-i.orig/apt-cdrom-setup.templates d-i.jbr/apt-cdrom-setup.templates
--- d-i.orig/apt-cdrom-setup.templates	2019-09-13 00:59:08.137525521 +0100
+++ d-i.jbr/apt-cdrom-setup.templates	2019-09-12 23:58:48.080551016 +0100
@@ -1,73 +1,71 @@
 Template: apt-setup/progress/cdrom
 Type: text
 # :sl1:
-_Description: Scanning the CD-ROM...
+_Description: Scanning the installation disk...
 
 Template: apt-setup/cdrom/failed
 Type: error
 # :sl2:
 _Description: apt configuration problem
- An attempt to configure apt to install additional packages from the CD
- failed.
+ An attempt to configure apt to install additional packages from the
+ installation disk failed.
 
 Template: apt-setup/cdrom/set-first
 Type: boolean
 Default: false
 #flag:translate!:3
 # :sl1:
-_Description: Scan another CD or DVD?
- Your installation CD or DVD has been scanned; its label is:
+_Description: Scan another installation disk?
+ Your installation disk has been scanned; its label is:
  .
  ${LABEL}
  .
- You now have the option to scan additional CDs or DVDs for use by the
+ You now have the option to scan additional disks for use by the
  package manager (apt). Normally these should be from the same set as the
- installation CD/DVD. If you do not have any additional CDs or DVDs
- available, this step can just be skipped.
+ one you booted from. If you do not have any more available, this step
+ can just be skipped.
  .
- If you wish to scan another CD or DVD, please insert it now.
+ If you wish to scan another, please insert it now.
 
 Template: apt-setup/cdrom/set-next
 Type: boolean
 Default: false
 #flag:translate!:3
 # :sl1:
-_Description: Scan another CD or DVD?
- The CD or DVD with the following label has been scanned:
+_Description: Scan another installation disk?
+ The installation disk with the following label has been scanned:
  .
  ${LABEL}
  .
- If you wish to scan another CD or DVD, please insert it now.
+ If you wish to scan another, please insert it now.
 
 Template: apt-setup/cdrom/set-double
 Type: boolean
 Default: true
 #flag:translate!:3
 # :sl1:
-_Description: Scan another CD or DVD?
- The CD or DVD with the following label has already been scanned:
+_Description: Scan another installation disk?
+ The installation disk with the following label has already been scanned:
  .
  ${LABEL}
  .
- Please replace it now if you wish to scan another CD or DVD.
+ Please replace it now if you wish to scan another.
 
 Template: apt-setup/cdrom/set-failed
 Type: boolean
 Default: true
 # :sl1:
-_Description: Scan another CD or DVD?
+_Description: Scan another installation disk?
  An attempt to configure apt to install additional packages from the
- CD/DVD failed.
+ disk failed.
  .
- Please check that the CD/DVD has been inserted correctly.
+ Please check that the disk has been inserted correctly.
 
 Template: apt-setup/cdrom/media-change
 Type: text
 # :sl1:
-# This template uses the same text as used in the package apt for apt-cdrom
-# Do not translate "/cdrom/" (the mount point)
 _Description: Media change
- /cdrom/: Please insert the disc labeled '${LABEL}' in the drive '/cdrom/'
+ Please insert the installation disk labeled '${LABEL}'
  and press enter.
 
 Template: finish-install/progress/apt-cdrom-setup
@@ -79,29 +77,29 @@
 Template: apt-setup/use/netinst_old
 Type: text
 # :sl1:
-_Description: If you are installing from a netinst CD and choose not to use a mirror, you will end up with only a very minimal base system.
+_Description: If you are installing from a netinst image and choose not to use a mirror, you will end up with only a very minimal base system.
 
 Template: apt-setup/use/netinst
 Type: text
 # :sl1:
-_Description: You are installing from a netinst CD, which by itself only allows installation of a very minimal base system. Use a mirror to install a more complete system.
+_Description: You are installing from a netinst image, which by itself only allows installation of a very minimal base system. Use a mirror to install a more complete system.
 
 Template: apt-setup/use/cd
 Type: text
 # :sl1:
-_Description: You are installing from a CD, which contains a limited selection of packages.
+_Description: You are installing from an installation image which contains a limited selection of packages.
 
 Template: apt-setup/use/cd-set1
 Type: text
 # :sl1:
 # The value of %i can be 2 or 3
-_Description: You have scanned %i CDs. Even though these contain a fair selecti

Re: Change templates: CD -> installation medium - proposal #2

[Justin B Rye]

Ben Hutchings wrote:
>> The only alternative I can think of (from Justin's list) 
>> would be installation image.
>> Additional benefit would be, that this term seems to be the
>> most used on the Debian website.
>> So if users know that term from the website or find it there, they can make 
>> the connection to the messages in d-i,
>> if in doubt what is meant.
>> 
>> What do you think?
> 
> An "installation image" is a regular file.  It has to be copied onto a
> physical device, or mapped as a virtual device, to create an
> "installation disk".

There are dialogues where it's basically talking about looking at an
image on a disk, so I'd have thought we need both terms in any case.
How about if I go ahead and try producing a patch that uses both
"installation image" and "installation disk", just to see how that
looks?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - proposal #2

[Justin B Rye]

Steve McIntyre wrote:
> Ben Hutchings wrote:
>> Holger Wansing wrote:
>>>  #: ../cdrom-detect.templates:14001
>>> -msgid "The CD-ROM drive contains a CD which cannot be used for 
>>> installation."
>>> +msgid "The detected installation drive cannot be used for installation."
>>>  msgstr ""
>>[...]
>>
>> I don't know exactly what cdrom-detect does, but it may still be
>> specific to optical drives.  In that case you could use more specific
>> terms here, e.g. "The optical disc drive contains a disc which cannot
>> be used for installation."
>>
>> Otherwise a suitable new text could be something like "The detected
>> drive does not contain a usable installation disk".
> 
> cdrom-detect (yes, overly-specific name) is still the piece in the
> initramfs that looks for the rest of d-i, so I still think just
> changing to "installation disk(s)" here is fine.

I don't follow your logic.  If this dialogue might be talking about a
thumbdrive, that sounds to me like a valid reason to want to say
something general like

   "The device does not contain a useful installation image."
or
   "No useful installation image found on detected media."

Okay, the message may be coming from something specifically named
"cdrom-detect", but users don't know that, do they?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - proposal #2

[Justin B Rye]

Holger Wansing wrote:
> And they all need to covered here.
> Maybe we cannot find a term that works perfectly for all of them, however
> having a suitable coverterm for all would be the major goal.

Contenders so far:
 * "insert another medium", "insert more media", and "insert another
   item of media" all run the risk of annoying readers because they're
   unidiomatic or "wrong" or clumsy.
 * "insert another installation device" works for thumbdrives, but
   okay, it's a slight stretch for a CD.
 * "insert another installation source" might also be usable some of
   the time, though "source" is already a rather overloaded technical
   term ("download the source from the configured source...")
 * "installation image" works well some of the time, but it's a poor
   fit for cases like "could not read data from the CD."
 * "insert an installation disk" has two problems: the annoying but
   minor one that the standard spelling for optical media is "disc",
   and the potentially more important one that it isn't obvious that
   it's intended to include things like thumbdrives.

Other options not yet considered include "data storage system",
"installation vector", some combo like "installation disk/device", or
"thingy".

Then again, how about if we say "Debian InstallDisk" as if it's a
brand-name?  Nobody expects those to make sense!  (But then I suspect
we'd need to spend a week bikeshedding the camelcase...)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - proposal #2

[Justin B Rye]

David wrote:
> Hi readers

Hi!  Thanks a lot for this alternative suggestion.

[...]
> These words "medium" & "media" are very awkward for a few reasons:
> 
> 1) Contemporary use of the words is such that their "correct" use might
> be evolving. So attempting to use these words correctly is annoying and
> clumsy.
> 
> 2) The majority current use of these words by the general popoulation is
> technically incorrect, so using them correctly produces a result that is
> uncomfortable for many readers and therefore might be considered poor
> or ineffective communication style. For example, most people in current
> everyday use will not understand that "medium" might refer to a computer
> file storage device.

I'd argue that there's no standards body with the jurisdiction to make
generally accepted English idioms "technically incorrect"; it's
awkward that we've ended up having to talk about "pieces of media",
but that seems to be the accepted idiom...

> 3) Technology has largely moved away from storage devices that actually use
> insertion of removable media into a reader device. These days it is much
> more likely that the user has a removable *device*, not removable *media*.
> 
> For these reasons, I offer a bold suggestion:
> 
>   Work towards eliminating the words "media" and "medium" everywhere,
>   except where they cannot be avoided.
> 
>   Prefer words like "installer device" or "installation device"
>   wherever possible,

Oh, now that might just work (I tend to agree with MJ Ray that
"installation device" feels better somehow).  And the places where it
doesn't work as well are mostly the places where we could switch to
"image".

[...]
> EXAMPLE PHRASES (taken from Justin's message)
> 
> "Load installer components from installer device files"

Thinking about it again, the installer doesn't pull *components* out
of individual *files*, does it?  It takes files from the installation
device filesystem and uses them as components, so we ought to be
saying something like:

  "Load components from installation image"
 
> "Failed to copy file from installer device. Retry?"
> 
> "There was a problem reading data. Please make sure you have inserted the "
> "installer device correctly. If retrying does not work, you should check the "
> "integrity of your installer device."
> 
> "Detecting hardware to find drives for installer device"
> 
> "Detecting hardware to find installer device"
> 
> "Scanning installer device"
> "Unmounting/ejecting installer device..."

(It belatedly occurs to me that "ejecting" is a diskism; but I suppose
here it's only offered as a possibility.)
 
> "You may need to load additional drivers from a removable device, such as "
> "a USB stick. If you have such a device available now, insert it, and "
> "continue. Otherwise, you will be given the option to manually select some "
> "modules."

Here I'd see no reason not to keep "from removable media" where what
we're talking about is the choice of media in the floppy-or-USB sense.

I'll see if I can come up with a proper patch for this.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: Change templates: CD -> installation medium - proposal #2

[Justin B Rye]

Holger Wansing wrote:
> I would like to change the term "CD" into "installation medium" in the
> debian-installer.
> These days our CD/DVD images can also be used for USB sticks, and virtual 
> machines
> are also quite common, so messages like "Loading components from CD" no 
> longer fit.

This is a good solution for a problem that also affects the
Installation Guide, since it also lets you leapfrog over the old
problem of what cover-term to use for "CD/DVD/BluRay media" (the
Guide says that it's going to use "CD-ROM", then doesn't - #794936).

> I have prepared a proposal (attached) and would welcome a review of the
> English language side.

The tricky part with this solution is that "medium" is one of those
words that seems to have been designed to confuse and annoy non-native
speakers.  A medium is something like newsprint or DVD format.  An
individual thing produced in such a medium (a newspaper, DVD, or
whatever) is a "piece/item of media", not a "medium", but this is so
clumsy that we usually just talk about (some) "media".

Unfortunately if you Google for this you'll just find people arguing
about an entirely separate problem: whether "the media" (i.e. the mass
communication industry) is singular or plural.

Sorry, no patch to go with this yet; for a start I'll want to reread
it to see if I agree with myself.

> --- change-cd-into-installation-media_by-package.txt  2019-09-08 
> 14:34:06.000700447 +0200
> +++ change-cd-into-installation-media_by-package_workingcopy.txt  
> 2019-09-09 20:52:15.227819598 +0200
> @@ -1,469 +1,466 @@
>  
>  in Package: cdrom-retriever
>  
>  #. Type: text
>  #. Description
>  #. Main menu item
>  #: ../load-cdrom.templates:1001
> -msgid "Load installer components from CD"
> +msgid "Load installer components from installation medium"
>  msgstr ""

It's possible you'd get away with these, but I'd definitely say
"media" myself, and it probably makes more sense to do a consistent
s/medium/media/

>  #. Type: boolean
>  #. Description
>  #. :sl2:
>  #: ../cdrom-retriever.templates:1001
> -msgid "Failed to copy file from CD-ROM. Retry?"
> +msgid "Failed to copy file from installation medium. Retry?"
>  msgstr ""

s/medium/media/
  
>  #. Type: boolean
>  #. Description
>  #. :sl2:
>  #: ../cdrom-retriever.templates:1001
>  msgid ""
> -"There was a problem reading data from the CD-ROM. Please make sure it is in 
> "
> -"the drive. If retrying does not work, you should check the integrity of 
> your "
> -"CD-ROM."
> +"There was a problem reading data from the medium. Please make sure it is 
> inserted "
> +"correctly. If retrying does not work, you should check the integrity of 
> your "
> +"installation medium."
>  msgstr ""

Take a slight shortcut:

   "There was a problem reading data. Please make sure you have inserted the "
   "installation media correctly. If retrying does not work, you should check 
the "
   "integrity of your installation media."

Or maybe: of the image.

>  in Package: iso-scan
>  
>  #. Type: text
>  #. Description
>  #. Main menu item
>  #: ../load-iso.templates:1001
>  msgid "Load installer components from an installer ISO"
>  msgstr ""
>  
>  
>  
>  in Package: cdrom-detect
>  
>  #. Type: text
>  #. Description
>  #. :sl1:
>  #: ../cdrom-detect.templates:2001
> -msgid "Detecting hardware to find CD-ROM drives"
> +msgid "Detecting hardware to find drives for installation media"
>  msgstr ""

Luckily this was plural anyway!  But do we talk about drives *for* USB
thumbdrives?  It might make more sense just to claim to be

   msgid "Detecting hardware to find installation media"

>  #. Type: text
>  #. Description
>  #. :sl1:
>  #: ../cdrom-detect.templates:10001
> -msgid "Scanning CD-ROM"
> +msgid "Scanning installation medium"
>  msgstr ""

s/medium/media/

>  
>  #. Type: text
>  #. Description
>  #. finish-install progress bar item
>  #. :sl1:
>  #: ../cdrom-detect.templates:19001
> -msgid "Unmounting and ejecting CD-ROM..."
> +msgid "Unmounting/ejecting installation medium..."
>  msgstr ""

s/medium/media/

>  #. Type: boolean
>  #. Description
>  #. :sl2:
>  #: ../cdrom-detect.templates:1001
>  msgid ""
> -"You may need to load additional CD-ROM drivers from removable media, such 
> as "
> -"a driver floppy. If you have such media available now, insert it, and "
> -"continue. Otherwise, you will be given the option to manually select CD-ROM 
> "
> +"You may need to load additional drivers from removable media, such as "
> +"a USB stick. If you have such media available now, insert it, and "
> +"continue. Otherwise, you will be given the option to manually select some "
>  "modules."
>  msgstr ""

Yes, I for one would be in trouble if I needed to install drivers from
a floppy!  Fortunately it's already using plural "media", though with
mangled number agreement - media are "them", not "it".  Perhaps it
would make sense to focus on the definitely plural additional drivers?

   "You may need to load additional drivers from removable 

Bug#875858: pkgsel: Offer to install/manage unattended-upgrades

[Justin B Rye]

Raphael Hertzog wrote:
> _Description: Updates management on this system:
>  Applying updates on a frequent basis is an important part of keeping the
>  system secure.
>  .
>  By default, security updates are not automatically installed as security
>  advisories should be reviewed before installation of the updates using
>  standard package management tools.

This would benefit from an extra comma before "as".  I'd like to make
it clear that it's the installing rather than the reviewing that's
done "using standard package management tools", but I don't think a
comma helps with that... maybe instead it should have an explicitly
contrasting "before manual installation [...]"?

>  .
>  Alternatively the unattended-upgrades package can be installed, it will
 
Comma-spliced sentences; make the second one a subclause, "which will
install".

>  install security updates automatically. Note however that automatic
>  installation of updates may occasionally cause unexpected downtime of
>  services provided by this machine in the rare cases where the update is
>  not fully backwards compatible or when the security advisory requires the
>  administrator to perform some other manual operation.

Another complicated unpunctuated sentence.  Make the two kinds of
"rare case" more parallel - instead of a "where" and a "when", make
them both "where"s.

"Backwards compatible" is slightly commoner in en-GB and "backward
compatible" in en-US; for debconf prompts the d-l-e standard is to
prefer en-US.  Either way, a hyphen would help.

So:


_Description: Updates management on this system:
 Applying updates on a frequent basis is an important part of keeping the
 system secure.
 .
 By default, security updates are not automatically installed, as security
 advisories should be reviewed before manual installation of the updates
 using standard package management tools.
 .
 Alternatively the unattended-upgrades package can be installed, which will
 install security updates automatically. Note however that automatic
 installation of updates may occasionally cause unexpected downtime of
 services provided by this machine in the rare cases where the update is
 not fully backward-compatible, or where the security advisory requires the
 administrator to perform some other manual operation.


-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#563647: debootstrap: manpage neglects complete path for

[Justin B Rye]

Hideki Yamane wrote:
>> If I was doing a pedantic review of every bit of debootstrap's
>> documentation and output I'd suggest replacing "http(s)" with
>> "HTTP(S)" throughout, but there's no point doing that just here.
> 
>  I can find only one "via http" word, as below. Is it okay?

Well, I was saying "don't bother"!  But it looks easier than I was
assuming.

> diff --git a/debootstrap.8 b/debootstrap.8
> index e802003..87e2ae1 100644
> --- a/debootstrap.8
> +++ b/debootstrap.8
> @@ -137,7 +137,7 @@ Don't delete the /debootstrap directory in the target 
> after completing the
>  installation.
>  .IP
>  .IP "\fB\-\-unpack\-tarball=FILE\fP"
> -Acquire .debs from tarball FILE instead of downloading via http.
> +Acquire .debs from tarball FILE instead of downloading via HTTP(S).

Yes, this is an improvement if it might use HTTPS, though not if it
will always use HTTP.

But you missed the equivalent text in the debootstrap usage message:

  --unpack-tarball=T acquire .debs from a tarball instead of http
 
(Elsewhere in the usage output it already uses uppercase.)

I notice one other mention of wrong-case "https" in the debootstrap
sources (apart from changelog mentions): "functions" has a "keyring()"
function with this output:

 info KEYRING "Keyring file not available at %s; switching to https 
mirror %s" "$1" "$DEF_HTTPS_MIRROR"
  ^
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#563647: debootstrap: manpage neglects complete path for

[Justin B Rye]

Hideki Yamane wrote:
>  Could you review below messages in deboostrap manpage, please?

Looks good to me.

> 
> On Wed, 21 Mar 2018 17:36:07 +0900 Hideki Yamane  
> wrote:
>>  Here's a proposed patch for it.
>> 
>> diff --git a/debootstrap b/debootstrap
>> index 083473d..1d5d5c6 100755
>> --- a/debootstrap
>> +++ b/debootstrap
>> @@ -550,7 +550,7 @@ fi
>>  
>>  if [ "$UNPACK_TARBALL" ]; then
>>  if [ "${UNPACK_TARBALL#/}" = "$UNPACK_TARBALL" ]; then
>> -error 1 TARPATH "Tarball must be given a complete path"
>> +error 1 TARPATH "Tarball must be given an absolute path"
>>  fi
>>  if [ "${UNPACK_TARBALL%.tar}" != "$UNPACK_TARBALL" ]; then
>>  (cd "$TARGET" && tar -xf "$UNPACK_TARBALL")
>> diff --git a/debootstrap.8 b/debootstrap.8
>> index e802003..699f1fd 100644
>> --- a/debootstrap.8
>> +++ b/debootstrap.8
>> @@ -137,11 +137,12 @@ Don't delete the /debootstrap directory in the target 
>> after completing the
>>  installation.
>>  .IP
>>  .IP "\fB\-\-unpack\-tarball=FILE\fP"
>> -Acquire .debs from tarball FILE instead of downloading via http.
>> +Acquire .debs from gzipped tarball FILE (specified with absolute path)
>> +instead of downloading via http.
>>  .IP
>>  .IP "\fB\-\-make\-tarball=FILE\fP"
>> -Instead of bootstrapping, make a tarball (written to FILE) of the downloaded
>> -packages.
>> +Instead of bootstrapping, make a gzipped tarball (written to FILE) of the
>> +downloaded packages.
>>  The resulting tarball may be passed to a later
>>  .BR \-\-unpack\-tarball .
>>  .IP

If I was doing a pedantic review of every bit of debootstrap's
documentation and output I'd suggest replacing "http(s)" with
"HTTP(S)" throughout, but there's no point doing that just here.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: d-i network configuration for VLAN, new templates review

[Justin B Rye]

Christian PERRIER wrote:
> Quoting Dimitri John Ledkov (x...@debian.org):
>> Template: netcfg/use_vlan
>> Type: boolean
>> Default: false
>> # :sl6:
>> _Description: Are you connected to an IEEE 802.1Q VLAN trunk port?

That's a rather personal question too - fixing it makes the synopsis
awkwardly long, but we can demote the IEEE part to the long
description:

   _Description: Is this system connected to a VLAN trunk port?

>>  Virtual LAN (VLAN) is a concept of partitioning a physical network to create
>>  distinct broadcast domains. Packets can be marked for different IDs by
>>  tagging, so that a single interconnect (trunk) may be used to transport
>>  data for various VLANs.

There's some room for improvements to the English here.  Rehousing the
demoted details:

IEEE 802.1Q Virtual LANs (VLANs) are a way of partitioning a physical
network into distinct broadcast domains. Packets can be tagged with
different VLAN IDs so that a single "trunk" connection may be used to
transport data for various VLANs.

>>  .
>>  If your network interface is directly connected to a VLAN trunk port,
>>  specifying a VLAN ID may be necessary to get a working connection.
> 
> Just try dropping "your" if possible (what we call
> "unpersonnalization") : s/your/the should be enough
> 
>> Template: netcfg/vlan_id
>> Type: string
>> # :sl6:
>> _Description: VLAN ID (1-4094):
>>  If your network interface is directly connected to a VLAN trunk port,
>>  specifying a VLAN ID may be necessary to get a working connection.
> 
> Ditto.

All agreed.

>> Template: netcfg/vlan_failed
>> Type: error
>> # :sl6:
>> _Description: Error setting up VLAN
>>  The command used to set up VLAN during the installation returned an
>>  error, please check installer logs, or go back and try another
>>  configuration.
> 
> "the" VLAN ? Justin?

In the long description, yes.
 
> Ditto for "the" installer logs?

Borderline, but I'd edit that line anyway to fix the comma-splice.

The command used to set up the VLAN during the installation returned
an error. Please check the installer logs, or go back and try another
configuration.

Patch attached.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- netcfg.templates.old	2016-04-15 12:04:44.882916886 +0100
+++ netcfg.templates.new	2016-04-15 12:07:32.790541127 +0100
@@ -2,26 +2,26 @@
 Type: boolean
 Default: false
 # :sl6:
-_Description: Are you connected to an IEEE 802.1Q VLAN trunk port?
- Virtual LAN (VLAN) is a concept of partitioning a physical network to create
- distinct broadcast domains. Packets can be marked for different IDs by
- tagging, so that a single interconnect (trunk) may be used to transport
- data for various VLANs.
+_Description: Is this system connected to a VLAN trunk port?
+ IEEE 802.1Q Virtual LANs (VLANs) are a way of partitioning a physical 
+ network into distinct broadcast domains. Packets can be tagged with
+ different VLAN IDs so that a single "trunk" connection may be used to
+ transport data for various VLANs.
  .
- If your network interface is directly connected to a VLAN trunk port,
+ If the network interface is directly connected to a VLAN trunk port,
  specifying a VLAN ID may be necessary to get a working connection.
 
 Template: netcfg/vlan_id
 Type: string
 # :sl6:
 _Description: VLAN ID (1-4094):
- If your network interface is directly connected to a VLAN trunk port,
+ If the network interface is directly connected to a VLAN trunk port,
  specifying a VLAN ID may be necessary to get a working connection.
 
 Template: netcfg/vlan_failed
 Type: error
 # :sl6:
 _Description: Error setting up VLAN
- The command used to set up VLAN during the installation returned an
- error, please check installer logs, or go back and try another
+ The command used to set up the VLAN during the installation returned
+ an error. Please check the installer logs, or go back and try another
  configuration.

Re: proofreading the installation-guide

[Justin B Rye]

Christian PERRIER wrote:
> Quoting Samuel Thibault (sthiba...@debian.org):
> There is ("msgattrib --clear-fuzzy") but this will un fuzzy also what
> was fuzzy before, which is not intended.
> 
> The real safe way is the first method:
>> - fix the english text
>> - fix the english version in the corresponding .po files *exactly* the
>> same way, so that po update will be a no-op
> 
> That may be painful to do if the changes in English text are
> complicated and end up being splitted on more than one line in the PO
> files (which will make a very painful "sed" operation to do)

They're frequently going to be that sort of complicated reshuffle, and
a long way beyond anything I'd trust to sed.

It's looking as though the only way this is going to be doable is if
I split it up into multiple runs with different methodologies:
 1) things like converting  →  and dhcp → DHCP
which ought to be introduced across the whole manual in one go
but are relatively easy to apply to the translations;
 2) semantics-preserving grammar-fixes etc. that I can introduce in
stages, chapter by chapter;
 3) other things, if I live long enough.
 
But I'm rather confused by the way instead of per-chapter .po files
(like "trunk/manual/po/fr/post-install.po") some languages have
complete translated copies of the individual .xml files (such as
"trunk/manual/de/post-install/post-install.xml").  What's the
procedure for those?

[...]
>> In that case, it may be hard to fix the translations. For those where it
>> is easy (fixing numbers, which AIUI are in all languages written with
>> arabic numbers), this is the same as b) and c). For other cases, you can
>> commit your change.  Christian, do you think he should update po files
>> and commit the fuzzied result, so that further po updating will be
>> no-ops?
> 
> Yes, that's the better way, imho.

Just to be sure: when people talk about "updating" a .po file, they
don't mean the stage of manually editing it to be up-to-date, they
mean running a particular .po-update script that handles the
importing of new strings, right?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: proofreading the installation-guide

[Justin B Rye]

Baptiste Jammet wrote:
> Dixit Justin B Rye:
>> Assuming I can get write access, how do I minimise the pain?
[...]
>> But while I know a few basic svn commands (which is more than I'll ever
>> understand of git), it's not clear to me whether doing (a), (b), (c),
>> and (d) as successive commits would let translators benefit from them
>> being separate.  
> 
> The fuzzy strings will appear only after re-generating po & pot files.
> No need to do several commits. I think you can keep your original
> patches.

I don't have patches yet.  This conversation is about whether I should
start creating patches split by edit-type or by XML file.

>> Would I need to learn how to do fancy stuff like branches and merges?
> 
> I don't think so.
> For orthographic changes, you could grep all the po-files and modify the
> original string, this would prevent the fuzzy to appear. Or manually
> unfuzzy some translations after re-generating. 
>
> But if you feel uncomfortable with this, don't do it : translators are
> used to this. It's just a matter of Ctrl-U / Ctrl-Down !

It sounds to me as if dividing my patches by type won't benefit
anybody unless I first turn my desktop into an unstable development
machine so that I can run chunks of the package's build process and
learn to fiddle with generated gettext files in the appropriate way.

If that's the case, I might as well fall back on the achievable option
of submitting patches split up by file.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: proofreading the installation-guide

[Justin B Rye]

Baptiste Jammet wrote:
>> At this stage what I'd *like* to be able to do is submit half a dozen
>> different patches for different types of recurring problem - one to
>> tidy up the s and s, one to fix up the outbreaks of
>> un-English grammar, one to correct the capitalisation of titles, and
>> so on.  Unfortunately each of these patches would trample on all the
>> others, so it would be pointless unless I could be confident that each
>> one would be applied promptly while I was generating the next one, and
>> that doesn't look likely.
[...]
>> Has anyone got any useful advice?
> 
> Ask for write access on alioth ?
> I (as a translator) am a little afraid about all the fuzzy strings we
> will get. And need to discover the very subtle variations. So I don't
> want to wait the end of the release cycle !

Assuming I can get write access, how do I minimise the pain?  I could
split the changes into:

 a) fixes for the English that shouldn't affect translations (e.g.
correcting Germanic uses of "respectively", objectless "allow",
etc.)
 b) fixes that affect everybody in a clearly parallel fashion, such as
correcting "dhcp" to "DHCP";
 c) similarly, changes to the docbook, like introducing  in
place of  for packages;
 d) (optional extra) content updates - for instance Appendix C3 claims
"an older home machine might have 32MB of RAM and a 1.7GB IDE
drive"... wow, even the first PC I cobbled together from junk
parts in the nineties was significantly better than that!

But while I know a few basic svn commands (which is more than I'll ever
understand of git), it's not clear to me whether doing (a), (b), (c),
and (d) as successive commits would let translators benefit from them
being separate.  Would I need to learn how to do fancy stuff like
branches and merges?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Re: proofreading the installation-guide

[Justin B Rye]

Justin B Rye wrote:
 First, the deep-rooted termininological issues that I'd prefer to have
 sane answers for before I start fiddling with details:
 
  * why is there so little mention of BD media?  [...]
  * D-I seems to have standardised on the term MD devices [...]
  * is there any hope of getting rid of the crazy backwards jargon of
   low priority installs?  [...]
 
 (Perhaps I should make these three separate bugreports?)

Okay, these have become bugreports:
 #794936 - claims it will use CD-ROM as cover-term then doesn't
 #795944 - should call a RAID a RAID
 #796662 - rethinking priorities

At this stage what I'd *like* to be able to do is submit half a dozen
different patches for different types of recurring problem - one to
tidy up the commands and packages, one to fix up the outbreaks of
un-English grammar, one to correct the capitalisation of titles, and
so on.  Unfortunately each of these patches would trample on all the
others, so it would be pointless unless I could be confident that each
one would be applied promptly while I was generating the next one, and
that doesn't look likely.

Plan B is to proceed by dividing the sweep up into one generic
proofreading bugreport per XML file, or perhaps more manageably one
for every dozen or so XML files (which is still verging on being a
Mass Bug Filing).

Has anyone got any useful advice?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package

Bug#796662: installation-guide: rethinking priorities

[Justin B Rye]

Source: installation-guide
Version: 20150528
Severity: minor
Tags: d-i patch

Again following up #794936, here's my third and final bugreport for a
big clear individual issue before I start on a general proofreading
sweep.

The jargon of low priority installs is just plain demented.
Lowering the priority of an install would mean declaring it less
urgent, but asking for expert mode doesn't do that; it doesn't even
cause prompts to have a lower debconf priority (so that they're less
likely to be shown).  What it does is lower the cutoff on the
filtering-by-priority applied to debconf prompts!

Unfortunately I can't find a good single English word that conveys
this - we might perhaps say that expert mode is a low handholdiness
or low automation or low simplification install, but really what's
needed is for debconf to be fixed so that it works entirely the other
way around, with debconf/prompting=high meaning an expert-mode
install.  Alas, that's never going to happen - for a start it would
break everybody's preseeding setups.

Instead what I've gone for in my patch is the longwinded option, using
various circumlocutions based on the idea that expert mode means
having the prompting cutoff set to low.  This may be hard to
follow, but that's still an improvement on having a natural and
straightforward interpretation that's completely wrong.  Constructive
alternatives gladly accepted.

In this case since I'm editing multiple files I've made this a minimal
patch, ignoring the grammar errors in neighbouring lines.

Annotated walkthrough:

 Index: appendix/pppoe.xml
 ===
 --- appendix/pppoe.xml(revision 70037)
 +++ appendix/pppoe.xml(working copy)
 @@ -56,8 +56,9 @@
  para
  
  The classnameppp-udeb/classname component is loaded as one of
 -the additional components in this step. If you want to install at
 -medium or low priority (expert mode), you can also manually select
 +the additional components in this step. If you want to install with
 +the prompting cutoff set to quotemedium/quote or
 +quotelow/quote (expert mode), you can also manually select
  the classnameppp-udeb/classname instead of entering the
  quotemodules/quote parameter at the boot prompt.

A straightforward case.  As well as complicating the terminology I'm
consistently putting quotes around the names of the levels.

(Meanwhile, appendix/chroot-install.xml talks about priorities but
means something completely different by them: *package* priorities.
We really shouldn't be using the same word in two different important
technical senses at the same time!)
  
 Index: appendix/preseed.xml
 ===
 --- appendix/preseed.xml  (revision 70037)
 +++ appendix/preseed.xml  (working copy)
 @@ -127,7 +127,8 @@
  
  Obviously, any questions that have been processed before the
  preconfiguration file is loaded cannot be preseeded (this will include
 -questions that are only displayed at medium or low priority, like the
 +questions that are only displayed when the prompting cutoff is set to
 +quotemedium/quote or quotelow/quote, like the
  first hardware detection run). A not so convenient way to avoid these
  questions from being asked is to preseed them through the boot parameters,
  as described in xref linkend=preseed-bootparms/.

Another simple case.

 @@ -139,7 +140,8 @@
  mode. This delays questions that would normally be asked too early for
  preseeding (i.e. language, country and keyboard selection) until after
  the network comes up, thus allowing them to be preseeded. It also runs
 -the installation at critical priority, which avoids many unimportant
 +the installation with the prompting cutoff set to
 +quotecritical/quote, which avoids many unimportant
  questions. See xref linkend=preseed-auto/ for details.
 
  /para/important

An installation at critical priority would be one I'm prepared to
put a lot of effort into, not one that requires no input from me.

 @@ -512,7 +514,7 @@
  literaltrue/literal delays the
  locale and keyboard questions until after there has been a chance to
  preseed them, while literalpriority/literal is an alias for
 -literaldebconf/priority/literal and setting it to
 +literaldebconf/priority/literal and setting the cutoff to
  literalcritical/literal stops any questions with a lower priority
  from being asked.

We can't fix this properly, but we can make it clearer.
  
(Meanwhile, boot-installer/parameters.xml has definitions of the boot
parameter debconf/priority, but unless we can think of a way of
renaming that it'll have to stay as it is.)

(Then boot-installer/powerpc.xml talks about priorities but means that
in the ordinary English sense of the word.)

 Index: using-d-i/modules/apt-setup.xml
 ===
 --- using-d-i/modules/apt-setup.xml   (revision 70037)
 +++ using-d-i/modules/apt-setup.xml   (working copy)
 

Bug#795944: installation-guide: should call a RAID a RAID

[Justin B Rye]

Source: installation-guide
Version: 20150528
Severity: minor
Tags: d-i patch

Following up #794936, here's my second bugreport for a big clear
individual issue before I start on a general proofreading sweep.

Section 6.3.3.4 (aka the file using-d-i/modules/mdcfg.xml) describes
how to set up RAID arrays in D-I.  But instead of just calling them
that it insists on using jargon which users are unlikely to be
familiar with and which isn't even technically correct.

I'm including general proofreading fixes in this patch as well as the
headline problem, because it's all in one .xml file - if I tried to
separate things out into one patch fixing the grammar issues and one
standardising the punctuation and so on then they'd all just trample
on one another's toes.

Here's an annotated copy of the patch (and yes, this time I've
double-checked the attached version is the same file!):

 Index: mdcfg.xml
 ===
 --- mdcfg.xml (revision 70030)
 +++ mdcfg.xml (working copy)
 @@ -2,32 +2,32 @@
  !-- $Id$ --
  
 sect3 id=mdcfg
 -   titleConfiguring Multidisk Devices (Software RAID)/title
 +   titleConfiguring Software RAID/title

Because absolutely nobody calls them Multidisk Devices, and MD has
never stood for that anyway.  (There are rumours it was once Mirror
Disk, but it has officially always been Multiple Device.)

I was going to add that if you Google Multidisk Devices, it just
goes did you mean...? - but in fact if I insist, it will do that
search, and finds Frans Pop filing bug #387696 about this in 2006.
That was allegedly fixed, but here it still is.

If the mdcfg module supported RAID plus some other things then it
might be more pedantically accurate to talk here in terms of using
Multiple Device storage in general.  But it doesn't.  It's talking
about RAID, which was already widely known as RAID before Linux
existed.  So call it RAID!

  para
  
 -If you have more than one harddrivefootnotepara
 +If you have more than one hard drivefootnotepara

I'm letting mountpoints and filesystems get away with being
written as one word, but harddrive is a step too far.

(Meanwhile, the day may be approaching when we'll need to say hard
disk, flash drive, or similar main non-volatile storage system.  Or
maybe we'll be able to use plain drive as a cover-term...)
  
 -To be honest, you can construct an MD device even from partitions
 -residing on single physical drive, but that won't give any benefits.
 +To be strictly accurate, you can construct a RAID array even from partitions
 +residing on a single physical drive, but that won't give any benefits.

Leaving out this detail wouldn't have been dishonest.

Our default name for RAID arrays should be RAID arrays.  Referring
to RAID in terms of the Linux kernel driver used for it makes even
less sense when you consider that this installer is also intended foe
use on systems where arch-kernel; != Linux.

Missing indefinite article.

 -/para/footnote in your computer, you can use
 -commandmdcfg/command to set up your drives for increased
 -performance and/or better reliability of your data. The result is
 -called firsttermMultidisk Device/firstterm (or after its most
 -famous variant firsttermsoftware RAID/firstterm).
 +/para/footnote in your computer, you can set up your drives for
 +improved performance and/or reliability by using software RAID.
 +The d-i; module used for this is literalmdcfg/literal, named
 +after the Linux literalmd/literal (quoteMultiple Device/quote)
 +driver.

Users of D-I are never told that they're using mdcfg, so it's fairly
pointless to act as if they'd recognise the name; instead, _introduce_
it here.  Tagging mdcfg as a command just spoils any plan we might
have for making the command tag pull its weight (they might for
instance link to manpages.debian.org - but D-I modules don't have man
pages).  I'm falling back on marking mdcfg as a basic literal here
(which should result in the same markup as for a command), but it's
not clear it's entitled even to this much, since it isn't a word that
users ever need to be treat as a verbatim string...

Reliability of your data is subtly wrong.  If my data is the
collected prophetic ramblings of Nostradamus, RAID isn't going to make
it any more reliable!  Just say improved [...] reliability.

Then the end of the second sentence is the main point of this bug
report.  The result of using mdcfg is _not_ called Multidisk Device.
It isn't even called MD.  It's called RAID.  Introduce it as RAID,
then note in case anybody cares that it's implemented in Linux under
the name md.  (This might even go in a footnote, but we've just had
one of those.)
  
  /parapara
  
 -MD is basically a bunch of partitions located on different disks and
 -combined together to form a emphasislogical/emphasis device. This
 -device can then be used like an ordinary partition (i.e. in
 -commandpartman/command you can format it, assign a mountpoint,
 -etc.).
 +A RAID array is 

Bug#794936: installation-guide: claims it will use CD-ROM as cover-term then doesn't

[Justin B Rye]

Samuel Thibault wrote:
 The file you attached doesn't contain all the changes you have
 described. (and trying to automatically pick them from the mail is
 deemed do fail :) )

Baffling.  I thought the ~/standardize_on_CD-ROM_as_cover-term.patch
that I attached was the same file as I'd included in the body.  I
don't know where the other version comes from - I don't even know what
kind of svn diff I'd need to do to get it.

Fortunately since it was in my home directory overnight there's also a
copy in my backups, and it turns out to be the good version.  That's
perhaps the most baffling part of all, but here it is.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Index: manual/en/appendix/chroot-install.xml
===
--- manual/en/appendix/chroot-install.xml	(revision 70017)
+++ manual/en/appendix/chroot-install.xml	(working copy)
@@ -165,7 +165,7 @@
 
 /parapara
 
-If you have a releasename; debian-gnu; CD mounted at
+If you have a releasename; debian-gnu; CD-ROM mounted at
 filename/cdrom/filename, you could substitute a file URL instead
 of the http URL: userinputfile:/cdrom/debian//userinput
 
Index: manual/en/appendix/files.xml
===
--- manual/en/appendix/files.xml	(revision 70017)
+++ manual/en/appendix/files.xml	(working copy)
@@ -202,7 +202,7 @@
 
 By default the installer will install the GNOME desktop environment, but
 alternative desktop environments can be selected either by using one
-of the special CD images, or by specifying the desired desktop environment
+of the special CD-ROM images, or by specifying the desired desktop environment
 when the installer is booted (see xref linkend=pkgsel/).
 
 /parapara
Index: manual/en/appendix/pppoe.xml
===
--- manual/en/appendix/pppoe.xml	(revision 70017)
+++ manual/en/appendix/pppoe.xml	(working copy)
@@ -20,7 +20,7 @@
 /parapara
 
 To have the option of setting up and using PPPoE during the installation,
-you will need to install using one of the CD-ROM/DVD images that are
+you will need to install using one of the CD-ROM images that are
 available. It is not supported for other installation methods (e.g.
 netbootphrase condition=supports-floppy-boot or floppy/phrase).
 
Index: manual/en/appendix/preseed.xml
===
--- manual/en/appendix/preseed.xml	(revision 70017)
+++ manual/en/appendix/preseed.xml	(working copy)
@@ -73,7 +73,7 @@
 
 tbody
 row
-  entryCD/DVD/entry
+  entryCD-ROM/entry
   entryyes/entry
   entryyes/entry
   entryyesfootnote id='apx-ps-net'
@@ -119,7 +119,7 @@
 An important difference between the preseeding methods is the point at which
 the preconfiguration file is loaded and processed. For initrd preseeding
 this is right at the start of the installation, before the first question is
-even asked. For file preseeding this is after the CD or CD image has been
+even asked. For file preseeding this is after the CD-ROM or CD-ROM image has been
 loaded. For network preseeding it is only after the network has been
 configured.
 
@@ -228,7 +228,7 @@
 the location from where you want to use it. Creating the preconfiguration file
 is covered later in this appendix. Putting it in the correct location is fairly
 straightforward for network preseeding or if you want to read the file off
-a floppy or usb-stick. If you want to include the file on a CD or DVD, you
+a floppy or usb-stick. If you want to include the file on a CD-ROM, you
 will have to remaster the ISO image. How to get the preconfiguration file
 included in the initrd is outside the scope of this document; please consult
 the developers' documentation for d-i;.
@@ -290,7 +290,7 @@
   preseed/url=tftp://host/path/to/preseed.cfg
   preseed/url/checksum=5da499872becccfeda2c4872f9171c3d
 
-- if you're booting a remastered CD:
+- if you're booting a remastered CD-ROM:
   preseed/file=/cdrom/preseed.cfg
   preseed/file/checksum=5da499872becccfeda2c4872f9171c3d
 
@@ -822,7 +822,7 @@
 
 Of course, preseeding the network configuration won't work if you're
 loading your preconfiguration file from the network. But it's great when
-you're booting from CD or USB stick. If you are loading preconfiguration
+you're booting from CD-ROM or USB stick. If you are loading preconfiguration
 files from the network, you can pass network config parameters by using
 kernel boot parameters.
 
@@ -1452,7 +1452,7 @@
 # Some versions of the installer can report back on what software you have
 # installed, and what software you use. The default is not to report back,
 # but sending reports helps the project determine what software is most
-# popular and include it on CDs.
+# popular and include it on CD-ROMs.
 #popularity-contest popularity-contest/participate boolean false
 

Bug#794936: installation-guide: claims it will use CD-ROM as cover-term then doesn't

[Justin B Rye]

Source: installation-guide
Version: 20150528
Severity: minor
Tags: d-i patch

In preparation for that proofreading sweep I claimed I was going to do
(https://lists.debian.org/debian-boot/2015/07/msg00455.html;) here's
a patch implementing a fix that has apparently already been decided on
but then not fully implemented.

The idea is, instead of constantly saying either CDs or CDs/DVDs,
seemingly at random, when what it means is optical media of any sort
whether that's CD, DVD, or BD, it should instead do what it announces
it's going to do: use CD-ROM as an official generic cover-term.

It's not a simple search-and-replace job, since sometimes CD really
means CD.  Here's a commented version of the patch.

(Let me know if these shouldn't get a d-i tag.)

 
 Index: appendix/chroot-install.xml
 ===
 --- appendix/chroot-install.xml   (revision 70017)
 +++ appendix/chroot-install.xml   (working copy)
 @@ -165,7 +165,7 @@
  
  /parapara
  
 -If you have a releasename; debian-gnu; CD mounted at
 +If you have a releasename; debian-gnu; CD-ROM mounted at
  filename/cdrom/filename, you could substitute a file URL instead
  of the http URL: userinputfile:/cdrom/debian//userinput

A basic example of CD where it might mean anything up to
BluRayDisc.

 Index: appendix/files.xml
 ===
 --- appendix/files.xml(revision 70017)
 +++ appendix/files.xml(working copy)
 @@ -202,7 +202,7 @@
  
  By default the installer will install the GNOME desktop environment, but
  alternative desktop environments can be selected either by using one
 -of the special CD images, or by specifying the desired desktop environment
 +of the special CD-ROM images, or by specifying the desired desktop 
 environment
  when the installer is booted (see xref linkend=pkgsel/).
  
  /parapara

(skipping appendix/plip.xml, where there's a mention of loading
components from CD, but that's a direct quote of something I'm not
editing.)

 Index: appendix/pppoe.xml
 ===
 --- appendix/pppoe.xml(revision 70017)
 +++ appendix/pppoe.xml(working copy)
 @@ -20,7 +20,7 @@
  /parapara
  
  To have the option of setting up and using PPPoE during the installation,
 -you will need to install using one of the CD-ROM/DVD images that are
 +you will need to install using one of the CD-ROM images that are
  available. It is not supported for other installation methods (e.g.
  netbootphrase condition=supports-floppy-boot or floppy/phrase).

A slightly atypical case of the second major variety, where it already
takes DVDs into account but not BDs.

  
 Index: appendix/preseed.xml
 ===
 --- appendix/preseed.xml  (revision 70017)
 +++ appendix/preseed.xml  (working copy)
 @@ -73,7 +73,7 @@
  
  tbody
  row
 -  entryCD/DVD/entry
 +  entryCD-ROM/entry
entryyes/entry
entryyes/entry
entryyesfootnote id='apx-ps-net'

A more normal Type Two.

 @@ -119,7 +119,7 @@
  An important difference between the preseeding methods is the point at which
  the preconfiguration file is loaded and processed. For initrd preseeding
  this is right at the start of the installation, before the first question is
 -even asked. For file preseeding this is after the CD or CD image has been
 +even asked. For file preseeding this is after the CD-ROM or CD-ROM image has 
 been
  loaded. For network preseeding it is only after the network has been
  configured.

Type One.  Mind you, this use of CD-ROM or CD-ROM image can be
confusing, since after all a CD-ROM out of an official set *is* a
CD-ROM image (burned onto optical media).  Maybe in my actual
proofreading sweep I'll get to rephrase it to something like this is
after the ISO image has been loaded (e.g. from CD or USB device)...
  
 @@ -228,7 +228,7 @@
  the location from where you want to use it. Creating the preconfiguration 
 file
  is covered later in this appendix. Putting it in the correct location is 
 fairly
  straightforward for network preseeding or if you want to read the file off
 -a floppy or usb-stick. If you want to include the file on a CD or DVD, you
 +a floppy or usb-stick. If you want to include the file on a CD-ROM, you
  will have to remaster the ISO image. How to get the preconfiguration file
  included in the initrd is outside the scope of this document; please consult
  the developers' documentation for d-i;.
 @@ -290,7 +290,7 @@
preseed/url=tftp://host/path/to/preseed.cfg
preseed/url/checksum=5da499872becccfeda2c4872f9171c3d
  
 -- if you're booting a remastered CD:
 +- if you're booting a remastered CD-ROM:
preseed/file=/cdrom/preseed.cfg
preseed/file/checksum=5da499872becccfeda2c4872f9171c3d
  

More simple cases; I'll correct the references to usbs some other day.

 @@ -822,7 +822,7 @@
  
  Of course, 

Re: Bug#794936: installation-guide: claims it will use CD-ROM as cover-term then doesn't

[Justin B Rye]

Joachim Wiedorn wrote:
 Justin B Rye wrote:
 The idea is, instead of constantly saying either CDs or CDs/DVDs,
 seemingly at random, when what it means is optical media of any sort
 whether that's CD, DVD, or BD, it should instead do what it announces
 it's going to do: use CD-ROM as an official generic cover-term.
 
 It's not a simple search-and-replace job, since sometimes CD really
 means CD.  Here's a commented version of the patch.
 
 I think about other media too, e.g. USB-Stick. Perhaps it would be
 better to only say media, or optical media and flash media?

Can you give examples?  We can't replace all uses of CD-ROM with
media because much of the time we're distinguishing between
different types of media.

We hardly seem to mention solidstate/flash/memory cards anywhere, even
though machines that can boot off them could use them for USB
installs.  We probably do need a coverterm for cards-and-USB-drives,
so it's a pity Adobe have made flash media so thoroughly ambiguous.

Optical media would make a plausible alternative in many of the
places where my patch standardises on CD-ROMs, but while it's
unambiguous it is distinctly technical.

Meanwhile the English word media causes problems in the many cases
where we need a singular.  In English, a medium is a *type* of media
(or a spiritualist).  A single floppy isn't a medium, it's an
individual item of media, and that rapidly gets clunky.

In the case of optical media we can also use the word discs as
opposed to disks - but few non-techies are aware of this slightly
crazy spelling distinction, so we can't rely on it.

 * * *

Upshot: we'll probably want another patch to handle flash drives, but
first we'd need to work out what it says, and we don't need to delay
the CD-ROM patch for that.

Once I get round to doing my final sweep of Priority: wishlist changes
just to make it sound better, I might introduce a few more uses of
discs and optical media to reduce repetition.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150808115646.ga8...@xibalba.demon.co.uk

Re: proofreading the installation-guide

[Justin B Rye]

Samuel Thibault wrote:
 On to spending some time on answering this...

Well, you may have noticed I'm rather taking the long view on actually
getting started on stage one.
 
 Justin B Rye:
 First, the deep-rooted termininological issues that I'd prefer to have
 sane answers for before I start fiddling with details:
 
  * why is there so little mention of BD media?  It seems to me that we
  should almost never say CDs and DVDs; we should settle on a
  cover-term like optical media and always use that.  The one
  time it does mention BD-ROMS it claims that it's going to
  use CD-ROMs as a cover-term... but then it doesn't.
 
 Probably just lack of coordination between manual contributors. Cleaning
 up probably welcome indeed.

So maybe this is the place to start, if I can produce a patch fully
implementing the idea to go with my bugreport.
 
  * D-I seems to have standardised on the term MD devices, expanding
  MD as Multidisk Device (what, so they're Multidisk Device
  devices?); but officially md stands for Multiple Device.
  Besides, if what we're talking about is in fact a software
  RAID array, why don't we just call it that?
 
 Probably because it's called md in the linux kernel.

Yes, that would explain how the mistake came to be made, but it's
worth noting that even the kernel documentation for it (aimed at the
most hardcore of techies) has always explained it in terms of RAID.
Section 6.3.3.4 Configuring Multidisk Devices (Software RAID) might
want to mention md somewhere, but not in the title - all that's
really needed is a footnote explaining why the tool for setting up
RAID is called mdcfg.

(And since that isn't even true anywhere outside D-I, in a sane world
we'd simply rename that module to raid.  But that would require much
more than just documentation patches.)
 
  * is there any hope of getting rid of the crazy backwards jargon of
  low priority installs?  When you ask for Expert mode, you
  aren't lowering the priority of the install (i.e. declaring it
  less urgent);
 
 I agree that this is confusing because the intuition of most people will
 be the converse of what is meant.  It's however not only in the manual
 that it needs to be fixed, but also in the installer itself.

And it can be traced back to debconf, which uses a template named
debconf/priority when what it means is debconf/filtering.  But
fixing that would cause havoc for every preseeding setup in existence,
and probably every installed system with a debconf database.  It's
about as likely to be fixed as the misnomer templates.

I'm currently looking for a way of patching over it in the
documentation, but I'm not getting very far.
 
 (Perhaps I should make these three separate bugreports?)
 
 To classify discussion, that may help, yes
 
 (In fact, maybe the answers are or should be in a README somewhere?)
 
 Probably. The doc folder already has some information, additions is
 welcome.

Actually I'd missed the doc folder in my svn checkout, which doesn't
help!

  * Structure - some of the XML files seem to be unused relics, but
  it's hard to tell which...
 
 There is the svn version it is based on at the top of each of them.

Looking at datestamps would flag the What is Debian page as
unmaintained, while the subpages giving tips for Linux 2.2 on PDP-11
or whatever would escape my notice as long as they keep getting
affected by global search-and-replace operations.

All I want to do is search for filenames that are never referenced in
other pages, but I need a version of grep that ignores commented-out
text...

  * tag questions - e.g.: command is used fairly consistently for
  executables (like grub), and classinfo for some reason marks
  Debian packages (like grub-pc), but what do we do with GRUB?
 
 It depends on the context. When it is about the software in general, it
 should be the official name, which is GRUB. When it's a command to type,
 then command, when it's a package to install, then it's classname
 (not classinfo, apparently).

Oh, yes, sorry, I don't know where I got classinfo from.  But I know
why I failed to remember classname!

It's not immediately obvious why we're going to the trouble of
distinguishing command from classname (along with filename,
prompt, literal, and who knows what else).  I'm sure it's all
lovely and semantic, but all we actually want is for them to be
flagged as verbatim literal strings by appearing in the same
nonproportional typeface.

  * Should all titles be titlecase?  Could we switch to sentencecase?
 
 A lot of people contributing to the manual are not native english
 speaker, that's probably why the casing :)
 
 I personally don't really mind, but I will probably always forget to
 stick to titlecase, if we choose that.

I thought for a while that we were trying to follow a rule of
titlecase for main titles, sentencecase for subtitles, but no, it's
just slightly random.
-- 
JBR with qualifications in linguistics

Re: proofreading the installation-guide

[Justin B Rye]

Samuel Thibault wrote:
 Justin B Rye, le Fri 07 Aug 2015 15:52:00 +0100, a écrit :
 It's not immediately obvious why we're going to the trouble of
 distinguishing command from classname (along with filename,
 prompt, literal, and who knows what else).  I'm sure it's all
 lovely and semantic, but all we actually want is for them to be
 flagged as verbatim literal strings by appearing in the same
 nonproportional typeface.
 
 It makes a lot of sense to at least distinguish what the user types from
 what the computer prompted. It also makes sense, for package names, to
 put hyperlinks to package maintenance pages, or things like this.
 
 My 2¢ guesses,

prompt is only used for prompt#/prompt versus prompt$/prompt
and promptboot:/prompt.

Packagenames as hyperlinks to the PTS would be a nice idea, though it
would require some work to tidy up uses of classname to the point
where it can be relied on not to be a preseed parameter or D-I module
name or something.  Oh, maybe we could use the docbook 4.4 tag
package: http://www.docbook.org/tdg/en/html/package.html;?  That
would certainly make it feel more useful.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150807155118.ga5...@xibalba.demon.co.uk

Re: proofreading the installation-guide

[Justin B Rye]

Holger Wansing wrote:
 Justin B Rye justin.byam@gmail.com wrote:
 So all cases of releasename-cap; in the English text are mistakes.
 Really if it's only for use in German we should have called it
 Veroeffentlichungsname;!
 
 No, it's not just for German!
 It gives _all_ translators the possibility, to spell the releasename as
 they want in their language.
 I just used German and how it's used in German, to explain the principle.
 
 Not much translators use that possibility though.
 
 Such as?  There *aren't* any other languages that have mandatory
 initial capitalisation on nouns (and even German allows exceptions for
 brandnames like das iPhone or xkcd).  There's not much else that
 you could automate, so I'd be interested to know who else finds it
 useful.
 
 A quick grep shows, that releasename-cap is used in:
   Korean
   Portuguese
   French
   Italian
   Czech
   German
 
 So guys, you are all wrong?

If they're just using it to capitalise a brandname that we've decided
is canonically uncapitalisable then it's just a question of whether
they're doing it wrong or whether the decision was wrong for English
in the first place.

But if you take a proper look at the results of that grep, you'll see
that every single case is a reflection of the same problem: there are
a couple of files where the English text has randomly switched to
using releasename-cap;, and those hits are just the places where the
translators haven't changed it.

So once my proofreading sweep has finished* and all the translations
catch up, there should be no mentions of releasename-cap; except in
places where it might as well be called Veroeffentlichungsname;.

* assuming it ever gets started...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150807145350.gb4...@xibalba.demon.co.uk

Re: proofreading the installation-guide

[Justin B Rye]

Holger Wansing wrote:
 No, not _all_ instances of releasename; have to be capitalised in German,
 for example in URLs they will have to stay lowercase.
 But I can use releasename; or releasename-cap; in my translation,
 where releasename; is used in English.

So all cases of releasename-cap; in the English text are mistakes.
Really if it's only for use in German we should have called it
Veroeffentlichungsname;!

But given that we're treating the name jessie as a special string
that's entitled to ignore the usual English capitalisation rules (so
that for instance it's still lowercase when it's sentence-initial),
it's not clear why this verbatim status wouldn't also licence it to
disregard the standard capitalisation rules of German.  Unless rules
stated in German are just intrinsically stricter!

Mind you, there's no obvious reason (apart from the stiffness of
developers' little fingers) for this habit of treating the lowercase
form of the release name as canonical in the first place.  Jessie is
after all named after something that had a capital J, and even the
announcement of the codename for Debian 8 spelled it that way:
https://lists.debian.org/debian-devel-announce/2012/07/msg4.html

Things would be a lot simpler if only we could standardise on the
*capitalised* form.  But then I suppose people would complain that
that isn't what's in /etc/os-release...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150804181120.ga10...@xibalba.demon.co.uk

Re: proofreading the installation-guide

[Justin B Rye]

Holger Wansing wrote:
 Justin B Rye justin.byam@gmail.com wrote:
 Holger Wansing wrote:
 No, not _all_ instances of releasename; have to be capitalised in German,
 for example in URLs they will have to stay lowercase.
 But I can use releasename; or releasename-cap; in my translation,
 where releasename; is used in English.
 
 So all cases of releasename-cap; in the English text are mistakes.
 Really if it's only for use in German we should have called it
 Veroeffentlichungsname;!
 
 No, it's not just for German!
 It gives _all_ translators the possibility, to spell the releasename as
 they want in their language.
 I just used German and how it's used in German, to explain the principle.
 
 Not much translators use that possibility though.

Such as?  There *aren't* any other languages that have mandatory
initial capitalisation on nouns (and even German allows exceptions for
brandnames like das iPhone or xkcd).  There's not much else that
you could automate, so I'd be interested to know who else finds it
useful.

Fortunately none of this should matter for a proofreading sweep of the
English.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150804194756.ga12...@xibalba.demon.co.uk

Re: proofreading the installation-guide

[Justin B Rye]

Holger Wansing wrote:
 Justin B Rye justin.byam@gmail.com wrote:
 An interesting idea, but one that seems unlikely to work, especially
 given the way it's used in the text.  For instance, there's a page
 welcome/what-is-debian-linux.xml, which is full of sentences like
 debian; was the first Linux distribution to include a package
 management system.
 
 It was mostly me changing Debian into debian; that days in 2010.
 If I remember correctly, it was initiated by a post of Frans Pop,
 who proposed that change. And the rationale was in fact, to get a
 manual, that can easily be turned from a Debian installer manual into
 a Ubuntu installer manual, for example.

Whoever it is that's reworking the manual for the derivative is still
going to need to go through the whole text changing the content.  The
debian; entity seems liable to cost us more effort than it saves them
(a single extra search-and-replace operation).

 And I can't see any particular pattern in when it's Debian
 installer, when it's debian; installer, and when it's d-i;.
 
 With the above been said, it should be as follows:
 In sentences which apply to Debian and also to its derivates, it should
 use debian; ,
 while in sentences which only apply to Debian and not to the derivates,
 it should be Debian.

 It was also my intention to make it that way indeed, but:
 1. I found out that the job was bigger than I first thought when taking it 
 over, leading to mistakes.
 2. due to the lack of manpower in the d-i team, especially the loss of Frans,
 the d-i manual guru (amongst other roles), there was probably not enough 
 reviewing of that changes, and things may got overlooked.

Oh, well, for now I'll plan on trying to get debian; into shape as
part of my proofreading sweep - it would be easy enough to switch back
from sometimes saying debian; to always saying Debian if we
decide to give up on it.

 The debian-gnu; entity is effectively just shorthand for Debian
 GNU/arch-kernel; - confusing but handy.

Wait, does it expand to Debian or debian;?

  The architecture;,
 arch-title; and arch-kernel; entities are slightly oddly named

Since I keep losing track and having to check again, I'll leave a note
for myself here:
architecture; = 32-bit PC, 32-bit soft-float ARM, etc.
arch-title; = i386, armel, etc.
arch-kernel; = Linux, KFreeBSD, etc.

 but make sense as parametrisations, as do release; and
 releasename; as long as they're used for things that stay true for
 every release.  (Oh, and I've just noticed there's a
 releasename-cap;, used instead of plain releasename; for no
 obvious reason in hardware/supported/arm.xml and nowhere else.)
 
 But there are also special entities for enterkey;, escapekey;,
 tabkey;, f10key;, and even ekey;!  Most of these are only
 used once each - the rest of the time (and always for keys like F2
 or space) it just uses keycap.../keycap.
 
 That entities like 
 releasename-cap;
 enterkey;
 escapekey;
 tabkey;
 were created, to give translators a chance to follow the rules for their
 language there (for example, in German we write Jessie, Stretch or Unstable
 uppercase, while in English that's mostly lowercase: jessie, stretch, 
 unstable)
 or to have tab key translated into Tabulator-Taste for German, for
 example.

Sorry, I don't follow.  Surely German needs *all* instances of
releasename; to be capitalised?  How does it help to have some of
them replaced in the text with releasename-cap;?

And why is it any easier to provide translations for tabkey; than for
keycodeTab/keycode?  Why would you need ones for f10key; and
ekey;, but not keycodeF2/keycode or keycodeSpace/keycode?
 
Hmm, I can imagine cases where the *English* version might benefit
from having an entity indefinitearticle; that automatically selects
either a or an depending on whether the following substituted-in
word starts with a vowel sound!  But let's not.

 Globally said, there may be several occurrences of above things not
 being perfectly consistent, because there are many editors for the manual
 these days, but there is no Frans Pop anymore, watching the changings and 
 correcting things where needed.

 [PS included for convenience:]
 So I suppose it would be reasonable to put a comment in the document
 source explaining this, perhaps where these macros are defined, and
 making further changes as we discover the need and have time, possibly
 prompted by bug reports from Debian derivatives or forks, or even just
 doing a diff between our d-i manual and some of the derivatives'

Okay.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150728200603.ga13...@xibalba.demon.co.uk

proofreading the installation-guide

[Justin B Rye]

A month ago in #789604, Justin B Rye wrote:
 Hmm, well, I've never proofread the installation-guide as a whole.  I
 ought to get round to doing that some time.

I'm trying to work out where I'd start with this.  I can see things
that need fixing, but they fall into several different categories and
I don't know if it makes sense to try to deal with all of them at
once.

 * * *

First, the deep-rooted termininological issues that I'd prefer to have
sane answers for before I start fiddling with details:

 * why is there so little mention of BD media?  It seems to me that we
should almost never say CDs and DVDs; we should settle on a
cover-term like optical media and always use that.  The one
time it does mention BD-ROMS it claims that it's going to
use CD-ROMs as a cover-term... but then it doesn't.
 * D-I seems to have standardised on the term MD devices, expanding
MD as Multidisk Device (what, so they're Multidisk Device
devices?); but officially md stands for Multiple Device.
Besides, if what we're talking about is in fact a software
RAID array, why don't we just call it that?
 * is there any hope of getting rid of the crazy backwards jargon of
low priority installs?  When you ask for Expert mode, you
aren't lowering the priority of the install (i.e. declaring it
less urgent); you aren't even lowering the priority of the
questions it asks.  What you're doing is lowering the amount
of filtering-by-priority applied to debconf prompts - or to
put that another way, you're asking for a low *simplification*
install.

(Perhaps I should make these three separate bugreports?)

 * * *

Second, questions specific to the installation-guide's docbook, which
again it would be nice to have answers for before I start trying to
produce patches.  (In fact, maybe the answers are or should be in a
README somewhere?)

 * Structure - some of the XML files seem to be unused relics, but
it's hard to tell which...
 * tag questions - e.g.: command is used fairly consistently for
executables (like grub), and classinfo for some reason marks
Debian packages (like grub-pc), but what do we do with GRUB?
 * Should all titles be titlecase?  Could we switch to sentencecase?
 * entity questions - when am I meant to say Debian and when is it
debian;?  This like many of these entities seems to have no
obvious function other than to make the source harder to
interpret...
 * The d-i; entity expands to debian-installer in bold verbatim
lowercase.  If that is in effect the brandname of the software
project then presumably we shouldn't be talking about the
d-i; - that ought to be the Debian installer.

 * * *

Third, the various categories of routine maintenance:

 * Decobwebbing - all those examples of tiny IDE hard drives with ext3
file systems.
 * systemd-proofing - stuff about initscripts, /etc/inittab, eth0.
 * When do we say APT, when is it apt-get/aptitude/apt?
 * Non-native-English-speakerisms - the usual objectless allows and
Teutonic respectivelies, plus one that's especially common in
D-I: yes, CDs are (installation) media, but one CD isn't a
medium.
 * All those references to dhcp and ram and ips.
 * All those OldWorld PowerMacs (canonically four words).
 * Standardi[sz]ation issues (mostly behaviour).
 * General phrasing upgrades (mostly to reduce repetition).
 * Optional-extra house style tweaks like adding Harvard commas.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150726121518.ga14...@xibalba.demon.co.uk

Re: proofreading the installation-guide

[Justin B Rye]

Hendrik Boom wrote:
 Justin B Rye wrote:
  * entity questions - when am I meant to say Debian and when is it
  debian;?  This like many of these entities seems to have no
  obvious function other than to make the source harder to
  interpret...
  * The d-i; entity expands to debian-installer in bold verbatim
  lowercase.  If that is in effect the brandname of the software
  project then presumably we shouldn't be talking about the
  d-i; - that ought to be the Debian installer.
 
 Presumably both of these parametrisations are for the convenience of 
 Debian derivatives and forks.  By making these macros, it's easier for 
 the, and it'll be easier for us to merge downstream patches.

An interesting idea, but one that seems unlikely to work, especially
given the way it's used in the text.  For instance, there's a page
welcome/what-is-debian-linux.xml, which is full of sentences like
debian; was the first Linux distribution to include a package
management system.

And I can't see any particular pattern in when it's Debian
installer, when it's debian; installer, and when it's d-i;.

The debian-gnu; entity is effectively just shorthand for Debian
GNU/arch-kernel; - confusing but handy.  The architecture;,
arch-title; and arch-kernel; entities are slightly oddly named
but make sense as parametrisations, as do release; and
releasename; as long as they're used for things that stay true for
every release.  (Oh, and I've just noticed there's a
releasename-cap;, used instead of plain releasename; for no
obvious reason in hardware/supported/arm.xml and nowhere else.)

But there are also special entities for enterkey;, escapekey;,
tabkey;, f10key;, and even ekey;!  Most of these are only
used once each - the rest of the time (and always for keys like F2
or space) it just uses keycap.../keycap.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150726133745.ga19...@xibalba.demon.co.uk

Bug#789798: [RFR] New grub-installer-template

[Justin B Rye]

Christian PERRIER wrote:
 _Description: Add GRUB to firmware NVRAM configuration?
  By default, GRUB will be registered into NVRAM on platforms where this is
  required, such as UEFI Boot Manager or OpenFirmware boot devices.
  .
  Occasionally this is not desired (for instance on systems that PXE boot
  and then chainload). If you do not choose this option, the NVRAM will
  be left untouched.
 
 (eventually arrange the tenses as the above if likely to be Frenglish
 wrt to tenses)

The tenses are fine (the only Frenglish you've got there is
eventually), but if the default is still *do* add GRUB, that
last sentence might still give a wrong impression of the results of
inaction.

Maybe we could say:

   Occasionally this is not desired (for instance on systems that PXE boot
   and then chainload). If you reject this option, the NVRAM will be left
   untouched.

-- 
JBR
less offline, more sunburnt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150701164154.ga31...@xibalba.demon.co.uk

Bug#789798: [RFR] New grub-installer-template

[Justin B Rye]

Philip Hands wrote:
  Template: grub-installer/no-nvram
  Type: boolean
  Default: false
  # :sl4:
  _Description: Avoid adding GRUB to Firmmware NVRAM configuration?
   ^
Hang on, typo (and why capitalised?)

   By default GRUB will be registered into NVRAM on platforms where this is
   required. e.g. UEFI Boot Manager or OpenFirmware boot device.
 ^
Stop followed by lowercase e.g.?  I'd suggest expanding the Latin
abbreviation to such as here and for instance below.

Then taking your revisions:
   Ocasionally this is not desired (e.g. on systems that PXE boot and then
 ^
Typo: occasionally.

PXE boot as a verb might want a hyphen, but then again maybe not.

   chainload).  Answering yes here will leave NVRAM untouched.

Or setting this option, or maybe accepting, though that might be
confusing with Default: false and yes meaning avoid doing it...
I'll leave it for now.  So:

  _Description: Avoid adding GRUB to firmware NVRAM configuration?
   By default GRUB will be registered into NVRAM on platforms where this is
   required, such as UEFI Boot Manager or OpenFirmware boot devices.
   .
   Occasionally this is not desired (for instance on systems that PXE boot
   and then chainload). Answering yes here will leave NVRAM untouched.

-- 
JBR
slightly offline, slightly sunburnt


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20150630160707.ga30...@xibalba.demon.co.uk

Re: grub2 2.02~beta2-18: Please update debconf PO translation for the package grub2

[Justin B Rye]

Ian Campbell wrote:
 On Fri, 2014-12-12 at 13:07 +0200, Andrei POPESCU wrote:
 #. Type: boolean
 #. Description
 #: ../templates.in:3001
 msgid 
 Some EFI-based systems are buggy and do not handle new bootloaders 
 correctly. If you force extra installation of GRUB to the EFI removable 
 path, it should make sure that this system will boot Debian correctly 
 despite such a problem. However, this may remove the ability to boot any 
 other operating systems that also depend on this path. If so, you will 
 need 
 to ensure that GRUB is configured successfully to be able boot any other 
 OS 
 installations correctly.
 msgstr 
 
 After doing some research I can guess EFI removable path is actually 
 EFI removable media path. Shouldn't this be changed in English as 
 well?
 
 Perhaps.
 
 CCing Sledge and Kibi (who IIRC had a related EFI terminology question)
 + debian-boot.

Don't forget it's also in the short description:

 _Description: Force extra installation to the EFI removable path?

But what exactly does force extra installation mean here?  If it's
just a slightly abbreviated way of saying force AN extra
installation of GRUB, the version in the long description ought to
spell it out.

And while I'm here, I'd reverse the uses of make sure and ensure,
and switch an it with a this.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- grub2-2.02~beta2.orig/debian/templates.in	2014-12-07 16:41:50.0 +
+++ grub2-2.02~beta2/debian/templates.in	2014-12-12 13:34:19.947882873 +
@@ -15,13 +15,14 @@
 Template: grub2/force_efi_extra_removable
 Type: boolean
 Default: false
-_Description: Force extra installation to the EFI removable path?
+_Description: Force extra installation to the EFI removable media path?
  Some EFI-based systems are buggy and do not handle new bootloaders correctly.
- If you force extra installation of GRUB to the EFI removable path, it should
- make sure that this system will boot Debian correctly despite such a problem.
- However, this may remove the ability to boot any other operating systems that
- also depend on this path. If so, you will need to ensure that GRUB is
- configured successfully to be able boot any other OS installations correctly.
+ If you force an extra installation of GRUB to the EFI removable media path,
+ this should ensure that this system will boot Debian correctly despite such a
+ problem. However, it may remove the ability to boot any other operating
+ systems that also depend on this path. If so, you will need to make sure that
+ GRUB is configured successfully to be able boot any other OS installations
+ correctly.
 
 # still unused
 Template: grub2/kfreebsd_cmdline

Re: New templates related to IPv6 in Debian Installer

[Justin B Rye]

Christian PERRIER wrote:
 The templates to review are those marke with # IPv6 comment.

I've attached a patch and revised versions only touching those
templates, but also a more thoroughgoing patch.

 Template: netcfg/use_autoconfig
 Type: boolean
 Default: true
 # IPv6
 # :sl6:
 _Description: Auto-configure networking?
  Networking can be configured by either manually entering all the
  information, or automatically detecting network settings using DHCP
  or a variety of IPv6-specific methods.  If you choose to use
  autoconfiguration and the installer is unable to get a working
  configuration from the network, you will be given the opportunity to
  configure the network manually.

I'm not keen on this phrasing; it isn't a choice between me personally
doing some manual configuring or me personally detecting network
settings.  I would prefer:

Networking can be configured either by entering all the information
manually, or by using DHCP (or a variety of IPv6-specific methods) to
detect network settings automatically. If you choose to use
 
[...]
 Template: netcfg/get_ipaddress
 Type: string
 # IPv6
 # :sl6:
 _Description: IP address:
 The IP address is unique to your computer and is either:
 .
  * Four numbers separated by periods (IPv4);
  * Blocks of hexadecimal characters separated by colons (IPv6).
 .
 You can also optionally specify a CIDR netmask.

(Ah, here we go, dotted quads versus colonic octopoids.)

I think if you're going to use an either it needs an or, or to be
a plain sentence rather than a two-bullet list... though on the other
hand this layout does make it clearer that the part about CIDR
notation is an optional extra rather than a third possibility.  How
about:

  The IP address is unique to your computer, and may be:
  .
   * four numbers separated by periods (IPv4);
   * blocks of hexadecimal characters separated by colons (IPv6).
  .
  You can also optionally append a CIDR netmask (such as /24).

Meanwhile in the templates I'm not meant to be reviewing... there are
some other trivial inconsistencies in spacing/commas/quotes.  Plus:

[...]
 Template: netcfg/dhcp_hostname
 Type: string
 # :sl1:
 _Description: DHCP hostname:
  You may need to supply a DHCP host name. If you are using
 ^
There are uses of host name in one or two other templates, but this
is the only one where it looks like an error.

[...]
 Template: netcfg/no_dhcp_client
 Type: error
 # :sl2:
 _Description: No DHCP client found
  No DHCP client was found. This package requires pump or dhcp-client.
  .
  The DHCP configuration process has been aborted.

This *package*?  What package?  How can this happen, and what is the
reader expected to do about it?  Besides, dhcp-client is a virtual
package provided by pump and a couple of others, so it's not pump or
dhcp-client.  Maybe it should just say:

   No DHCP client was found.
   .
   The DHCP configuration process has been aborted.

(But that's not in either patch.) 
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
diff -ru old/netcfg-common.templates new-ipv6/netcfg-common.templates
--- old/netcfg-common.templates 2012-09-15 10:59:52.008411497 +0100
+++ new-ipv6/netcfg-common.templates2012-09-15 12:02:36.324733845 +0100
@@ -10,9 +10,9 @@
 # IPv6
 # :sl6:
 _Description: Auto-configure networking?
- Networking can be configured by either manually entering all the
- information, or automatically detecting network settings using DHCP
- or a variety of IPv6-specific methods.  If you choose to use
+ Networking can be configured either by entering all the information
+ manually, or by using DHCP (or a variety of IPv6-specific methods) to
+ detect network settings automatically. If you choose to use
  autoconfiguration and the installer is unable to get a working
  configuration from the network, you will be given the opportunity to
  configure the network manually.
diff -ru old/netcfg-static.templates new-ipv6/netcfg-static.templates
--- old/netcfg-static.templates 2012-09-15 10:59:54.616411426 +0100
+++ new-ipv6/netcfg-static.templates2012-09-15 11:58:30.220411687 +0100
@@ -3,12 +3,12 @@
 # IPv6
 # :sl6:
 _Description: IP address:
- The IP address is unique to your computer and is either:
+ The IP address is unique to your computer and may be:
  .
-  * Four numbers separated by periods (IPv4);
-  * Blocks of hexadecimal characters separated by colons (IPv6).
+  * four numbers separated by periods (IPv4);
+  * blocks of hexadecimal characters separated by colons (IPv6).
  .
- You can also optionally specify a CIDR netmask.
+ You can also optionally append a CIDR netmask (such as /24).
  .
  If you don't know what to use here, consult your network administrator.
 
Template: netcfg/enable
Type: boolean
Default: true
Description: for internal use; can be preseeded
 Set to false to disable netcfg entirely via preseed.

Template: 

Re: [SCM] d-i netcfg repository branch, people/sorina/show_essids, updated. 1.65-150-ga603dff

[Justin B Rye]

Gaudenz Steinlin wrote:
 Joey Hess jo...@debian.org writes:
  Select the wireless network name (ESSID) to use during this
  installation process.
[...]
 
 I like this variant most. Thanks for the suggestion Joey. I suggest to
 drop name and to just say the installation process:
 
 Select the wireless network (ESSID) to use during the
 installation process.
 
 While it's technically more correct that you select the name
 wpasupplicant will use, I think people will think of it as the wireless
 network they want to connect to.

People may well think in terms of the answer they give here being the
wireless network.  However, saying the wireless network (ESSID)
implies that the ESSID is the network - which is logically equivalent,
I suppose, but I'd still prefer to avoid it.

 the installation process sounds
 better to me, but I'm not a native speaker. Comments?

It sounds good to me.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120629233854.ga2...@xibalba.demon.co.uk

Re: [SCM] d-i netcfg repository branch, people/sorina/show_essids, updated. 1.65-150-ga603dff

[Justin B Rye]

Christian PERRIER wrote:
  Type: select
  Choices: ${essid_list}, Enter ESSID manually
  Description: Select wireless network
 - Select desired network name (ESSID) to attempt to connect.
 + Select desired network name (ESSID) attempt connecting to.
 
 Hmmm, Sorina, I'm not sure this is really an improvement..:-)

Neither version is quite grammatical; what an ordinary native-speaker
would say is something like:

 Select desired network name (ESSID) to attempt to connect to.

However, I suspect a lot of people would find this triple to
offputting; even native-speakers are often taught a taboo against
ending sentences with prepositions.  You could reduce the number of
repeats by taking the attempt part for granted: 

 Select desired network name (ESSID) to connect to.

Or you could mangle it to shift the final preposition:

 Select the network name (ESSID) to which a connection should be attempted.

But I suspect the best solution is:

 Select desired network name (ESSID) for connection attempt.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20120627071019.ga26...@xibalba.demon.co.uk

Re: [RFR] templates://partman-zfs/partman-zfs.templates

[Justin B Rye]

Christian PERRIER wrote:
 (please keep -boot CC'ed to answers)
[...]
 Template: partman-zfs/multipv_root
 Type: error
 # :sl4:
 Description: Separate /boot mandatory for this ZFS configuration
  The ZFS pool where your root file system is hosted is configured to use more
  than one physical volume.
  .
  With the exception of Mirror mode, configurations with multiple volumes
  (Striped or RAID-Z) are not supported by the boot loader.
  .
  You should use a separate /boot partition in another ZFS
  pool in Mirror mode or with another file system, such as UFS.

I'm not sure I follow the logic here.  The second paragraph seemed
to say that a multivolume ZFS pool in Mirror mode was okay, so if I'm
using that, why do I need to create a separate /boot partition?  And
if I create that partition on a new ZFS pool that's confined to one
volume, does it really matter what mode it's in? 

I'm guessing it should say something like:

   Your root file system is on a ZFS pool that uses more than one
   physical volume. The boot loader only supports this configuration
   for pools in Mirror mode, not Striped or RAID-Z modes.
   .
   Make sure /boot is on a partition using a supported ZFS pool
   configuration, or a different file system such as UFS.
 
 Template: partman-zfs/multipv_boot
 Type: error
 # :sl4:
 Description: Unsupported multiple volume ZFS for /boot
  The ZFS pool where your /boot file system is hosted is configured to use more
  than one physical volume.
  .
  With the exception of Mirror mode, configurations with multiple volumes
  (Striped or RAID-Z) are not supported by the boot loader.
  .
  The /boot partition should use a separate ZFS pool or another
  file system, such as UFS.

Oh!  I've ended up with suggested long-description text for
multipv_root that also works as-is for multipv_boot.  Though maybe
that's a sign it isn't specific enough.

[...]
 Template: partman-zfs/lowmem
 Type: boolean
 # :sl4:
 _Description: Go back to the menu and correct this problem?
  You have configured one or more partitions with the ZFS file
  system. Using ZFS on a computer with less than 512 Mb of memory
  MB
  may lead to stability problems and is not recommended.
[...] 
 Template: partman-zfs/vgcreate_multipv
 Type: select
 Choices: ${MULTIPV_CHOICES}
 # :sl4:
 _Description: Multidisk mode for this ZFS pool:
  Please chose the mode  for multidisk operations for this ZFS pool:
^^
   - Striped: (default) data is spread across the physical volumes.
  Similar to RAID 0;
   - Mirror:  data is replicated to each physical volume.
  Similar to RAID 1;
   - RAID-Z:  some physical volumes store parity bits and data is
  spread across others.
  Similar to RAID 5 or RAID 6.

Well, normally we'd recommend asterisks as bullets.  And it seems odd
to put a semicolon on the end of the list item when it has already
contained a period.  Actually, how about:

* Striped: similar to RAID 0 (default) - data is spread across the
   physical volumes;
* Mirror:  similar to RAID 1 - data is replicated to each physical
   volume;
* RAID-Z:  similar to RAID 5 or RAID 6 - some physical volumes
   store parity bits and data is spread across others.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110805095722.ga13...@xibalba.demon.co.uk

Re: [RFR] templates://partman-zfs/partman-zfs.templates

[Justin B Rye]

Justin B Rye wrote:
[...]

Attachments attached this time.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- partman-zfs.templates.old   2011-08-05 12:18:02.001958260 +0100
+++ partman-zfs.templates   2011-08-05 12:22:18.685960639 +0100
@@ -20,27 +20,23 @@
 Type: error
 # :sl4:
 Description: Separate /boot mandatory for this ZFS configuration
- The ZFS pool where your root file system is hosted is configured to use more
- than one physical volume.
+ Your root file system is on a ZFS pool that uses more than one
+ physical volume. The boot loader only supports this configuration
+ for pools in Mirror mode, not Striped or RAID-Z modes.
  .
- With the exception of Mirror mode, configurations with multiple volumes
- (Striped or RAID-Z) are not supported by the boot loader.
- .
- You should use a separate /boot partition in another ZFS
- pool in Mirror mode or with another file system, such as UFS.
+ Make sure /boot is on a partition using a supported ZFS pool
+ configuration, or a different file system such as UFS.
 
 Template: partman-zfs/multipv_boot
 Type: error
 # :sl4:
 Description: Unsupported multiple volume ZFS for /boot
- The ZFS pool where your /boot file system is hosted is configured to use more
- than one physical volume.
- .
- With the exception of Mirror mode, configurations with multiple volumes
- (Striped or RAID-Z) are not supported by the boot loader.
+ Your /boot partition is on a ZFS pool that uses more than one
+ physical volume. The boot loader only supports this configuration
+ for pools in Mirror mode, not Striped or RAID-Z modes.
  .
- The /boot partition should use a separate ZFS pool or another
- file system, such as UFS.
+ Make sure /boot is on a partition using a supported ZFS pool
+ configuration, or a different file system such as UFS.
 
 Template: partman-zfs/i386
 Type: boolean
@@ -61,7 +57,7 @@
 # :sl4:
 _Description: Go back to the menu and correct this problem?
  You have configured one or more partitions with the ZFS file
- system. Using ZFS on a computer with less than 512 Mb of memory
+ system. Using ZFS on a computer with less than 512 MB of memory
  may lead to stability problems and is not recommended.
  .
  You should go back to the partitioning menu and configure
@@ -191,14 +187,13 @@
 Choices: ${MULTIPV_CHOICES}
 # :sl4:
 _Description: Multidisk mode for this ZFS pool:
- Please chose the mode  for multidisk operations for this ZFS pool:
-  - Striped: (default) data is spread across the physical volumes.
- Similar to RAID 0;
-  - Mirror:  data is replicated to each physical volume.
- Similar to RAID 1;
-  - RAID-Z:  some physical volumes store parity bits and data is
- spread across others.
- Similar to RAID 5 or RAID 6.
+ Please chose the mode for multidisk operations for this ZFS pool:
+  * Striped: similar to RAID 0 (default) - data is spread across the
+ physical volumes;
+  * Mirror:  similar to RAID 1 - data is replicated to each physical
+ volume;
+  * RAID-Z:  similar to RAID 5 or RAID 6 - some physical volumes
+ store parity bits and data is spread across others.
 
 Template: partman-zfs/vgcreate_raidz_parity
 Type: select
@@ -372,7 +367,7 @@
  Logical volume or ZFS pool names may only contain alphanumeric
  characters, hyphen, colon, period, and underscore. They must be 255
  characters or less and must begin with an alphanumeric character. The names
- mirror, raidz, spare and log are not allowed.
+ mirror, raidz, spare, and log are not allowed.
  .
  Please choose a different name.
 
Template: partman-zfs/text/zfs
Type: text
# :sl4:
# File system name (untranslatable in many languages)
_Description: zfs

Template: partman/filesystem_short/zfs
Type: text
# :sl4:
# Short file system name (untranslatable in many languages)
_Description: zfs

Template: partman/filesystem_long/zfs
Type: text
# :sl4:
# File system name
_Description: ZFS file system

Template: partman-zfs/multipv_root
Type: error
# :sl4:
Description: Separate /boot mandatory for this ZFS configuration
 Your root file system is on a ZFS pool that uses more than one
 physical volume. The boot loader only supports this configuration
 for pools in Mirror mode, not Striped or RAID-Z modes.
 .
 Make sure /boot is on a partition using a supported ZFS pool
 configuration, or a different file system such as UFS.

Template: partman-zfs/multipv_boot
Type: error
# :sl4:
Description: Unsupported multiple volume ZFS for /boot
 Your /boot partition is on a ZFS pool that uses more than one
 physical volume. The boot loader only supports this configuration
 for pools in Mirror mode, not Striped or RAID-Z modes.
 .
 Make sure /boot is on a partition using a supported ZFS pool
 configuration, or a different file system such as UFS.

Template: partman-zfs/i386
Type: boolean
# :sl4:
_Description: Go back to the menu and correct

Re: [RFR] templates://partman-zfs/partman-zfs.templates

[Justin B Rye]

Justin B Rye wrote:
 - Please chose the mode  for multidisk operations for this ZFS pool:
 + Please chose the mode for multidisk operations for this ZFS pool:

Hang on, uncaught typo - it rhymes with lose and whose but it's
spelt like loose and moose...
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Template: partman-zfs/text/zfs
Type: text
# :sl4:
# File system name (untranslatable in many languages)
_Description: zfs

Template: partman/filesystem_short/zfs
Type: text
# :sl4:
# Short file system name (untranslatable in many languages)
_Description: zfs

Template: partman/filesystem_long/zfs
Type: text
# :sl4:
# File system name
_Description: ZFS file system

Template: partman-zfs/multipv_root
Type: error
# :sl4:
Description: Separate /boot mandatory for this ZFS configuration
 Your root file system is on a ZFS pool that uses more than one
 physical volume. The boot loader only supports this configuration
 for pools in Mirror mode, not Striped or RAID-Z modes.
 .
 Make sure /boot is on a partition using a supported ZFS pool
 configuration, or a different file system such as UFS.

Template: partman-zfs/multipv_boot
Type: error
# :sl4:
Description: Unsupported multiple volume ZFS for /boot
 Your /boot partition is on a ZFS pool that uses more than one
 physical volume. The boot loader only supports this configuration
 for pools in Mirror mode, not Striped or RAID-Z modes.
 .
 Make sure /boot is on a partition using a supported ZFS pool
 configuration, or a different file system such as UFS.

Template: partman-zfs/i386
Type: boolean
# :sl4:
_Description: Go back to the menu and correct this problem?
 You have configured one or more partitions with the ZFS file
 system. Although ZFS is supported on 32-bit i386, using it without
 special tuning may lead to performance or stability problems
 due to limitations of this architecture.
 .
 You should either use the 64-bit (amd64) version of this
 installer (if your hardware supports this), or go back to the
 partitioning menu and configure the partitions to use another
 file system.

Template: partman-zfs/lowmem
Type: boolean
# :sl4:
_Description: Go back to the menu and correct this problem?
 You have configured one or more partitions with the ZFS file
 system. Using ZFS on a computer with less than 512 MB of memory
 may lead to stability problems and is not recommended.
 .
 You should go back to the partitioning menu and configure
 the partitions to use another file system.

Template: partman-zfs/text/configure_zfs
Type: text
# :sl4:
_Description: Configure ZFS

Template: partman-zfs/text/in_use
Type: text
# :sl4:
# What is in use is a partition
_Description: In use by ZFS pool ${VG}

Template: partman-zfs/menu/display
Type: text
# :sl4:
# Menu entry
# Use infinitive form
_Description: Display configuration details

Template: partman-zfs/menu/createvg
Type: text
# :sl4:
# Menu entry
# Use infinitive form
_Description: Create ZFS pool

Template: partman-zfs/menu/deletevg
Type: text
# :sl4:
# Menu entry
# Use infinitive form
_Description: Delete ZFS pool

Template: partman-zfs/menu/createlv
Type: text
# :sl4:
# Menu entry
# Use infinitive form
_Description: Create logical volume

Template: partman-zfs/menu/deletelv
Type: text
# :sl4:
# Menu entry
# Use infinitive form
_Description: Delete logical volume

Template: partman-zfs/menu/finish
Type: text
# :sl4:
# Menu entry
# Use infinitive form
_Description: Finish

Template: partman-zfs/confirm
Type: boolean
Default: false
# :sl4:
#flag:translate!:4
_Description: Write the changes to disk and configure ZFS?
 Before ZFS can be configured, the current
 partitioning scheme has to be written to disk. These changes cannot
 be undone.
 .
 After ZFS is configured, no additional changes
 to the partitioning scheme of disks containing physical volumes are
 allowed during the installation. Please decide if you are satisfied
 with the current partitioning scheme before continuing.
 .
 ${ITEMS}

Template: partman-zfs/commit_failed
Type: error
# :sl4:
_Description: ZFS configuration failure
 An error occurred while writing the changes to the disks.
 .
 ZFS configuration has been aborted.

Template: partman/method_long/zfs
Type: text
# :sl4:
_Description: physical volume for ZFS

Template: partman/method_short/zfs
Type: text
# :sl4:
# keep it short (ideally a 3-letter acronym)
_Description: zfs

Template: partman-zfs/mainmenu
Type: select
Choices-C: ${CHOICES}
Choices: ${CHOICES_L10N}
# :sl4:
_Description: ZFS configuration action:
 Summary of current ZFS configuration:
 .
  Free physical volumes:  ${FREE_PVS}
  Used physical volumes:  ${USED_PVS}
  ZFS pools:  ${VGS}
  ZFS logical volumes:${LVS}
Help: partman-zfs/help

Template: partman-zfs/displayall
Type: note
# :sl4:
#flag:translate!:2
_Description: Current ZFS configuration:
 ${CURRENT_CONFIG}

Template: partman-zfs/vgcreate_parts
Type: multiselect
Choices: ${PARTITIONS

Re: new strings in partman-zfs

[Justin B Rye]

Christian PERRIER wrote:
 Quoting Robert Millan (r...@debian.org):
 Please see:
 
 http://anonscm.debian.org/gitweb/?p=d-i/partman-zfs.git;a=commitdiff;h=dc5406791a0685a3be3daf1a226462d09de2b7cf#patch13
 
 I made a few corrections. Please see
 bb075983e0c60e1c5375c4df995428f8f6897114. However, given the length of
 these changes, I'd prefer debian-l10n-english to also have a look at
 these templates. Justin and others, if you're not on a beach somewhere
 in the world, would you mind looking at the abovementioned file (it
 includes my minor corrections)

| Template: partman-zfs/confirm
| Type: boolean
| Default: false
| # :sl4:
| #flag:translate!:4
| Description: Write the changes to disks and configure ZFS?
^
Shouldn't that be to disk, as below?

|  Before ZFS can be configured, the current
|  partitioning scheme has to be written to disk. These changes cannot
|  be undone.
|  .
|  [...]
| Template: partman-zfs/vgdelete_confirm
| Type: boolean
| Default: true
| # :sl4:
| Description: Really delete the ZFS pool?
|  Please confirm the ${VG} ZFS pool removal.

Ungrammatical.  Maybe you want:

   Please confirm the removal of the ZFS pool ${VG}.

(I gather pool is just the ZFS equivalent of a VG.)

| [...]
| Template: partman-zfs/lvcreate_nonamegiven
| Type: error
| # :sl4:
| Description: No logical volume name entered
|  No name for the logical volume has been entered.  Please enter a
|  name.

This one still has a double space. ^^
  
| [...]
| Template: partman-zfs/lvdelete_error
| Type: error
| # :sl4:
| Description: Error while deleting the logical volume
|  The logical volume (${LV}) on ${VG} could not be deleted.
|  .
|  Check /var/log/syslog or see virtual console 4 for the details.

This use of parentheses makes it sound as if it is saying that there's
only one logical volume on the pool ${VG}, and that this LV (called
${LV}) could not be deleted.

I suspect what you want so say is that the specific logical volume
${LV} which happens to be on the pool ${VG} could not be deleted:

   The logical volume ${LV} on ${VG} could not be deleted.

| [...]
| Template: partman-zfs/badnamegiven
| Type: error
| # :sl4:
| Description: Invalid logical volume or ZFS pool name
|  Logical volume or ZFS pool names may only contain alphanumeric
|  characters, hyphen, plus, period and underscore. They must be 128
   ^,
(Harvard comma)

|  characters or less and may not begin with a hyphen. The names . and
|  .. are not allowed. In addition, logical volume names can not begin
|  with snapshot.

You've changed may not begin to can not begin; I'd recommend
either cannot begin (preventing the misreading is able to not
begin) or if it's just suicidal rather than impossible, should not
begin.

| [...]
| Template: partman-zfs/help
| Type: note
| # :sl4:
| Description: ZFS
|  A common situation for system administrators is to find that some disk
|  partition (usually the most important one) is short on space, while some
|  other partition is underused. ZFS can help with this.
|  .
|  ZFS allows combining disk or partition devices (physical volumes) to form
|  a virtual disk (ZFS pool), which can then be divided into virtual
|  partitions (logical volumes). ZFS pools and logical volumes may span
|  across several physical disks. New physical volumes may be added to a ZFS 
pool
|  at any time, and logical volumes have no size limit other than the total
|  size of the ZFS pool.

You've turned span to span across; in fact span can be used
alone (bridges span rivers), but I suppose given the choice span
across does give more clues to non-fluent readers.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
  


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110801133204.ga7...@xibalba.demon.co.uk

Re: Debian Installer Keyboard choices

[Justin B Rye]

Samuel Thibault wrote:
 I've gone through all the keyboard layouts that we should support
 at installation time since we have enabled translations for the
 corresponding languages in localechooser, I end up with the following
 list of addition:
 
 Albanian
 Arabic
 Asturian
 Bengali
 Bhutanese
 Bosnian - Herzegovinian

If that's of Bosnia-Herzegovina then it shouldn't be spaced - it's
Bosnian-Herzegovinian.
 
The country's standard name in English is Bosnia and Herzegovina,
which doesn't seem to have an adjective form, but then again maybe
this is talking about the Bosnian-and/or-Herzegovinian language(s).

 Catalan
 Chinese
 Corean

Korean!

 Esperanto
 Ethiopian
 Georgian
 Gujarati
 Hindi
 Irish

(I'm surprised Irish needs its own keyboard layout...)

 Kannada
 Kazakh
 Khmer
 Kurdish
 Laotian
 Malayalam
 Nepali
 Northern Norwegian

Are you sure you mean Northern?  The two standard forms of
Norwegian - Nynorsk and Bokmål - are split east/west rather than
north/south.  If either of them is more northern I would have
thought it was Bokmål, except that surely that would have been the
*first* Norwegian entry on this list, not a late addition...

 Persian
 Punjabi
 Sinhala
 Tamil
 Telugu
 Vietnamese
 
 My question is now for debian-l10n-english: are these OK as keyboard
 layout names?

The general approach of using a mixture of national and linguistic
labels seems fine...
 
 We can typically use the adjective for the country and/or for the
 language: it happens that sometimes we need to designate the country
 (because there are various keyboards for the same language, depending on
 the country), and sometimes we need to designate the language (because
 there are several languages in the country, and thus various keyboard),
 but I'm wondering for the case when there is just one widespread
 language in just one country.

In theory it's even more confusing than this, because strictly
speaking it's not a matter of languages so much as writing systems.
If I decided to start writing everything in the Shavian alphabet
tomorrow, I'd still be using British English, but I'd need to switch
keyboard layouts.  Fortunately this is academic given that all the
big-name scripts are known by the name of the language they're
designed for.
 
 For the record, the current list (a mixture of language and country
 adjectives) is:
 
 American English
 Belarusian
 Belgian
 Brazilian
 British English

(The difference between en_US and en_GB keyboards has nothing to do
with the language or even spelling-system differences - it's mostly a
matter of LC_MONETARY.  But if we dropped the word English we'd be
opening a can of worms with the label American.)

 Bulgarian
 Canadian French
 Canadian Multilingual
 Croatian
 Czech
 Danish
 Dutch
 Dvorak

(Another kind of odd-man-out.)

 Estonian
 Finnish
 French
 German
 Greek
 Hebrew
 Hungarian
 Icelandic
 Italian
 Japanese
 Kirghiz
 Latin American

Do Brazilians get a three-way choice of Brazilian, Latin American,
and Portuguese?  Or do those layouts really mean pt_BR, es_NON-ES,
and pt_PT?

 Latvian
 Lithuanian
 Macedonian
 Norwegian
 Polish
 Portuguese
 Romanian
 Russian
 Serbian (Cyrillic)
 Slovakian
 Slovene
 Spanish
 Swedish
 Swiss French
 Swiss German
 Thai
 Turkish
 Ukrainian

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110411004548.ga25...@xibalba.demon.co.uk

Bug#538850: [Fwd: #538850 - cdrom-detect template review]

[Justin B Rye]

Martin Eberhard Schauer wrote:
 we have an open BR about a template message.
 Can  you comment/review this template?

Chris is right that try again to [do X] is subtly awkward, but his
suggested alternative try and [do X] again has the drawback of
involving try and - an English idiom that styleguides discourage in
formal writing.

A second obvious option is try to [do X] again, but this just draws
attention to a potential ambiguity (in both try to and try and
versions): is it a repeated attempt, or an attempt to repeat?

If at first you don't succeed... we could go with the third option of
retry [doing X].  Yes, that one's growing on me - patch attached.
I've also fixed an unrelated typo in cdrom-detect/cdrom_module:
s/a unusual/an unusual/.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Template: cdrom-detect/load_media
Type: boolean
Default: true
# :sl2:
_Description: Load CD-ROM drivers from removable media?
 No common CD-ROM drive was detected.
 .
 You may need to load additional CD-ROM drivers from removable media, such as
 a driver floppy. If you have such media available now, insert it, and
 continue. Otherwise, you will be given the option to manually select
 CD-ROM modules.

Template: cdrom-detect/detect_progress_title
Type: text
# :sl1:
_Description: Detecting hardware to find CD-ROM drives

Template: cdrom-detect/manual_config
Type: boolean
Default: true
# :sl2:
_Description: Manually select a CD-ROM module and device?
 No common CD-ROM drive was detected.
 .
 Your CD-ROM drive may be an old Mitsumi or another non-IDE, non-SCSI
 CD-ROM drive. In that case you should choose which module to load and
 the device to use. If you don't know which module and device are
 needed, look for some documentation or try a network installation
 instead of a CD-ROM installation.

Template: cdrom-detect/retry
Type: boolean
Default: true
# :sl2:
_Description: Retry mounting the CD-ROM?
 Your installation CD-ROM couldn't be mounted. This probably means that
 the CD-ROM was not in the drive. If so you can insert it and try again.

Template: cdrom-detect/cdrom_module
Type: select
Choices: ${choices}
Default: none
# :sl2:
_Description: Module needed for accessing the CD-ROM:
 The automatic detection didn't find a CD-ROM drive. You can try to
 load a specific module if you have an unusual CD-ROM drive (that is
 neither IDE nor SCSI).

Template: cdrom-detect/cdrom_device
Type: string
Default: /dev/cdrom
# :sl2:
_Description: Device file for accessing the CD-ROM:
 In order to access your CD-ROM drive, please enter the device file that
 should be used. Non-standard CD-ROM drives use non-standard device
 files (such as /dev/mcdx).
 .
 You may switch to the shell on the second terminal (ALT+F2) to check the
 available devices in /dev with ls /dev. You can return to this screen
 by pressing ALT+F1.

Template: cdrom-detect/cdrom_fs
Type: string
Default: iso9660
Description: for internal use only
 File system used on cdrom-detect/cdrom_device.

Template: cdrom-detect/hybrid
Type: boolean
Default: false
Description: for internal use only
 Set if the CD appears to be on a USB stick.

Template: cdrom-detect/usb-hdd
Type: boolean
Default: false
Description: for internal use only
 Set if the CD appears to be a live USB-HDD image.

Template: cdrom-detect/scanning_progress_title
Type: text
# :sl1:
_Description: Scanning CD-ROM

Template: cdrom-detect/scanning_progress_step
Type: text
# :sl1:
_Description: Scanning ${DIR}...

Template: cdrom-detect/success
Type: note
# :sl2:
_Description: CD-ROM detected
 The CD-ROM autodetection was successful. A CD-ROM drive has been found and it
 currently contains the CD ${cdname}. The installation will now continue.

Template: cdrom-detect/wrong-cd
Type: error
# :sl2:
_Description: Incorrect CD-ROM detected
 The CD-ROM drive contains a CD which cannot be used for installation.
 .
 Please insert a suitable CD to continue with the installation.

Template: cdrom-detect/no-release
Type: error
# Translators: DO NOT TRANSLATE Release. This is the name of a file.
# :sl2:
_Description: Error reading Release file
 The CD-ROM does not seem to contain a valid 'Release' file, or that file
 could not be read correctly.
 .
 You may try to repeat CD-ROM detection but, even if it does succeed the
 second time, you may experience problems later in the installation.

Template: cdrom-detect/eject
Type: boolean
Default: true
Description: for internal use; can be preseeded
 Set to false to prevent the system from ejecting the CD-ROM before rebooting

Template: cdrom/suite
Type: select
Choices: stable, testing, unstable
Description: for internal use only
 Debian version to install

Template: cdrom/codename
Type: string
Description: for internal use only
 Codename for the selected suite

Template: finish-install/progress/cdrom-detect
Type: text
# finish-install progress bar item
# :sl1:
_Description: Unmounting and ejecting 

Bug#555394: os-prober: still failing

[Justin B Rye]

On Wed, Sep 15, 2010, antoine beaupre wrote:
 So this is still happening in 1.39, which is fairly disappointing. It
 seems that os-prober relies on a linux-specific sysfs in line 29:

That would explain why os-prober's so useless under kfreebsd; but
there's more to it.  When os-prober running on GNU/Linux tries to
detect a GNU/kFreeBSD partition it still doesn't achieve anything.
I've just set up a new dual-Debian-OS machine, and on this occasion
I've had enough spare time to do some more searching through
shellscripts, so here's some extra information.


On kfreebsd-i386:
 • os-prober fails to detect Linux from FreeBSD.

These days as soon as /usr/bin/os-prober's partition-finding routine
discovers that [ $(uname -s) != Linux ] it just silently exits (though
not before it's returned a couple of errors).  Doesn't this make the
os-prober_1.42_kfreebsd-{amd64,i386} packages somewhat pointless?

On i386:
 • os-prober can't see a Debian GNU/kFreeBSD install on an unmounted
   UFS2 partition (as created by debian-installer).

This is because the filesystem has too many variants; os-prober just
asks for ufs, and mount automatically defaults to ufstype=old.  I
don't see any solution for this...

On i386:
 • os-prober misidentifies a Debian GNU/kFreeBSD install on a mounted
   UFS2 partition as Debian GNU/Linux.  It can recognise the release
   number, but not the OS!

This is because /usr/lib/os-probes/mounted/90linux-distro believes
anything with files matching /lib*/ld*.so* and /etc/debian_version
must therefore be Debian GNU/Linux.  I could probably produce some
sort of hacky fix for that, but it can't live in 90linux-distro as a
special case for Debian, because that script always outputs a result
including the word linux if it finds anything.  The tidy-seeming
alternative would be to put it in the script that handles BSD probes,
except that there's no such script...

(By the way, why are these shellscripts split off from the ones under
/usr/share/os-prober and - even more bafflingly - from the ones under
/usr/lib/os-prober?  Instead they're all sitting in a subdirectory of
/usr/lib/os-probes...)

On all arches:
 • os-prober has no effect on the grub.cfg generated by update-grub.

This is unsurprising because /etc/grub.d/30_os-prober is told it's
Linux, and therefore runs linux-boot-prober on it (which gives up when
it can't see a vmlinuz).  If I hacked together some sort of
/usr/lib/os-probes/mounted/85debiangnukfreebsd-specialcase, it would
instead correctly fall through to a message about this OS not yet
being supported by grub-mkconfig.  I can see why people might not be
making this a high priority.

On all arches:
 • os-prober's documentation consists of the package name and
   description and nothing else.  Still, at least it's a good name.

The long description should at least name the supported operating
systems so that sysadmins can tell whether there's any point keeping
it installed.
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)



--
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20110122185754.ga25...@xibalba.demon.co.uk

Re: Request for review: new templates in live installer

[Justin B Rye]

Justin B Rye wrote:
 Or merge it into the previous paragraph:
 
Text and Graphical refer to the type of user interface - Text is
character-based and operated using a keyboard, whilst Graphical allows
^^
Oops, I missed a Commonwealthism; make that while.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- live-installer-launcher.templates.old   2010-07-30 21:25:28.0 
+0100
+++ live-installer-launcher.templates   2010-07-30 21:32:13.0 +0100
@@ -5,13 +5,11 @@
 Choices: Text, Text (expert mode), Graphical, Graphical (expert mode)
 # :sl3:
 Description: Installer interface:
- Text and Graphical refer to the nature of graphical environment - Text 
is
- character-based and driven solely using a keyboard, whilst Graphical can be
- operated with a mouse and supports more languages.
- .
- The functionality of the GUI installer is essentially the same as the
- Text installer as it basically uses the same programs, but with a different
- frontend.
+ Text and Graphical refer to the type of user interface - Text is
+ character-based and operated using a keyboard, while Graphical allows
+ the use of a mouse and supports more languages. Otherwise the two front
+ ends offer what is essentially the same functionality, provided via the
+ same programs.
  .
  Expert mode gives full control over the installation process. For
  example, if the hardware requires passing options to kernel modules as
Template: live-installer-launcher/mode
Type: select
Default: text
Choices-C: text, text-expert, gtk, gtk-expert
Choices: Text, Text (expert mode), Graphical, Graphical (expert mode)
# :sl3:
Description: Installer interface:
 Text and Graphical refer to the type of user interface - Text is
 character-based and operated using a keyboard, while Graphical allows
 the use of a mouse and supports more languages. Otherwise the two front
 ends offer what is essentially the same functionality, provided via the
 same programs.
 .
 Expert mode gives full control over the installation process. For
 example, if the hardware requires passing options to kernel modules as
 they are installed, you will need to start the installer in expert mode.

Template: live-installer-launcher/kernel-version-mismatch/title
Type: title
# :sl3:
Description: Kernel version mismatch

Template: live-installer-launcher/kernel-version-mismatch/error
Type: error
# :sl3:
#flag:comment:2,3
# Both LIVE_KERNEL and DI_KERNEL are kernel version numbers, such as
# 2.6.32-5-486, 2.6.32-5-amd64, or 2.6.32-5-powerpc etc.
Description: Live system kernel and installer kernel don't match
 The installer can only be used if the kernel versions of the live system
 (${LIVE_KERNEL}) and of the installer (${DI_KERNEL}) are the same.
 .
 Please reboot with the correct kernel (${DI_KERNEL}).

Re: Request for review: new templates in live installer

[Justin B Rye]

Christian PERRIER wrote:
 Template: live-installer-launcher/mode
 Type: select
 Default: text
 Choices-C: text, text-expert, gtk, gtk-expert
 Choices: Text, Text (expert mode), Graphical, Graphical (expert mode)
 # :sl3:
 Description: Installer interface:
  Text and Graphical refer to the nature of graphical environment - Text 
 is
  character-based and driven solely using a keyboard, whilst Graphical can be
  operated with a mouse and supports more languages.

I would have written the nature of ^the graphical environment, or
maybe s/nature/type/.  Hang on, though, how is a text interface a
type of graphical environment at all?

Driving an interface smells slightly of developer jargon.  It's
clear enough in context, but perhaps we could switch things around:

   Text and Graphical refer to the type of user interface - Text is
   character-based and operated using a keyboard, whilst Graphical allows
   the use of a mouse and supports more languages.

  .
  The functionality of the GUI installer is essentially the same as the
  Text installer as it basically uses the same programs, but with a different
  frontend.

s/GUI/Graphical/.  Ideally I'd like to get rid of one of those two
weaselly adverbs, but it takes quite a lot of work:

   The Graphical and Text installers offer what is essentially the same
   functionality, provided via the same programs, but with different front
   ends.

Or merge it into the previous paragraph:

   Text and Graphical refer to the type of user interface - Text is
   character-based and operated using a keyboard, whilst Graphical allows
   the use of a mouse and supports more languages. Otherwise the two front
   ends offer what is essentially the same functionality, provided via the
   same programs.

  .
  Expert mode gives full control over the installation process. For
  example, if the hardware requires passing options to kernel modules as
  they are installed, you will need to start the installer in expert mode.

No complaints here.
 
 Template: live-installer-launcher/kernel-version-mismatch/error
[...]
 Description: Live system kernel and installer kernel don't match
  The installer can only be used if the kernel versions of the live system
  (${LIVE_KERNEL}) and of the installer (${DI_KERNEL}) are the same.
  .
  Please reboot with the correct kernel (${DI_KERNEL}).

Usually the installer in debconf templates is a red flag, but here
I think you're entitled to it.

(Is a full reboot compulsory or do these kernels have CONFIG_KEXEC?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
--- live-installer-launcher.templates.old   2010-07-30 21:25:28.0 
+0100
+++ live-installer-launcher.templates   2010-07-30 21:32:13.0 +0100
@@ -5,13 +5,11 @@
 Choices: Text, Text (expert mode), Graphical, Graphical (expert mode)
 # :sl3:
 Description: Installer interface:
- Text and Graphical refer to the nature of graphical environment - Text 
is
- character-based and driven solely using a keyboard, whilst Graphical can be
- operated with a mouse and supports more languages.
- .
- The functionality of the GUI installer is essentially the same as the
- Text installer as it basically uses the same programs, but with a different
- frontend.
+ Text and Graphical refer to the type of user interface - Text is
+ character-based and operated using a keyboard, whilst Graphical allows
+ the use of a mouse and supports more languages. Otherwise the two front
+ ends offer what is essentially the same functionality, provided via the
+ same programs.
  .
  Expert mode gives full control over the installation process. For
  example, if the hardware requires passing options to kernel modules as
Template: live-installer-launcher/mode
Type: select
Default: text
Choices-C: text, text-expert, gtk, gtk-expert
Choices: Text, Text (expert mode), Graphical, Graphical (expert mode)
# :sl3:
Description: Installer interface:
 Text and Graphical refer to the type of user interface - Text is
 character-based and operated using a keyboard, whilst Graphical allows
 the use of a mouse and supports more languages. Otherwise the two front
 ends offer what is essentially the same functionality, provided via the
 same programs.
 .
 Expert mode gives full control over the installation process. For
 example, if the hardware requires passing options to kernel modules as
 they are installed, you will need to start the installer in expert mode.

Template: live-installer-launcher/kernel-version-mismatch/title
Type: title
# :sl3:
Description: Kernel version mismatch

Template: live-installer-launcher/kernel-version-mismatch/error
Type: error
# :sl3:
#flag:comment:2,3
# Both LIVE_KERNEL and DI_KERNEL are kernel version numbers, such as
# 2.6.32-5-486, 2.6.32-5-amd64, or 2.6.32-5-powerpc etc.
Description: Live system kernel and installer kernel don't match
 The installer can only be used if the kernel versions of the live 

Re: Driver injection disk debconf templates in D-I

[Justin B Rye]

Christian PERRIER wrote:
 Quoting Frans Pop (elen...@planet.nl):
 So maybe:
 Detect device driver media from hardware manufacturer
 
 I like that onethough it brings back wording to any kind of
 driver disk while the original idea was very special things embarked
 in the devices itself and was fitting something apparently asked by
 Dell to Ubuntu (ref: Colin comment on IRC).

Actually what I was thinking was either:

  _Description: Detect manufacturer-supplied device driver injection disks

or just:

  _Description: Detect built-in device driver injection disks

or indeed:

  _Description: Detect on-board device driver media

(But would people read on-board as necessarily meaning integrated
onto the motherboard and complain that these disks aren't?)
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100530083522.ga31...@xibalba.demon.co.uk

Re: Driver injection disk debconf templates in D-I

[Justin B Rye]

Steve Langasek wrote:
 Er, no.  The OEM is the original manufacturer of the equipment.  There's
 nothing ambiguous or diluted about this.  There are many different OEMs, and
 in different contexts the term will be used to refer to different equipment,
 but the term is used quite consistently and accurately across the industry.

I'm sure that's how it looks from your angle, but it looks very
different to poor ignorant industry outsiders like me and the
authors of Wikipedia's entry on this TLA, which starts with a
paragraph titled Contradictory and confusing definitions and says
they date right back to the sixties.

 So ? I dont' think we lose any information by being more explicit.
 
 You're not being more explicit, you're being *less* explicit. An OEM
 driver injection disk explicitly refers to a driver injection disk provided
 by the OEM.

That's true.  Would manufacturer-supplied cover it?  Or maybe even
just built-in?

  A hardware driver injection disk could refer to a driver disk
 provided by anyone, with no hint to the user as to where they should find
 this or when to give up looking.  If you tell the user, this refers to
 disks provided by your OEM, then they know where to look for such a disk
 and when to conclude that no such disk exists for their use.

How specialised is this hardware?  I don't think ordinary shoppers
in PC World consider themselves to _have_ OEMs, and nor would they
benefit particularly from fine distinctions between the manufacture,
assembly, and retail stages in the supply chain - all the users want
to know is that the driver injection disk is provided as part of the
hardware they're buying.

In fact, emphasising the fact that it's built in might save the user
some trouble looking for removable-media OEM driver disks.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100529235154.ga19...@xibalba.demon.co.uk

Re: Driver injection disk debconf templates in D-I

[Justin B Rye]

Christian PERRIER wrote:
 (please keep crosspost)
 
 Two new templates appeared recently in D-I, in the hw-detect
 component.
 
 They're related to the possibility of using driver injection disks
 to allow using OEM drivers for some devices. This feature was imported
 from Ubuntu.
 
 I think that these tempaltes deserve a review, to guarantee
 consistency with wording and style in other parts of D-I.
 
 Here they are:
 
 Template: debian-installer/driver-injection-disk-detect/title
 Type: text
 #  Main menu item
 # :sl1:
 _Description: Detect OEM driver injection disks
 
 Template: driver-injection-disk/load
 Type: boolean
 # :sl2:
 _Description: Load OEM supported drivers from driver injection disk?
  Your OEM has prepared internal media that contains the drivers you may
  need for supporting this hardware with this OS release.

Extra problem: a media that contains?  Media is a non-countable
noun, so it takes singular agreement.  Or to avoid making anybody
worry about that, eliminate the need for agreement by saying:

   [...] has prepared internal media containing the drivers [...]

But what on earth are internal media, anyway?  Is it talking about
drivers that are on a partition of the hard drive?
 
 My first concern here is that OEM is close to be jargon

And jargon that has drifted from the meaning it originally conveyed,
since people now use it to mean the high street PC retailer rather
than the transistor factory or the assembly plant.  Users really
shouldn't be expected to care about details of the supply chain
anyway.

 and
 driver injection disk is something quite uncommon AFAICT.
 
 Why not just talk about drivers disk? This is how things are named
 everywhere (either in the free software world or in the proprietary
 software world).

A drivers disk sounds like a floppy/CD/DVD (it seems to rule out
flash drives and memory cards, though this may not be intended).
But I don't know whether or not we're talking about removable media
here anyway. 

And when it says drivers, does it mean modules or firmware?

 Your OEM also sounds weird. I do not own any OEM...:-)

Do you mean in the sense that only retailers are entitled to talk
about our OEM?  Or does your parents also sound weird?

 I would say
 something like my hardware supplier or The hardware manufacturer.
 this hardware: what hardware? The template doesn't say what part of
 the machine might need extra drivers. As it might be complicated to
 telle which in the template, at least we could be vague and say Some
 hardware
 
 this OS release: we never talk like this in other parts of D-I. If
 we want to avoid branding (this release of Debian), we could at
 least use this release of the operating system).

Is there any reason to tie it to a particular release anyway?  I
mean, do we know of any hardware that comes with drivers labelled
certified for use with Debian Lenny?

And may need - is this uncertainty because it can detect the
existence of hardware for which drivers are available, but doesn't
know whether it's (e.g.) your sole network card or whether it's
something that can safely be ignored until the system's up and
running?

Making a few arbitrary guesses about what this template is trying to
say (I won't be very surprised if I'm wrong), I would suggest:

  _Description: Load drivers from removable media?
   Installing on this hardware may require some firmware to be
   loaded from a drivers disk provided by the manufacturers.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100526174804.ga24...@xibalba.demon.co.uk

Re: Driver injection disk debconf templates in D-I

[Justin B Rye]

Justin B Rye wrote:
 Extra problem: a media that contains?  Media is a non-countable
 noun, so it takes singular agreement.  Or to avoid making anybody
 worry about that, eliminate the need for agreement by saying:

Whoops, contains _is_ third-person singular.  The thing that
sounds so odd about your OEM has provided media that contains the
drivers is the combination of mass-noun syntax with count-noun
semantics (compare this _piece_of_ media contains drivers).

So much for not worrying about it.
-- 
JBR
Never work between meals - Norfolk proverb


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100526195419.ga28...@xibalba.demon.co.uk

Re: Driver injection disk debconf templates in D-I

[Justin B Rye]

Petter Reinholdtsen wrote:
 I see there is some confusion about this feature.  This new udeb
 provide an automatic way to activate driver debs that are made
 available as part of the hardware.  The internal driver disk is part
 of the hardware (think USB stick that is part of the BIOS or ILO/DRAC
 devices), and not a removable media.  The new udeb detect such devices
 and take care of the driver loading.  I hope this explains more what
 it is.

Wow, so it's only a driver disk in a sort of analogical sense;
that's a pretty good justification for giving it a name of its own.
Driver injection is jargon, but at least it's likely to be what
the accompanying hardware docs call it.

Latest attempt:

 _Description: Load drivers from internal drivers disk?
  Installing on this hardware may require some drivers provided by the
  manufacturer to be loaded from the built-in driver injection disk.

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100526225535.gb29...@xibalba.demon.co.uk

Re: [RFC] Draft of announcement and errata, last chance of change

[Justin B Rye]

 I've done the proposed fixes and also update the errata for another
 review.
 
 Please give it a last look before we announce. Errata is at
 http://people.debian.org/~otavio/d-i/errata.en.html and the announcement
 text below.

Apologies if this mail's a bit of a misshape - once again I've stopped
receiving any mail from lists.debian.org, so I'm having to fake things
up from the d-l-e web archive.
 
 The Debian Installer Team[1] is pleased to announce the Debian Installer
 6.0 Alpha1. This first release since Lenny brings a lot of new features
 and improvements.
 
 Is also important to note that we disabled the Graphical Installer for
 optional: ^have

(Implying current, but impermanent, consequences.)

 this release due a breakage in DirectFB backend of GTK+ library. We are
^the^the
 working to get this fixed for next release.
   ^the
 
 As most people will have noticed, this release has taken more time than
 usual. This was due a lot of different reasons that go from technical

Due to reasons is common enough in speech, but it's the kind of
technically redundant expression that annoys some people, so say:

   This was for various reasons

 (major changes in installer itself and other components that affect us)
   ^the
(in d-i but in the installer)

 to lack of manpower to manage all needed things in timely way. We really
 all the work required quickly.

(Timely means on schedule, which isn't quite right; maybe
without delay?  In a hurry?)

 need more people to help us and contribute, please contact us if you're
   comma splice! promote s/,/;/
 interested in helping.
 
 Here follows the most important new features and improvements.
 
 Help during the installation process
 
 The dialogs presented during the installation process now have the
 possibility to offer a help option for user. This is already in use in
  capacity(?) to offer the user a help option.
 some dialogs during the installation and its usage will grow during next
 and will be increasingly used in future
 releases. We believe this will improve the user experience during the
 installation process, especially for new users.
 
 Installation of recommended packages
 
[is all good]
 Changes in selection of language/country/locale
 ---
 The localechooser component of the installer has received some love. This
 component combines selection of three values:
 - language
 - location (country)
 - locale

I'm standardising on * content; * content; * content.

What exactly is the difference between selecting an en_GB locale and
selecting (British) English as your language?  Does the latter just
set LC_MESSAGES=en_GB.UTF-8 for the d-i session?
 
 There have been improvements to make the selection of location and locale
 less interdependent and at the same time more flexible. The dialogs have
 been improved to provide better guidance.
 
 When selecting a location, users should select the country where they
 live as the selected location determines the local time zone the
 installed system will use. New is that for languages for which multiple
 locales are available, the installer will then (if needed) ask which
 locale the user prefers.
 
 So, using the Squeeze installer it is now possible during default
 installations to say for example I want to use English as language, I
^my
 live in Germany (and thus want CET as time zone), and prefer en_GB.UTF-8
   ^my ^I
 as my system locale.

 Selection of additional locales to be generated (including legacy locales)
 is still only possible when installing in expert mode (using medium or low
 debconf priority).

When you say still only possible, you mean this has remained true?
 
 More flexible preseeding of language/country/locale
 ---
[...]
 
 Improved mirror selection
 -
 The main improvements are better support for installing oldstable and
 archived releases from archive.debian.org.
 
 Other changes:
 * only displays available releases (in case of partial mirrors)
 * normally displays both the codename and the suite of available releases
 * warns if the default release is not available (instead of silently
   falling back to a different release)
 * improved checks that the selected mirror is consistent

That's three verb phrases and a noun phrase, but never mind.
Standardise the punctuation, though.
 
 Option to select the UTC time zone
 
 This new option is only available in expert mode (or more exact: when
 installing at medium or low debconf priority).
 
 Changes in the 

Re: [RFC] Draft of announcement and errata, last chance of change

[Justin B Rye]

Justin B Rye wrote:
 Tasks changes
 -
 Many changes were done regarding packages selection and also:
 - Accessibility packages were add to GNOME task;
 - laptop task has been modernized;
 - SSH Server task has been added;
 
   Many changes have been made to package selection, plus:
   * accessibility packages have been added to the GNOME task;
   * the laptop task has been modernized;
   * a SSH Server task has been added.
   ^n
Oops; yes, I pronounce SSH as [səʃ], but I think an ess-ess-aitch
server is standard.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100220203406.ga10...@xibalba.demon.co.uk

Re: [RFC] Draft of announcement and errata, last chance of change

[Justin B Rye]

Oops, I missed another one:
 Is also important to note that we disabled the Graphical Installer for

s/Is/It is/
-- 
JBR
Never work between meals (Norfolk proverb)


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20100220232646.ga14...@xibalba.demon.co.uk

Bug#555394: os-prober: fails both sides of a Linux/kFreeBSD dual-boot

[Justin B Rye]

Package: os-prober
Version: 1.35
Severity: normal

My Squeeze testbed system dual-boots Debian GNU/Linux and Debian
GNU/kFreeBSD (installed from an October debian-installer netinst
daily image).  On both OSes, os-prober is pulled in by grub2, but
fails to live up to its documentation (by which of course I mean the
package description).

The partition layout is just:
 /dev/hda1 AKA ad0s1 (ext3) = i386 system
 /dev/hda2 AKA ad0s2 (ufs2) = kfreebsd-i386 system
 /dev/hda3 AKA ad0s3 (vfat) = unused data partition
 /dev/hda4 AKA ad0s4 (swap) = swap partition

On the Linux side (running either 2.6.30-2-486 or a kernel-packaged
2.6.31.custom), sudo os-prober outputs nothing - unless I first
mount the partition that has the GNU/kFreeBSD system on it, in which
case it misidentifies it:

 /dev/hda2:Debian GNU/Linux (squeeze/sid):Debian:linux

As a result, /etc/grub.d/30_os-prober either silently fails to
detect anything, or outputs:

 Found Debian GNU/Linux (squeeze/sid) on /dev/hda2

Either way it does nothing to the generated grub.cfg.  I might guess
that this is because linux-boot-prober /dev/hda2 finds nothing,
but then again nor does linux-boot-prober /dev/hda1.

No, wait, my mistake: update-grub also outputs copious debug
output to syslog.  That looks like a recently-added grub2 bug, but
here's a copy of the output anyway:

 Nov  9 12:00:07 xan 10freedos: debug: /dev/hda3 is a FAT32 partition
 Nov  9 12:00:07 xan 10qnx: debug: /dev/hda3 is not a QNX4 partition: exiting
 Nov  9 12:00:07 xan 20microsoft: debug: /dev/hda3 is a FAT32 partition
 Nov  9 12:00:07 xan kernel:
 Nov  9 12:00:07 xan kernel: WARNING Wrong ufstype may corrupt your 
filesystem, default is ufstype=old
 Nov  9 12:00:07 xan kernel: You didn't specify the type of your ufs filesystem
 Nov  9 12:00:07 xan kernel: mount -t ufs -o 
ufstype=sun|sunx86|44bsd|ufs2|5xbsd|old|hp|nextstep|nextstep-cd|openstep ...
 Nov  9 12:00:07 xan kernel: ufs_read_super: bad magic number
 Nov  9 12:00:07 xan macosx-prober: debug: /dev/hda3 is not an HFS+ partition: 
exiting
 Nov  9 12:00:07 xan os-prober: debug: running 
/usr/lib/os-probes/50mounted-tests on /dev/hda1
 Nov  9 12:00:07 xan os-prober: debug: running 
/usr/lib/os-probes/50mounted-tests on /dev/hda2
 Nov  9 12:00:07 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/10freedos on mounted /dev/hda3
 Nov  9 12:00:07 xan os-prober: debug: running /usr/lib/os-probes/mounted/10qnx 
on mounted /dev/hda3
 Nov  9 12:00:07 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/20macosx on mounted /dev/hda3
 Nov  9 12:00:07 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/20microsoft on mounted /dev/hda3
 Nov  9 12:00:07 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/30utility on mounted /dev/hda3
 Nov  9 12:00:08 xan 30utility: debug: /dev/hda3 is a FAT32 partition
 Nov  9 12:00:08 xan 50mounted-tests: debug: /dev/hda4 is a swap partition; 
skipping
 Nov  9 12:00:08 xan os-prober: debug: os detected by 
/usr/lib/os-probes/50mounted-tests
 Nov  9 12:00:08 xan os-prober: debug: running 
/usr/lib/os-probes/50mounted-tests on /dev/hda4
 Nov  9 12:00:08 xan os-prober: debug: running /usr/lib/os-probes/mounted/40lsb 
on mounted /dev/hda3
 Nov  9 12:00:08 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/70hurd on mounted /dev/hda3
 Nov  9 12:00:08 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/80minix on mounted /dev/hda3
 Nov  9 12:00:08 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/90linux-distro on mounted /dev/hda3
 Nov  9 12:00:08 xan os-prober: debug: running 
/usr/lib/os-probes/mounted/90solaris on mounted /dev/hda3

It obviously isn't guessing the UFS-type that d-i gave me.

On the kFreeBSD side, sudo os-prober outputs only:

 Cannot find list of partitions!

...with no debug output to syslog.

The same problem with identifying kFreeBSD partitions affects
grub-install, which isn't a disaster because I don't really want it
to lay claim to the boot sector.  update-grub does at least generate
a grub.cfg with a kFreeBSD boot stanza, and I can use a script on
the Linux side to copy that from /mnt/boot/grub/grub.cfg into 
/boot/grub/grub.cfg... so everything boots happily.

Nonetheless, it seems to me that os-prober should be able to identify
Debian installs, and it isn't managing to do that here.

-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing'), (50, 'unstable')
Architecture: {i386,kfreebsd-i386} (i686)

Kernel: {Linux 2.6.31.custom,kFreeBSD 7.2-1-686}
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages os-prober depends on:
ii  libc{6,0.1} 2.10.1-5   GNU C Library: Shared libraries

os-prober recommends no packages.

os-prober suggests no packages.

-- no debconf information
-- 
JBR
Ankh kak! (Ancient Egyptian blessing)



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of 

Bug#477092: [PATCH] add support for setting a username + password in grub-installer for GRUB 2

[Justin B Rye]

Christian Perrier wrote:
 Quoting Felix Zielcke (fziel...@z-51.de):
[...]
 +Template: grub-installer/superuser
 +Type: string
 +# :sl2:
 +_Description: GRUB superuser:
 + The GRUB boot loader offers many powerful interactive features, which could
 + be used to compromise your system if unauthorized users have access to the
 + machine when it is starting up. To defend against this, you may choose a
 + username and password which will be required before editing menu entries or
 + entering the GRUB command-line interface. By default, any user will still 
 be
 + able to start any menu entry without entering a username and password.
 + .
 + If you do not wish to set a GRUB username, leave this field blank.
 +
 
 s/your system/the system
 
 maybe s/starting up/booting up
 
 I'm not sure about To defend against this

No strong opinion on any of these (even the you might not be the
owner quibble is weak here).

 username or user name?

One word.  Christian Perrier and Justin B Rye are user names,
but not their usernames.

 +Template: grub-installer/grub2-password
[...]
 
 Another option is somethign similar to the root password prompt:
 
 _Description: GRUB password:  
  You need to set a password for GRUB. A malicious or unqualified user
  with GRUB access can have disastrous results, so you should take care
  to choose a GRUB password that is not easy to guess. It should not be
  a word found in dictionaries, or a word that could be easily
  associated with you.

Looks good to me.

 +Template: grub-installer/empty-password
 +Type: error
 +# :sl2:
 +_Description: Empty password
 + You have given a username but no password. If you don't want authorization
 + please don't specify an username, else you have to give a password.

Looks bad to me: s/an username/a username/; s/, else/; otherwise/;
and you don't want (to get) authorization, you want there to be 
authentication. 

 You may want to use the same wording than the similar template in
 user-setup:
 
 _Description: Empty password
  You entered an empty password, which is not allowed.
  Please choose a non-empty password.

This loses the advice on what to do if you're not trying to set up a
password.  On the other hand, how would I apply that advice if I
didn't already know about dpkg-reconfigure?  Is there a back
button?
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#452388: Back on 'standard system' is confusing bug report

[Justin B Rye]

Christian Perrier wrote:
 Description: Standard system
  This task installs a reasonably small character-mode system.
 
 What about something like:
 
 Description: Standard (non-graphical) system
  This task installs a reasonably small character-mode system,
  that provides the most commonly used tools in non-graphical environments.

No comma before a that clause; and the last part isn't quite right
either (provides [...] tools in [...] environments?).  I assume
the intended sense is the tools that in non-graphical environments
are used most commonly, but there's no good way of phrasing that.
How about just:

  This task installs a reasonably small character-mode system, providing
  tools often used in non-graphical environments.

However, I worry that this will encourage CLI-phobic users to
uncheck the Standard task.  It's not for console-only systems; after
all, I'm using mutt right now in my window manager.  It's a basic
neutral user environment, including apt, exim4, perl, python, and
so on, just not X - the only time I would leave it out is on a
bare-bones server with no users.  Perhaps it should say something
more like: 

  This task sets up a basic user environment, providing a reasonably
  small selection of services and tools usable on the command line.

Or if the idea is that GNOME users _don't_ need it, it needs a name
change to, say, Traditional or Command Line User Environment.  A
name change might be appropriate anyway, given that tasksel's
Standard task includes the whole of Priority: required and
Priority: important, not just Priority: standard.
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package



-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Request for review change in user-setup template

[Justin B Rye]

Christian Perrier wrote:
 Quoting Luk Claes (l...@debian.org):
 + Choosing an empty root password is not allowed. If you choose an empty
 + password, then a user account will be created and given the power to
 + become root using the 'sudo' command.

 Hmmm, the templates says that using an empty password is not allowed
 and *then* that choosing one will switch to sudo mode. That can be
 confusing.
 
 Also, the templates gives the feeling that the user account will be
 created *only* when choosing an empty password, which is of course not
 true..:-)

It certainly had me fooled - I had no idea it didn't mean what it
said.  And I'm still not clear whether it means plain sudoing
privileges or NOPASSWD sudoing privileges...
 
 I'd suggest:
 
 If the password is left empty, the unprivileged account that is
 created in next steps will be granted with the power to become root
 using the sudo command.

The account sounds fairly privileged to me, and is created in next
steps needs work.  My best guess so far:

 Setting an empty root password is not allowed. If you specify an empty
 password, the system's initial user account will be given the power to
 become root using the 'sudo' command[ without a password].

-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Re: Request for review change in user-setup template

[Justin B Rye]

Christian Perrier wrote:
 Quoting Justin B Rye (j...@edlug.org.uk):
  Setting an empty root password is not allowed. If you specify an empty
  password, the system's initial user account will be given the power to
  become root using the 'sudo' command[ without a password].
 
 That still leaves us with This is not allowed. If you di it, blah
 blahwhich anybody will immediately answe: So? Is it allowed *or
 not*?

Specifying an empty password is allowed, but it doesn't set an
empty root password.  Still, your approach is much clearer:

 The root user should not have an empty password. If you leave this
 empty, the root account will be disabled and the system's initial user
 account will be given the power to become root using the sudo
 command.

And the root account will be disabled is useful information.

All that's left is: mind the quotes round sudo!
-- 
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package


-- 
To UNSUBSCRIBE, email to debian-boot-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org