@all: Raphaël agreed that it would be useful to him to get an overview of where I'm heading with the large volume of work I'm submitting for live-build. He asked that I submit it to the list. Please bare in mind that this work is subject to review and acceptance by himself and/or Luca, as much as they can spare time to do so.
@Raphaël: appologies for the delay, here is the overview we spoke of the other day. I was originally writing it directly into this mail, but ended up hosting it here as a task list: https://salsa.debian.org/jnqnfe/live-build/-/wikis/todo-list @Raphaël: you can stop reading here if you like, the below is just for the benefit of everyone else in the list... @everyone-else... Intro & merged ============== I thought that it might be a good idea, or of interest to some, to give a quick intro and overview of user facing changes accomplished so far, to be found in the next release. Read on if indeed interested. Some of my work dates back to ~2014/2015 following my discovery of live-build and starting to look at its codebase; I'd become pretty familiar with much of it back then, sending out various patches to the original maintainer, who seemed fine with my doing that work but was slow to look at it and a large amount ended up being left unmerged by the time he abandoned the project not very much later, by which time I'd moved on to other things for while. Recently I've returned and resubmitted a big chunk of that work that I'd been maintaining privately for personal use. Most of that has now successfully been accepted by the current maintainers. I've also basically picked up where I left off in 2015 continuing my development work, with a bunch of new stuff submitted and accepted along with the old stuff. A lot has been crossed off my to-do list for this project. A lot more remains though. This work encompasses bug fixes, feature enhancements, and refactoring. I've been working intensly hard churning out a lot of work, which of course requires time of the team members to review. How much I can accomplish, particularly of the latter type, is thus subject to the patience and good will of the team who have to put effort in also on their end. FYI I have no financial or corporate backing, I'm simply just doing all of this off my own back. I'm very much appreciative of Raphaël and Luca for the work they've been putting into reviewing it all and their patience with me in perfecting things. Here's a brief highlight of the most notable enhancements that have been merged for the next release already (those of mine). (Particularly focussing on user facing changes rather than internal ones). In no particular order: - Updated and enhanced manpages. - Big step forward with performing basic validation of config values. - Addition of `--validate` option to `lb config` which helps you to check validity of your config (as combined from saved, auto, and command line), without saving new config. - Improvements to expressing successful completion and failure of the build. - Finished enabling of colour in the output and enhanced its use (optional, default enabled for tty only output). - Improved bootloader customisation - now you only have to provide in your config the files you want to add/replace, rather than a full copy of the bootloader-specific files. - Furthermore grub-pc/grub-efi menu construction has been modified to extract a lot of stuff to preprepared files like syslinux, making customisation easier. (Backwards compatibility is preserved). - Avoiding adding of graphical install, or any install, bootloader entries when not wanted per user config, rather than having dead entries. - Expansion of install menu entries to the full set provided in official Debian 7 install discs (this was from 2015 work), and expanded use of hotkeys. (Note more entries to be added as mentioned below). - The previous item includes addition of a speech synthesis (accessibility) install bootloader entry, with addition of more such entries pending. - An attempt to hide temporary mountpoints from popping up in nautilus during the build (imperfect, requires debootstrap to also fix, and then maybe a bug to be filed on nautilus if it still persists, but their appearance is greatly reduced in my testing). - Removal of long obsolete hacks and disabling of various long obsolete options (for which a warning is given, no breakage, don't worry!). - Reduced reliance on perl for grub2 menu creation. (To be completely removed). - Fix for removal of auto-installed packages installed during build process. - Fixes to using grub2 bootloaders without syslinux. - Fix for broken undocumented config/environment[.binary] feature (only config/environment.chroot worked). - Addition of a new `chroot_prep` helper for bulk execution of "chroot preparation" scripts, which will be of interest to anyone taking a dive into manually executing component stages (mostly only of interest to developers). - Fix for the differently formatted config/build config file, that originated from a partially completed transision to a new format long ago (reverted the partial conversion since it was confusing and far less efficient). - Security fix for permissions of copied `/etc/resolv.conf` file (kudos to @Tails guys for reporting). - Enhancements to support both space or comma separated lists of items for some multi-item options (e.g. `--bootloaders syslinux,grub-efi` and `--bootloaders "syslinux grub-efi"` will both work). - Tidier saved config files, with one particularly notable change of no longer printing misleading 'defaults' data which was actually just a copy of the values (not feasable to print actual useful defaults data). - Rename of `--architectures` to `--architecture` (though the old name still works) to reflect correctly that it only carries a single architecture, thus reducing potential confusion. - Many, many fixes and internal code improvements I won't list here. You'll of course find all of this in the changelog when the next version is released, and for a complete detailed list of course please look to the git repo. For the list of work I'd still like to get done, see the link given at the start of this mail. Helping ======= If anyone was inclined to do some work testing things to spot any regressions slipping through, that might be helpful. Doing test builds takes significant time and thus it can be difficult to get sufficient coverage. I don't want to have broken anything in the next release. By all means point out further issues to me (other than what's already in the todo list), which if at all possible I might very well add to the list if I can understand, agree with them, and feel I might be able to address (best to typically record properly in the bug tracker). Lyndon. Please consider supporting my work? My links below. (please also consider the team's work reviewing my work) https://liberapay.com/jnqnfe/donate https://www.patreon.com/jnqnfe https://www.buymeacoffee.com/jnqnfe
signature.asc
Description: This is a digitally signed message part
