Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Christian PERRIER]

Quoting Ole Streicher (oleb...@debian.org):

> The "standard" task is IMO one of the concepts in this step that
> actually *nobody* understands: I myself don't know what it means, and
> all the people I asked (when I presented the current scheme of
> installing the blends) have no idea what happens if they (de)select this.

Longstanding "issue". It installs packages of priority "standard", so
that brings us to the definition of these "standard" packages. IIRC
(but I even don't remember where it lies) I spent hours thinking about
the "right" way to translate the "standard" task name into French.

Anyway, the "standard" tasks I was talking about are the other tasks
in tasksel, not "standard" itself.


> > I still remember Joey's objections about *not* having users forced
> > to choose between desktop environmentsbecause, contrary to what
> > the average geek thinks, most people have no idea about what is a
> > desktop environment. So, just imagine if we present them with
> > "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> > strange things.
> 
> So, if the average user doesn't have a glue about a Desktop environment,
> why is it offered in the installation by default? You seem to contradict
> to your own arguments here.

Because there has always been a contradiction..:-)

In the past, precisely for these reasons, the D.E. tasks were not
presented to users. However, over time, we had more and more and more
requests to allow this and it finally got enabled, but nnot really
with great enthusiasm...:-). This is kinda acknowledging that, indeed,
Debian installations from scratch with user's manual interaction is
now more something that skilled users are doing (let's face reality :
is Debian really used and installed by unskilled users
nowadays...certainly not).

So, more or less, we currently already are in a kind of compromise
which will never satisfy everybody

About the name of the "Debian Blends" menu entry : I have no intent to
rename the project, but more to present users with a meaningful
choice. Holger's suggestion in this thread seems to be the way to go
--> keep "Debian Blends" but explain in a few words what it is.



signature.asc
Description: PGP signature

Re: Grant access to debian-installer project (Kabyle translation)

[Christian PERRIER]

Quoting Belkacem Mohammed (belkace...@gmail.com):
> Hello,
> I am going to start a translation project (add new localization) for
> Debian. I created a gues account (belkacem77-guest) on
> http://alioth.debian.org/ so I need to be granted with access to
> debian-installer project to checkout debian project.
> 
> For now, I just want to translate Debian (UI and docs) into Kabyle

Thank you for your proposal.

We have a formalized process for this:
http://d-i.alioth.debian.org/doc/i18n/

It includes a few steps before we grant access to users.

Your mail indeed can be considered as the first step:
http://d-i.alioth.debian.org/doc/i18n/ch03s01.html

Would you mind going through this document and then we can go for the
formal process I'd prefer doing it publicly here in debian-boot rather
than by private mail, even though I'll be the person you'll talk with
about all this.




signature.asc
Description: PGP signature

Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

[Anton Zinoviev]

On Wed, May 18, 2016 at 01:33:06PM -0300, Felipe Sateler wrote:
> 
> Ok. I see that the rules file appears to invoke the scripts in /etc
> directly. Is this intended

Yes.  The keyboard is configured by /lib/console-setup/keyboard-setup.sh 
and the font by the scripts in /etc.

Notice that /lib/console-setup/console-setup.sh does not run the scripts 
in /etc at all.  If necessary it runs setupcon.

