Re: DD application (Re: Next attempt to add Blends to Debian installer)

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Sat, 11 May 2024 22:07:44 +0200):
> You're definitely acquainted with the a bunch of things in the installer
> ecosystem, you're also knowledgeable about l10n topics, and you're
> definitely an excellent team player.
> 
> As far as I'm concerned, the only bug is that your key is not in the
> right keyring! :)

So, let's see if I can fix this bug:
https://nm.debian.org/process/1292/


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Next attempt to add Blends to Debian installer

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Sun, 12 May 2024 08:54:11 +0200):
> Keeping the whole git history of tasksel without its tag is probably
> fine, in case anyone needs to dig up why this thing is done that way,
> but I'm not sure we should keep tasksel entries in debian/changelog; I
> would probably only keep the blendsel entry, adding a reference to the
> version of tasksel it was forked off from. Unless some others feel
> strongly we should keep the whole tasksel history in debian/changelog?

I only kept that for completeness; didn't intended to keep it on the long
run. Now cleaned up.

> I've fixed a few minor things for the rename. It looks to me the README
> could probably be stripped down to mention blendsel's being a fork of
> tasksel, and pointing at tasksel's README for more information. Less
> duplication would be best (and I'm not sure how current the contents are
> anyway). Ditto for tasks/README.

Adapting READMEs is my todo list.

> I think you know best how to adjust README.translators :)
> 
> I'm happy to upload it as-is (modulo debian/changelog), but I suspect
> it'd make sense to adjust tasks/ before doing so? Happy either way.

I would like to leave it as is for now.
Thank you very much for taking care of this thingy!

> > - I prepared a change in pkgsel, to call blendsel depending on the
> >   descision, if Debian pure blends are wanted or not.
> >   See https://salsa.debian.org/holgerw/pkgsel/
> 
> That I didn't check yet, my focus is on the current blocker (as far as
> the DM vs. DD limitation is concerned).

Ok, fine with me.
Just wanted to illustrate to whole idea behind this approach.

> > Anyway, I think I have it running so far, the blendsel dialog appears
> > and shows the items to select; I'm attaching a screenshot showing the 
> > current state (please note, that the dialog shows three desktop environments
> > as placeholder for now; the tasksel - and therefore blendsel as well -
> > logic does not allow to have packages|tasks|blends listed that don't
> > have the corresponding task-* packages in the archive).
> 
> Understood, but please let me know if it makes sense to have them in the
> 0.1 upload, or if you'd like to introduce them in 0.2 once 0.1 has been
> accepted.

I would like to keep that for future releases, even if I already went one step
further: thanks to Phil's Salsa CI black-magic tests it's proven that basically
it works in the wild as expected. Thanks Phil!

> > The template should be rephrased, I would ask for review on
> > debian-l10n-english when the time comes, but I guess there is still
> > time for that...
> 
> You should talk to our beloved l10n coordinator!

Need to find some time when being along at home, to prevent my wife from
pondering "Hmm, Holger is getting bewildered, he's having a discussion with 
himself!" :-)))


> And yeah, lintian/bookworm reports some things we don't normally do:
> 
> W: blendsel: using-first-person-in-templates blendsel/tasks [templates:16]
> 
> Seriously though, I'm not familiar with the semantics behind /first vs.
> /tasks in tasksel. Do we want/need the same semantics in blendsel?

I already realized, that blendsel/first is not used at all, so that can go away
I think.

> I think we should have lintian-overrides for the main package, just like
> tasksel, at least for those (again, only running lintian/bookworm):
> 
> E: blendsel: no-debconf-config
> W: blendsel: debconf-is-not-a-registry 
> [usr/lib/blendsel/blendsel-debconf:3]

Done.

> Finally, this should probably go away from both packages, I don't even
> remember having managed that package:
> 
> Conflicts: base-config (<< 2.32)
> 
> (And indeed, that was 20 years ago.)

Done.
So ready for first upload! Get the ball rolling :-)


> Bonus points: maybe clean up tasksel's debian/source/lintian-overrides?
> 

On the todo list now.



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Reword non-free-firmware description

[Holger Wansing]

Hi,

Holger Wansing  wrote (Sat, 4 May 2024 13:28:41 +0200):
> Hi,
> 
> Holger Wansing  wrote (Wed, 1 May 2024 17:02:10 +0200):
> > What to do about this MR regarding rewording of (non-free) firmware 
> > description ?
> > https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/15
> > 
> > Should something be done there?
> 
> Any objections against applying this, adding information to the respective
> dialog, what firmware files are and why they are needed (or not) ?

Just applied; MR closed.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

DD application (Re: Next attempt to add Blends to Debian installer)

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Fri, 10 May 2024 09:00:39 +0200):
> Holger Wansing  (2024-05-10):
> > Now blendsel being moved to installer-team, would you mind giving me
> > dm permissions, so I can upload? Thanks
> 
> I seem to recall that only works for existing packages?

Ah ok, yes that makes sense.
Then anyone else will have to do the upload :-(

> May I suggest to think about turning your DD account into a
> non-non-uploading one? :)

I know you repeatedly suggested this.
Especially every time I ask for more packages to get dm permissions for :-))


My problem with this:
am I really capable of being a DD? You might remember that I am not a 
programmer, I have no real skills in this direction.
I can do some scripting, gained by self-learning, but that does not make
a programmer of me IMO ;-)
So I am unsure if I can successfully go the apply-for-DD path...
I fear I lack some basic knowledge for this.
Don't want to waste my and the application manager's time and effort for 
something, that does not lead to anything at the end.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Next attempt to add Blends to Debian installer

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Thu, 9 May 2024 23:18:06 +0200):
> > Would the installer-team be ok with taking blendsel under its umbrella,
> > as tasksel is, to get it uploaded?
> 
> Looks good to me.

Now blendsel being moved to installer-team, would you mind giving me dm
permissions, so I can upload? Thanks


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Next attempt to add Blends to Debian installer

[Holger Wansing]

Hi,

Holger Wansing  wrote (Tue, 13 Feb 2024 23:43:35 +0100):
> could we just "copy tasksel with its UI and infrastructure" into a new 
> package 
> (I name it 'blends-di-tasks' here), which has all the blends listed, and add 
> one entry to tasksel with a name like "Debian Pure Blends" or similar?
> 
> If one then selects "Debian Pure Blends" in the good all known tasksel, the 
> blends-di-tasks package would be installed on /target, and later a new dialog 
> would appear, listing all the blends, where the user could select which one 
> to 
> install.
> (If the "Debian Pure Blends" entry stays unchecked, as would be the default
> value, everything stays as is: the new dialog would not appear, no difference
> to previous releases.)
> 
> Would that be a possible solution for all involved parties?

I worked on this in the meantime, and would like to propose my current 
state:

- I adapted tasksel, to become an installer for Debian pure blends. The
  new package is blendsel, see https://salsa.debian.org/holgerw/blendsel/

- I prepared a change in pkgsel, to call blendsel depending on the
  descision, if Debian pure blends are wanted or not.
  See https://salsa.debian.org/holgerw/pkgsel/


I did some testing in d-i, however that's tricky:
testing is problematic as long as the new blendsel package is not in the
archive, and the same with the changed pkgsel.
So I had to "live-patch" the d-i for testing of blendsel, and therefore
I cannot provide a working test image or the like (or I don't know how).

Anyway, I think I have it running so far, the blendsel dialog appears
and shows the items to select; I'm attaching a screenshot showing the 
current state (please note, that the dialog shows three desktop environments
as placeholder for now; the tasksel - and therefore blendsel as well -
logic does not allow to have packages|tasks|blends listed that don't
have the corresponding task-* packages in the archive).

However, there will most likely be some glitches and edges to fix in
blendsel, a review would be more than welcome...
The template should be rephrased, I would ask for review on debian-l10n-english
when the time comes, but I guess there is still time for that...


So, how to proceed now?
To make progress, the new blendsel needs to get into the archive I guess,
otherwise testing and providing test images will not work IMO.

Would the installer-team be ok with taking blendsel under its umbrella,
as tasksel is, to get it uploaded?


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1016957: remove kbd-chooser from the archive?

[Holger Wansing]

Hi,

Paul Gevers  wrote (Sat, 4 May 2024 07:46:45 +0200):
> Hi Bastian,
> 
> On Sat, 9 Sep 2023 19:03:07 +0200 Bastian Germann  wrote:
> > Control: severity -1 serious
> 
> Can you please elaborate? I'm not seeing anything serious in this bug 
> report.

I think Bastian's approach is, to remove kbd-chooser from the archive, since
it was stated (see below) that it's no longer in use.
d-i has switched away from it to console-setup 12 years ago with
https://salsa.debian.org/installer-team/debian-installer/-/commit/2575a669e91252a6253430020137154c995c9b38

Are there any ports maybe, that still use it somehow?
Or what about derivatives?
It's an udeb-only package, so the use in the installer is the only imaginable 
scenario...

@installer-team: any comments?

> 
> > On Wed, 10 Aug 2022 21:42:34 +0200 Holger Wansing  
> > wrote:
> > > kbd-chooser is no longer in use, I think.
> > > Or am I missing something?
> > 
> > I am raising severity to serious then so that it can be autoremoved from 
> > testing.
> 
> This package is a key package (because of debian-installer), so it can't 
> be autoremoved.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Bug#1043226: debian-installer: Please consider moving root user setup to expert install, or change text

[Holger Wansing]

With latest user-setup upload 1.97, this has been dealed with, so closing.


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Reword non-free-firmware description

[Holger Wansing]

Hi,

Holger Wansing  wrote (Wed, 1 May 2024 17:02:10 +0200):
> What to do about this MR regarding rewording of (non-free) firmware 
> description ?
> https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/15
> 
> Should something be done there?

Any objections against applying this, adding information to the respective
dialog, what firmware files are and why they are needed (or not) ?


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Uploading user-setup: update password selection advice

[Holger Wansing]

Version: 1.97


Forgot to mention bug closure in changelog before uploading, so closing now
manually.

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Reword non-free-firmware description

[Holger Wansing]

What to do about this MR regarding rewording of (non-free) firmware description 
?
https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/15

Should something be done there?


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064617: update password selection advice

[Holger Wansing]

Apparently we have reached something like a consensus on this topic, 
should we merge this then?



Any objections?


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 8. März 2024 19:58:56 MEZ schrieb Philip Hands :
>
>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

Well, the idea was, to mention that 'passphrase' thing one time in the dialog.

Now having it at all places is indeed not strictly an improvement.
Feel free to drop it.


Holger




-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 7. März 2024 08:50:25 MEZ schrieb 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).

All the above looks like an improvement to me.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 5. März 2024 20:44:52 MEZ schrieb Philip Hands :
>BTW I don't know much about how the translation side of things works,
>but given that there are many ways of getting the fine detail of this to
>be incorrect in various ways, is there a standard method for adding
>hints for translators, and should that be done?

Such hints for translators can be added to the templates file, as in

They will then end up in translator's po files.


Do you have some specific sentence in mind, which deserves a
special hint?
I noticed that my English is not good enough to formulate such details.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi all,

Am 5. März 2024 19:28:25 MEZ schrieb Cyril Brulebois :
>Philip Hands  (2024-03-05):
>> Cool, in that case I'll fix those two things and then use the result
>> for the MR[1], and if the openQA test runs look OK, will merge that.
>
>Only skimmed over it, but that looks sensible, thanks all.
>
>Is it worth getting d-l-english involved in a final review before
>getting that translated? Contrary to a lot of not-so-critical l10n
>material, that particular screen is crucial, and I'd hate it if we
>wasted translator efforts due to a missed typo or obvious improvement.

Good idea.

@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


There was some (more) discussion / various attempts on finding
the correct wording, most of which can be found in



Maybe we should have put d-l10n-english into the loop earlier, sorry for not
doing that.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 5. März 2024 15:01:21 MEZ schrieb Philip Hands :
>Here are my latest attempts:

"Be aware that that a ..."
doubled "that"

"... (unless you select to show it)"
missing fullstop.

Otherwise: looks good to me.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Diederik de Haas  wrote (Mon, 04 Mar 2024 15:57:10 
+0100):
> On Monday, 4 March 2024 10:43:59 CET Holger Wansing wrote:
> > >Regarding the password advice, I ended up concluding that it's pretty
> > >unlikely that anything we say at this point will have any effect on
> > >people's behaviour, but then I'm probably just an old cynic. Also, I
> > >failed when trying to come up with a wording which I was happy with,
> > >which is why I ended up discarding the advice entirely.
> > >
> > >If we want to keep the password advice in then I think what you wrote is
> > >(mostly) OK, although I think it implies that one should be choosing a
> > >single "password" (although, not a word in any normal sense), which
> > >could be argued to steer people away from the perfectly decent xkcd
> > >approach of using several dictionary words. Saying "Password or
> > >Passphrase" at least once would probably address that.
> > 
> > Ok, makes it a bit longer, but it could be worth it.
> 
> https://wiki.debian.org/Passwords doesn't exist (yet), but it's an easy to 
> remember URL and we'd have all the space we need to give proper advise?

Would need to check if that fits in the relevant screens (I want to avoid
having a scroll bar on that screens).


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Holger Wansing  wrote (Mon, 04 Mar 2024 10:43:59 +0100):
> Hi,
> 
> Am 4. März 2024 06:17:31 MEZ schrieb Philip Hands :
> >I found that there were some phrases that I was avoiding for various
> >reasons, a couple of which I see you've used, so I'll say why I was avoiding
> >them and see if I have a persuasive argument for doing so.
> >
> >"allow/deny login/access as root":
> >
> >  The problem here is that not having a password for root only prevents
> >  one from getting direct access to root by using a password. Indirect
> >  access is still available via sudo, and direct access is still
> >  available via key bassed ssh.  I was also avoiding saying things like
> >  "disable the root account" for the same reason.
> >
> >  This is why I ended up with the phrasing:
> >
> > direct password-based logins to 'root'.
> 
> Ok, seems fair. I would change to that then.
> 
> >
> >"using the 'sudo' command":
> >
> >  This I was avoiding becuase it might give the impression that one MUST
> >  use sudo, whereas most people will actually get their root acces via a
> >  GUI prompting them for their own pasword (because it's checked that
> >  they're in the sudo group) when doing things like unlocking their
> >  network or printer settings. I thought it was worth mentining the
> >  'sudo' group explicitly because that gives something to search for if
> >  they want to find out more, but telling people they need to use the
> >  sudo command seemed like a step too far.
> 
> Correct so far. Maybe a bit more technical and therefore probably
> not the easiest choice for newbies, but I have no problem using that.
> 
> >Regarding the password advice, I ended up concluding that it's pretty
> >unlikely that anything we say at this point will have any effect on
> >people's behaviour, but then I'm probably just an old cynic. Also, I
> >failed when trying to come up with a wording which I was happy with,
> >which is why I ended up discarding the advice entirely.
> >
> >If we want to keep the password advice in then I think what you wrote is
> >(mostly) OK, although I think it implies that one should be choosing a
> >single "password" (although, not a word in any normal sense), which
> >could be argued to steer people away from the perfectly decent xkcd
> >approach of using several dictionary words. Saying "Password or
> >Passphrase" at least once would probably address that.
> 
> Ok, makes it a bit longer, but it could be worth it.
> 
> I will prepare a new patch with above.

Updated patch attached.

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index cdb6d78..437b9d7 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -33,22 +33,21 @@ _Description: Allow login as root?
 Template: passwd/root-password
 Type: password
 # :sl1:
-_Description: Root password:
- You need to set a password for 'root', the system administrative
- account. A malicious or unqualified user with root access can have
- disastrous results, so you should take care to choose a root 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.
+_Description: Root password/passphrase:
+ If you want to allow direct password-based login as root, you need to set a
+ password for 'root', the system administrative account now.
+ A malicious or unqualified user with root access can have
+ disastrous results, so you should take care to choose a root
+ password/passphrase that cannot be guessed. It should not be a word found in
+ dictionaries, or something that could be easily associated with you.
  .
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
+ You can also leave the password for root empty here, to disable the root
+ account; the system's initial user account (which will be set up in the next
+ step) will then be given the power to become root via 'sudo' (by adding it to
+ the 'sudo' group).
  .
