* zsync was orphaned 2021-09-19 #994648
* zsync FTBFS with GCC-14 #1075710
* zsync was only available for iso and iso-hybrid
* zsync output is ignored by the live-setup package which generates the
official live images
Work together with Emanuele Rocca during MiniDebCamp Hamburg 2024
* rebuild: New command line option: --architecture
* installer: Enable the GTK installer
* bootloader: Set a default bootloader
* no qemu-binary in chroot
This makes the default value of --parent-debian-installer-distribution
the same as --debian-installer-distribution, like the other
--parent-distribution-* options.
This previously undocumented value for '--chroot-filesystem' creates the
uncompressed folder 'live/filesystem.dir'.
This will speed up the generation of live images a lot, because the
squashfs compression is skipped.
Example command line:
lb config -b hdd --chroot-filesystem plain --binary-filesystem ext4
Notes:
- No bootloader is configured; images must be booted via direct kernel
- Tested via qemu + opensbi fw_jump.elf + kernel/initrd
- As riscv64 is currently in ports, the following options are required:
--distribution unstable
--mirror-bootstrap http://ftp.ports.debian.org/debian-ports/
--security false
--debootstrap-options --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg
- Normally ports require stacking two dists, unstable and unreleased.
debootstrap does not support doing this, but as of this writing, there
is nothing in riscv64 unreleased which is required to bootstrap.
However, this would not have been possible a year ago.
There are two main scenarios:
1) The host with live-build is configured to use a proxy
This proxy will automatically be used by live-build
2) The user of live-build explicitly specifies a proxy
2A) With the environment variable 'http_proxy' (preferred)
2B) With the command line option --apt-http-proxy
Any inconsistency in the setting of a proxy results in an error message of 'lb config'
All internal tools (apt/apt-get/aptitude, wget and debootstrap) use the environment variables 'http_proxy' and 'no_proxy', which are passed along to the chroot where needed.
Test scenario:
- A virtual machine with all out-going traffic blocked, except for the proxy.
MR !173 removed the export of several variables moving/renaming them.
Continue to export both the new name and older compatibility name.
Closes: #992572
1) lb config rejected multiple checksum types
2) When using the installer, cdrom-checker requires a md5 checksum file,
use 'Check the integrity of the installation media' in the installer
3) The comments in the first lines of the checksum files caused
cdrom-checker to fail the integrity of the image
We want to be resilient to small network hiccups and when you download
a large number of packages, the probability of a network hiccup are
increasing... as are the chances of hitting one of the apt bugs
(cf "Undetermined error"...).
the design choice from when EFI support was introduced was to change
`--bootloader` to `--bootloaders`, with users specifying their selection
of BIOS and EFI bootloaders together. at this time there were not even any
decent validation checks being performed, and invalid combinations could
cause some chaos.
since then proper validation was put in place, including checking that
only a single instance of each of BIOS and EFI bootloaders exists in the
selection.
here we tweak things such that we stick with the same option, but we split
the selection up such that we store the BIOS and EFI selections separately
within the saved config file, and offer it up to scripts to help simplify
those scripts.
we must however retain support for splitting from the combined option,
both because we still use it in the combined option, and for backwards
compatibility with older saved configs.
Gbp-Dch: Short
thus far, config bootloader validation only did the basic check that each
bootloader specified was a known and supported bootloader, it did not check
combinations.
it now checks combinations, and strips out the previous "bootloader role"
stuff.
the no-bootloaders warning is duplicated, covering two slightly different
situations (empty string, and whitespace string). this is anticipated to
be just temporary, with this just being the first step in better handling
bootloader selections.
Gbp-Dch: Short
The core purpose of `Prepare_config()` is to prepare the config by setting
defaults where not specified. It should not be involved itself in
validation of user options.
This can be an important distinction, for instance in `clean` where we
use this function, but avoid validation to potentially allow for an option
that deletes the config, that should work even in the face of an invalid
config.
Gbp-Dch: Ignore
using `$VERSION` as part of the default `$LB_ISO_PREPARER` means that when
you simply run `lb config` once, this variable is stored as a part of the
string, and replaced on use, but if you run `lb config` twice, it gets
replaced with a fixed version, that is then used in all subsequent builds.
let's replace with a placeholder (`@LB_VERSION@`) that can be used both in
the default, or in user strings, and will be replaced on use only.
this means that subsequent builds will always reflect the actual version
of live-build used.
Gbp-Dch: Ignore
`DATE_UTC_OPTION` is set in `Prepare_config()` for use by scripts, even
though only a few scripts will actually use it, since it allows those
scripts to be cleaner. we may want to possibly extend this as a
`DATE_OPTIONS` variable perhaps as part of enabling proper reproduciblity.
Gbp-Dch: Short
This is considered to be more robust.
Two instances remain:
scripts/build/chroot_archives, line 257:
if [ "${LB_APT}" = "aptitude" ] && [ ! $(Chroot chroot "which aptitude") ]
The command is run inside a chroot where the environment might be special,
and would need further testing.
manpages/Makefile, line 42:
@if [ ! -x "$$(which po4a 2>/dev/null)" ]; \
I am insufficiently familiar with makefile syntax to edit this.
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 44b9b0a650, 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
this was previously not done in 8b109ffb96
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
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
Roland Clobus
Nick Brown
Ryan Finnie
Unit 193
Raphaël Hertzog
Lyndon Brown
johnraff
Raphaël Hertzog