> (IOW, shouldn't they invoke the wrappers at /lib/console-setup)?

Although setupcon is an universal and reliable tool, this cames at a 
price --- it is slow.  Many people have complained that console-setup 
slows down the boot and thats the only reason I decided to use scripts 
in /etc instead of setupcon.

By the way, the only thing /lib/console-setup/console-setup.sh does in 
addition to the scripts in /etc is to rebuild the scripts in /etc if 
necessary.  And it is necessary to rebuild these scripts only if the 
sysadmin modifies the console configuration by hand and doesn't run 
`setupcon --save-only` afterwards.  In this case the wrapper will 
rebuild the scripts in /etc during the first reboot.

> But upstream systemd and udev have pushed for mounting /usr in the 
> initramfs for a long time,

Is there a place where one can learn about such things?

> Note that because it has no WantedBy line, this service will not be
> actually executed during boot. If the service should run as part of
> normal system boot, it should have either WantedBy=sysinit.target or
> WantedBy=multi-user.target.
> Services WantedBy=sysinit.target will be pulled in both single user
> and multi user boots. Services in multi-user.target will only be
> pulled in multi user boots.

OK, then it has to be WantedBy=multi-user.target.  Rebuilding the 
scripts in /etc is not something we want in single user mode.

Anton Zinoviev

Re: Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

[Anton Zinoviev]

On Wed, May 18, 2016 at 12:12:29PM +, Holger Levsen wrote:
> 
> it fails to build now, quoting from
> https://jenkins.debian.net/job/d-i_build_console-setup/211/console:

Thanks.  Hopefuly, now it is fixed.

Anton Zinoviev

Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

[Felipe Sateler]

On 18 May 2016 at 07:59, Anton Zinoviev  wrote:
> On Wed, May 11, 2016 at 01:27:52PM -0300, Felipe Sateler wrote:
>>
>> Sure. Also, feel free to point me to what you have, and I can comment
>> on that as well.
>
> I've pushed the changes I made in git. The new version of
> keyboard-setup.service is more or less unchanged:
>
> [Unit]
> Description=Set the console keyboard layout
> DefaultDependencies=no
> Before=local-fs-pre.target
> Wants=local-fs-pre.target
> ConditionPathExists=/bin/setupcon
>
> [Service]
> Type=oneshot
> ExecStart=/lib/console-setup/keyboard-setup.sh
> RemainAfterExit=yes
>
> [Install]
> WantedBy=sysinit.target

This looks good to me.

> As for console-setup.service, this script doesn't actually configure the
> console (that is on Linux; on FreeBSD it does).  Therefore, I removed
> the instructions Before=system-getty.slice and WantedBy=sysinit.target.
> The actual configuration of the console is accomplished by udev (see
> /lib/udev/rules.d/90-console-setup.rules).

Ok. I see that the rules file appears to invoke the scripts in /etc
directly. Is this intended (IOW, shouldn't they invoke the wrappers at
/lib/console-setup)?

>
>> > What about the following additional instruction: RequiresMountsFor=/usr
>>
>> It would be redundant, as /usr is guaranteed to be mounted by the
>> initramfs (for stretch, both dracut and initramfs-tools do so). It
>> would cause no harm, though.
>>
>> Split-/usr without an initramfs that mounts /usr is not supported and
>> is likely to break.
>
> I suppose this is so only on Debian?  In order to support other
> nonstandard/future distributions I added this instruction.

It does no harm, so it is OK to leave there. But upstream systemd and
udev have pushed for mounting /usr in the initramfs for a long time,
so it is unlikely a systemd-based system will not have /usr mounted,
except as a misconfiguration.

>  So, now
> console-setup.service looks in this way:
>
> [Unit]
> Description=Set console font and keymap
> DefaultDependencies=no
> After=console-screen.service kbd.service local-fs.target
> RequiresMountsFor=/usr
> ConditionPathExists=/bin/setupcon
>
> [Service]
> Type=oneshot
> ExecStart=/lib/console-setup/console-setup.sh
> RemainAfterExit=yes


Note that because it has no WantedBy line, this service will not be
actually executed during boot. If the service should run as part of
normal system boot, it should have either WantedBy=sysinit.target or
WantedBy=multi-user.target.
Services WantedBy=sysinit.target will be pulled in both single user
and multi user boots. Services in multi-user.target will only be
pulled in multi user boots.

-- 

Saludos,
Felipe Sateler

Grant access to debian-installer project

[Belkacem Mohammed]

Hello,
I am going to start a translation project (add new localization) for
Debian. I created a gues account (belkacem77-guest) on
http://alioth.debian.org/ so I need to be granted with access to
debian-installer project to checkout debian project.

For now, I just want to translate Debian (UI and docs) into Kabyle

Best Regards.

M.Belkacem

-- 



*M. BelkacemIngénieur Systèmes informatiques ESI (Ex INI)Consultant
technico-fonctionnel  OpenERP -Chef de projet IT /Formateur*

*Tel :*  00213561891991/00213555044419
*mail :* belkace...@gmail.com, m.belka...@itsolutions.dz
*Skype :*  belkacem.mohammed3

Bug#824648: win32-loader: cannot start the Debian installer on a GPT partition

[Francisco Gómez García]

Package: win32-loader
Version: 0.8.0
Severity: important

After copying Debian's kernel and initrd at the system's C: partition 
and rebooting to the installer, the system shows up an error 0xc07b 
related to the file g2ldr.mbr. This is probably due to a lack of support 
for GPT disks.


win32-loader has been tested on a x64 computer with UEFI and Windows 
8.1. There are no errors on a Windows 10 VirtualBox machine with BIOS 
and a MBR table.

Re: Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

[Holger Levsen]

Hi Anton,

On Wed, May 18, 2016 at 02:59:46PM +0300, Anton Zinoviev wrote:
> I've pushed the changes I made in git.

it fails to build now, quoting from
https://jenkins.debian.net/job/d-i_build_console-setup/211/console:

dpkg-buildpackage: info: source package console-setup
dpkg-buildpackage: info: source version 1.143
dpkg-buildpackage: info: source distribution UNRELEASED
dpkg-buildpackage: info: source changed by Anton Zinoviev 
 dpkg-source --before-build workspace
dpkg-buildpackage: info: host architecture amd64
 fakeroot debian/rules clean
Fonts/Makefile:203: 
/var/lib/jenkins/jobs/d-i_build_console-setup/workspace/Fonts/soft.Makefile: No 
such file or directory
make: *** No rule to make target 
'/var/lib/jenkins/jobs/d-i_build_console-setup/workspace/Fonts/soft.Makefile'.  
Stop.
dpkg-buildpackage: error: fakeroot debian/rules clean gave error exit status 2
 
cheers,
Holger


signature.asc
Description: Digital signature

Bug#796603: Questions about console-setup.service (Re: Bug#796603: closed by Anton Zinoviev <zinov...@debian.org> (Bug#796603: fixed in console-setup 1.138))

[Anton Zinoviev]

On Wed, May 11, 2016 at 01:27:52PM -0300, Felipe Sateler wrote:
> 
> Sure. Also, feel free to point me to what you have, and I can comment
> on that as well.

I've pushed the changes I made in git.  The new version of 
keyboard-setup.service is more or less unchanged:

[Unit]
Description=Set the console keyboard layout
DefaultDependencies=no
Before=local-fs-pre.target
Wants=local-fs-pre.target
ConditionPathExists=/bin/setupcon

[Service]
Type=oneshot
ExecStart=/lib/console-setup/keyboard-setup.sh
RemainAfterExit=yes

[Install]
WantedBy=sysinit.target


As for console-setup.service, this script doesn't actually configure the 
console (that is on Linux; on FreeBSD it does).  Therefore, I removed 
the instructions Before=system-getty.slice and WantedBy=sysinit.target.  
The actual configuration of the console is accomplished by udev (see 
/lib/udev/rules.d/90-console-setup.rules).
 
> > What about the following additional instruction: RequiresMountsFor=/usr
> 
> It would be redundant, as /usr is guaranteed to be mounted by the
> initramfs (for stretch, both dracut and initramfs-tools do so). It
> would cause no harm, though.
>
> Split-/usr without an initramfs that mounts /usr is not supported and
> is likely to break.

I suppose this is so only on Debian?  In order to support other 
nonstandard/future distributions I added this instruction.  So, now 
console-setup.service looks in this way:

[Unit]
Description=Set console font and keymap
DefaultDependencies=no
After=console-screen.service kbd.service local-fs.target
RequiresMountsFor=/usr
ConditionPathExists=/bin/setupcon

[Service]
Type=oneshot
ExecStart=/lib/console-setup/console-setup.sh
RemainAfterExit=yes

Anton Zinoviev

Bug#824645: task-print-server: Please reconsider the dependencies of this package

[Brian Potkin]

Package: task-print-server
Version: 3.34
Severity: wishlist
Tags: d-i



cups and cups-client are Depends:. However, cups depends on cups-client
and has done so since version 1.3.10-3. From the changelog:

 [ Till Kamppeter ]

 [...snip...]

  * debian/control: Moved dependency on cups-client to Depends:, as 
   
cups-client is needed by the post-install script for the update of the  
   
PPDs of existing print queues.

I would also query cups-bsd as a Depends: (or even as a Recommends:).
cups itself has it as a Suggests: and command line printing is well
covered by the System V utilities in cups-client.

Regards,

Brian.

Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

On 18.05.2016 10:58, Petter Reinholdtsen wrote:
> [Ole Streicher]
>> In my opinion, the situation for the Debian Pure Blends is better here
>> than for the Desktop environments: If a user doesn't know what the
>> Blends mean, he just ignores it and doesn't install anything from it.
> 
> An unskilled user do not ignore options he do not understand, he worries
> and tries to understand them in order to avoid making a mistake that
> will bother him in the future.  If you believe options that are unknown
> or confusing do not cause any harm, I am quite sure you are mistaken.
> They increase the cognitive strain and force people to spend time trying
> to understand that the option can be ignored.  They also slow down the
> installation process.

Again, this questiones the whole tasksel step during the installation:
As Christian points out, the majority of users doesn't understand what
"Desktop Environment" means, especially if is should decide whether he
needs "Cinnamon" or "Mate".

My own experiences are that I don't know anyone who understands the
"standard tools" item.

Compared to that, "DebiChem" is understandable: That has something to do
with chemistry. If the help would have been displayed, then he could
also know it. He then could also understand what a "Pure Blend" is. It
may help him to understand what a "Desktop environment" is. And maybe
someone finds a smart help text for the "standard tools".

If we really care that people should understand what they see, the first
issue *should* be to implement the help texts here.

> Note, I am not against the blends selection option during installation,
> but believe it should be introduced after taking the negative effects as
> well as the positive effects into account, not by claiming the negative
> effects do not exist.

I claim that they do not increase much. The issues are already there.

> There exist usability research indicating that more than 7 options will
> confuse the human brain and cause a lot of cognitive strain.  To me it
> tell us that we should avoid "just two screenfulls" of options, and
> instead try to make sure at most one screenfull, and preferably less
> than 7 options are presented in any dialog in the installer.

This is already violated in some steps of the installation. And we
already have 13 Blends; I don't see a good way to squeeze them into 7.

Best regards

Ole

Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Holger Levsen]