- 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.
- .
- Note that you will not be able to see the password as you type it.
+ Note that you will not be able to see the password as you type it (except if
+ you choose to show it in clear text).
 
 Template: passwd/root-password-again
 Type: password
@@ -109,9 +108,8 @@ _Description: Reserved username
 Template: pa

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 4. März 2024 06:17:31 MEZ schrieb Philip Hands :
>I found that there were some phrases that I was avoiding for various
>reasons, a couple of which I see you've used, so I'll say why I was avoiding
>them and see if I have a persuasive argument for doing so.
>
>"allow/deny login/access as root":
>
>  The problem here is that not having a password for root only prevents
>  one from getting direct access to root by using a password. Indirect
>  access is still available via sudo, and direct access is still
>  available via key bassed ssh.  I was also avoiding saying things like
>  "disable the root account" for the same reason.
>
>  This is why I ended up with the phrasing:
>
> direct password-based logins to 'root'.

Ok, seems fair. I would change to that then.

>
>"using the 'sudo' command":
>
>  This I was avoiding becuase it might give the impression that one MUST
>  use sudo, whereas most people will actually get their root acces via a
>  GUI prompting them for their own pasword (because it's checked that
>  they're in the sudo group) when doing things like unlocking their
>  network or printer settings. I thought it was worth mentining the
>  'sudo' group explicitly because that gives something to search for if
>  they want to find out more, but telling people they need to use the
>  sudo command seemed like a step too far.

Correct so far. Maybe a bit more technical and therefore probably
not the easiest choice for newbies, but I have no problem using that.

>Regarding the password advice, I ended up concluding that it's pretty
>unlikely that anything we say at this point will have any effect on
>people's behaviour, but then I'm probably just an old cynic. Also, I
>failed when trying to come up with a wording which I was happy with,
>which is why I ended up discarding the advice entirely.
>
>If we want to keep the password advice in then I think what you wrote is
>(mostly) OK, although I think it implies that one should be choosing a
>single "password" (although, not a word in any normal sense), which
>could be argued to steer people away from the perfectly decent xkcd
>approach of using several dictionary words. Saying "Password or
>Passphrase" at least once would probably address that.

Ok, makes it a bit longer, but it could be worth it.

I will prepare a new patch with above.


Holger


-- 
Sent from /e/ OS on Fairphone3

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Am 2. März 2024 21:07:34 MEZ schrieb Philip Hands :
>
>This sentence is the thing that prompted me to change things in the
>first place, because it is not true. One does not _need_ to set a root
>password.

It should be understood as 
"If you want to enable login as root, you have to set a root password now."

And in expert mode it is in fact working this way:
At first, you are asked if you want to enable login as root. If you answer yes 
here, you are prompted to set a root password. 
And at that point it is indeed required to set a root password, since you 
chose to enable root login in the first question and the installer does not
allow an empty password for root.

To make it work in default install, we could change the question as
in above citation.

>I don't actually care very much whether we encourage sudo use. My
>wording ended up (after many variations) quite strongly encouraging it
>mostly as an antidote to the implication that comes from having a
>question dedicated to setting the root password, but I'd be happy with
>any wording that makes sure that people understand that both options are
>totally fine.

The sudo possibility is also mentioned:

'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.'

I have rephrased that a bit, see below.

>The other thing that I was trying to ensure is that people are reassured
>that they'll get to specify a password that will get them root access even if
>they decide to leave the root password unset.  This is because I've seen
>people become quite uncertain about what to expect at this point in the
>install.
>
>I've found that it is not easy to come up with things that include much
>nuance about this, while still fitting in the space available, which is
>why I decided to try a more opinionated approach.
>
>One could soften what I wrote by replacing "generally recommended" with
>something like "often appropriate" -- how does that seem to people?

Your proposal too much focusses on the sudo way IMO.
We risk getting complains from people, who miss advise regarding the
enabled root login.

I have rephrased the dialog a bit, to make the sudo way more visible and
better understandable.

>One can of course tinker with this stuff indefinitely. I actually spent
>a fair amount of time wondering how best to describe not setting a root
>password for instance -- should one say "leave the password unset", "set
>an empty password", "enter no password", or something like "just hit
>"? (and does that last one actually apply to all the available
>UIs?).
>
>The same goes for how you say that the password is not going to get
>shown (unless you ask for it to be shown), which in the GTK UI gets
>characters replaced with dots, IIRC in the text UI its with asterisks,
>and I'd guess it just gets completely hidden in the speech install.

I think that's not much of a problem. People are used to the situation,
that passwords are not shown, but replaced by asterisks or similar.
And we have the checkbox for showing it in clear text, that should be
enough.


Updated patch attached.


Holger



diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index cdb6d78..7393511 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -34,21 +34,19 @@ Template: passwd/root-password
 Type: password
 # :sl1:
 _Description: Root password:
- You need to set a password for 'root', the system administrative
- account. A malicious or unqualified user with root access can have
+ If you want to allow login as root, you need to set a password for 'root',
+ the system administrative account now.
+ A malicious or unqualified user with root access can have
  disastrous results, so you should take care to choose a root 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.
+ that cannot be guessed. It should not be a word found in dictionaries,
+ or something that could be easily associated with you.
  .
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
+ You can also leave the password for root empty here, to disable the root
+ account; the system's initial user account (which will be set up in the next
+ step) will then be given the power to become root using the "sudo" command.
  .
- 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.
- .
- Note that you will not be able to see the password as you type it.
+ Note that you will not be able to see the password as you type it (except if
+ you choose to show it in clear text).
 
 Template: passwd/root-password-again
 Type: password

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Philip Hands  wrote (Fri, 01 Mar 2024 06:46:27 +0100):
> If you want to make a constructive contribution, how about suggesting a
> wording that reflects the advice that you think would be most useful to
> the people that actually read the advice?

I would like to make a proposal, leaving the default setting as is 
(aka: default to an enabled root account, no sudo), with only some wording 
changings.

Patch attached.

What do you think?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/user-setup-udeb.templates b/debian/user-setup-udeb.templates
index cdb6d78..2715cfb 100644
--- a/debian/user-setup-udeb.templates
+++ b/debian/user-setup-udeb.templates
@@ -32,28 +32,26 @@ _Description: Allow login as root?
 
 Template: passwd/root-password
 Type: password
 # :sl1:
 _Description: Root password:
  You need to set a password for 'root', the system administrative
  account. A malicious or unqualified user with root access can have
  disastrous results, so you should take care to choose a root password
- that is not easy to guess. It should not be a word found in dictionaries,
+ that cannot be guessed. It should not be a word found in dictionaries,
  or a word that could be easily associated with you.
  .
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
- .
  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.
  .
- Note that you will not be able to see the password as you type it.
+ Note that you will not be able to see the password as you type it (except if
+ you choose to show it in clear text).
 
 Template: passwd/root-password-again
 Type: password
 # :sl1:
 _Description: Re-enter password to verify:
  Please enter the same root password again to verify that you have typed it
  correctly.
 
@@ -105,18 +103,17 @@ Type: error
 _Description: Reserved username
  The username you entered (${USERNAME}) is reserved for use by the system.
  Please select a different one.
 
 Template: passwd/user-password
 Type: password
 # :sl1:
 _Description: Choose a password for the new user:
- A good password will contain a mixture of letters, numbers and punctuation
- and should be changed at regular intervals.
+ Make sure to select a strong password, that cannot be guessed.
 
 Template: passwd/user-password-again
 Type: password
 # :sl1:
 _Description: Re-enter password to verify:
  Please enter the same user password again to verify you have typed it
  correctly.
 

Bug#1064617: Passwords should not be changed frequently

[Holger Wansing]

Hi,

Philip Hands  wrote (Thu, 29 Feb 2024 20:53:10 +0100):
> Depending upon whether we think it's worth using translators' time on
> this subject, we can then select one or both commits, and finally close
> these bugs.

I think it would be worth it to generate some work for translators here, yes.

> You can see my latest attempt here:
> 
>   https://openqa.debian.net/tests/238094#step/passwords/1
> 
> in which I'm recommending setting no password for root, which then gives
> the initial user 'sudo' membership[1].

