(mirror of https://github.com/vyos/vyos-live-build.git) https://git.amelek.net/vyos/vyos-live-build.git/atom?h=current 2020-05-05T18:55:28+00:00 2020-05-05T18:55:28+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-05T15:45:57+00:00 urn:sha1:18eefdd6f38631e15e56a2bd7a25bba50b05acfa it removes one or more, so should be plural for clarity Gbp-Dch: Short 2020-05-05T18:55:28+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-05T15:42:44+00:00 urn:sha1:919a464b64b4bda52a56b8732ea5ef7727649cf0 it installs one or more, so should be plural for clarity Gbp-Dch: Short 2020-04-23T16:54:31+00:00 Lyndon Brown jnqnfe@gmail.com 2020-04-06T17:43:41+00:00 urn:sha1:83d9145257220d39e487021e993344adafe71b8a 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 2020-04-23T09:38:01+00:00 Lyndon Brown jnqnfe@gmail.com 2020-04-01T09:04:19+00:00 urn:sha1:8c0e802d139a6c4e79566e019d3ebe38b8a4a6f5 there are additional instances in binary_* scripts that are left here because they are covered by changes in MR #157 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-12T10:31:39+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-11T18:43:12+00:00 urn:sha1:1e0339a4e36f85f468ecbdc21c645541f51e5e56 677415f6d7efc1e5b888570d70af311d2900c69c (2007) in v1.0~a2-1 added a hack relating to the loop-aes-utils package and losetup. this commit bundled a bunch of changes, it was not specific to the hack, and so info about the hack is limited to a brief comment included within the related change in defaults: ``` # Workaround for loop-aes-utils divertion # (loop-aes-utils' losetup lacks features). ``` though it is very similar to the removed fdisk hack in that it seems that one package may replace a binary from another, moving the original to a new location, and this hack gives the user the opportunity to select the original instead of the one put in its place, for use in LB. the comment mentions a package called loop-aes-utils as being the package that performs such a diversion, and that the need for the hack was that losetup itself lacked features, presumably encryption support, and it is clear that it is the losetup binary that is the focus of the diversion. looking into the history of loop-aes-utils a little, this package was dropped from debian back in 2012 (#680748), favouring encrytion support of dm-crypt/cryptsetup. double checking file contents of packages, only the mount package carries an /sbin/losetup file, so presumably this means that dm-setup/cryptsetup do not perform such a diversion of losetup (i.e. their use is exclusively done directly). since the possible diversion is simply gone, that completely removes any point in having the hack of giving users choice between losetup and the diverted one. so let's remove this obsolete hack...