(mirror of https://github.com/vyos/vyos-live-build.git) https://git.amelek.net/vyos/vyos-live-build.git/atom?h=rolling 2020-06-01T14:49:56+00:00 2020-06-01T14:49:56+00:00 Ryan Finnie ryan@finnie.org 2020-05-31T18:57:08+00:00 urn:sha1:56186add3c47969678b74ce956c32d0dc9600e04 2020-05-04T22:22:10+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-04T22:19:58+00:00 urn:sha1:7cf7f74bc0570beedbea4b085fc799653a87c86e Gbp-Dch: Ignore 2020-05-04T22:22:10+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-04T22:15:52+00:00 urn:sha1:8a1bbe0841ced044444ebf4d7f2b44a689b9c26b Gbp-Dch: Ignore 2020-05-04T22:21:44+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-04T22:11:27+00:00 urn:sha1:08c86dc8ace433bd1efacc807357dc92661510ab - the comparison with LB_ARCHITECTURE seems to be based upon an old idea of it potentially being intended in the past to hold more than one arch (when it's name as also plural), but it in fact only holds one. - similarly LB_BOOTSTRAP_QEMU_ARCHITECTURE is singular, so the comparison with the set of params is bad. - storing $@ in a variable before then looping is not a good idea - script name was not being passed to the warnings - can simplify by just returning in the valid case i'm very suspicious about the correctness of the qemu bits, but that can wait for now. Gbp-Dch: Short 2020-05-01T09:59:11+00:00 johnraff github@rafflesnagoya.com 2020-05-01T02:23:39+00:00 urn:sha1:0e5d0483e5596e200430d28356b808af76806439 This is considered to be more robust. Two instances remain: scripts/build/chroot_archives, line 257: if [ "${LB_APT}" = "aptitude" ] && [ ! $(Chroot chroot "which aptitude") ] The command is run inside a chroot where the environment might be special, and would need further testing. manpages/Makefile, line 42: @if [ ! -x "$$(which po4a 2>/dev/null)" ]; \ I am insufficiently familiar with makefile syntax to edit this. 2020-04-23T14:00:34+00:00 Lyndon Brown jnqnfe@gmail.com 2020-04-01T10:25:56+00:00 urn:sha1:8ffe48d8f3825a3741deeb0a45e5372b5ed5504c 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-16T22:10:03+00:00 Lyndon Brown jnqnfe@gmail.com 2020-02-20T06:58:11+00:00 urn:sha1:c55eb8a0c3ca5b8ed1081e7eb8a423563288fb58 all vars affected have been carefully checked to be quite certain that they are definitely local where variable is assigned the return value of a function/command, the local "declaration" is deliberately done on a separate line, since `local FOO` is actually treated itself as a command rather than a declaration; will thus always cause $? to be zero, and thus if done on the same line as such an assignment can not only clobber $? but in doing so unintentionally blocks failure of a command from triggering the expected exit from having `set -e`. also, from testing, i have found that when assigning "${@}" this must be done on a separate line confusingly as otherwise an error occurs. Gbp-Dch: Short 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 2020-03-12T12:32:26+00:00 Luca Boccassi luca.boccassi@microsoft.com 2020-03-12T12:32:06+00:00 urn:sha1:015e6b65f3173e16d7ee4c3d9fa407d7ed1c9c45 This reverts commit 2d9ab1f7f82f9a98b97d1503c1e3f31c86061c15. Causes test failure due to bashism.