(mirror of https://github.com/vyos/vyos-live-build.git) https://git.amelek.net/vyos/vyos-live-build.git/atom?h=rolling 2020-05-02T12:06:17+00:00 2020-05-02T12:06:17+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-02T12:05:03+00:00 urn:sha1:5f318c5a444ef05bdf79b1f7640294c7423fd10e - it's only used by the debootstrap script after alternatives were dropped long ago, so let's move it, avoiding it being loaded for everything else. - there's no need to pass printing another message through it. - there's little point in making the sid distinction if you happen to decide to build sid, it's a given that it's less stable than stable. really, is there any need for this at all? Gbp-Dch: Ignore 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-16T13:32:16+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-13T18:36:26+00:00 urn:sha1:ca520eb5f0556094338e0c841dcaa970d9a28886 thus for some reason if one is connected to a tty and the other a file, we still get colour in the tty by default. in terms of options, --color and --no-color override both, no granular ones added since it's not worth it imo. this is backwards compatible with custom configs setting `_COLOR`. it could be argued that setting $_COLOR to "false" for the auto non-tty cases is redundant, which it is, but it doesn't hurt to do so; it ensures that if anything (inc. 3rd-party hooks and such) rely on it that it remains correct; and ensures that if anything in the future mistakenly uses $_COLOR instead of $_COLOR_OUT|$_COLOR_ERR that at least that will only be broken for the use case of only one of stdout|sdterr being a tty. Gbp-Dch: Ignore 2020-03-13T15:23:13+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-11T22:05:27+00:00 urn:sha1:346e3e1c36f8dc61e93fdd76dd28174d85e2aa5d previously this was white+bold. the white aspect was dropped since this would not be sensible for users with a white background for their terminal. bold however does not have any effect for me at least so effectively there is no highlighting at all. here we reintroduce a colour, one that will work for both black and white backgrounds of course. purple looks good to me - significantly different to that used for errors and warnings, and works well with command highlighting (as enabled separately). 2020-03-13T13:50:35+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-07T02:33:08+00:00 urn:sha1:c54cc2c497977d5234a8ea6eb39deb09f0286546 all echo helpers are used as logging functions with output to go to the terminal. when used in functions that are designed to return a string though the message printed would get incorrectly captured. the previous fix done in e3a987d977aaa417afe74349fa4d97dd6afc1c94 was stupidly flawed; somehow my testing led me to mistakenly believe that was adequate, but retesting proves that it was not. here we create a new FD #3 linked to stdout to output the messages on, which testing shows works as I had actually intended it. e.g. here: ``` Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n"; fi; } ``` we get: ``` ~$ Foo a foo ~$ Foo b error ~$ XX="$(Foo a)" ~$ echo "${XX}" foo ~$ XX="$(Foo b)" ~$ echo "${XX}" error ``` and as demonstrated, "error" got incorrectly captured by in the variable whereas here: ``` exec 3>&1 Foo () { if [ "$1" = "a" ]; then printf "foo\n"; else printf "error\n" >&3; fi; } ``` it is different in the last case: ``` ~$ XX="$(Foo b)" error ~$ echo "${XX}" ``` the error successfully makes it to the terminal, and the variable is an empty string (with a newline automatically printed). Gbp-Dch: Short 2020-03-11T13:51:19+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-11T10:07:21+00:00 urn:sha1:7a4a9f94b89d22c083c1610ecbcb7a173f1b73db Current versions of the project files are built upon versions published and licensed by Daniel Baumann, but are modified copies of those files and thus need to be marked as such per licensing requirements (afaik he did not pass along ownership / licensing rights to anyone when he left the project). We should also be careful to not be misrepresenting such modified copies as being attributed to Daniel. Adding a new copyright line referring to "The Debian Live team" should suffice for this. The authorship block in man pages has also similarly been updated. Notes: - tweaked a copy of daniel copyright lines stating 2014 instead of 2015. both of these cases were in files that i had personally introduced in some of my past merged commits that moved some code around. i don't know why they stated 2014. - binary_onie was introduced in 2018, so that has a 2018 date instead of 2016 unlike the rest. - 'efi-image' is a 3rd-party (Canonical Ltd) work that we bundle, but it has been modified by 674794a8f4d61a729d2dbd6d99385d2826138694 and 36a3ba76347ef72df1c316312ed3a26aa4b0c816 so I similarly added a debian live copyright line. - 'grub-cpmodules' is similar. it was only changed by the indentation fix of 36a3ba76347ef72df1c316312ed3a26aa4b0c816 but modification is modification, and this does help cover any possible future changes that might be made. 2020-03-09T12:52:08+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-07T08:50:52+00:00 urn:sha1:62b3efa6869a79b0f134203f87fbc9234b0d9d4d white is not going to work well on a terminal with a white background, obviously. We should keep the standard colour and just try applying the bold. or do we want to consider a non black/white colour? like blue...? Gbp-Dch: Short 2020-03-09T12:47:08+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-07T05:57:15+00:00 urn:sha1:a6c4094cf02fb0458cf8af204cd4abceae20c980 2020-03-05T21:04:23+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-01T03:49:57+00:00 urn:sha1:cac44b28d5699c4e6733310b1f8b4968e09a2854 Gbp-Dch: Ignore 2020-03-05T21:04:23+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-01T03:00:29+00:00 urn:sha1:73c1100c01da680a2d9f57aa26e48e6dc808fdf6 Partial fix for #952880 Gbp-Dch: Short