The special setup for nicely-named groups which have a single
hidden subgroup containing the actual packages, has the problem
that there is a non-empty subgroups item, but this results
in zero actual children: then the number of selected and partly
selected children is also zero in updateSelected() and therefore
the item ends up unselected.
Special-case this to avoid unnecessarily unselecting the item.
Reported by Vitor L.
The status for an empty login name is '' (empty), for ok -- this is
so that there is no complaint about it. But it's not ok to
continue with an empty name.
The status for an empty login name is '' (empty), for ok -- this is
so that there is no complaint about it. But it's not ok to
continue with an empty name.
- The EXPECT_FAIL value "Abort" stops the test (I wanted 'if this
unexpectedly passes, raise an error' -- should have read the
documentation more closely).
- Set the shell in the config object, not just in GS.
- add a status member so the different steps can show progress
as the user is created and configured. The progress values
are hard-coded guesses as to how much work is done for each step.
- while here, reduce the scope of the global storage variable
This is somewhat experimental and weird; the idea is that bool
arguments are a lot easier to understand if there are proper
names attached, rather than "true" and "false".
This improves the situation for jobs that do not provide
a status: their blank status does not overwrite the status
bar, and since (previous commit) the description or name
is used to start the job if the status is empty, at least
**something** is displayed.
SEE #1528
- os-proper may return an extra file after the device:
/dev/sda1:Ubuntu 19.10 (19.10):Ubuntu:linux
/dev/sdb1@/EFI/Microsoft/Boot/bootmgfw.efi:Windows Boot Manager:Windows:efi
- The API definitions are just the symbols to define; these
are variously added through add_definitions() (needs -D)
or target_add_definitions() (doesn't).
I think we had this (kind of) module a long time ago and it was
removed for over-complicating things; re-introduce one now that
KPMcore is used in 3 different places and all would benefit
from consistent API handling / defines.
