There is a file conflict in the non-free-firmware realtek packages,
which prevent the sid live images from being built.
This workaround will be removed a soon as the bug is resolved.
* 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
Moved includes.chroot to includes.chroot_after_packages and added
includes.chroot_before_packages. includes.chroot does still work as before.
We also now use rsync for copying files if it is installed.
This improves runtime and space consumption for large includes.
Gbp-Dch: Short
Closes: #927128
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"...).
some scripts temporarily install packages to accomplish some work before
then removing them. the list of packages installed is kept in memory in a
variable.
a weakness of this design is that if a failure occurs or the user cancels,
and then following this the user re-runs `lb build`, letting it try to
pick up and recover from where it left off, that list of packages that had
been installed is lost, resulting in those packages that were installed
then being a permanent part of the chroot.
here we fix this weakness by backing up the list to a file, which is always
read from on removal. thus in a recovery situation, any packages still
installed from a situation like that just described, will be removed upon
the next use of `Remove_package()`.
this is not perfect, since we are having to wait for opportunistic
execution of the remove function. we need to find a suitable place for the
`Cleanup_temp_packages()` function to be used.
- doing so in `Init_config_data()` would not be suitable because we don't
hold the lock when that's run, even if we ignored the hijacking of that
function for taking such action...
- doing it in `Exit()` doesn't seem a good fit either.
- putting it explicitly in every build script just seems a little messy...
perhaps a local exit trap like for removing the lock...?
note that `binary_rootfs` skips running the remove function after installing
tooling, since it just throws the wrapper chroot away, which then leaves the
file around with stale data for the next remove instance to pick up, which
then does not actually remove it because it's not installed. this is not
ideal either... perhaps the optimisation should be removed from that script?
Gbp-Dch: Short
Roland Clobus
Nick Brown
Unit 193
Ryan Finnie
Luca Boccassi
Luca Boccassi
Unit 193
Jan Kot
Thore Sommer
Raphaël Hertzog
Lyndon Brown