What about the "Allow login as root?" question (only shown in expert mode),
which is asked directly before the above mentioned dialog?
(That's in user-setup-udeb.templates - line 25 ff.)

Maybe that needs some re-wording too?

Seems somewhat inconsistent now IMO:
if you say 'Yes' to 'Allow login as root' you get the next dialog allowing
the same choice again (or at least very similar): 
'It is possible [...] to lock the root acount ... If you leave the password
here unset, then this is what happens.'

Is that understandable for users?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Problem of upgrade tasksel from 3.73 to 3.74

[Holger Wansing]

Hi,

agn  wrote (Fri, 02 Feb 2024 07:50:13 +):
> I wonder why package tasksel revert the default input method framework 
> of Traditional Chinese (and only for Traditional Chinese) to fcitx4. It 
> seems to me that there is no practical reason to revert to an old input 
> method framework while the newer and maintained one is still usable 
> without any issue.

You can find history for this at
https://salsa.debian.org/installer-team/tasksel/-/merge_requests/27


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

apt-setup merge request on Salsa - please comment

[Holger Wansing]

Hi guys,

we got a merge request on Salsa for apt-setup, with changings to questions/
dialogs in debian-installer regarding firmware:

https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/15

Could someone please review that one?
(for example, see 
https://salsa.debian.org/installer-team/apt-setup/-/merge_requests/15#note_464848
 )

Many thanks

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: grub-installer_1.199_source.changes REJECTED

[Holger Wansing]

Hi,

Holger Wansing  wrote (Fri, 16 Feb 2024 20:17:08 +0100):
> Hi Aurelien,
> 
> upload of grub-installer 1.199 seems to be missing in git:
> https://salsa.debian.org/installer-team/grub-installer

Forget about it.
Everything was correct by you.
Fault at my site :-(

Sorry for the noise

Holger



> 
> That's why todays upload of such version failed.
> 
> Could you add that upload to git, please?
> Thanks
> 
> Holger
> 
> 
> Debian FTP Masters  wrote (Fri, 16 Feb 2024 
> 19:04:42 +):
> > 
> > 
> > Version check failed:
> > Your upload included the source package grub-installer, version 1.199,
> > however testing already has version 1.199.
> > Uploads to unstable must have a higher version than present in testing.
> > 
> > 
> > 
> > ===
> > 
> > Please feel free to respond to this email if you don't understand why
> > your files were rejected, or if you upload new files which address our
> > concerns.
> > 
> 
> 
> -- 
> Holger Wansing 
> PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
> 


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: grub-installer_1.199_source.changes REJECTED

[Holger Wansing]

Hi Aurelien,

upload of grub-installer 1.199 seems to be missing in git:
https://salsa.debian.org/installer-team/grub-installer

That's why todays upload of such version failed.

Could you add that upload to git, please?
Thanks

Holger


Debian FTP Masters  wrote (Fri, 16 Feb 2024 
19:04:42 +):
> 
> 
> Version check failed:
> Your upload included the source package grub-installer, version 1.199,
> however testing already has version 1.199.
> Uploads to unstable must have a higher version than present in testing.
> 
> 
> 
> ===
> 
> Please feel free to respond to this email if you don't understand why
> your files were rejected, or if you upload new files which address our
> concerns.
> 


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: tasksel_3.74_source.changes ACCEPTED into unstable

[Holger Wansing]

Hi,

Am 14. Februar 2024 09:09:34 MEZ schrieb Cyril Brulebois :
>Besides, I'm very much not sure it's a good idea to have standard be
>listed first. I'd expect people to want to turn desktop environment
>on/off, and be accustomed to have that first. Do we really want to break
>finger memory? Being able to disable standard to save a little space has
>never looked like a bad idea to me, but having that be the first entry
>on that list feels very weird.

So that should be changed in tasks/standard then:

  Task: standard 
- Relevance: 0 
+ Relevance: 9
  Section: user 
  Description: standard system utilities 
  This task sets up a basic user environment, providing a reasonably 


Holger




-- 
Sent from /e/ OS on Fairphone3

Re: Next attempt to add Blends to Debian installer

[Holger Wansing]

Hi,

I would like to push a proposal here on this longstanding topic:

By other means, my attention was drawn to the blends-tasks package.
While this package is not new, an idea came to my mind when reading the
package description:

As a possible way to solve (or work-around ?) this issue: 
could we just "copy tasksel with its UI and infrastructure" into a new package 
(I name it 'blends-di-tasks' here), which has all the blends listed, and add 
one entry to tasksel with a name like "Debian Pure Blends" or similar?

If one then selects "Debian Pure Blends" in the good all known tasksel, the 
blends-di-tasks package would be installed on /target, and later a new dialog 
would appear, listing all the blends, where the user could select which one to 
install.
(If the "Debian Pure Blends" entry stays unchecked, as would be the default
value, everything stays as is: the new dialog would not appear, no difference
to previous releases.)

Would that be a possible solution for all involved parties?

I know, the current (?) plan is something like an "enhanced tasksel" with some
sort of hierarchy included, but I'm not sure, if this will ever happen

Thus, I wonder if this could be an alternative, which would be do-able?


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file

[Holger Wansing]

Version: 1.225

Emanuele Rocca  wrote (Thu, 8 Feb 2024 15:25:50 +0100):
> Hi,
> 
> On 2024-02-08 02:06, Colin Watson wrote:
> > On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote:
> > > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca :
> > > >Perhaps this is related to the fact that 1.224 dropped the binary
> > > >package console-setup-pc-ekbd?
> > > 
> > > What makes you think, that this has happened?
> > > 
> > > There is a merge request that includes the removal of said package,
> > > but it has not yet been merged.
> 
> Looks like the change has been uploaded though, there is no
> console-setup-pc-ekbd here:
> https://sources.debian.org/src/console-setup/1.224/debian/control/
> 
> But on 1.223 it's there:
> https://sources.debian.org/src/console-setup/1.223/debian/control/#L161
> 
> > My inclination is to upload 1.225 without that patch for now, as we need
> > to rebuild for the new xkb-data to sort out uninstallability in
> > unstable, and then get the kFreeBSD-removal patch sorted out after that.
> > Objections?

This was fixed by a clean upload of 1.225 without said changings.

Thanks everybody


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#848972: Fixed in Ubuntu

[Holger Wansing]

Control: tags -1 + patch

Ferenc Wágner  wrote (Mon, 26 Jun 2023 12:27:49 +0200):
> Control: tag + patch
> 
> Hi,
> 
> This issue was fixed in 1.178ubuntu12, as detailed at
> https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1824227
> Please consider taking over the fix.

I have grabbed the changings from
https://git.launchpad.net/ubuntu/+source/console-setup/commit/?h=applied/ubuntu/disco=dc3395232928c2a3f53c7e5e29ad25a2638ddcae


Patch attached.

Any objections?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/changelog b/debian/changelog
index fb41ffd..ce2f43b 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,3 +1,13 @@
+console-setup (1.227) UNRELEASED; urgency=medium
+
+  * setupcon: use /run for tempfiles (and dump the various unnecessary
+fallback paths), since /run is always mountable rw at least as early as
+/tmp is and is guaranteed to be safe from tmpcleaners at boot.  Only keep
+/tmp as a fallback in case we have access to write to /tmp and to a
+console, but not to /run.  Closes: #848972
+
+ -- Holger Wansing   Sun, 11 Feb 2024 13:03:18 +0100
+
 console-setup (1.226) unstable; urgency=medium
 
   * Team upload
diff --git a/setupcon b/setupcon
index 04641c6..5d83433 100755
--- a/setupcon
+++ b/setupcon
@@ -60,11 +60,8 @@ trap 'rm -f $tempfiles >/dev/null 2>&1' 0
 trap "exit 2" 1 2 3 13 15
 tempfile () {
 if \
-TMPFILE=`mktemp /tmp/tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp /run/tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp /dev/.tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XX 2>/dev/null` \
-|| TMPFILE=`mktemp 2>/dev/null`
+TMPFILE=`mktemp /run/tmpkbd.XX 2>/dev/null` \
+|| TMPFILE=`mktemp /tmp/tmpkbd.XX 2>/dev/null`
 then
 tempfiles="$tempfiles $TMPFILE"
 return 0

Re: Bug#1051846: installation-reports: gnome_flashback installation fails on openQA with daily netinst image

[Holger Wansing]

Hi,

Roland Clobus  wrote (Wed, 13 Sep 2023 15:59:37 +0200):
> Comments/Problems:
> 
> The installation proceeds without error.
> After rebooting, the screen with 'Oh no! Something has gone wrong' is shown.
> 
> My attempts to reproduce and pinpoint the cause:
> I've tested with QXL and VGA graphical cards on openQA. In both cases the 'Oh
> no!' is shown.
> 

Apparently only a temporary problem; looks fine again.

Closing this bug


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Fix and improve usability of keyboard layout and input methods for users under zh_TW locale

[Holger Wansing]

Hi,

Andrew Lee  wrote (Sun, 17 Sep 2023 13:22:43 +0200):
> 
> * Add Taiwanese xkb-keymap answer and default for zh_TW locales:
>   https://salsa.debian.org/installer-team/console-setup/-/merge_requests/20

'Taiwanese' keyboard layout is now available in the installer (and default
for Traditional Chinese).

Could you try a netinst daily, to check if everything works as expected?
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/


Thanks

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Debian installation wifi card not being detected

[Holger Wansing]

Am 10. Februar 2024 12:48:03 MEZ schrieb Exeonz :
>Hey thanks for your time in advance. I'm trying to install debian bookworm
>12.4 on MacbookAir7,2 that doesn't have an ethernet port and the installer
>doesn't recognize it's wifi card and what drivers it needs for the card to
>work. From searching the web I found that it uses Broadcom BCM 4360
>wireless network adapter and requires broadcom-sda-dkms firmware drivers to
>function. The installer doesn't detect the wifi card and none of the
>drivers from the select list work and when I use 2nd bootable USB formatted
>as FAT32 with broadcom-sda-dkms firmware drivers saved to root and firmware
>folder it doesn't accept drivers and gives out error "ethernet card not
>found" I've looked through entire debian wiki and other wikis and forums
>like arch wiki and found no answers anywhere. I have successfully installed
>ubuntu on this macbook air and it works just fine with the wifi card. Could
>you please shed some light on how I can possibly install debian on this
>macbook air.

Try to use a testing daily from



Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file

[Holger Wansing]

Hi,

Colin Watson  wrote (Thu, 8 Feb 2024 14:06:05 +):
> On Wed, Feb 07, 2024 at 11:13:01PM +0100, Holger Wansing wrote:
> > Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca :
> > >  Dumping the encoded keymaps for pc105...
> > >  WARNING: Can not find "caps_switch" in "group".
> > >  WARNING: Can not find "caps_toggle" in "group".
> > >  gzip -9n >/Keyboard/pc105.ekbd 
> > > >/<>/Keyboard/pc105.ekbd.gz
> > >  /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such 
> > > file
> > >  make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] 
> > > Error 2
> > >  make[1]: Leaving directory '/<>'
> > >  make: *** [debian/rules:204: udeb-install] Error 2
> > >
> > >Version 1.223 builds fine in unstable instead. Perhaps this is related
> > >to the fact that 1.224 dropped the binary package console-setup-pc-ekbd?
> > 
> > What makes you think, that this has happened?
> > 
> > There is a merge request that includes the removal of said package,
> > but it has not yet been merged.
> 
> It's not in git, but you appear to have built 1.224 from an unclean
> source tree that had that patch applied.
> 
> My inclination is to upload 1.225 without that patch for now, as we need
> to rebuild for the new xkb-data to sort out uninstallability in
> unstable, and then get the kFreeBSD-removal patch sorted out after that.

Uhm, that was not my plan :-(
Sorry for that.

> Objections?

None, of course.
Will work that out.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1063413: FTBFS: cannot open /<>/Keyboard/pc105.ekbd: No such file

[Holger Wansing]

Am 7. Februar 2024 21:55:05 MEZ schrieb Emanuele Rocca :
>  Dumping the encoded keymaps for pc105...
>  WARNING: Can not find "caps_switch" in "group".
>  WARNING: Can not find "caps_toggle" in "group".
>  gzip -9n >/Keyboard/pc105.ekbd 
> >/<>/Keyboard/pc105.ekbd.gz
>  /bin/sh: 1: cannot open /<>/Keyboard/pc105.ekbd: No such file
>  make[1]: *** [rules.mk:17: /<>/Keyboard/pc105.ekbd.gz] Error 2
>  make[1]: Leaving directory '/<>'
>  make: *** [debian/rules:204: udeb-install] Error 2
>
>Version 1.223 builds fine in unstable instead. Perhaps this is related
>to the fact that 1.224 dropped the binary package console-setup-pc-ekbd?

What makes you think, that this has happened?

There is a merge request that includes the removal of said package,
but it has not yet been merged.


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1051968: #1051968please make task-mate-desktop install libreoffice-gnome

[Holger Wansing]

Control: tags -1 pending


MR just merged.


-- 
Sent from /e/ OS on Fairphone3

Bug#619328: console-setup-freebsd: Uninstallable on Linux hosts

[Holger Wansing]

Hi,

Paul Gevers  wrote (Sat, 28 Oct 2023 20:14:13 +0200):
> Hi,
> 
> On Mon, 24 Jul 2023 17:17:54 +0200 Paul Gevers  wrote:
> > On Wed, 23 Mar 2011 10:49:42 +0100 Julien Cristau  
> > wrote:
> > > On Wed, Mar 23, 2011 at 11:36:00 +0200, Anton Zinoviev wrote:
> > > > Does this mean the 
> > > > architectures are not equal in rights - an 'all' package is allowed to 
> > > > be uninsallable on kFreeBSD but not on Linux?
> > > > 
> > > No, it's fine.
> > 
> > While I totally stand behind this, with the kfreebsd's removed now even 
> > from the ports [1], maybe it's time to stop building console-setup-freebsd?
> 
> And now, due to changes in our migration software, this issue has caused 
> console-setup to be blocked for 34 days already [1]:
> uninstallable on arch amd64, not running autopkgtest there
> 
> I'll hint it through now, but it would be nicer if console-setup-freebsd 
> would be dropped next time (as it would ensure src:console-setup gets 
> the normal autopkgtest treatment).
> 
> Paul
> 
> [1] https://qa.debian.org/excuses.php?package=console-setup

While cleaning up the whole code of console-setup from kfreebsd parts
is out of my skills, I managed to get it so far, that the kfreebsd packages
are no longer beeing built, and those packages removed from control file.
Could this be enough for now?

I filed this as MR [1].

The pipeline on that push went fine first [2], while there was a job within
the pipeline named "D-I" which I triggered manually and that failed, however 
I'm not exactly sure what this job does, and what failed there; a mini.iso 
image was however successfully created. I did not notice this pipeline
funtionality before. Is this expected to work?

Comparing all the remaining packages with debdiff shows no unexpected 
differences compared to the previous version, so for me it looks ok.

Maybe someone wants to take a look?


Holger

[1] https://salsa.debian.org/installer-team/console-setup/-/merge_requests/21
[2] https://salsa.debian.org/holgerw/console-setup/-/pipelines/608351


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Holger Wansing]

Hi,

Am 24. November 2023 23:54:49 MEZ schrieb David Hillman 
:
>On 11/24/23 12:59, Holger Wansing wrote:
>Thanks Holger.  I could do that, but that would completely defeat the purpose. 
> I installed Debian 12 on this machine as a test, to confirm that everything 
>necessary works, before installing it on a dozen or so other similar machines.

Trying a debian 13 image was meant as some sort of debugging. 
It would involve a newer kernel for example, in case it's a kernel issue...


Holger



-- 
Sent from /e/ OS on Fairphone3

Bug#1056697: 12.2 Installation Report, Complete Failure of Network

[Holger Wansing]

Hi,

David Hillman  wrote (Fri, 24 Nov 2023 12:34:50 -0600):
> Ubuntu 20 and 22 installers work just fine on the same hardware, so this 
> is a Debian-specific issue.  All four interfaces work just fine under 
> both Ubuntu 20 and 22, but are totally dysfunctional with Debian 12.

Maybe you could try a preview Debian 13 image?
https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: [rt.debian.org #9382] Upgrade dillon to bullseye

[Holger Wansing]

Hi,

Am 19. November 2023 02:05:46 MEZ schrieb Cyril Brulebois :
>Hi Adam,
>
>Adam D. Barratt via RT  (2023-11-18):
>> I'd like to look at upgrading dillon to bullseye in the
>> not-too-distant future.
>
>Sure thing.

Wow, I wasn't aware that Debian machines are running oldoldstable :-o


>> The d-i.debian.org metapackage fails to install on bullseye, because
>> it depends on ko.tex-base, which no longer exists in bullseye. The
>> removal notice suggests that its replacement is texlive-lang-korean,
>> which the metapackage already depends on for a few years now, so
>> hopefully dropping ko.tex-base shouldn't be an issue.
>
>That was an installation-guide dependency, removed in 2017, first
>released in 20180603:
>  
> https://salsa.debian.org/installer-team/installation-guide/-/commit/3aa082a832ed636874995bf9e7bd25d0910c3365
>
>Some more cleanup might be possible in there, but if you can build a
>package that's installable again right away, let's do that.
>
>> Do you see any issues with the upgrade from a d-i perspective? Are
>> there any particularly good times to do the upgrade, or that you'd
>> prefer to avoid?
>
>I'm less used to keeping an eye on the l10n machinery than Holger does,
>so you might want to wait for an explicit ACK there, but the rest I can
>probably check and fix/adjust as needed once the upgrade happens.
>
>No particular constraints on my side, thanks for asking.

Yes, please go ahead at your own schedule


Holger

-- 
Sent from /e/ OS on Fairphone3

Re: installation-guide: simplify RAM/disk space requirements

[Holger Wansing]

Hi,

Pascal Hambourg  wrote (Wed, 1 Nov 2023 23:35:00 +0100):
> On 01/11/2023 at 20:46, Holger Wansing wrote:
> >>>
> >>> In chapter 6.3.1.1. "Check available memory / low memory mode":
> >>>
> >>> "If the installer runs in low memory mode, it is recommended to create a
> >>> relatively large swap partition (64–128MB)."
> >>
> >> I could change that into something like 1-2 GB.
> >> One might think, this is still "relatively small" these days, but it's
> >> always enough for the installer, so I think that would be ok.
> > 
> > Ah, I realize that the above is completely bullshit:
> > the swap partition is not only for the installer, but later for installed
> > system as well (shame on me).
> > 
> > So should I change to "2-4 GB at least" ?
> 
> The installer running in low memory mode means that the system RAM is 
> less than 1 GB, so I doubt that a swap bigger than 2 GB makes sense.

Now changed to "1-2GB".


Thanks
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: installation-guide: simplify RAM/disk space requirements

[Holger Wansing]

Hi,

Holger Wansing  wrote (Mon, 30 Oct 2023 11:49:29 +0100):
> Hi,
> 
> Pascal Hambourg  wrote (Wed, 18 Oct 2023 11:49:42 
> +0200):
> > On 06/08/2023 at 14:32, Samuel Thibault wrote:
> > > 
> > > The doc probably just ended up wrong by just not getting updated,
> > 
> > In chapter 6.3.1.1. "Check available memory / low memory mode":
> > 
> > "If the installer runs in low memory mode, it is recommended to create a 
> > relatively large swap partition (64–128MB)."
> 
> You are right.
> I could change that into something like 1-2 GB.
> One might think, this is still "relatively small" these days, but it's
> always enough for the installer, so I think that would be ok.

Ah, I realize that the above is completely bullshit:
the swap partition is not only for the installer, but later for installed 
system as well (shame on me). 

So should I change to "2-4 GB at least" ?

Holger



> > These values are very low by today standards.
> > Also, mentions of ext3 are outdated, I doubt anybody still uses it for 
> > new installations.



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Add Feature Prevent Installing non-free-firmware in Noraml Mode (Like expert mode)

[Holger Wansing]

Hi,

Am 1. November 2023 10:27:16 MEZ schrieb Modaresi Soft Hard 
:
>Hello. From Debian 12 onwards, proprietary drivers will be automatically 
>installed in normal mode.
>
>Can you make the installer ask questions in normal mode for installing 
>proprietary drivers?
>(Like a check box with No and Yes)

Based on the assumption, that for the vast majority of users it's wanted
to have non-free firmware installed, this is the default behavior.
If this is not wanted, you can use the parameter "firmware=never".

>What does firmware=never do? # 
>https://wiki.debian.org/Firmware#How_to_disable_detection_and_use_of_non-free_firmware
>
>Does firmware=never affect the installation and detection of free firmwares?

Detection of firmware still works, but you don't get non-free firmware 
installed automatically
(from the install media or via web).
In such situation, the installer may ask for firmware files nevertheless, 
if a device is detected, which requires this. 
You can provide such file then via USB stick for example, if you want.
This is the same behaviour as in Debian 11 and before.

Free firmware is not affected at all by this.


Holger




-- 
Sent from /e/ OS on Fairphone3

Re: Bug#1054615: [INTL:sv] Swedish strings for tasksel debconf

[Holger Wansing]

Hi,

Martin Bagge / brother  wrote (Thu, 26 Oct 2023 22:40:32 
+0200):
> package: tasksel
> severity: wishlist
> tags: patch l10n
> 
> Please consider to add this file to translation of debconf.

This file has already been updated ~1 month ago:
https://salsa.debian.org/installer-team/tasksel/-/commit/e7a3e305fa67582e4a44a2e547976ceaa7725f3a


So closing this bug
Thanks anyway for your time


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: installation-guide: simplify RAM/disk space requirements

[Holger Wansing]

Hi,

Pascal Hambourg  wrote (Wed, 18 Oct 2023 11:49:42 
+0200):
> On 06/08/2023 at 14:32, Samuel Thibault wrote:
> > 
> > The doc probably just ended up wrong by just not getting updated,
> 
> In chapter 6.3.1.1. "Check available memory / low memory mode":
> 
> "If the installer runs in low memory mode, it is recommended to create a 
> relatively large swap partition (64–128MB)."

You are right.
I could change that into something like 1-2 GB.
One might think, this is still "relatively small" these days, but it's
always enough for the installer, so I think that would be ok.

> 
> These values are very low by today standards.
> Also, mentions of ext3 are outdated, I doubt anybody still uses it for 
> new installations.



Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#851555: debian-junior: Desktop environment for Debian Junior

[Holger Wansing]

Hi, 

Stefan Kropp  wrote:
> I would like to provide a Desktop environment for
> Debian Junior in Debian 13 (trixie). It would be very
> nice, if we will be able to provide this task into the
> Debian Installer and provide a Debian live system.

Since Debian Junior is one of the Debian Pure Blends, this bug
is another incarnation of a very longstanding issue:
Add the blends to the installer (or: have an easy way, to install 
blends from the installer).

See 


Holger

-- 
Sent from /e/ OS on Fairphone3

Bug#1036886: Text input fields very hard to identify in high contrast / dark mode

[Holger Wansing]

Hi,

Samuel Thibault  wrote (Mon, 23 Oct 2023 02:00:25 +0200):
> I had a hard time getting a border. The simplest might be to just have
> a black background, as attached. Would that be fine enough? (we don't
> actually lose any contrast since it's the same blue as before)

Any disadvantages in advocating the text installer to those people?

IMO the situation is much better there (only one input field per page
+ a hyphened baseline below it).

See attachment.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Install testing/trixie 2023-08-31, IPv6/v4 issue, tasksel base system only, grub install not working

[Holger Wansing]

Hi,

Axel Kittenberger  wrote (Thu, 31 Aug 2023 
10:26:07 +0200):
> 1) Detect network got a local link IPv6 address, but not an IPv4 (likely 
> DHCP not configured correctly on my part). The installer asked me for 
> DNS servers, and out of habit I put in the IPv4 addresses. The issue is 
> unlikely previous installers the installer didn't ask for a IPv4 address 
> (also fine), however obviously later it will not be able to connect to a 
> repository.  -> took me a little while figure out i had to put in the 
> IPv6 addresses for DNS ---> Suggestion: warn the user if not IPv4 
> address was acquired by DHCP and they put in only IPv4 DNS Servers.
> 
> 2) tasksel in installer only offered "Base system", no usual options of 
> graphical desktop.

I guess the installer had no working network at this point, due to the
DHCP/DNS server address issues stated above?

In that case, it's expected to have only the base-system task available,
when you use the netinstall image for install.

> 3) grub would not install complaining it cannot mount /target/proc 
> (albeit it is mounted)

That's most probably 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1051468


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Swedish Translation complete for tasksel Debconf and where to send these?

[Holger Wansing]

Hi,

Luna Jernberg  wrote (Mon, 4 Sep 2023 14:29:43 +0200):
> Started continuing with some translations of debconf files during the
> first day of Debconf
> Attached the first one i am done with now
> is there a good place to send these, to not spam the mailinglist?

I seem to have missed replying on this, sorry.

I have committed this file to tasksel's git repo now:
https://salsa.debian.org/installer-team/tasksel/-/commit/e7a3e305fa67582e4a44a2e547976ceaa7725f3a

If you have more translation updates for the installer, you can sent them
to me privately, if you want.

> Also how should they be named forgot as it was a couple of years ago i
> did this, can take steam-installer and some others for example

I don't get your point here; but if you tell me it's a Swedish translation
for tasksel, I can always get the filename correct, so don't bother to much
on this.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Wed, 30 Aug 2023 22:33:08 +0200):
> Holger Wansing  (2023-08-30):
> > So you mean a changing like attached...
> 
> I'm so sorry, I had assumed the other image section was built using a
> loop on devel image list, that's why I thought we'd need an addition
> there. Since that's using an hardcoded list of download links, no need
> to change that, and the single change required is adjusting devel and
> trixie images list?

