don't include the advanced menu at all if it's only entry - memtest - is
not included (you just get a menu entry that does nothing, which may
confused users into thinking that something is broken, as opposed to
showing an empty submenu as i expected).
Gbp-Dch: Short
backwards compatibility:
1. the new file will be included alongside any user custom config
2. rather than replace MEMTEST with an actual config entry, we replace it
with a line to import the content of the new file, and thus will work
just as before.
thus no backwards compatible breakage
Gbp-Dch: Short
backwards compatibility:
1. the new install.cfg and install_start.cfg files (chosen
automatically from the install_*gui.cfg and install_*test.cfg
files) will be included alongside any user custom config.
2. the placeholders are now replaced with lines importing these files
thus everything will work just as before, i.e. no backwards
compatibility breakage.
Gbp-Dch: Short
as just done for grub2|loopback
the primary benefit here is that it means that user configs do not
have to carry copies of all files; they just carry the ones they
want to replace (or add).
Gbp-Dch: Short
`$_SOURCE` is always composed of `<foo>/${_BOOTLOADER}`, so we can just use
`${_BOOTLOADER}` as the basename, without calling `basename ${_SOURCE}`
Gbp-Dch: Ignore
...rather than choosing between the default set and a user provided set
1. ensures backwards compatibility after we switch from generation of
certain content to that content being in pre-prepared config files,
and thus no longer writing that config out to existing files.
2. means that user configs do not have to carry copies of all files; they
just carry the ones they want to replace (or add).
Gbp-Dch: Short
this takes a step forward in moving towards the same updated layout as
with syslinux; here we get:
- <live entries>
- Start installer
- Advanced install options...
- <full set of install options>
- Advanced options...
- Memory Diagnostic Tool (memtest86[+])
note that this only affects the default menu. custom configs are not
affected by this change.
further steps to complete the move to the updated layout will follow
later.
"Advanced options..." should perhaps be renamed later.
Gbp-Dch: Short
an official current debian install disc was compared with to achieve
better consistency.
main menu:
- i: for the single "start" entry
advanced submenu:
- g: for the main graphical entry
- i: for the main text-based entry
- x: for the main expert entry
- a: for the main auto entry
- r: for the main rescue entry
- s: for the synth entry
for expert, auto and rescue, the hotkey is given to the graphical entry
where present, otherwise to the text entry.
Gbp-Dch: Short
...for consistency with syslinux config placeholders and improved
clarity of what text is a placeholder.
the old placeholders without the bookends are still replaced for
user configs for backwards compatibility.
the new ones are little used just at the moment but are expected to
become used much more in later commits.
Gbp-Dch: Short
For consistency with install entries (both in live-build and
official Debian install discs).
Comparing with live-build created installer entries, grub-legacy
and grub2 both favour vga-788 for GUI entries and vga=normal for
test entries, whilst syslinux uses vga-788 for everything.
Gbp-Dch: Short
apt v2.0.1 introduced support for coloured E:/W:/N: labels. this adds
support to control it based upon our own colour control.
note that with utilities like dpkg we do not do this, but apt only uses
its new colour support automatically when `apt` is used directly, it is
not automatically enabled (per isatty()) for `apt-get`/`aptitude` (the
`apt` developer responsible for adding colour support in response to my
request for it told me that it was deliberately done like this per being
customary to not change behaviour of those tools for compatibility
reasons). colour errors/warnings are useful, so we want to turn it on for
our use of these tools where we can.
Gbp-Dch: Short
this reverts commit 0cef87ffca though
retaining the 'advanced options' menu entry using a label rather than a
title.
despite having done a lot of testing back in 2015 with my bootloader
improvements, i notice now that in fact the syslinux caret fix has an
undesired side effect of modifying the title displayed above the menus. it
does not help that the text embedded into the splash overlaps with this
menu title; perhaps this explains why i missed this problem back in 2015.
purely reverting the implemented fix solves this title problem, but
restores the caret problem to the advanced options menu (in menu.cfg);
however that menu was using a caret in a title entry, unlike everywhere
else where they are only used with labels, which must have been the
original source of the problem all along. ensuring that this menu uses a
label instead of a title in this reversion leaves everything working
correctly afaict.
Gbp-Dch: Ignore
...from the `Set_config_defaults` function, to being done directly
in `build.sh` (the component which is also responsible for loading
functions, loaded at the start of every script, including the front
end).
thus the colouring decision will now correctly...
- apply to the frontend, such as to the 'root privileges needed'
error, the 'no such script' error, and the command name
colouring that I want to add (the most significant issue).
- apply to error messages generated by the `Arguments` and
`Read_conffiles` functions, which are called before
`Set_config_defaults` by scripts.
as things were, due to the comparison with "false", colour would
_always_ be used in these places (unless _COLOR_ERR=false or
_COLOR_OUT=false wrt. the new command highlight, were set in the
environment when executing a script throught the frontend).
this would not be a problem for normal terminal use of course,
besides being inconsistent where color were turned off, but would
be a bit of a problem if redirected to a file.
a re-evaluation of _COLOR is performed in `Set_config_defaults` to
adjust _COLOR_OUT and _COLOR_ERR where necessary, to correctly
respond to _COLOR being set in saved config files (disabled by
default but a user could always enable), after the point of config
files being loaded.
_COLOR can still be controlled from the environment just as before,
overriding both _COLOR_OUT and _COLOR_ERR.
note that this does not address the fact that --color|--no-color
do not work in the frontend and thus will not impact the colouring
of to-be-introduced command highlighting. this needs to be
addressed separately.
Gbp-Dch: Short
d-i removed this in commit 0917b2dde3ff73a204d27dd2f2fffc8a41175ddd
Note: There was inconsistency between grub and syslinux in use of this, with
syslinux not having it on graphical rescue and auto modes while grub entries
did. The patch to fix that has been dropped since we're removing it everywhere
anyway.
(#395040)
Gbp-Dch: Short
progress-linux, as discussed in MR #142 ([1]) is a little known distro,
which appears to be little more than a personal project of the original
author of live-build.
given that, the expense of maintaining all of these old hacks for it
cannot be justified. it is not known whether or not live-build is even
used with respect to it since the author abandoned live-build some
years ago.
also, at least one past change in live-build possibly broke progress-linux
compatibility anyway, which would have required progress-linux users of
live-build to use a custom progress-linux config, or a progress-linux
fork of live-build, and there is no knowing how much of the hacks in this
"upstream" codebase any user of progress-linux currently relies upon.
and again, progress-linux appears to just be a personal project of
Daniel's, with afaik very little userbase. (Daniel seems to be the only
developer working on the project which speaks to how small it is).
[1]: https://salsa.debian.org/live-team/live-build/-/merge_requests/142
Gbp-Dch: Short
seems to have been obsolete since all the way back at v1.0~a22-1.
history:
- in 0d0de885e3 it was renamed from
LIVE_ROOT to LH_ROOT, but also seems to have become completely
obsolete at this point, and thus mistakenly not actually removed.
before this it seems to have been used to hold the base directory of
live-build from which paths were constructed, but then this use was
removed making it redundant, but it remained in the code.
- 83bc63f725 renamed to LB_ROOT.
- a79a5bea10 dropped setting the variable
only if not already set, in favour of always setting it depending upon
LB_MODE. but still it remained unused.
Gbp-Dch: Short
when the --fdisk and --losetup options were removed, the entries in the
getopt option list should have remained for backwards compatibility such
that the usage warnings can kick in instead of unknown option errors.
Gbp-Dch: Ignore
unless `LIVE_BUILD` is set in the environment when running live-build,
this var will be empty. this will result in the frontend trying to load
the file '/scripts/build.sh', which is doubtful the file intended to be
loaded, if it exists. the intention of checking the path
"${LIVE_BUILD}/scripts/build.sh" is really only to do so if the var is
actually used, so let's only do so if it's non-empty.
since we use `set -e`, if build.sh is not found in either location then
failure will occur. if it is found, presuming it is the real file that we
expect to be found, this file sets the var to a default if it was an empty
string, thus we need not worry about use of the var later in the frontend
script.
also, the var is exported prior to exec'ing the command script, so we know
that in the command scripts it is not going to be empty, and those in
themselves loading build.sh which again exports the var ensures that it
will be set for subsequent loads of component scripts (which happens to
go through the frontend again, not that that matters. so except for at the
start of execution, it should never be found to be empty.
Gbp-Dch: Short
the frontend handles -h|--help directly and correctly redirects to the
man page.
component scripts however fail to load the correct manpage because they
are being directed to `man <script>` instead of `man lb script`.
(affects the top level commands and major build stages which actually have
man pages; the low level components don't and so will always fail anyway).
this is handled for every script in build.sh. this is not stored in the
saved config or anything, so no need to re-evaluate in
`Set_config_defaults`. this just seems to completely pointless.
Gbp-Dch: Short
Lyndon Brown
Luca Boccassi