On Wed, May 18, 2016 at 09:41:54AM +0200, Ole Streicher wrote:
> > So, with something like "Special-purpose packages" or "Specialized 
> > installations" or whatever along those lines, *then* a menu with the 
> > Blends list (unsorted) and the possibility of going back just in
> > case people see the list and think "heck, I have no idea about what
> > this stuff is about"then I'd say this is the way to go.
> I personally don't have problems with changing this; however this would
> open again the discussion about the names -- IMO we should be consistent
> here. We can't call them "Specialized Installations" in the installer,
> but "Debian Pure Blends" on the web page. Renaming would have a tail of
> renaming it everywhere.
 
Agreed. (And I don't think changing the name again is wise. Nor is
reverting to the old name before blends.)

So IMO "Debian blends" should be used alone here, but explained, something
like this:

 [ ] enable Debian blends (customized Debian variations)

And in the Blends menu I'd be in favor of not sorting them alphabetical,
but by relevance. (And determining the relevance won't be easy, as we
don't have useful metrics for this. So it will has to be guesswork.)

+btw, I'm not sure how best present the choices for the Debian Edu
blend, as Debian Edu has several installation options (eg mainserver,
ltsp-server, workstation and standalone) and some can be combined. So I
guess the chain of selections would be:

[x] enable Debian blends

->

[x] choose Debian Edu blend

->

present the Debian Edu installation options to choose from again…

[ ] edu main-server
[x] edu ltsp-server
[x] edu workstation
[ ] edu standalone


-- 
cheers,
Holger


signature.asc
Description: Digital signature

Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Petter Reinholdtsen]