Done.
https://salsa.debian.org/webmaster-team/webwml/-/commit/b943a80cdd64fe6421d841054d7fae8fc0768ede


BTW: mipsel CD (netinst) images are no longer being built apparently?
Can they be removed as well?
The netboot images for mipsel seem to stay, as it is for i386?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Mon, 28 Aug 2023 18:03:35 +0200):
> Holger Wansing  (2023-08-28):
> > There's already a mechanism for filtering archs here, so I'm not
> > sure, if inventing another method in parallel is an improvement.
> 
> That's really apples and oranges:
>  - s390x is here and is here to stay (I have no opinions regarding the
>current exclusion/implementation though — in passing, s390 is long
>gone even if it still appears…);
>  - i386 is in a weird state where it's going to be in the archive, with
>d-i builds, without debian-cd builds.
> 
> It really does make sense to me to have both archs treated separately.

So you mean a changing like attached...

Resulting in a html page like the attached html...


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/english/devel/debian-installer/images.data b/english/devel/debian-installer/images.data
index 499bce27778..0fdc241bf2c 100644
--- a/english/devel/debian-installer/images.data
+++ b/english/devel/debian-installer/images.data
@@ -54,20 +54,23 @@
 https://cdimage.debian.org/cdimage/_di_/@ARCH@/bt-cd/" arch="" />
 
 
 https://cdimage.debian.org/cdimage/_di_/@ARCH@/bt-dvd/" arch="" />
 
 
 
 https://deb.debian.org/debian/dists/testing/main/installer-@ARCH@/current/images/; arch="" "source" />" />
 
 
+
+https://deb.debian.org/debian/dists/testing/main/installer-i386/current/images/; arch="i386" />
+
 
 
 # obsoleted; replaced by "devel-small-cd"
 
 https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/@ARCH@/iso-cd/debian-testing-@a...@-netinst.iso; arch="" " s390 s390x source" />" />
 
 
 # obsoleted; replaced by "devel-small-cd"
 
 https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/@ARCH@/iso-cd/debian-testing-@a...@-businesscard.iso; arch="" " s390 s390x source" />" />
@@ -121,21 +124,20 @@
 # Note that changes here should also be reflected in
 # scripts/daily-build-aggregator in the d-i repository, and in debian-cd.
 
 
 
 https://d-i.debian.org/daily-images/amd64/daily/;>amd64
 https://d-i.debian.org/daily-images/arm64/daily/;>arm64
 https://d-i.debian.org/daily-images/armel/daily/;>armel
 https://d-i.debian.org/daily-images/armhf/daily/;>armhf
 https://d-i.debian.org/daily-images/hurd-i386/daily/;>hurd-i386
-https://d-i.debian.org/daily-images/i386/daily/;>i386
 https://d-i.debian.org/daily-images/mips64el/daily/;>mips64el
 https://d-i.debian.org/daily-images/mipsel/daily/;>mipsel
 https://d-i.debian.org/daily-images/ppc64el/daily/;>ppc64el
 https://d-i.debian.org/daily-images/s390x/daily/;>s390x
 
 
 
 
 # Support for  tags:
 
diff --git a/english/devel/debian-installer/index.wml b/english/devel/debian-installer/index.wml
index 47ba84021eb..c7dd0d32c1b 100644
--- a/english/devel/debian-installer/index.wml
+++ b/english/devel/debian-installer/index.wml
@@ -173,20 +173,21 @@ unstable.
 
 netinst CD images (via jigdo)
 
 
 
 
 
 
 other images (netboot, USB stick, etc.)
 
+
 
 
 
 
 
 
 Notes
 
 
 #	Before you download the daily built images, we suggest you check for
diff --git a/english/template/debian/installer.wml b/english/template/debian/installer.wml
index 719743ecfac..e71ff1e0eb1 100644
--- a/english/template/debian/installer.wml
+++ b/english/template/debian/installer.wml
@@ -1,33 +1,33 @@
 #use wml::debian::release_info
 
-amd64\narm64\narmel\narmhf\ni386\nmips64el\nmipsel\nppc64el\ns390x\nsource
+amd64\narm64\narmel\narmhf\nmips64el\nmipsel\nppc64el\ns390x\nsource
 
 alpha\narm\nhppa\ni386\nia64\nm68k\nmips\nmipsel\npowerpc\nsparc\ns390\nsource
 alpha\namd64\narm\nhppa\ni386\nia64\nmips\nmipsel\npowerpc\nsparc\ns390\nsource
 alpha\namd64\narm\narmel\nhppa\ni386\nia64\nmips\nmipsel\npowerpc\nsparc\ns390\nsource
 amd64\narmel\nkfreebsd-i386\nkfreebsd-amd64\ni386\nia64\nmips\nmipsel\npowerpc\nsparc\ns390\nsource
 amd64\narmel\narmhf\ni386\nia64\nkfreebsd-i386\nkfreebsd-amd64\nmips\nmipsel\npowerpc\nsparc\ns390\ns390x\nsource
 amd64\narm64\narmel\narmhf\ni386\nmips\nmipsel\npowerpc\nppc64el\ns390x\nsource
 arm64\nmips\nmipsel\npowerpc\nppc64el\ns390x\nsource
 amd64\narmel\narmhf\ni386\nsource
 amd64\narm64\narmel\narmhf\ni386\nmips\nmips64el\nmipsel\nppc64el\ns390x\nsource
 mips\nmipsel\npowerpc\nppc64el\ns390x\nsource
 amd64\narm64\narmel\narmhf\ni386\nsource
 amd64\narm64\narmel\narmhf\ni386\nmips\nmips64el\nmipsel\nppc64el\ns390x\nsource
 mips\nmipsel\npowerpc\nppc64el\ns390x\nsource
 amd64\narm64\narmel\narmhf\ni386\nsource
 amd64\narm64\narmel\narmhf\ni386\nmips64el\nmipsel\nppc64el\ns390x\nsource
 mips\nmipsel\npowerpc\nppc64el\ns390x\nsource
 amd64\narm64\narmel\narmhf\ni386\nsource
 amd64\narm64\narmel\narmhf\ni386\nmips64el\nmipsel\nppc64el\ns390x\nsource
-amd64\narm64\narmel\narmhf\ni386\nmips

Re: Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

Am 28. August 2023 15:50:24 MESZ schrieb Cyril Brulebois :
>Thanks for the proposal, but I'm not sure this is the best way to do it.
>
>I think editing i386 out of english/template/debian/installer.wml (devel
>and trixie lists), and adding it manually in the netboot section would
>be better? (Naturally it'll show up before or after the list, but that's
>really an unimportant cosmetic issue that could be fixed by having an
>extra sort-arches macro if one feels strongly about it.)

There's already a mechanism for filtering archs here, so   I'm not sure, if 
inventing another method in parallel is an improvement.


Holger


-- 
Sent from /e/ OS on Fairphone3

Re: Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Sun, 27 Aug 2023 21:42:54 +0200):
> Holger Wansing  (2023-08-27):
> > So no more netinst images,
> 
> And any other sections about CD, DVD, etc. must go.
> 
> > but the "Other images" section will stay (netboot images, hd-media
> > ...)?
> 
> Right, only that one stays.

I have prepared a patch with this changings.

@kibi:
Since this file has 
"# This file should only be updated by a D-I release manager."
at its top:
do you want to commit it or do a proofreading?


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/english/devel/debian-installer/images.data b/english/devel/debian-installer/images.data
index 499bce27778..ef84b9ba483 100644
--- a/english/devel/debian-installer/images.data
+++ b/english/devel/debian-installer/images.data
@@ -3,136 +3,136 @@
 # This file should only be updated by a D-I release manager.
 
 #include wml::debian::installer
 
 
 # Release name
 bookworm
 # Version
 rc4
 rc4
 Bookworm RC 4
 
 # Has Alpha 1 happened already during this release cycle? (yes/no)
 
 
 # If arches are added here, then also comment them out for the
 # devel-other-images tag below
 
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-cd/debian--DI--@a...@-netinst.iso" arch="" "s390 s390x source" />" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-cd/debian--DI--@a...@-netinst.iso" arch="" "i386 s390 s390x source" />" />
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-cd/debian--DI--@ARCH@-netinst.jigdo" arch="" "s390 s390x source" />" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-cd/debian--DI--@ARCH@-netinst.jigdo" arch="" "i386 s390 s390x source" />" />
 
 
 # Turned out not to be such a good idea for official releases as the link would
 # point to the same directory as full CD images
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-cd/" arch="" "s390 s390x source" />" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-cd/" arch="" "i386 s390 s390x source" />" />
 
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-cd/" arch="" "source" />" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-cd/" arch="" "i386 source" />" />
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-dvd/" arch="" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/iso-dvd/" arch="" "i386" />" />
 
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-cd/" arch="" "source" />" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-cd/" arch="" "i386 source" />" />
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-dvd/" arch="" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-dvd/" arch="" "i386" />" />
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-bd/" arch="amd64 i386 source" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/jigdo-bd/" arch="amd64 source" />
 
 
 # BitTorrent images not built anymore (to be removed)
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/bt-cd/" arch="" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/bt-cd/" arch="" "i386" />" />
 
 
-https://cdimage.debian.org/cdimage/_di_/@ARCH@/bt-dvd/" arch="" />
+https://cdimage.debian.org/cdimage/_di_/@ARCH@/bt-dvd/" arch="" "i386" />" />
 
 
 
 https://deb.debian.org/debian/dists/testing/main/installer-@ARCH@/current/images/; arch="" "source" />" />
 
 
 
 
 # obsoleted; replaced by "devel-small-cd"
 
 https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/@ARCH@/iso-cd/debian-testing-@a...@-netinst.iso; arch="" " s390 s390x source" />" />
 
 
 # obsoleted; replaced by "devel-small-cd"
 
 https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/@ARCH@/iso-cd/debian-testing-@a...@-businesscard.iso; arch="" " s390 s390x source" />" />
 
 
 
-https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/@ARCH@/iso-cd/; arch="" " s390 s390x source" />" />
+https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/@ARCH@/iso-cd/; arch="" " i386 s390 s390x source" />" />
 
 
 
-https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/@ARCH@/jigdo-cd/; arch="" " s390 s390x source" />" />
+ht

Re: Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

