(mirror of https://github.com/vyos/vyos-live-build.git) https://git.amelek.net/vyos/vyos-live-build.git/atom?h=master 2020-04-23T13:46:43+00:00 2020-04-23T13:46:43+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-28T13:05:27+00:00 urn:sha1:3d2b280c8f44fe8b5fe52fdd0622f4e044ca98da 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-20T10:19:33+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-19T00:19:26+00:00 urn:sha1:945a166f75f7bf0419a7caefa7e7337119732929 progress-linux, as discussed in MR #142 ([1]) is a little known distro, which appears to be little more than a personal project of the original author of live-build. given that, the expense of maintaining all of these old hacks for it cannot be justified. it is not known whether or not live-build is even used with respect to it since the author abandoned live-build some years ago. also, at least one past change in live-build possibly broke progress-linux compatibility anyway, which would have required progress-linux users of live-build to use a custom progress-linux config, or a progress-linux fork of live-build, and there is no knowing how much of the hacks in this "upstream" codebase any user of progress-linux currently relies upon. and again, progress-linux appears to just be a personal project of Daniel's, with afaik very little userbase. (Daniel seems to be the only developer working on the project which speaks to how small it is). [1]: https://salsa.debian.org/live-team/live-build/-/merge_requests/142 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-15T21:54:37+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-14T00:46:46+00:00 urn:sha1:00a2fabcdf3e6c3021b8392a404ab7d068571250 Gbp-Dch: Ignore 2020-03-15T21:54:37+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-14T00:46:46+00:00 urn:sha1:a67febdd824c553dddca11276f0d74096697223b Gbp-Dch: Ignore 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