(mirror of https://github.com/vyos/vyos-live-build.git) https://git.amelek.net/vyos/vyos-live-build.git/atom?h=master 2020-05-04T12:21:12+00:00 2020-05-04T12:21:12+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-04T12:21:12+00:00 urn:sha1:7acd1f488f3b9d4348449a27d9412488dc8e1657 Gbp-Dch: Ignore 2020-05-03T00:38:17+00:00 Lyndon Brown jnqnfe@gmail.com 2020-05-03T00:25:55+00:00 urn:sha1:7276d0213fd26ee68b62b84080261e29512871e9 - the definition of $PROGRAM as used in $USAGE strings defined in each script has been broken for a long time, being simply "lb" when it needs to be "lb COMMAND". - `config` changed $PROGRAM to "lb config" thus its output was correct in this regard unlike everything else, but with the switch to a more "intelligent" `Man()` function recently, it means that instead of `man lb config`, what was actually run was `man lb config config`, which displayed the manpage, then on exiting with `q`, it showed some sort of index line todo with a "config" search (no exact manpage match?), for which you had to enter `ctrl+c` to get rid of. this revises things to fix the issues, minimising change by changing $PROGRAM to "lb COMMAND", with the frontend overriding this. Gbp-Dch: Ignore 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-29T18:03:58+00:00 Lyndon Brown jnqnfe@gmail.com 2020-04-29T18:00:40+00:00 urn:sha1:1374e82e24aead5c827b49dd7a37e8d14dc7bf41 trying to use `lb --debug config` for instance did not output debug info unlike `lb config --debug`. Gbp-Dch: Ignore 2020-04-24T14:24:01+00:00 Raphaël Hertzog hertzog@debian.org 2020-04-24T14:00:05+00:00 urn:sha1:55d9b213cfaa55f6be0ce9d803e3603dfbf87dd7 2020-04-24T13:37:13+00:00 Raphaël Hertzog raphael@offensive-security.com 2020-04-23T20:17:23+00:00 urn:sha1:104fa2039990f17e02dd9d2dbfc801763987b532 This reverts commit 6b7c8ed4bf15175299729355f04d60dcbac1aded as it's breaking multi-value space-separated parameters. 2020-04-23T20:30:43+00:00 Raphaël Hertzog raphael@offensive-security.com 2020-04-23T20:26:52+00:00 urn:sha1:440c0b7738cbbcd2fa2dd948ab201d40e23db074 This is a recipe for disaster and it actually already fails when you pass something that looks like a long option as first argument because $(which --long-option) will produce an "Illegal option" string on its standard output. $ lb --debug config --archive-areas "main contrib non-free" Illegal option -- /usr/bin/lb: 54: [: Usage:: unexpected operator E: Unknown command: --debug 2020-04-23T14:38:59+00:00 Raphaël Hertzog hertzog@debian.org 2020-04-23T14:38:59+00:00 urn:sha1:4c75f80e6763490d5bcb0e0a460b096a3292ae61 2020-04-23T14:32:26+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-30T16:32:07+00:00 urn:sha1:b3bba232ac6e1feff9e506506247aa20cd7f467c thus it can correctly indicate success/fail status instead of always indicating failure. when a user asks for usage with -u|--usage then we should exit in success mode rather than failure as when usage in printed in response to incorrect usage. Gbp-Dch: Short 2020-04-23T14:29:00+00:00 Lyndon Brown jnqnfe@gmail.com 2020-03-18T01:51:53+00:00 urn:sha1:6b7c8ed4bf15175299729355f04d60dcbac1aded this means that the usage goes from: lb {-h|--help|-u|--usage|-v|--version} lb COMMAND [OPTIONS] to: lb {-h|--help|-u|--usage|-v|--version} lb [FRONTEND_OPTIONS] COMMAND [COMMAND_OPTIONS] though it is probably not worth is to update the description in the manpages...? hmm... so for instance this matters for color control with --color|--no-color (you already had full control via environment vars). previously you could do `lb COMMAND --no-color` to turn off colour, only to find that output at the frontend level was still coloured (the option is processed at the command context level, not the frontend), so you might try to instead use `lb --no-color COMMAND`, only to find that this was not supported. Well now it is, and used at the frontend level will fully control colour output (after the command is processed anyway). the full set of common options are thus available (except --force) at the frontend level, and thus for instance all Echo_*() helpers used in the frontend will work correctly after args are processed. furthermore usage like `lb --color --help` will actually work. (not that color is used there, but this previously would have failed with the frontend treating the `--color` argument as the command; that's the point!) Gbp-Dch: Short