(mirror of https://github.com/vyos/vyos-live-build.git) https://git.amelek.net/vyos/vyos-live-build.git/atom?h=current 2021-08-02T14:15:21+00:00 2021-08-02T14:15:21+00:00 Kim Hagen kim@sentrium.io 2021-08-02T14:15:21+00:00 urn:sha1:d70a3f5e86f37abe657c13d16ccc081832356d40 2021-01-11T13:34:11+00:00 Roland Clobus rclobus@rclobus.nl 2021-01-11T13:34:11+00:00 urn:sha1:831da55c0114c4dbb4f81b33c0b03addeacece4b 2020-05-30T21:11:45+00:00 Ryan Finnie ryan@finnie.org 2020-05-30T21:11:45+00:00 urn:sha1:13cf0e9ebe30a5af217ef5c64c550b64a92bcaf9 Note that this does not include grub-ieee1275 support so the images will not be bootable, but it's a first step and produces ISOs without error. 2020-04-23T13:54:19+00:00 Lyndon Brown jnqnfe@gmail.com 2020-04-01T09:58:47+00:00 urn:sha1:6cc72509541404dc0af57bf2b29dfaaa1ee3e1a4 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 2020-03-17T22:59:37+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-15T13:05:44+00:00 urn:sha1:fb0790cc4379280084cc9a4469a515e243f45b9b 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 2020-03-17T18:57:02+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-13T17:11:53+00:00 urn:sha1:fe9195b59c9647598ecea00900edfe2678bddcac 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 2020-03-17T18:57:02+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-12T01:21:39+00:00 urn:sha1:04d9ee0211e7cf2d5f637941ff6579b4f5462da6 - 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 2020-03-13T16:19:59+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-13T16:19:59+00:00 urn:sha1:a46985b08ac8b8c73d8a3965ee83daa4d4c41e22 Gbp-Dch: Ignore 2020-03-13T15:37:38+00:00 jnqnfe jnqnfe@gmail.com 2015-02-05T03:30:47+00:00 urn:sha1:b27927724a5da017796d16de47979116d01455dc 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 2020-03-13T13:56:21+00:00 jnqnfe jnqnfe@gmail.com 2015-01-18T20:39:36+00:00 urn:sha1:a6cc72bf6d2c27c8f10546085ed6a6a295b248cc (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