Am 27. August 2023 20:33:31 MESZ schrieb Cyril Brulebois :
>Holger Wansing  (2023-08-27):
>> Am 27. August 2023 10:12:09 MESZ schrieb Holger Wansing 
>> :
>> >Hi,
>> >
>> >Am 27. August 2023 08:48:20 MESZ schrieb Holger Wansing 
>> >:
>> >OTOH I would then remove the i386 link from
>> ><https://www.debian.org/devel/debian-installer/index.en.html>
>> >now?
>> 
>> I searched for a confirmation, that this was dropped from debian-cd,
>> but found nothing.
>> 
>> Should I just remove the link nevertheless?
>
>d-i daily builds will keep i386, so don't drop that link. Links to
>debian-cd locations can go away. The lack of symmetry might require
>tweaking some wml logic/definitions.

So no more netinst images, but the "Other images" section will stay (netboot 
images, hd-media ...)?

Is that correct?

Holger


-- 
Sent from /e/ OS on Fairphone3

Re: Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

Am 27. August 2023 10:12:09 MESZ schrieb Holger Wansing :
>Hi,
>
>Am 27. August 2023 08:48:20 MESZ schrieb Holger Wansing :
>Ah, sorry. 
>By accident I found a bug against release-notes, which documents that
>i386 d-i images will be dropped for trixie.
><https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036358>
>
>So, sorry for the noise.
>
>OTOH I would then remove the i386 link from
><https://www.debian.org/devel/debian-installer/index.en.html>
>now?

I searched for a confirmation, that this was dropped from debian-cd,
but found nothing.

Should I just remove the link nevertheless?


Holger



-- 
Sent from /e/ OS on Fairphone3

Re: Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

Am 27. August 2023 08:48:20 MESZ schrieb Holger Wansing :
>Hi,
>
>I noticed that the link to the daily built netinst image for i386 is "Not 
>found" currently:
><https://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/i386/iso-cd/>
>on
><https://www.debian.org/devel/debian-installer/index.en.html>
>
>The directory is not existing.
>
>Is this a known issue?

Ah, sorry. 
By accident I found a bug against release-notes, which documents that
i386 d-i images will be dropped for trixie.
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1036358>

So, sorry for the noise.

OTOH I would then remove the i386 link from
<https://www.debian.org/devel/debian-installer/index.en.html>
now?


Holger




-- 
Sent from /e/ OS on Fairphone3

Daily d-i images for i386 not being built?

[Holger Wansing]

Hi,

I noticed that the link to the daily built netinst image for i386 is "Not 
found" currently:

on


The directory is not existing.

Is this a known issue?


Holger


-- 
Sent from /e/ OS on Fairphone3

Re: installer help screen (Was: Re: installation-guide: simplify RAM/disk space requirements)

[Holger Wansing]

Hi,

Samuel Thibault  wrote (Thu, 24 Aug 2023 21:14:29 +0200):
> Holger Wansing, le jeu. 24 août 2023 08:01:46 +0200, a ecrit:
> > Holger Wansing  wrote (Tue, 8 Aug 2023 00:06:14 
> > +0200):
> > > amd64:minimum_memory_strict=350
> > > amd64:minimum_memory=780
> > > 
> > > i386:minimum_memory_strict=285
> > > i386:minimum_memory=485
> > 
> > Looking at this values (the current ones from lowmem), we have 350MB for
> > amd64 and 285MB for i386.
> > The installer help screen F2 has the 285MB value (grabbed from i386 ?) even 
> > on 
> > the amd64 image.
> > 
> > Should this be sync'ed somehow?
> 
> They need to be updated when updating the values in lowmem, yes.
> 
> > (Of course, bumping this value from 285 to 350 means, that the i386 
> > installer
> > help screen says "350MB needed", which is strictly not correct, but that's 
> > not a blocker IMO ?)
> 
> I'd say we can as well just put the amd64 values there.

Done.
Thanks


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

installer help screen (Was: Re: installation-guide: simplify RAM/disk space requirements)

[Holger Wansing]

Hi,

a follow-up on this regarding installer help screen:

Holger Wansing  wrote (Tue, 8 Aug 2023 00:06:14 +0200):
> amd64:minimum_memory_strict=350
> amd64:minimum_memory=780
> 
> arm64:minimum_memory_strict=245
> arm64:minimum_memory=260
> 
> armel:minimum_memory_strict=140
> armel:minimum_memory=190
> 
> armhf:minimum_memory_strict=140
> armhf:minimum_memory=190
> 
> i386:minimum_memory_strict=285
> i386:minimum_memory=485

Looking at this values (the current ones from lowmem), we have 350MB for
amd64 and 285MB for i386.
The installer help screen F2 has the 285MB value (grabbed from i386 ?) even on 
the amd64 image.

Should this be sync'ed somehow?

(Of course, bumping this value from 285 to 350 means, that the i386 installer
help screen says "350MB needed", which is strictly not correct, but that's 
not a blocker IMO ?)


Or another approach:
should we rephrase this similar to what we have now on
https://d-i.debian.org/manual/en.amd64/ch02s05.html
to say something like 
"We recommend xx MB of RAM" 
instead of 
"You need at least xx"
?

Or even 
"You must have at least 350 megabytes of RAM to use this Debian installer,
but we recommend a minimum of 512 megabytes."



Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

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

[Holger Wansing]

Hi,

Holger Wansing  wrote (Wed, 16 Aug 2023 19:40:38 +0200):
> Hi,
> 
> Thorsten Glaser  wrote (Fri, 28 Jul 2023 19:53:52 + 
> (UTC)):
> > Holger Wansing dixit:
> > 
> > >>Could this information (valid unit sufficēs) be added to the dialogue
> > >>where the size is entered? Screen space should suffice.
> > >
> > >Yes, I already thought about if changing the template would make sense 
> > >here.
> > 
> > Thanks!
> 
> Just pushed (to partman-partitioning, partman-auto-lvm and partman-lvm).

And uploaded:
- partman-partitioning 148
- partman-auto-lvm 92
- partman-lvm 147


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1049919: #1049919 installation-guide: add information about how to append boot parameters to the installer?

[Holger Wansing]

Control: reassign -1 installation-guide
-- 
Sent from /e/ OS on Fairphone3

Bug#1049919: #1049919 d-i: pressing ESC in graphical installer does nothing, unable to preseed installation

[Holger Wansing]

Control: retitle -1 installation-guide: add information about how to append 
boot parameters to the installer?


Ernesto Alfonso  wrote:
> The docs for preseeding debian recommend pressing ESC after entering
> the graphical installer menu:
> 
> 
> > Loading the preseeding file from a webserver
> > Most install methods you can interrupt early on and add a URL to a preseed 
> > file, for an almost fully automated installations. Here exemplified with 
> > the graphical installer:
> > 
> > When the graphical installer boot menu appears, press ESC
> > 
> > (Type "help" if you want view generic help)
> > Type "auto url=http://webserver/path/preseed.cfg;, replacing the URL with 
> > the address to your preseed configuration file
> > 
> 
> But when pressing ESC after selecting the debian bookworm graphical 
> installer, nothing happens.
> 
> I am using the amd64 DVD-1 ISO image: debian-12.0.0-amd64-DVD-1.iso

I found that you refer to the Debian Wiki at
https://wiki.debian.org/DebianInstaller/Preseed
when you talk about "docs for preseeding debian" above.

Please note, that the Wiki is not the "official" documentation for our 
installer.
That would be the installation-guide, see 
https://www.debian.org/releases/stable/installmanual
A chapter about preseeding installation is at
https://www.debian.org/releases/stable/amd64/apb.en.html

That being said, I see that the information on the Wiki page you mentioned 
is outdated and thus no longer working.
I have updated it now in that regard.




Moreover, I notice that we probably have some deficit in the installation-guide,
when it comes to information about how to append boot parameters to the 
installer
(at least for some architectures).

For amd64 and ii386 that is mentioned in chapter "5.1.5. The Boot Screen"
see https://www.debian.org/releases/stable/amd64/ch05s01.en.html#boot-screen

and s390x has it in "5.1.2. S/390 Boot Parameters"
https://www.debian.org/releases/stable/s390x/ch05s01.en.html

But for all other archs I cannot find any such information.

Would it make sense to add that?
(OTOH, nobody has complained about that for years, so maybe it's not necessary?)


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

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

[Holger Wansing]

Hi,

Thorsten Glaser  wrote (Fri, 28 Jul 2023 19:53:52 + (UTC)):
> Holger Wansing dixit:
> 
> >>Could this information (valid unit sufficēs) be added to the dialogue
> >>where the size is entered? Screen space should suffice.
> >
> >Yes, I already thought about if changing the template would make sense here.
> 
> Thanks!

Just pushed (to partman-partitioning, partman-auto-lvm and partman-lvm).


> Could we also get the size output in both formats? I realise that
> will most likely not be a change as simple…


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

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

[Holger Wansing]

Hi,

Am 13. August 2023 10:46:50 MESZ schrieb Richard Lewis 
:
>Holger Wansing  writes:
>
> (Terabytes), 10TiB (Tebibytes). The default unit is Megabytes.
> ^^
>
>I wonder if this last word is a typo and should say Gigabytes? (if not
>please consider changing the installer default - no-one is going to be
>happy to have accidentally made a MB-sized partition!)

No, that's no typo. And the patch does not touch this.
So, it's just the current status quo.

But I will evaluate, if that should be changed.

>I reads OK as-is, but to avoid repetition of 'enter the size' you could
>start the second sentence with something like "You can use the following
>formats:"

LGTM, thanks


Holger

-- 
Sent from /e/ OS on Fairphone3

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

[Holger Wansing]

Hi,

Justin B Rye  wrote (Fri, 28 Jul 2023 10:04:09 
+0100):
> 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).

I found there is another template, which needs to be changed for this.

Patch attached (especially for review on l10n-english).


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/debian/partman-lvm.templates b/debian/partman-lvm.templates
index 509d9a7..63219c0 100644
--- a/debian/partman-lvm.templates
+++ b/debian/partman-lvm.templates
@@ -376,8 +376,9 @@ Type: string
 # :sl3:
 _Description: Logical volume size:
  Please enter the size of the new logical volume. The size may be
- entered in the following formats: 10K (Kilobytes), 10M (Megabytes),
- 10G (Gigabytes), 10T (Terabytes). The default unit is Megabytes.
+ entered in the following formats: 10KB (Kilobytes), 10KiB (Kibibytes), 10MB
+ (Megabytes), 10MiB (Mebibytes), 10GB (Gigabytes), 10GiB (Gibibytes), 10TB
+ (Terabytes), 10TiB (Tebibytes). The default unit is Megabytes.
 
 Template: partman-lvm/lvcreate_error
 Type: error

Re: installation-guide: simplify RAM/disk space requirements

[Holger Wansing]

Hi,

Samuel Thibault  wrote (Tue, 8 Aug 2023 00:14:11 +0200):
> Hello,
> 
> This looks reasonable, thanks!

Now pushed to git.

thanks



> Samuel
> 
> Holger Wansing, le mar. 08 août 2023 00:06:14 +0200, a ecrit:
> > Hi again,
> > 
> > Samuel Thibault  wrote (Sun, 6 Aug 2023 14:32:22 
> > +0200):
> > > Holger Wansing, le sam. 05 août 2023 20:46:27 +0200, a ecrit:
> > > > Now looking in the doc source, I see that the "780MB" value from above 
> > > > is 
> > > > architecture-dependent too.
> > > 
> > > Ah, yes, that's part of the lowmem testing.
> > > 
> > > > While 780MB seems realistic for amd64 to me, I wonder if the other 
> > > > values can
> > > > be up-to-date:
> > > > 
> > > > amd64:minimum_memory=780
> > > > arm64:minimum_memory=260
> > > > armel:minimum_memory=80
> > > > armhf:minimum_memory=190
> > > > i386:minimum_memory=485
> > > > mips:minimum_memory=85
> > > > mips64el:minimum_memory=345
> > > > mipsel:minimum_memory=170
> > > > ppc64el:minimum_memory=64
> > > > s390x:minimum_memory=44
> > > > 
> > > > In the most eye-catching case of s390x, my proposal would mean, to 
> > > > change
> > > > the value in the guide from 44 to 512MB !
> > > > That leads to the question, if the new situation after my changing 
> > > > would be 
> > > > wrong, or if the doc was wrong in the past?
> > > 
> > > The doc probably just ended up wrong by just not getting updated,
> > > because we don't have people who both care about updating them, and have
> > > access to the hardware or know the qemu tricks to test all archs.
> > > 
> > > I see that in the lowmem package,
> > > bbb4ed4c4da20d585cf30ceba9f0987173d3ac70 raised the default levels from
> > > 32MB/64MB to 120MB/155MB, that being the minimum numbers that were
> > > actually seen to work on at least some arch.
> > 
> > Ok, I have now included those changes into my patch, to get the numbers
> > up-to-date for all archs. 
> > 
> > That is:
> > 
> > amd64:minimum_memory_strict=350
> > amd64:minimum_memory=780
> > 
> > arm64:minimum_memory_strict=245
> > arm64:minimum_memory=260
> > 
> > armel:minimum_memory_strict=140
> > armel:minimum_memory=190
> > 
> > armhf:minimum_memory_strict=140
> > armhf:minimum_memory=190
> > 
> > i386:minimum_memory_strict=285
> > i386:minimum_memory=485
> > 
> > mips64el:minimum_memory_strict=200
> > mips64el:minimum_memory=345
> > 
> > mipsel:minimum_memory_strict=160
> > mipsel:minimum_memory=170
> > 
> > ppc64el:minimum_memory_strict=256
> > ppc64el:minimum_memory=500
> > 
> > s390x:minimum_memory_strict=120
> > s390x:minimum_memory=155
> > 
> > See patch.
> > 
> > 
> > > > And, if a generic value for all archs is realistic and makes sense at 
> > > > all?
> > > 
> > > Probably not, as seen in the values in the lowmem package.
> > 
> > I think I found a reasonable solution.
> > 
> > Current situation is:
> > 
> > We have two sorts of numbers for RAM size:
> > 
> > a) some kind of rough values, identical for all archs. These are just 
> >subjective values, rounded up to the next bigger RAM modules you can buy
> >(current values can be found in
> >"Table 3.2. Recommended Minimum System Requirements" at
> >https://d-i.debian.org/manual/en.amd64/ch03s04.html )
> >These are only rough recommendations, as in "we **recommend** X MB".
> >And this chapter 3.4 also mentions, that these recommendations can well 
> > be 
> >underrun by the second sort of values:
> > b) these are values based on meassurements during lowmem testing. They are 
> >different over the archs, and in the current text they are considered as 
> >some kind of strict requirement, as in "you **need** at least X MB" 
> > values.
> >--> Compare this to the "we **recommend** X MB" values from a) !
> > 
> > 
> > 
> > 
> > Taking all this as a basis, I would like to propose the following:
> > 
> > 
> > 1. in chapter 2 
> > (https://people.debian.org/~holgerw/installation-guide___improve-ram-size-values/amd64/ch02s05.html)
> >which is about hardware requirements, just mention the minimal rough 
&

Re: installation-guide: simplify RAM/disk space requirements

[Holger Wansing]

Hi again,

Samuel Thibault  wrote (Sun, 6 Aug 2023 14:32:22 +0200):
> Holger Wansing, le sam. 05 août 2023 20:46:27 +0200, a ecrit:
> > Now looking in the doc source, I see that the "780MB" value from above is 
> > architecture-dependent too.
> 
> Ah, yes, that's part of the lowmem testing.
> 
> > While 780MB seems realistic for amd64 to me, I wonder if the other values 
> > can
> > be up-to-date:
> > 
> > amd64:minimum_memory=780
> > arm64:minimum_memory=260
> > armel:minimum_memory=80
> > armhf:minimum_memory=190
> > i386:minimum_memory=485
> > mips:minimum_memory=85
> > mips64el:minimum_memory=345
> > mipsel:minimum_memory=170
> > ppc64el:minimum_memory=64
> > s390x:minimum_memory=44
> > 
> > In the most eye-catching case of s390x, my proposal would mean, to change
> > the value in the guide from 44 to 512MB !
> > That leads to the question, if the new situation after my changing would be 
> > wrong, or if the doc was wrong in the past?
> 
> The doc probably just ended up wrong by just not getting updated,
> because we don't have people who both care about updating them, and have
> access to the hardware or know the qemu tricks to test all archs.
> 
> I see that in the lowmem package,
> bbb4ed4c4da20d585cf30ceba9f0987173d3ac70 raised the default levels from
> 32MB/64MB to 120MB/155MB, that being the minimum numbers that were
> actually seen to work on at least some arch.

Ok, I have now included those changes into my patch, to get the numbers
up-to-date for all archs. 

That is:

amd64:minimum_memory_strict=350
amd64:minimum_memory=780

arm64:minimum_memory_strict=245
arm64:minimum_memory=260

armel:minimum_memory_strict=140
armel:minimum_memory=190

armhf:minimum_memory_strict=140
armhf:minimum_memory=190

i386:minimum_memory_strict=285
i386:minimum_memory=485

mips64el:minimum_memory_strict=200
mips64el:minimum_memory=345

mipsel:minimum_memory_strict=160
mipsel:minimum_memory=170

ppc64el:minimum_memory_strict=256
ppc64el:minimum_memory=500

s390x:minimum_memory_strict=120
s390x:minimum_memory=155

See patch.


> > And, if a generic value for all archs is realistic and makes sense at all?
> 
> Probably not, as seen in the values in the lowmem package.

I think I found a reasonable solution.

Current situation is:

We have two sorts of numbers for RAM size:

a) some kind of rough values, identical for all archs. These are just 
   subjective values, rounded up to the next bigger RAM modules you can buy
   (current values can be found in
   "Table 3.2. Recommended Minimum System Requirements" at
   https://d-i.debian.org/manual/en.amd64/ch03s04.html )
   These are only rough recommendations, as in "we **recommend** X MB".
   And this chapter 3.4 also mentions, that these recommendations can well be 
   underrun by the second sort of values:
b) these are values based on meassurements during lowmem testing. They are 
   different over the archs, and in the current text they are considered as 
   some kind of strict requirement, as in "you **need** at least X MB" values.
   --> Compare this to the "we **recommend** X MB" values from a) !




