Re: Dropping haveged from the installer

[Cyril Brulebois]

Ben Hutchings  (2020-03-15):
> On Sat, 2020-03-14 at 08:13 +0100, Cyril Brulebois wrote:
> [...]
> > Anyway, to get the ball rolling, I've performed some tests to see
> > how it would go. I've tried dropping haveged-udeb from pkg-lists and
> > that seems to be working fine: there are no obvious delays with
> > either the all-HTTPS scenario or the encrypted LVM one. I'm seeing
> > the “random: crng init done” message after 23 or 52 seconds
> > respectively, likely when the first entropy-needing operations are
> > happening. Can you confirm this is the expected behaviour?
> [...]
> 
> Yes, that's what I would expect.
> 
> However: I've just run a test where the initramfs script reads one
> byte of /dev/random then reports the time and relevant log messages.
> On 5.5, with random.trust_cpu=N, it still hangs for many minutes.
> Eventually I stopped waiting and pressed keys, and that un-stuck it.
> So I think the in-kernel entropy generator might not be reliable
> (yet).

OK, I'll postpone the change then, and keep haveged-udeb for now. Feel
free to let us/me know when you think this is reliable enough for us to
implement the suggested change.

Thanks!


Cheers,
-- 
Cyril Brulebois (k...@debian.org)
D-I release manager -- Release team member -- Freelance Consultant


signature.asc
Description: PGP signature

Re: boot-time accessibility issues

[Samuel Thibault]

Hello,

Rich Morin, le jeu. 12 mars 2020 09:28:49 -0700, a ecrit:
> The idea of detecting the presence (or absence) of a blind-related device 
> seems worth pursuing, even if there are some issues to be resolved.

The Debian Installer detects the presence of a braille device and then
enables accessibility automatically.

> For example, following Jude's notion of checking for a monitor, maybe Avahi 
> and SSH could be enabled whenever a monitor isn't found.

That might be frowned on: opening such ports just because a monitor is
not detected seems a bit scary to me.

> For that matter, enabling Orca (or whatever) by default when no
> monitor is present wouldn't be that big a problem for a sighted user.

Actually it would be. The accessibility stack slows applications down,
at least a bit, and thus we can't really enable it by default, only keep
it ready to be enabled on a shortcut press.

> I've been wondering about the notion of checking for a USB flash drive that 
> contains some sort of magic files.  The files probably can't contain 
> executable binary files (due to hardware incompatibility issues), but they 
> could certainly contain textual configuration data.  Can anyone suggest ideas 
> for file content, format, naming, etc?

This is actually what the GPII project is after: https://gpii.net/

Samuel

Re: Dropping haveged from the installer

[Ben Hutchings]

On Sat, 2020-03-14 at 08:13 +0100, Cyril Brulebois wrote:
[...]
> Anyway, to get the ball rolling, I've performed some tests to see how it
> would go. I've tried dropping haveged-udeb from pkg-lists and that seems
> to be working fine: there are no obvious delays with either the
> all-HTTPS scenario or the encrypted LVM one. I'm seeing the “random:
> crng init done” message after 23 or 52 seconds respectively, likely when
> the first entropy-needing operations are happening. Can you confirm this
> is the expected behaviour?
[...]

Yes, that's what I would expect.

However: I've just run a test where the initramfs script reads one byte
of /dev/random then reports the time and relevant log messages.  On
5.5, with random.trust_cpu=N, it still hangs for many minutes. 
Eventually I stopped waiting and pressed keys, and that un-stuck it. 
So I think the in-kernel entropy generator might not be reliable (yet).

Ben.

-- 
Ben Hutchings
Humour is the best antidote to reality.




signature.asc
Description: This is a digitally signed message part

Processed: Re: Bug#951709: /boot should get a bigger share of disk in default installation

[Debian Bug Tracking System]

Processing control commands:

> tags 951709 + pending
Bug #951709 [debian-installer] /boot should get a bigger share of disk in 
default installation
Ignoring request to alter tags of bug #951709 to the same tags previously set

-- 
951709: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951709
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Processed: Re: Bug#951709: /boot should get a bigger share of disk in default installation

[Debian Bug Tracking System]

Processing control commands:

> tags 951709 + pending
Bug #951709 [debian-installer] /boot should get a bigger share of disk in 
default installation
Added tag(s) pending.

-- 
893886: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=893886
951709: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951709
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems

Bug#893886: Bug#951709: /boot should get a bigger share of disk in default installation

[Holger Wansing]

Control: tags 951709 + pending


Steve McIntyre  wrote:
> On Fri, Mar 13, 2020 at 06:03:38AM +0100, Cyril Brulebois wrote:
> >Steve McIntyre  (2020-03-12):
> >> I'm torn - that's a good plan for large systems, but people on smaller
> >> platforms (e.g. small SD on rpi) that's a lot of space.
> >
> >Don't people usually flash ready to use images on such devices, instead
> >of going through d-i? Meaning acepting whatever (hopefully appropriate)
> >choices were made by recipe authors?
> 
> Some do, some don't IME. To be honest, let's just go with the biggser
> size anyway. People can always tweak if they need to.

So I have pushed that now to 512 - 768 MB
(closes 893886 and 951709, as the changelog says).

Holger


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

Bug#949694: tasksel: Please drop all kde-l10n packages

[Holger Wansing]

Hi,

Wolfgang Schweer  wrote:
> Package: tasksel
> Version: 3.58
> Severity: normal
> 
> Hi,
> 
> all kde-l10n packages are no longer available. They have been removed 
> from unstable and testing some time ago, see: 
> https://tracker.debian.org/pkg/kde-l10n
> 
> See also the related bug: 
> https://bugs.debian.org/935665 
> 
> (As far as I can tell, translations are now contained in the 
> libkf5i18n-data package, which is installed as a kde dependency.)

Hmm, libkf5i18n-data was already existing in buster, and it has nearly the
same filesize in sid compared to buster, so it seems that it does not contain
additional translations which have been dropped from kde-l10n-*

kde-l10n-* packages contain masses of .mo files, which I cannot find
anymore in unstable. Where have all those translations gone?

CC'ing kde people for advise.


Holger




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