| Age | Commit message (Collapse) | Author |
|---|
|
this is already covered by the check above it
Gbp-Dch: Ignore
|
|
|
|
|
|
This reverts commit 6b7c8ed4bf15175299729355f04d60dcbac1aded as it's
breaking multi-value space-separated parameters.
|
|
just as most scripts are skipped if their stagefile exists (indicating
that they have already been run to completion), including chroot
preparation scripts in install mode, this implements the same guard for
chroot prep remove mode, such that they exit early if their stagefile
does not exist, indicating that the modification has already been removed.
(also override-able by --force in the same way).
this basically just uses a tweaked copy of Check_stagefile().
Gbp-Dch: Short
|
|
no backwards compatibility hack for reading the old var from existing
saved config used because this was previously stored in the alternate
format config/build file.
Gbp-Dch: Short
|
|
no backwards compatibility hack for reading the old var from existing
saved config used because this was previously stored in the alternate
format config/build file.
Gbp-Dch: Short
|
|
|
|
back in v4.0~a6-1 a transition process was started to move the live-build
config to a new format. the new format was INI style, and required
parsing functions to read/write values, compared to the existing format
which was just shell script code setting variables.
this partial transition is the explanation for the existence of the
`New_configuration()` function, and understanding this is important to
understanding the purpose of it - it is not in fact intended for creating
a new configuration, it is just related to the new config format
transition.
the positives of the new format were that it was somewhat cleaner looking,
while the negative was the terrible relative efficiency.
the file `config/build` was created to hold options in this new format.
the transition was only ever completed for a handful of config options:
- architecture
- archive areas and parent archive areas
- live image name
- live image type
a 'configuration version' attribute was also saved, which is not used by
anything.
the bootstrap-mirror and parent-bootstrap-mirror attributes are pointlessly
stored in it seemingly resulting from work done in v4.0~a17-1. (they are
also stored in another config file from which the value is actually used).
it in fact seems to have been a source of confusion for Raphaël in
authoring 44b9b0a6501476de594ce3783cea5df0c141478c, since the new
`[parent]-distribution-{chroot|binary}` options it introduced were stored
both in `config/bootstrap` and in `config/build`, while only used from the
former. i expect, understandably, that he thought that `config/build` was
just an information file.
Gbp-Dch: Short
|
|
It used to rely on the $LIVE_BUILD/VERSION file which is now gone.
Instead we now rely on the debian/changelog file just like we do in the
Makefile.
|
|
|
|
thus it can correctly indicate success/fail status instead of always
indicating failure. when a user asks for usage with -u|--usage then we
should exit in success mode rather than failure as when usage in printed
in response to incorrect usage.
Gbp-Dch: Short
|
|
this means that the usage goes from:
lb {-h|--help|-u|--usage|-v|--version}
lb COMMAND [OPTIONS]
to:
lb {-h|--help|-u|--usage|-v|--version}
lb [FRONTEND_OPTIONS] COMMAND [COMMAND_OPTIONS]
though it is probably not worth is to update the description in the
manpages...? hmm...
so for instance this matters for color control with --color|--no-color
(you already had full control via environment vars). previously you could
do `lb COMMAND --no-color` to turn off colour, only to find that output
at the frontend level was still coloured (the option is processed at the
command context level, not the frontend), so you might try to instead use
`lb --no-color COMMAND`, only to find that this was not supported. Well
now it is, and used at the frontend level will fully control colour output
(after the command is processed anyway).
the full set of common options are thus available (except --force) at the
frontend level, and thus for instance all Echo_*() helpers used in the
frontend will work correctly after args are processed.
furthermore usage like `lb --color --help` will actually work. (not that
color is used there, but this previously would have failed with the
frontend treating the `--color` argument as the command; that's the point!)
Gbp-Dch: Short
|
|
|
|
Custom hook scripts may use the variable. And conditional package lists
can also rely on this variable.
|
|
this was previously not done in 8b109ffb96282a6dd1aa5d61aa935bcba69c56f1
to keep the renaming simple, but leaving the variable plural is a cause
for confusion.
since this property is stored in the INI style config/build config file
rather than a shell script based one, at the property there is already
singular, there was no need for a backwards compatibility hack.
Gbp-Dch: Short
|
|
being done in Prepare_config() meant that it would get saved into the
config stored on disk which is not what was intended.
being saved on disk is not a big problem, since the injection of the
dynamically determined option is always done on top of the value read
from the saved config anyway, so you'd always end up with two copies of
the option given to apt, the first being from the saved config, the second
being the more correct dynamically determined one, overriding the first.
so there is no functional change here, just better achieving what was
intended.
Gbp-Dch: Ignore
|
|
Gbp-Dch: Ignore
|
|
Gbp-Dch: Short
|
|
note that the bit of code removed from source_debian relies upon a
variable LB_TASKS which itself is an old leftover artefact from before
v4.0.
Gbp-Dch: Short
|
|
|
|
--net-root-path probably needs to go too, but it is being used for
something i don't fully understand currently.
Gbp-Dch: Short
|
|
|
|
since everywhere where 'apt' is a permitted value, 'apt-get' is also, it
just wasn't listed in the option's documentation and thus was also not
listed in the new validation check.
Gbp-Dch: Short
|
|
80aa5ab61100b6b11ae47984bab9a2eb988074f5 implemented a hack to handle
replacement of LB_LINUX_FLAVOURS with LB_LINUX_FLAVOURS_WITH_ARCH in
config files, but implemented it in the wrong place.
adding a conditional conversion within the config file meant that the old
value would only be read from **new** config files that are created
obviously without it, including re-saved configs if `lb config` were
re-run with additional options (not recommended). any existing value in an
existing config file would actually be ignored.
the right place to read the old value was in the Set_defaults() function
(since renamed).
a second issue also existed with the hack, it failed to excape the `$`
and thus printed the existing value of $LB_LINUX_FLAVOURS into the
conditional check being constructed in the config file, instead of
printing the name of the variable. the check embedded into the config
file thus became this on an amd64 machine:
```
if [ -n "amd64" ]
then
LB_LINUX_FLAVOURS_WITH_ARCH="amd64"
fi
```
which is clearly not what was intended.
Gbp-Dch: Short
|
|
Gbp-Dch: Ignore
|
|
Gbp-Dch: Ignore
|
|
Gbp-Dch: Ignore
|
|
to cover checking available value choices
Gbp-Dch: Short
|
|
splitting into two parts will make things much tidier
Gbp-Dch: Short
|
|
- add a validation check where an error will be printed
- replace the check done in the grub scripts with one that simple exits
if executed bypassing the validation check
Gbp-Dch: Short
|
|
|
|
...and second we then change the filename
Gbp-Dch: Short
|
|
the stuff in defaults.sh is only partially to do with setting default
config values, it also does other prep work like centralised comma
separated value to space separated conversion, and validation.
this is split into two parts to keep the diff simple, first we move the
two small functions from configuration.sh into default.sh...
Gbp-Dch: Short
|
|
it mostly applies defaults where a value does not exist, but does more in
some cases. the new name better reflects its usage and functionality.
Gbp-Dch: Short
|
|
this is used after applying user settings on top of the defaults,
so is not specific to checking defaults; it's a validation checker.
Gbp-Dch: Short
|
|
Gbp-Dch: Ignore
|
|
whilst some parts of the codebase were set up to work with multiple types
specified, others did not work with it and would not necessarily be easy
to adjust. this thus makes some tweaks to adjust things accordingly.
- option renamed to singular form (maintaining backwards compatibility)
- a validation check has been added
- unnecessary glob style type references fixed
- checks with In_list changed to a direct singular comparison
- typo of type "netboot" written as just "net" fixed (though unreachable
so of no consequence; really the code could be removed but it's trivial)
Gbp-Dch: Short
|
|
this option actually only has an impact when used for `lb config`; it thus
was incorrectly accepted and captured by Arguments() and the documentation
was wrong.
going back through git history, this has been incorrect since the v0.99 days.
also, reorganised the list alphabetically (no-color was inserted in the
wrong place).
Gbp-Dch: Short
|
|
|
|
|
|
|
|
two parts of the code worked with both comma and space separated lists,
while two others only worked with comma separated.
swapping out commas with spaces when we setup the var in
Set_config_defaults() means that individual scripts no longer need to worry
about it and everything supports both; and that we can avoid the
IFS/OLDIFS mess.
Gbp-Dch: Short
|
|
|
|
$@ when unquoted is subject to further word splitting. this fixes a bunch
of instances where it was incorrectly being used unquoted.
Gbp-Dch: Short
|
|
i've been noticing that in the binary_syslinux stage a wholebunch of
packages get installed whilst installing isolinux, and then upon removing
the installed packages at the end of the script, apt is listing a large
number of those that were auto installed as no longer in use and can be
removed via `apt autoremove`. this then persists through package
installation and removal steps throughout remaining scripts.
adding `--auto-remove` to `apt-get remove --purge` and similarly
`--purge-unused` to `aptitude purge` instructs apt to get rid of the unused
auto-installed packages at the same time as removing specific package that
brought them in in the first place, and thus resolves the problem.
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
|
|
...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
|
|
Gbp-Dch: Ignore
|