[Ole Streicher]
> In my opinion, the situation for the Debian Pure Blends is better here
> than for the Desktop environments: If a user doesn't know what the
> Blends mean, he just ignores it and doesn't install anything from it.

An unskilled user do not ignore options he do not understand, he worries
and tries to understand them in order to avoid making a mistake that
will bother him in the future.  If you believe options that are unknown
or confusing do not cause any harm, I am quite sure you are mistaken.
They increase the cognitive strain and force people to spend time trying
to understand that the option can be ignored.  They also slow down the
installation process.

Note, I am not against the blends selection option during installation,
but believe it should be introduced after taking the negative effects as
well as the positive effects into account, not by claiming the negative
effects do not exist.

There exist usability research indicating that more than 7 options will
confuse the human brain and cause a lot of cognitive strain.  To me it
tell us that we should avoid "just two screenfulls" of options, and
instead try to make sure at most one screenfull, and preferably less
than 7 options are presented in any dialog in the installer.

-- 
Happy hacking
Petter Reinholdtsen

Re: Bug#758116: Allow to select Blends selection during installation - just "DE", "Web server", "Mail server" is NOT enough

[Ole Streicher]

Hi Christian,

I agree that the best compromise would probably be to have a separate
page "Debian Pure Blends". But someone should implement this -- any
volunteers? I myself don't have enough Perl knowledge to do this.