Taking all this as a basis, I would like to propose the following:


1. in chapter 2 
(https://people.debian.org/~holgerw/installation-guide___improve-ram-size-values/amd64/ch02s05.html)
   which is about hardware requirements, just mention the minimal rough 
   recommended values from a) which says something like "512MB" or "1GB",
   corresponding to RAM modules available from your favorite hardware store.

2. People who want to try to go with lower values, are guided to
   chapter 3 
(https://people.debian.org/~holgerw/installation-guide___improve-ram-size-values/amd64/ch03s04.html),
   where they find the values from b) based on lowmem tests, which contain
   the "absolute minimum values", drawing the baseline that cannot be underrun.
   Note, that this page is different, depending on arch!

3. Move all the constraints / advanced infos like
 - installer should automatically do memory-saving tricks on low-memory 
systems"
 - warning, when lowmem levels are untested for some archs
 - note, that graphical installer images need more RAM
  from chapter 2 to 3, where they fit better: That's not hardware (which would
  be chapter 2), but how the software deals with the available hardware (so 
  that's chapter 3).

4. I moved the values for "Table 3.2. Recommended Minimum System Requirements"
   from hardcoded values to entities, to ease changings on this in the future
   (especially when looking at translations).

5. I bumped the recommended RAM size values from a) 
   from
   256MB (minimum) + 512MB (recommended)
   to
   512MB (minimum) + 1G (recommended)



All the resulting htm

Re: installation-guide: MS-DOS and Windows

[Holger Wansing]

Hi,

Am 3. August 2023 22:49:29 MESZ schrieb John Paul Adrian Glaubitz 
:
>Hello!
>
>On Thu, 2023-08-03 at 22:03 +0200, Holger Wansing wrote:
>>  
>> -On Windows 7 systems, you have to select the property Hardware 
>> IDs in the
>> +On Windows 7/10 systems, you have to select the property Hardware 
>> IDs in the
>>  device manager's details tab to actually see the IDs, as they are not
>>  displayed by default.
>
>I would suggest just using the term "Windows" here so you don't have to keep
>updating it every time a new major release of Windows has been released.

I changed that into "On newer Windows systems, ..."

Thanks


Holger

Re: installation-guide: simplify RAM/disk space requirements

[Holger Wansing]

Hi,

Samuel Thibault  wrote (Fri, 4 Aug 2023 23:06:11 +0200):
> Holger Wansing, le ven. 04 août 2023 21:03:38 +0200, a ecrit:
> > So I propose to change chapter 3 values like
> > 
> >   Install Type  RAM (minimum)   RAM (recommended)   Hard Drive
> > - No desktop256 megabytes   512 megabytes   4 gigabytes
> > + No desktop512 megabytes   1 gigabytes 4 gigabytes
> >   With Desktop  1 gigabytes 2 gigabytes 10 gigabytes
> > 
> > 
> > 
> > 
> > I would propose to change chapter 2
> > like
> > 
> > - You must have at least 780MB of memory and 1160MB of hard disk space to 
> > - perform a normal installation."
> > + You must have at least 512MB of memory and 4GB of hard disk space to 
> > + perform an installation."
> > 
> > 
> > 
> > 
> > Comments?
> 
> That looks good to me indeed.

Now looking in the doc source, I see that the "780MB" value from above is 
architecture-dependent too.
While 780MB seems realistic for amd64 to me, I wonder if the other values can
be up-to-date:

amd64:minimum_memory=780
arm64:minimum_memory=260
armel:minimum_memory=80
armhf:minimum_memory=190
i386:minimum_memory=485
mips:minimum_memory=85
mips64el:minimum_memory=345
mipsel:minimum_memory=170
ppc64el:minimum_memory=64
s390x:minimum_memory=44

In the most eye-catching case of s390x, my proposal would mean, to change
the value in the guide from 44 to 512MB !
That leads to the question, if the new situation after my changing would be 
wrong, or if the doc was wrong in the past?
And, if a generic value for all archs is realistic and makes sense at all?


My current plan would boil down to the attached patch.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/build/entities/common.ent b/build/entities/common.ent
index 1e58745e1..94c20298b 100644
--- a/build/entities/common.ent
+++ b/build/entities/common.ent
@@ -66,8 +66,12 @@
 Cancel">
 Go Back">
 
-
+
 
+
+
+
+
 
 
 
-
+
 
 

installation-guide: simplify RAM/disk space requirements

[Holger Wansing]

Hi all,

as a follow-up to #1032940, I think we have some open points in the doc 
regarding
RAM/disk space requirements.

In the installation-guide, we have 3 places referring to needed RAM/disk space
size, and unfortunately they are not very well conform with each other:
(at least for the end-user POV, who does not know all the details and tricks)


chapter 2:
https://d-i.debian.org/doc/installation-guide/en.amd64/ch02s05.html
says
"You must have at least 780MB of memory and 1160MB of hard disk space to 
perform a normal installation."



chapter 3:
https://d-i.debian.org/doc/installation-guide/en.amd64/ch03s04.html
says
"Table 3.2. Recommended Minimum System Requirements

Install TypeRAM (minimum)   RAM (recommended)   Hard Drive
No desktop  256 megabytes   512 megabytes   4 gigabytes
With Desktop1 gigabytes 2 gigabytes 10 gigabytes"



And chapter D.2:
https://d-i.debian.org/doc/installation-guide/en.amd64/apds02.html
has a table for different tasks:

"Task   Installed size (MB) Download size (MB)  Space needed to install 
(MB)
Desktop environment  
  • GNOME (default) 3216859 4075
  • KDE Plasma  458413165900
  • Xfce2509683 3192
  • LXDE2539693 3232
  • MATE2851762 3613
  • Cinnamon467613246000
Web server  85  19  104
SSH server  2   1   3   "





I remember some reports from users in the past, saying that the values in
chapter 2 are totally unrealistic, and the answer from debian-boot was
"Well, those values are minimal values over all archs", so a light-weight
arch could work with those values indeed. But for most users those values
are not real-world.
But hey, for those people, there is the link to chapter 3:
"Note that these are fairly minimal numbers. For more realistic figures, 
see Section 3.4, “Meeting Minimum Hardware Requirements”.
So, if chapter 2 advise is of no value at all, why not skip it completely?
Or make it compliant with chapter 3. ???



I would like to get this into a better shape, so that the different chapters
are talking "with the same speach" (and don't conflict).


To get this done, I propose to change (or unify) the values in chapter 2 + 3, 
so 
that they show a consistent picture.


I did some test installations with QEMU on amd64.
The results are:Installing with 256 MB of RAM fails, the installer 
stopps with "320 MB RAM is required"

Installing with 512 MB of RAM switches to low-memory
mode installer, but the installation succeeds.


So I propose to change chapter 3 values like

  Install Type  RAM (minimum)   RAM (recommended)   Hard Drive
- No desktop256 megabytes   512 megabytes   4 gigabytes
+ No desktop512 megabytes   1 gigabytes 4 gigabytes
  With Desktop  1 gigabytes 2 gigabytes 10 gigabytes




So:

1.
To have chapter 2 compliant with chapter 3 (regarding RAM size)

and
2.
since we have changed the minimal harddisk value to 4 gigabytes in 
bug#1032940 (harddisk size)

and
3.
since users will probably misinterpret the phrase of "a normal installation" 
here
(What is a *normal* installation? What is *normal* in this case? I would skip 
the *normal* here and just talk of *an installation*. )

I would propose to change chapter 2
like

- You must have at least 780MB of memory and 1160MB of hard disk space to 
- perform a normal installation."
+ You must have at least 512MB of memory and 4GB of hard disk space to 
+ perform an installation."




Comments?

Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

installation-guide: MS-DOS and Windows

[Holger Wansing]

Hi all,

I'm planning to do some changings to finally remove MS-DOS from the doc and
make some unification regarding the different Windows versions.


A patch is attached.



Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076
diff --git a/en/appendix/files.xml b/en/appendix/files.xml
index 63b44735c..0ec85aaa8 100644
--- a/en/appendix/files.xml
+++ b/en/appendix/files.xml
@@ -45,10 +45,10 @@ The most important device files are listed in the tables below.
 
 
   ttyS0
-  Serial port 0, COM1 under MS-DOS
+  Serial port 0, also referred to as COM1
 
   ttyS1
-  Serial port 1, COM2 under MS-DOS
+  Serial port 1, also referred to as COM2
 
   psaux
   PS/2 mouse device
diff --git a/en/howto/installation-howto.xml b/en/howto/installation-howto.xml
index 6e79c5d10..2e8cb763e 100644
--- a/en/howto/installation-howto.xml
+++ b/en/howto/installation-howto.xml
@@ -243,7 +243,7 @@ to autopartition, choose Manual from the menu.
 
 
 
-If you have an existing DOS or Windows partition that you want to preserve,
+If you have an existing Windows partition that you want to preserve,
 be very careful with automatic partitioning. If you choose manual partitioning,
 you can use the installer to resize existing FAT or NTFS partitions to create
 room for the  install: simply select the partition and specify its new size.
diff --git a/en/partitioning/partition/x86.xml b/en/partitioning/partition/x86.xml
index dfcd44487..fd8d9aa3e 100644
--- a/en/partitioning/partition/x86.xml
+++ b/en/partitioning/partition/x86.xml
@@ -24,7 +24,7 @@ bootloader.
 
 
 
-If you have an existing other operating system such as DOS or Windows and
+If you have an existing other operating system such as Windows and
 you want to preserve that operating system while installing , you may
 need to resize its partition to free up space for the  installation.
 The installer supports resizing of both FAT and NTFS filesystems; when you
diff --git a/en/preparing/needed-info.xml b/en/preparing/needed-info.xml
index 2db3a4d23..12eb563a5 100644
--- a/en/preparing/needed-info.xml
+++ b/en/preparing/needed-info.xml
@@ -339,7 +339,7 @@ On Windows systems, the IDs for a device can be found in the Windows device
 manager on the tab details, where the vendor ID is prefixed with VEN_
 and the product ID is prefixed with DEV_.
 
-On Windows 7 systems, you have to select the property Hardware IDs in the
+On Windows 7/10 systems, you have to select the property Hardware IDs in the
 device manager's details tab to actually see the IDs, as they are not
 displayed by default.
 
diff --git a/en/preparing/non-debian-partitioning.xml b/en/preparing/non-debian-partitioning.xml
index 9f53f611a..f31ff773b 100644
--- a/en/preparing/non-debian-partitioning.xml
+++ b/en/preparing/non-debian-partitioning.xml
@@ -21,7 +21,7 @@ means an LPAR or VM guest in this case.
 If you already have an operating system on your system
 
 
-(Windows 9x, Windows NT/2000/XP/2003/Vista/7, OS/2, MacOS, Solaris, FreeBSD, )
+(Windows, OS/2, MacOS, Solaris, FreeBSD, )
 
 
 
@@ -39,8 +39,7 @@ root filesystem.
 
 You can find information about your current partition setup by using
 a partitioning tool for your current operating system, such as the integrated Disk Manager in Windows or fdisk in
-DOS, such as the integrated Disk Manager in Windows, such as Disk Utility, Drive Setup, HD Toolkit, or MacTools, such as the VM diskmap. Partitioning tools always
 provide a way to show existing partitions without making changes.
@@ -61,10 +60,9 @@ making space for additional partitions without losing existing data.  Even
 though this works quite well in most cases, making changes to the
 partitioning of a disk is an inherently dangerous action and should only be
 done after having made a full backup of all data.
-For FAT/FAT32 and NTFS partitions as used by DOS and
+For FAT/FAT32 and NTFS partitions as used by
 Windows systems, the ability to move and resize them losslessly is provided 
-both by  as well as by the integrated Disk Manager of Windows
-7. 
+both by  as well as by the integrated Disk Manager of Windows.
 
 
 
diff --git a/en/using-d-i/modules/clock-setup-finish.xml b/en/using-d-i/modules/clock-setup-finish.xml
index 45301f0cc..a6e8fbc6e 100644
--- a/en/using-d-i/modules/clock-setup-finish.xml
+++ b/en/using-d-i/modules/clock-setup-finish.xml
@@ -18,7 +18,7 @@ whether or not the clock is set to UTC.
 Macintosh hardware clocks are normally
 set to local time. If you want to dual-boot, select local time instead of
 UTC.
-Systems that (also) run Dos or Windows are normally
+Systems that (also) run Windows are normally
 set to local time. If you want to dual-boot, select local time
 instead of UTC.
 

Re: Add Belarusian language to Weblate

[Holger Wansing]

Hi,

Am 30. Juli 2023 23:19:52 MESZ schrieb v...@eq.by:
>Hello!
>
>I do Belarusian translation of d-i and would like to try using Weblate. Could 
>you please add Belarusian language for d-i to Weblate?

Done.

Regards

Holger


-- 
Sent from /e/ OS on Fairphone3

Re: Bug#1042437: partman-auto-lvm: using binary units for size of volume group does not work correctly

[Holger Wansing]

Hi,

Pascal Hambourg  wrote (Fri, 28 Jul 2023 11:49:35 
+0200):
> > With a bookworm 12.0 netinst image:
> > when choosing guided partitioning -> set up LVM, it is now allowed to use
> > binary units for volume group size (MiB, GiB, ...), but the size is wrongly
> > calculated.
> > For example, if I choose a volume group of 12 GiB, I get one with 11,9 GB, 
> > but
> > it should be roughly 12,9 GB.
> 
> 1) How do you choose the VG size ? AFAICS, the only possible choice is 
> to restrict the VG use to a given size or percentage.

