| Age | Commit message (Collapse) | Author |
|---|
|
- 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
|
|
Gbp-Dch: Ignore
|
|
|
|
|
|
|
|
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 0d0de885e32ff67d57bb7def451b62d75b8920ab 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.
- 83bc63f725263c571094e3af1c88c58992bf0ac6 renamed to LB_ROOT.
- a79a5bea1063da4010f145a0e29aaf9a672ef291 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
|
|
The LB_GRUB_SPLASH variable is populated by the --grub-splash param
but is not actually used for anything.
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
|
|
md5 & sha1 are not considered secure anymore and thus are of questionable
value here if checksums are wanted.
Gbp-Dch: Short
|
|
|
|
this function takes one or more required stage fileS _plural_, and exits
if any are missing (or at least it does now after the refactor).
let's rename it to make things more clear
Gbp-Dch: Short
|
|
|
|
the name of the stage is already printed earlier in the output prior to
the error here being printed. so the error really does not need to include
the script name itself.
|
|
now having investigated my suspicions of the functionality and use of
Require_stagefile(), i conclude that it has been fundamentally broken
all the way back to v1.0~a8-1 (or at least usage of it since v1.0.1-2).
gah. (╯°□°)╯︵ ┻━┻
----
very early on in the history of live-build this function took the name of
a _single_ stage file only and did `exit 1` should the file not be found.
this was simple and clearly accomplished "what was on the tin", so to
speak.
in bd1a5ddc8203907eb40135303bea5488397ec5d0 (2007, 1.0~a8-1) things got
weird. it was modified to support a list of multiple files. but instead of
being written to cause failure if _any_ of the listed files were missing
as perhaps one might expect, it was instead written to fail only if all
files were missing!
if you jump to the conclusion that i'm talking about a simple flipped
logic from a lack or otherwise of a `!` here, you'd be mistaken; there is
a comment inside the function that could not be more clear about what was
intended by the author - "Find at least one of the required stages"! this
makes me thoroughly confused about what they were thinking.
as we'll get to, this was fundamentally flawed (or at least its later use
was), but furthermore there were other notable issues introduced at this
point (but don't worry too much about these, they've all been addressed):
- `NAME` was modified in the loop, using the existing value, but nothing
initially set it...
- the setting of `NAME` seems related to its use in the subsequent error
output, yet they are logically separated; it is only set if a file
exists, while the error is only printed if none exist.
- it is pointlessly using a messy `CONTINUE="true"` based mechanism,
when it could just `return 0`.
- it did not handle correctly the bad use case of no params having been
supplied.
it doesn't seem to have been entirely thought through, despite its
pervasive use throughout the build system.
note that no change was made in that commit to make actual use of the
new multi-param support. it would not be used until about a year later.
the function has remained largely untouched since then. in
c68c0a270832ca340429878ce6a0ab606d435b06 a notable change was made to add
an initial setting of `NAME`, which partially addressed one of the above
issues. but it did not really address the issue the change was meant to
solve, since the `NAME` as printed in the error was now the name of the
script when what was really wanted was the name of the stagefile. this was
finally fixed properly in d54990695f334d205fa846c42b6e0f2afd3c47f5.
however the weirdly pointless setting of `NAME` persisted in the loop.
finally i personally just refactored the function in the commit prior to
this one, retaining the same functionality but addressing the remaining
of the above minor implementation issues.
looking at usage of the new functionality introduced in
bd1a5ddc8203907eb40135303bea5488397ec5d0, it does not seem to have been
until 0cbbde2b9664b9fafb311f1048db25ea69952222 (2008, almost a year after
it was made possible) that changes were made to finally start making use
of the ability to pass more than one filename at a time to the function,
and it would appear that perhaps the author forgot what it actually was
that the function accomplished when used with multiple params, and failed
to double check.
in this first use of multiple parameters, this commit went from passing
single file names to individual calls to the function to passing the files
in one single call, in a commit the purpose of which was described as
simply tidying things up. it was most certainly not intended to change
stage requirements.
unfortunately, a change in requirements did occur as a result since the
new usage of the function was not accomplishing the same as before. this
change completely broke the stage requirements protection mechanism such
that only a single one of the listed stages needed to have completed for
the check to pass, rather than all as expected.
this flaw made it into release v1.0.1-2 and it has existed every since.
in the very next commit from that one,
6204dc0e6db02859a07a978d87f1a5231c0214cf things got even worse. here we
see the config stage being specified commonly as the first stage listed,
which is still the case today. this means that ever since this commit,
if you've already got a config before building (which you inevitably do,
especially after some later commits introduced automatically creating it
if missing), then all other stage requirements are simply ignored.
so it seems pretty damn clear that this function is accomplishing
completely the wrong objective. it _should_ be checking that _all_ files
given to it exist, not just one or more. ¯\_(ツ)_/¯
this FINALLY addresses this mistake.
(not that i wish to berate the author; i've made silly mistakes of my own
before)
|
|
- count of params is available as $#, we don't need the pipe-to-wc logic.
- the whole 'CONTINUE' based logic is silly, we can just return once one
of the files is found.
- setting of 'NAME' in the loop was completely pointless.
- the error message for multiple files was not very clear just injecting
a sequence of words into a sentence.
- it did not work correctly if no arguments were given (bad usage)
note, you might question whether the functionality of this function is
correct, as did I; this is tackled in a followup commit whilst this
commit retains the existing functionality!
Gbp-Dch: Short
|
|
as suggested by Raphaël
rather than have fixed stagefile filename strings at all in the scripts,
use `$(basename $0)` to use the name of the script (which is the same for
almost all cases anyway, and the stage files are supposed to be almost
exclusively unique per-script). we can thus simplify things by determining
the filename for most use cases within the functions themselves.
this does change the file used by a couple of scripts, affecting backwards
compatibility of executing live-build upon an existing partially or fully
completed build:
- binary_grub-pc used "binary_grub"
- chroot_includes used "includes.chroot"
care had to be taken for the following cases:
- there are some cases like bootstrap_cache, source_debian and
bootstrap_debootstrap which are dealing with more than one file, and/or
otherwise a filename that is not specific to the script itself exactly,
or should not be based upon its name.
- some cases like chroot_cache, bootstrap_cache and
chroot_install-packages need to append something to the end of the name
depending upon which pass/action mode the script is being executed with.
- furthermore in the bootstrap_cache case one of the filenames is used
within the bootstrap_debootstrap and thus needs very careful handling
to be certain that a change in filename of bootstrap_cache does not
break bootstrap_debootstrap.
Gbp-Dch: Short
|
|
- avoid all need to pass ".build/" path in stage file names into the
functions
- add a helper to remove a stage file (required to complete the above
properly)
- avoid duplicating filenames within scripts which makes them prone to
mistakes (some instances of which I've actually encountered and had
to fix)
Gbp-Dch: Short
|
|
missed in c55eb8a0c3ca5b8ed1081e7eb8a423563288fb58
Gbp-Dch: Ignore
|
|
all vars affected have been carefully checked to be quite certain
that they are definitely local
where variable is assigned the return value of a function/command, the
local "declaration" is deliberately done on a separate line, since
`local FOO` is actually treated itself as a command rather than a
declaration; will thus always cause $? to be zero, and thus if done on
the same line as such an assignment can not only clobber $? but in doing
so unintentionally blocks failure of a command from triggering the
expected exit from having `set -e`.
also, from testing, i have found that when assigning "${@}" this must be
done on a separate line confusingly as otherwise an error occurs.
Gbp-Dch: Short
|
|
thus for some reason if one is connected to a tty and the other a file,
we still get colour in the tty by default.
in terms of options, --color and --no-color override both, no granular
ones added since it's not worth it imo.
this is backwards compatible with custom configs setting `_COLOR`.
it could be argued that setting $_COLOR to "false" for the auto non-tty
cases is redundant, which it is, but it doesn't hurt to do so; it ensures
that if anything (inc. 3rd-party hooks and such) rely on it that it
remains correct; and ensures that if anything in the future mistakenly
uses $_COLOR instead of $_COLOR_OUT|$_COLOR_ERR that at least that will
only be broken for the use case of only one of stdout|sdterr being a tty.
Gbp-Dch: Ignore
|
|
...when stdout+stderr connected to a tty (as opposed for example to being
piped to a log file)
very helpful to have colour such that the red/yellow of errors/warnings
can draw the eye to problems.
Gbp-Dch: Short
|
|
necessary to give control when colour is default enabled
Gbp-Dch: Short
|
|
|
|
|
|
Combine the check+create done in each script. (The original functions
are still callable as before, but a new combined `Aquire_lockfile`
function can be called instead, as now used).
Note, a further simplification could be done in removing the passing of
the lock filename in as a parameter since every use of the functions is
with ".lock". The lock functions already have a fallback to ".build/lock"
though. Checking the history, the fallback used to be for a system wide
lock, which was then replaced with this config-tree specific one. As long
as that is not used implicitly by 3rd-party hooks then surely we are free
to change the fallback to ".lock" and further remove passing in a name as
a param...?
history:
db5d2b0dcdae96e712661605e17bc9875e224f9f
0aa8289a3773fd8a3885090b72622c2f95ab099c
Gbp-Dch: Short
Closes: #952918
|
|
previously this was white+bold. the white aspect was dropped since this
would not be sensible for users with a white background for their terminal.
bold however does not have any effect for me at least so effectively there
is no highlighting at all.
here we reintroduce a colour, one that will work for both black and white
backgrounds of course. purple looks good to me - significantly different
to that used for errors and warnings, and works well with command
highlighting (as enabled separately).
|
|
if a script exits due to a failure and `set -e`, we should ensure that an
error message is printed to be clear to the user that something actually
went wrong.
similarly it would be good to print a suitable message should the user
cancel with ctrl+c for instance.
Gbp-Dch: Short
|
|
(part of never completed side-by-side multi archi support)
Several scripts make a call to a function called Check_multiarchitectures,
the purpose of which is to adjust the target directory that certain 'live'
and 'install' files are located in. The idea is that a script sets up
'DESTDIR', 'DESTDIR_LIVE' and 'DESTDIR_INSTALL' as appropriate and then
the script appends a suitable arch dependant postfix to the directory
name, depending upon the arch currently being targetted. This would allow
the script to be run multiple times, each for a different architecture.
This is a part of an implementation of allowing multiple architectures to
sit side by side within the same live image, selectable from the
bootloader menus. (As opposed to multiple architectures mixed within the
same userland).
This is evidently the case both from the fact that:
1) The arch specific postfix chosen in that function depends on a var
called LB_CURRENT_ARCHITECTURE, which is never set. In fact going
back through the git history to the introduction of the function in
0d5ff4ca7596790f853cf637e0fe225cad810a76, the var (even considering
var name changes) has never been set by anything. So effectively the
call to the function has been entirely redundant all this time.
2) The major build stages do not perform multiple executions of substages
per arch. Thus from this perspective it seems that the support was
never fully implemented.
3) If any doubt remained, there is an old branch called 'tmp-multiarch'
which has a couple of commits making progress with completing support,
such as implementing the above missing pieces.
The above mentioned branch is 10 years old and can be considered abandoned.
It is not clear whether the original author ever intended to complete and
merge this; nor is it at all clear at what stage of completion it was at.
At any rate, imo it is not at all particularly useful to have extra code
and complexity in order to be able to cram multiple environments side by
side in one image, not when CDs/DVDs and even to some extent USB pen drives
are so cheap. And who really needs more than one environment so
desperately on just one such medium.
If this was not enough to justify removal, then there is also the fact that
the support that was implemented has become completely broken over the
years with scripts diverging in terms of the variable names the function
modifies such that they are incompatible with it.
A quick assessment of the state of this latter aspect:
good:
- grub-legacy uses the correct var names so is fine
- memtest similarly good
- installer_debian-installer looks okay
questionable:
- binary_linux-image uses the correct vars but might not select the
right kernel and initrd files to copy (seems to copy all)
bad:
- grub-pc is making a redundant call, after functionality was moved
to the loopback script
- loopback is using the wrong vars (INITFS instead of DESTDIR +
DESTDIR_INSTALL + DESTDIR_LIVE), plus is doing its own amd64+i686
thing anyway, so the function call would achieve nothing anyway.
- syslinux is also using the wrong var names so would not work with
it and is not even making the necessary function call. Also the
install paths are fixed in the hard coded cfg files anyway so this
would need addressing with placeholders and sed replacement, but
then it is not entirely clear how things should work with respect
to install entries and multi-arch anyway, are we having multiple
copies of the installer, one for each target arch and then multiple
copies of the install menus, perhaps under different submenus?
So, this removes the artefacts of this never completed feature.
Gbp-Dch: Short
|
|
all echo helpers are used as logging functions with output to go to the
terminal. when used in functions that are designed to return a string
though the message printed would get incorrectly captured.
the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was
stupidly flawed; somehow my testing led me to mistakenly believe that
was adequate, but retesting proves that it was not.
here we create a new FD #3 linked to stdout to output the messages on,
which testing shows works as I had actually intended it.
e.g. here:
```
Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; }
```
we get:
```
~$ Foo a
foo
~$ Foo b
error
~$ XX="$(Foo a)"
~$ echo "${XX}"
foo
~$ XX="$(Foo b)"
~$ echo "${XX}"
error
```
and as demonstrated, "error" got incorrectly captured by in the variable
whereas here:
```
exec 3>&1
Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; }
```
it is different in the last case:
```
~$ XX="$(Foo b)"
error
~$ echo "${XX}"
```
the error successfully makes it to the terminal, and the variable is an
empty string (with a newline automatically printed).
Gbp-Dch: Short
|