However, I don't understand your rationale here:

Am 18.05.2016 um 07:25 schrieb Christian Perrier:
> At first, I'm not happy with the idea of Pure Blends tasks mixing up
> with standard tasks. I fully respect the work done by the variou
> sblends teams, but having our usual longstanding "standard" tasks
> kinda lost in the middle of "strange" and obscure tasks which the
> average user has no idea about what they're about...is a no-no for
> me.

The "standard" task is IMO one of the concepts in this step that
actually *nobody* understands: I myself don't know what it means, and
all the people I asked (when I presented the current scheme of
installing the blends) have no idea what happens if they (de)select this.

The help text in the tasks file (which is anyway not displayed in
tasksel) does not help: f.e. if I want to use Debian for web browsing
and e-mail, shall I install it? If I am a Java developer? The "standard"
task itself is "obscure"; IMO even more than an "DebiChem" task (where
already the name suggests that you don't need it if you are not
interested in chemistry).

> I still remember Joey's objections about *not* having users forced
> to choose between desktop environmentsbecause, contrary to what
> the average geek thinks, most people have no idea about what is a
> desktop environment. So, just imagine if we present them with
> "Hamradio", "NeuroDebian", "Debian Med" and such a list of unsorted
> strange things.

So, if the average user doesn't have a glue about a Desktop environment,
why is it offered in the installation by default? You seem to contradict
to your own arguments here.

In my opinion, the situation for the Debian Pure Blends is better here
than for the Desktop environments: If a user doesn't know what the
Blends mean, he just ignores it and doesn't install anything from it.
This will cause no harm -- he will just not get something he anyway
doesn't know about. But if a user doesn't understand what a "Desktop
environment" is and therefore decides to not install it, he may left
with an installation that he did not expect, and may have no chance to
correct this without external help. Therefore it may be better to hide
the desktop environment choice as well.

> That leaves us with the idea of a "Debian Blends" choice in the
> standard task menu, which would lead to a dedicated "blends" menu. I
> think this is the best compromise to do, provided we find a good name
> for the menu entry : "Debian Blends" or "Debian pure Blends" is a
> great name for the project in its entirety...but probably not for the
> menu entry. Again, because it means nothing to Joe User.
> 
> So, with something like "Special-purpose packages" or "Specialized 
> installations" or whatever along those lines, *then* a menu with the 
> Blends list (unsorted) and the possibility of going back just in
> case people see the list and think "heck, I have no idea about what
> this stuff is about"then I'd say this is the way to go.
> 

I personally don't have problems with changing this; however this would
open again the discussion about the names -- IMO we should be consistent
here. We can't call them "Specialized Installations" in the installer,
but "Debian Pure Blends" on the web page. Renaming would have a tail of
renaming it everywhere.

So, I would propose to explain the name and the concept in the
installer. There is already some text in the debian-blends-tasks.desc
that would help to explain it -- it should just be displayed. Again, it
would help much if tasksel would be able to display the help texts that
are already there, and IMO if the programming efforts are limited, we
would gain more in implementing help texts instead of separating the
blends from the desktop environments.

Best regards

Ole