Yes, I use that dialog.

> 2) How do you see the VG size ?

It is displayed in the next dialog (partition overview screen).

> I tested guided LVM with all in one partition and restrict the VG used 
> size to 12 GiB and I get a root LV of 11.9 GB and a swap LV of 1 GB, so 
> a total use of 12.9 GB as expected. vgs shows 12 GiB used.

I wasn't aware of that concept, that the value I enter gets divided into
several volume groups (here: root and swap).
But that of course makes sense. 
(I don't use LVM usually, so no experience with it; I just did a test 
regarding to bug#684128 "src:debian-installer: allow use of binary units in
disk partitioner").


Sorry for the noise, my fault.
Closing this bug


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1042437: partman-auto-lvm: using binary units for size of volume group does not work correctly

[Holger Wansing]

Package: partman-auto-lvm
Severity: normal


With a bookworm 12.0 netinst image:
when choosing guided partitioning -> set up LVM, it is now allowed to use
binary units for volume group size (MiB, GiB, ...), but the size is wrongly
calculated.
For example, if I choose a volume group of 12 GiB, I get one with 11,9 GB, but 
it should be roughly 12,9 GB.

Using the manual way of configuring (so not guided partitioning, but manual),
it works correctly.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

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

[Holger Wansing]

Hi,


Am 26. Juli 2023 23:19:31 MESZ schrieb Thorsten Glaser :
>
>Could this information (valid unit sufficēs) be added to the dialogue
>where the size is entered? Screen space should suffice.

Yes, I already thought about if changing the template would make sense here.



That would require synchron changings in partman-partitioning and
partman-auto-lvm.


Patches attached as a proposal.
CC'ing debian-l10n-english for template review (three identical additions
in two packages).


Holger







diff --git a/debian/partman-partitioning.templates b/debian/partman-partitioning.templates
index 8464201..298a3ae 100644
--- a/debian/partman-partitioning.templates
+++ b/debian/partman-partitioning.templates
@@ -25,30 +25,32 @@ _Description: Write previous changes to disk and continue?
  .
  You cannot undo this operation.
  .
  Please note that the resize operation may take a long time.
 
 Template: partman-partitioning/new_size
 Type: string
 Default: some number
 # :sl2:
 _Description: New partition size:
  The minimum size for this partition is ${MINSIZE} (or ${PERCENT}) and its
  maximum size is ${MAXSIZE}.
  .
  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).
 
 Template: partman-partitioning/bad_new_size
 Type: error
 # :sl2:
 _Description: The size entered is invalid
  The size you entered was not understood.
  Please enter a positive integer size followed by an optional unit of measure
  (e.g. "200 GB"). The default unit of measure is the megabyte.
 
 Template: partman-partitioning/big_new_size
 Type: error
 # :sl2:
 _Description: The size entered is too large
  The size you entered is larger than the maximum size of the partition.
  Please enter a smaller size to continue.
@@ -65,30 +67,32 @@ Type: error
 # :sl2:
 _Description: Resize operation failure
  An error occurred while writing the changes to the storage devices.
  .
  The resize operation has been aborted.
 
 Template: partman-partitioning/new_partition_size
 Type: string
 Default: some number
 # :sl2:
 _Description: New partition size:
  The maximum size for this partition is ${MAXSIZE}.
  .
  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).
 
 Template: partman-partitioning/bad_new_partition_size
 Type: error
 # :sl2:
 _Description: Invalid size
 
 Template: partman-partitioning/new_partition_place
 Type: select
 # :sl1:
 __Choices: Beginning, End
 # :sl1:
 _Description: Location for the new partition:
  Please choose whether you want the new partition to be created at the
  beginning or at the end of the available space.
 
diff --git a/debian/partman-auto-lvm.templates b/debian/partman-auto-lvm.templates
index 271294e..f5f4bbd 100644
--- a/debian/partman-auto-lvm.templates
+++ b/debian/partman-auto-lvm.templates
@@ -79,30 +79,32 @@ Type: string
 Default: some number
 # :sl3:
 _Description: Amount of volume group to use for guided partitioning:
  You may use the whole volume group for guided partitioning, or part of it.
  If you use only part of it, or if you add more disks later, then you will
  be able to grow logical volumes later using the LVM tools, so using a
  smaller part of the volume group at installation time may offer more
  flexibility.
  .
  The minimum size of the selected partitioning recipe is ${MINSIZE} (or
  ${PERCENT}); please note that the packages you choose to install may
  require more space than this. The maximum available size is ${MAXSIZE}.
  .
  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).
 
 Template: partman-auto-lvm/bad_guided_size
 Type: error
 # :sl3:
 _Description: Invalid input
  You entered "${INPUT}", which was not recognized as a valid size.
 
 Template: partman-auto-lvm/big_guided_size
 Type: error
 # :sl3:
 _Description: ${SIZE} is too big
  You asked for ${SIZE} to be used for guided partitioning, but the available
  space is only ${MAXSIZE}.
 
 Template: partman-auto-lvm/small_guided_size

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

[Holger Wansing]

Thorsten Glaser  wrote (Tue, 25 Jul 2023 20:15:04 + (UTC)):
> why is this bug still unfixed?
> 
> In bookworm d-i, entering 512 MiB seems to be using something
> entirely different, and 512 Mi gives an error “invalid size”.
> 
> This still makes d-i unsuitable for most partitioning.

With a 12.0 netinst image, creating a new partition with a size of 512 MiB
results in a parition of 536 MB, creating a partiton of 10 GiB results in
a partition of 10,7 GB.
So I guess it works as it should.

The (visual) output is still in MB / GB, apart from this a see no issue.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Bookworm Installer and Hibernate

[Holger Wansing]

Hi,

Am 9. Juli 2023 13:18:24 MESZ schrieb Rainer Dorsch :
>I installed a new system (16GB RAM, 512 GB SSD) with the bookworm installer, 
>took the guided disk partitioning and selected use full disk with single 
>partition (which is I think recommended for beginners in the installer). With 
>that setup hibernate does not seem to work reliably, if e.g. 4 GB of the RAM 
>are used, hibernate does not work anymore. I think it is because the installer 
>created a swap partition on 1 GB in size. For me that seems ways to small to 
>make hibernate work. [...]

There is already a bugreport
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=987503
about this (which also has some background infos).

Sadly, nothing has happened prior the release of Bookworm.


Holger

-- 
Sent from /e/ OS on Fairphone3

Re: installation-guide upload for bookworm

[Holger Wansing]

Hi,

Samuel Thibault  wrote (Fri, 23 Jun 2023 02:07:01 +0200):
> Samuel Thibault, le ven. 23 juin 2023 01:15:55 +0200, a ecrit:
> > Holger Wansing, le jeu. 22 juin 2023 22:20:54 +0200, a ecrit:
> > > I have just pushed a change to installation-guide, which I would like to 
> > > have
> > > in stable|bookworm:
> > 
> > Yes, sure, we can upload that +id in stable once we have it settled in
> > unstable!
> 
> I have uploaded it to unstable, let's check how well it goes.

The new version has migrated into testing, and I see no blockers to get
this into stable, right?

So I guess, I could file an bookworm-pu bug against release.debian.org, to
get this pushed forward?


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: #1031319 partman-cros: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Holger Wansing]

Hi,

Paulo Henrique de Lima Santana wrote:
> Could you please update this Brazilian Portuguese translation?
> 
> Attached you will find the file pt_BR.po. It is UTF-8 encoded and
> tested with msgfmt and podebconf-display-po.

I have merged this into d-i translation now.

Thanks for your work

Closing this bug


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: #1036376 [INTL:es] Spanish translation of depthcharge-tools-installer debconf template

[Holger Wansing]

Hi,

Camaleón wrote:
> You can find enclosed the Spanish translation template to be uploaded with 
> the latest package build.
> 
> Kindly place this file in debian/po/ as es.po for your next upload.

I have merged this into d-i translation now.

Thanks for your work

Closing this bug


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: #1031317 depthcharge-tools-installer: [INTL:pt_BR] Brazilian Portuguese debconf templates translation

[Holger Wansing]

Hi Paulo,

Paulo Henrique de Lima Santana wrote:
> Could you please update this Brazilian Portuguese translation?
> 
> Attached you will find the file pt_BR.po. It is UTF-8 encoded and
> tested with msgfmt and podebconf-display-po.

I have merged this into d-i translation now.

Thanks for your work

Closing this bug


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: #1031316 depthcharge-tools-installer: [INTL:nl] Dutch translation of debconf messages

[Holger Wansing]

Hi Frans,

Frans Spiesschaert wrote:
> Please find attached the Dutch translation of depthcharge-tools-
> installer debconf messages. A draft has been posted to the debian-l10n-
> dutch mailing list allowing for review. 
> Please add it to your next package revision. 
> It should be put as debian/po/nl.po in your package build tree. 

I have merged this into d-i translation now.

Thanks for your work

Closing this bug


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Bug#1028597: depthcharge-tools-installer: [INTL:de] initial German debconf translation

[Holger Wansing]

Hi Helge,

Holger Wansing  wrote (Sat, 14 Jan 2023 00:38:46 +0100): 
> Helge Kreutzmann  wrote (Fri, 13 Jan 2023 13:49:39 
> +0100):
> > Please find the initial German debconf translation for 
> > depthcharge-tools-installer
> > attached.
> 
> Anyway, I have decided to release depthcharge-tools-installer and partman-cros
> without any translations in Bookworm, so this bug is for Trixie.

I have just merged this into the d-i translations
(amongst some changes, to harmonize the speech with german in d-i).

Thanks for your work

Closing this bug


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Debian Installer support for Chromebooks

[Holger Wansing]

Hi,

Am 26. Juni 2023 20:57:36 MESZ schrieb Alper Nebi Yasak 
:
>On 26/06/2023 20:14, Holger Wansing wrote:
>> I have now added them to the l10n-machinery.
>> Translation material should appear for translators then shortly.
>
>Thank you. I have already received some translations as bug reports, how
>should I process them?

Those bugreports are a bit problematic.
Ideally translators should not work on d-i packages directly, but 
that seems difficult to communicate.
Now we have those translations nevertheless.
Processing them is a bit of by-hand work.
I will take care of them tomorrow.


Holger



-- 
Sent from /e/ OS on Fairphone3

Re: Debian Installer support for Chromebooks

[Holger Wansing]

Hi,

Holger Wansing  wrote (Wed, 14 Dec 2022 22:21:42 +0100):
> Hi,
> 
> Am 14. Dezember 2022 16:50:58 MEZ schrieb Alper Nebi Yasak 
> :
> >So if I understand it right, things will go mostly in this flow:
> >
> >- depthcharge-tools-installer and partman-cross pass NEW review
> >- Holger uploads version 2 for both, with note for translators (Thanks!)
> >- No translation work is done for the two packages for now
> >- Bookworm releases
> >- The templates' original texts get reviewed for English
> >- The packages are integrated to d-i l10n workflow
> >- Translators start working on the packages for Trixie within d-i
> 
> That would be my plan, yes.

I have now added them to the l10n-machinery.
Translation material should appear for translators then shortly.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

installation-guide upload for bookworm

[Holger Wansing]

Hi Samuel, hi Cyril,

I have just pushed a change to installation-guide, which I would like to have
in stable|bookworm:

