On Thu, 2020-03-12 at 11:50 +0900, John Crawley wrote: > On 2020-03-12 11:41, jnq...@gmail.com wrote: > > On Thu, 2020-03-12 at 11:11 +0900, John Crawley wrote: > > > On 2020-03-02 07:12, jnq...@gmail.com wrote: > > > > Package: live-build > > > > Version: 1:20191221 > > > > Owner: jnq...@gmail.com > > > > Severity: minor > > > > > > > > there are lots of checks being done that tools are available > > > > and > > > > executable. this is done with a mixture of use of `which` and > > > > fixed > > > > paths, redirection of output to /dev/null (`2>/dev/null`) and > > > > redundant > > > > executability tetsing on top of `which` checks (which already > > > > does > > > > such > > > > a check). > > > > > > > > this can be tidied up and robustified. > > > > - we can move everything to `which` and drop fixed paths, > > > > thus > > > > robustifying things should a bin every move (you never know). > > > > - we can drop performing pointless `-x` testig on top of > > > > `which` > > > > use, > > > > since `which` already performs this and signals such in its > > > > exist > > > > code > > > > (returns 1 if nonexistant or nonexecutable). > > > > - we can drop the `2>/dev/null` redirection which in my > > > > testing > > > > seemed > > > > to make no difference. > > > > > > > > proposal: switch to conditionals of the form: > > > > ``` > > > > if [ $(which dpkg) ]; then > > > > #whatever > > > > fi > > > > ``` > > > > > > The use of 'which' is not universally regarded as robust: > > > depending > > > on > > > the environment it can return true even if the executable does > > > not > > > exist, and may also output an error message, breaking the above > > > test. > > > > oh really. that's disappointing :/ > > > > > POSIX has 'command -v <command>' which should work under the > > > #!/bin/sh > > > shebang that live-build scripts use: > > > if command -v dpkg >/dev/null > > > then > > > echo "we have dpkg" > > > fi > > > > > > See: https://mywiki.wooledge.org/BashFAQ/081 > > > > yeah I actually came across the `command -v` solution a few days > > ago > > but with the `which` based solution already in place saw little > > value > > in reworking it. if `which` is flakey though, then perhaps its > > important that we do change. > > > > i've got rather a lot of stuff still to work on on live-build > > already > > never mind anything else. would you have time to submit a patch > > yourself? > > > Time, yes probably, but I'm not a Debian developer, just a user (of > live-build too) and - rightly - don't have write access to the repo. > If, given that status, there's anything I can do which would help, > please say. Does salsa support "pull requests" ala GitHub?
I'm not a DD either, nor have my own access rights to the official repo, I'm just making a lot of contributions currently. yes, you can create an account on salsa (which is a Debian hosted copy of gitlab), you can use your existing gitlab (or even github i think) credentials for this. you can then fork, create a branch, create a commit, push the branch to your salsa fork, then create a merge request on the official Debian Live repo and someone will take a look. it's a hell of a lot nicer than emailing patches as I was doing back in 2015, the last time i worked on live-build.