We received a new translation into Indonesian some time ago, but this is not
visible on the website currently.
The reason for this is: I missed to add id to debian/langlist and therefore
Indonesian is not included into the package, sadly :-(

To fix this, I would like to have this in stable, and thus get this uploaded
into proposed-updates before the next point release.

That would also bring 
"Document power-of-two support in partman" (commit a7a45dfe) 
and some translation updates for this into stable as well.


Would that work?

Could you care about an respective upload?
Thanks


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1037350: Package: installation-reports

[Holger Wansing]

Control: retitle -1 installation-reports: grub not installed (correctly)



-- 
Sent from /e/ OS on Fairphone3

Bug#1037350: Package: installation-reports

[Holger Wansing]

Control: rename -1 installation-reports: grub not installed (correctly)



Am 11. Juni 2023 22:45:34 MESZ schrieb Peter Ehlert :
>Package: installation-reports
>
>Boot method: USB
>Image version: debian-12.0.0-amd64-netinst.iso
>Date: 2023-06-11 9-16-23
>
>Machine: Type: Desktop System: Hewlett-Packard product: HP Z820 Workstation
>Processor: CPU: 2x 8-core Intel Xeon E5-2687W 0 (-MT MCP SMP-)
>Memory: Mem: 1310.8/48189.1 MiB (2.7%) Storage: 9.32 TiB (3.2% used)
>Partitions: 
>
>$ df -Tl
>Filesystem Type 1K-blocks    Used Available Use% Mounted on
>udev   devtmpfs  24639364   0  24639364   0% /dev
>tmpfs  tmpfs  4934568    2036   4932532   1% /run
>/dev/sdb24 ext4  28660644 4437152  22742276  17% /
>tmpfs  tmpfs 24672828   0  24672828   0% /dev/shm
>tmpfs  tmpfs 5120  12  5108   1% /run/lock
>/dev/sdb26 ext4  19046484    1228  18052388   1% /home
>tmpfs  tmpfs  4934564  80   4934484   1% /run/user/1000
>
>
>
>Output of lspci -knn (or lspci -nn):
>
>$ lspci -knn
>00:00.0 Host bridge [0600]: Intel Corporation Xeon E5/Core i7 DMI2 [8086:3c00] 
>(rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 DMI2 [103c:158b]
>00:01.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 1a [8086:3c02] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 1a [103c:158b]
>    Kernel driver in use: pcieport
>00:01.1 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 1b [8086:3c03] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 1b [103c:158b]
>    Kernel driver in use: pcieport
>00:02.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 2a [8086:3c04] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 2a [103c:158b]
>    Kernel driver in use: pcieport
>00:03.0 PCI bridge [0604]: Intel Corporation Xeon E5/Core i7 IIO PCI Express 
>Root Port 3a in PCI Express Mode [8086:3c08] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 IIO PCI Express Root 
>Port 3a in PCI Express Mode [103c:158b]
>    Kernel driver in use: pcieport
>00:05.0 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Address 
>Map, VTd_Misc, System Management [8086:3c28] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Address Map, VTd_Misc, 
>System Management [103c:158b]
>00:05.2 System peripheral [0880]: Intel Corporation Xeon E5/Core i7 Control 
>Status and Global Errors [8086:3c2a] (rev 07)
>    Subsystem: Hewlett-Packard Company Xeon E5/Core i7 Control Status and 
>Global Errors [103c:158b]
>00:05.4 PIC [0800]: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c] 
>(rev 07)
>    Subsystem: Intel Corporation Xeon E5/Core i7 I/O APIC [8086:3c2c]
>00:11.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
>Express Virtual Root Port [8086:1d3e] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset PCI Express 
>Virtual Root Port [103c:158b]
>    Kernel driver in use: pcieport
>00:16.0 Communication controller [0780]: Intel Corporation C600/X79 series 
>chipset MEI Controller #1 [8086:1d3a] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset MEI Controller 
>[103c:158b]
>    Kernel driver in use: mei_me
>    Kernel modules: mei_me
>00:16.2 IDE interface [0101]: Intel Corporation C600/X79 series chipset IDE-r 
>Controller [8086:1d3c] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset IDE-r 
>Controller [103c:158b]
>    Kernel driver in use: ata_generic
>    Kernel modules: ata_generic
>00:16.3 Serial controller [0700]: Intel Corporation C600/X79 series chipset KT 
>Controller [8086:1d3d] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset KT Controller 
>[103c:158b]
>    Kernel driver in use: serial
>00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network 
>Connection (Lewisville) [8086:1502] (rev 05)
>    DeviceName: Onboard LAN
>    Subsystem: Hewlett-Packard Company 82579LM Gigabit Network Connection 
>(Lewisville) [103c:158b]
>    Kernel driver in use: e1000e
>    Kernel modules: e1000e
>00:1a.0 USB controller [0c03]: Intel Corporation C600/X79 series chipset USB2 
>Enhanced Host Controller #2 [8086:1d2d] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset USB2 Enhanced 
>Host Controller [103c:158b]
>    Kernel driver in use: ehci-pci
>    Kernel modules: ehci_pci
>00:1b.0 Audio device [0403]: Intel Corporation C600/X79 series chipset High 
>Definition Audio Controller [8086:1d20] (rev 05)
>    Subsystem: Hewlett-Packard Company C600/X79 series chipset High Definition 
>Audio Controller [103c:158b]
>    Kernel driver in use: snd_hda_intel
>    Kernel modules: snd_hda_intel
>00:1c.0 PCI bridge [0604]: Intel Corporation C600/X79 series chipset PCI 
>Express 

Re: Upcoming D-I Bookworm RC 4 and pseudo-RC 5

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Sat, 3 Jun 2023 20:07:05 +0200):
> At the moment I've spotted three uploads:
>  - apt-setup (1:0.183), for ports architectures.
>  - preseed (1.118), for Hurd, even if the changelog is not quite verbose
>about that part…
>  - vte2.91 (0.70.5-1): new upstream (bugfix) release with no particular
>bugfixes identified.

I have just uploaded grub-installer 1.194, which completes Croatian and
Ukranian translation.
Feel free to include it in bookworm, if possible.


Holger

-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Debian Installer weblate lang list

[Holger Wansing]

Hi,

Fatih Altun  wrote (Tue, 16 May 2023 11:31:03 +0300):
> Hi d-i team,
> 
> I was sending the Turkish translations of the
> https://salsa.debian.org/installer-team/d-i project as a merge request.
> I think translations sent with weblate are included in the project
> faster. Therefore, I request that Turkish(tr.po) be added to the
> weblate list.

Done.
Sorry for the delay

Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1023472: Workaround implemented for live images

[Holger Wansing]

Hi kibi,

Cyril Brulebois  wrote (Fri, 19 May 2023 10:50:57 +0200):
> Hi,
> 
> Roland Clobus  (2023-05-19):
> > I consider it a workaround, because the netinst D-I is still affected.
> > If the LXQt desktop is selected in the installer, the Wayland desktop
> > manager is used instead of xfwm4.
> > The MR for a proposed fix (in tasksel) is at [1].
> 
> OK, I'll leave that one to people more used to tasksel than me.

Do you think, that just changing the order in the Recommends packages list
like in


  Depends: ${misc:Depends},
   task-desktop,
+ # Mention the preferred theme before sddm, otherwise another theme will be 
used
+  sddm-theme-debian-elarun | sddm-theme,
   sddm,
-  sddm-theme-debian-elarun | sddm-theme-debian-elarun,
   lxqt,
  Recommends: xsane,


changes the result?
My guess would be that the order is of no relevance.


Holger



-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Upcoming l10n uploads

[Holger Wansing]

Hi,

Am 16. Mai 2023 23:40:47 MESZ schrieb Cyril Brulebois :
>Enforcing a string freeze would have meant not being able to address
>those issues.

For sure, every medal has two sides.

>That being said, I don't think we've had many *changes* to existing
>strings, even less so late in the release cycle.
>
>So if that looks like a plan to you, we could decide to announce a
>string freeze, maybe matching a given freeze milestone[1], to resume
>sending a signal to translators. We should probably add some kind of
>warning or disclaimer, saying we shouldn't have changes to existing
>translations, but that some additions might still happen if absolutely
>required (which was the case for grub/grub-installer this cycle).
>
> 1. https://release.debian.org/testing/freeze_policy.html
>
>What do you think?

Sounds not bad...


Holger

-- 
Sent from /e/ OS on Fairphone3

Re: Upcoming l10n uploads

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Tue, 16 May 2023 22:38:51 +0200): 
> Holger: Those uploads can happen at any time, and I'm happy to perform
> a bunch of them. I see translations.txt already filled up; but I know
> at least Turkish is coming. Should I wait a few hours or days before
> starting those uploads?

I would propose to wait some days, let's say 5 days (if this timeline is fine
for you), and then we make a cut and close the window for bookworm.

For whatever reason translators come active at the very last this time;
maybe that's because we have nothing like a string freeze, as it was
some time in the past.

A very significant part of development happens at the very end of the
development cycle in d-i, if not during freeze.
Which can be considered as a kind of ignorance regarding translations.

Anyway, we can take it as it is, and to make the best of this, postpone
the latest uploads as much as we can.
Thus, my best plan would be to start with the last round of l10n uploads
during the coming weekend.

How does that sound?


Holger




-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Debian Installer weblate lang list

[Holger Wansing]

Hi,

Am 16. Mai 2023 10:31:03 MESZ schrieb Fatih Altun :
>Hi d-i team,
>
>I was sending the Turkish translations of the
>https://salsa.debian.org/installer-team/d-i project as a merge request.

I have merged that today.

>I think translations sent with weblate are included in the project
>faster. Therefore, I request that Turkish(tr.po) be added to the
>weblate list.
>https://hosted.weblate.org/projects/debian-installer/

No problem, I will add Turkish there shortly.


Holger


-- 
Sent from /e/ OS on Fairphone3

Re: Translation updates for grub-installer

[Holger Wansing]

Hi,

Am 12. Mai 2023 16:17:50 MESZ schrieb Luna Jernberg :
>Looks to be done :) so taking weekend now

Yes, Swedish is at 100%, nothing to be done there.

Holger


>
>On Fri, May 12, 2023 at 10:39 AM Luna Jernberg  wrote:
>>
>> Hey!
>>
>> Think i sent an updated Swedish file to Steve and have updated the
>> translations on Weblate, but if more needs doing for Swedish i can try
>> to help out with this if needed during the weekend after the dayjob
>> today
>>
>> On Thu, May 11, 2023 at 11:28 PM Cyril Brulebois  wrote:
>> >
>> > Hi,
>> >
>> > Not trying to put words in Steve's mouth of course, but I'll hazard a
>> > guess anyway:
>> >
>> > Holger Wansing  (2023-05-11):
>> > > Here I see, that a call for translation update was sent to previous
>> > > translators for the grub-installer package.
>> > > Maybe this happened in a semi-automated way together with a package 
>> > > upload
>> > > or similar, but for packages under the hood of debian-installer it does 
>> > > not
>> > > make sense, to sent such calls, at least not in this form quoted above:
>> > > If such a call is sent, it should point to the "master po files" in the
>> > > d-i repo:
>> > > https://salsa.debian.org/installer-team/d-i/-/tree/master/packages/po
>> > > and not to the po files of the individual packages. The master po files 
>> > > are
>> > > the only files, where translators should work on!!!
>> > > Maybe some workflow has to be adapted somewhere, to avoid such calls?
>> > >
>> > > Sorry for the noise, if you are already aware of this :-)
>> >
>> > Steve also maintains GRUB packages, and grub2 needed some updates as well,
>> > e.g. this one I spotted on the French list while I was wondering whether
>> > work had started there:
>> >   https://lists.debian.org/debian-l10n-french/2023/04/msg00183.html
>> >
>> > So maybe the same process has been used for grub-installer…
>> >
>> > [ … ]
>> >
>> > > @kibi: I plan to hold back uploads for these translation changings until
>> > > RC3 is out. (We also have a big bunch of changings received via Weblate,
>> > > so there will be a mass of uploads again, but I plan that for RC4.)
>> > > Thus, ready for RC3 from my side.
>> >
>> > OK, thanks!
>> >
>> > I had a few other packages on my radar:
>> >
>> >   [ Updated translations in ./packages/choose-mirror ]
>> >   * Polish (pl.po) by Matthaiks
>> >
>> >   [ Updated translations in ./packages/partman-efi ]
>> >   * Polish (pl.po) by Matthaiks
>> >
>> >   [ Updated translations in ./packages/s390-netdevice ]
>> >   * Norwegian Nynorsk (nn.po) by Kjetil Sørlund
>> >
>> >   [ Updated translations in ./packages/s390-dasd ]
>> >   * Norwegian Bokmal (nb.po) by Kjetil Sørlund
>> >   * Norwegian Nynorsk (nn.po) by Kjetil Sørlund
>> >
>> > which I planned on checking, possibly uploading and unblocking before RC
>> > 3, but I didn't check actual contents there (yet).
>> >
>> >
>> > Cheers,
>> > --
>> > Cyril Brulebois (k...@debian.org)<https://debamax.com/>
>> > D-I release manager -- Release team member -- Freelance Consultant

-- 
Sent from /e/ OS on Fairphone3

Translation updates for grub-installer

[Holger Wansing]

Hi,

Steve McIntyre  wrote (Thu, 11 May 2023 00:40:40 +0100):
> Here's a big set of extra translations...

Thanks.


> From: Kevin Scannell 
> To: Steve McIntyre 
> Cc: Irish 
> Subject: Re: grub-installer 1.189: Please update debconf PO translation for 
> the package grub-installer
> Date: Tue, 25 Apr 2023 06:41:56 -0500
> 
> 
> 
> Hi Steve,
> 
>   Translated file attached.
> 
> Best regards
> Kevin

Here I see, that a call for translation update was sent to previous translators
for the grub-installer package.
Maybe this happened in a semi-automated way together with a package upload
or similar, but for packages under the hood of debian-installer it does not
make sense, to sent such calls, at least not in this form quoted above:
If such a call is sent, it should point to the "master po files" in the
d-i repo:
https://salsa.debian.org/installer-team/d-i/-/tree/master/packages/po
and not to the po files of the individual packages. The master po files are
the only files, where translators should work on!!!
Maybe some workflow has to be adapted somewhere, to avoid such calls?

Sorry for the noise, if you are already aware of this :-)




Now acting on the po files itself:
General: the files sent are all outdated english-wise; they have 55 strings
in summary, while the recent ones have 59 strings.

The Irish, Hungarian and Latvian files are ok so far, I have included the
translations into the master po files by hand. But since the sent files are
outdated, we still will not have 100% translated for those languages.

The (two) files for Serbian were not used, because sr already had a 
translation status of 100%, so translator's time has been wasted (sadly!),
but nothing else happens. 

The file for Bosnian is mostly corrupt, nearly nothing of it can be used
without doubt.

The Persian file (fa) does not have any content we could use.
It does not have the new strings which were added recently to grub-installer.
So no benefit for Persian.


@kibi: I plan to hold back uploads for these translation changings until
RC3 is out. (We also have a big bunch of changings received via Weblate,
so there will be a mass of uploads again, but I plan that for RC4.)
Thus, ready for RC3 from my side.


Greetings
Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Re: Tags and l10n uploads

[Holger Wansing]

Hi,

Am 10. Mai 2023 21:04:35 MESZ schrieb Steve McIntyre :
>On Wed, May 10, 2023 at 06:22:53PM +0200, Cyril Brulebois wrote:
>>Hey Holger,
>>
>>I've seen a bunch of uploads and refreshed master branches, but it looks
>>like we're missing a number of tags. Please push them when you have a
>>chance? Nothing time sensitive though.
>>
>>For what it's worth, once we get a little closer to the tentative release
>>dates, I start looking at https://d-i.debian.org/translations.txt and
>>uploading packages with l10n changes (as I did for previous releases).
>>
>>Hopefully between your uploads and mine, we won't be leaving any l10n work
>>behind! :)
>>
>>(There's even a script to help me spot + unblock l10n-only changes on the
>>release side, so that I can focus on reviewing the less easy packages.)
>
>I've still got a stack of grub-installer l10n updates that were just
>sent to me (AFAICS). What's the best way to apply those?


I can take care of that.
Could you sent them here?


Holger




-- 
Sent from /e/ OS on Fairphone3

Re: Tags and l10n uploads

[Holger Wansing]

Hi,

Cyril Brulebois  wrote (Wed, 10 May 2023 18:22:53 +0200):
> Hey Holger,
> 
> I've seen a bunch of uploads and refreshed master branches, but it looks
> like we're missing a number of tags. Please push them when you have a
> chance? Nothing time sensitive though.

Done.


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076

Bug#1034750: tasksel default value for preseeding

[Holger Wansing]

Hi,

"Adam Baxter"  wrote:
> A full desktop environment was installed without prompting but I think this 
> is a side effect 
> of using priority=critical as a boot parameter. 

Yes, that's correct.
Using priority=critical leads to questions not being asked, if they have a 
reasonable default value; and the default value for the "tasksel tasksel/first"
question is "Installing gnome desktop environment".
So you get Gnome, if you bypass that question :-)


"Adam Baxter"  wrote:
> 
> #The original didn't have this, but this stops the desktop environment being 
> installed.
> d-i pkgsel/run_tasksel boolean false

Setting 
tasksel tasksel/first multiselect standard
in your preseed file would also work (installing all "standard" packages,
and that's it; would lead to what's often called a "minimal Debian system").


Holger


-- 
Holger Wansing 
PGP-Fingerprint: 496A C6E8 1442 4B34 8508  3529 59F1 87CA 156E B076