https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-2897 Lustre <p>If not cleared, the backtrace and bug reporting function gets invoked.<br/> Since calls to fatal() imply an error was detected, it is not<br/> an "uncaught error" but a well-known error.</p> <p>Also a dinkleberry version of "usage()" was left in lbuild.</p> LU-2897

the lbuild "trap 'xxxx' ERR" must be unset before exit

Bug Minor Resolved Won't Fix WC Triage Bruce Korb Fri, 1 Mar 2013 15:47:40 +0000 Fri, 24 Apr 2015 00:36:37 +0000 Fri, 24 Apr 2015 00:36:37 +0000 0 3 <p>Um, wrong web site. Sorry. <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/sad.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>Even so, you are not wrong. Even just running "lbuild -h" trips the trap, dumps backtrace, and tries to send email to whamcloud. So I would say this site is a fine place to discuss and work on the problem.</p> <p>I'm not sure which fatal() issue you are seeing, but I fixed one in <a href="https://github.com/chaos/lustre/commit/dcce9cc80a220cd486305e2d7322a96b3dd3c0d1" class="external-link" target="_blank" rel="nofollow noopener">a commit on github</a>. I have a patch in gerrit to relocate the lbuild files, so I waiting to submit other lbuild changes to gerrit until that one lands.</p> <p>That fix addresses a bug that makes fatal() throw an exception any time a message is not given as an option to fatal(). Perhaps that is the problem you are seeing?</p> <p>That commit and a couple of other lbuild cleanup changes are on my <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a> work-in-progress branch here:</p> <p> <a href="https://github.com/chaos/lustre/commits/LU-1199-wip" class="external-link" target="_blank" rel="nofollow noopener">https://github.com/chaos/lustre/commits/LU-1199-wip</a></p> <p>In that case, a patch is on its way. I've fixed it in the Xyratex sources and presumed that it was me and didn't test the original. (I had made another change to make the configuring of lbuild comprehensible.)</p> <p>Given the utter incomprehensibility of lbuild, I'm a bit surprised that it hasn't been seen before.</p> <p>Anyway, the fix is to have fatal() disarm the uncaught error trap: trap '' ERR<br/> and presto! no problem. And, yes, it is triggered by: [ -n '' ]<br/> resulting in a command failure.</p> <p>The fix I am preparing will also fix inconsistencies between the help text and the command line parsing, remove help text for the two no-op options and document the "extra" dozen configurables for which there are no command line options. I also create this config file template:</p> <p> &gt;# lbuild configuration file (template - rename to '.lbuildrc')</p> <p> &gt;# command line option: -d ROOT | --root-dir=ROOT<br/> &gt;#<br/> &gt;# Specifies the SCM root directory to use when extracting files.<br/> &gt;# ${SCMROOT:<del>${CVSROOT:</del>${GITROOT}}} is used if this option is not<br/> &gt;# present.<br/> &gt;#<br/> &gt;# SCMROOT=${SCMROOT:<del>${CVSROOT:</del>${GITROOT}}}</p> <p> &gt;# command line option: -l LOCALDIR | --localdir=LOCALDIR<br/> &gt;#<br/> &gt;# Specifies local directory with lustre sources.<br/> &gt;#<br/> &gt;# LOCALDIR=</p> <p> &gt;# command line option: --external-patches=PATCHES<br/> &gt;#<br/> &gt;# Directory similar to lustre/lustre/kernel_patches/ that lbuild should<br/> &gt;# look for seres and config files in before looking in the lustre tree.<br/> &gt;#<br/> &gt;# EXTERNAL_PATCHES=</p> <p> &gt;# command line option: --extraversion=EXTRA<br/> &gt;#<br/> &gt;# Text to use for the rpm release and kernel extraversion.<br/> &gt;#<br/> &gt;# EXTRA_VERSION=</p> <p> &gt;# command line option: --timestamp=TIMESTAMP<br/> &gt;#<br/> &gt;# Date of building lustre in format YYYYMMDDhhmmss<br/> &gt;#<br/> &gt;# TIMESTAMP=</p> <p> &gt;# command line option: --reuserpm=DIR<br/> &gt;#<br/> &gt;# Try to reuse old kernel RPMs from DIR<br/> &gt;#<br/> &gt;# REUSERPM=</p> <p> &gt;# command line option: --reusebuild=DIR<br/> &gt;#<br/> &gt;# Try to reuse old kernel builds from DIR<br/> &gt;#<br/> &gt;# REUSEBUILD=</p> <p> &gt;# command line option: --kernelrpm=DIR<br/> &gt;#<br/> &gt;# Path to distro kernel RPM collection<br/> &gt;#<br/> &gt;# KERNELRPMSBASE=</p> <p> &gt;# command line option: --ccache<br/> &gt;#<br/> &gt;# Use ccache<br/> &gt;#<br/> &gt;# CCACHE=</p> <p> &gt;# command line option: --norpm<br/> &gt;#<br/> &gt;# Do not build RPMs (compile only mode)<br/> &gt;#<br/> &gt;# NORPM=false</p> <p> &gt;# command line option: --patchless<br/> &gt;#<br/> &gt;# Build lustre client only<br/> &gt;#<br/> &gt;# PATCHLESS=false</p> <p> &gt;# command line option: --distro=DISTRO<br/> &gt;#<br/> &gt;# Which distro using. Autodetect by default<br/> &gt;#<br/> &gt;# DISTRO=</p> <p> &gt;# command line option: --kernelurl=URL<br/> &gt;#<br/> &gt;# URL for obtaining Linux source tarballs referenced by target files.<br/> &gt;#<br/> &gt;# KERNELURL='http://downloads.lustre.org/public/kernels/$target/old'</p> <p> &gt;# command line option: --kerneldir=KERNELDIR<br/> &gt;#<br/> &gt;# Directory containing Linux source tarballs referenced by target<br/> &gt;# files.<br/> &gt;#<br/> &gt;# KERNELDIR=</p> <p> &gt;# command line option: --kerneltree=KERNELTREE<br/> &gt;#<br/> &gt;# Directory containing dirs with Linux source tarballs referenced by<br/> &gt;# target files. Dir names in format kernel version ('2.6.9', etc.)<br/> &gt;#<br/> &gt;# KERNELTREE=</p> <p> &gt;# command line option: --linux=LINUX<br/> &gt;#<br/> &gt;# Directory of Linux kernel sources. When this option is used, only<br/> &gt;# Lustre modules and userspace are built.<br/> &gt;#<br/> &gt;# LINUX=</p> <p> &gt;# command line option: --lustre=LUSTRE<br/> &gt;#<br/> &gt;# Path to an existing lustre source tarball to use instead of<br/> &gt;# pulling from a source code archive.<br/> &gt;#<br/> &gt;# LUSTRE=</p> <p> &gt;# command line option: --nodownload<br/> &gt;#<br/> &gt;# Do not try to download a kernel<br/> &gt;#<br/> &gt;# DOWNLOAD=true</p> <p> &gt;# command line option: --noiokit<br/> &gt;#<br/> &gt;# Do not build lustre-iokit RPM. Build by default<br/> &gt;#<br/> &gt;# IOKITRPM=true</p> <p> &gt;# command line option: --release<br/> &gt;#<br/> &gt;# Specifies that the files generated do not include timestamps,<br/> &gt;# and that this is an official release.<br/> &gt;#<br/> &gt;# RELEASE=false</p> <p> &gt;# command line option: --src<br/> &gt;#<br/> &gt;# Build a .src.rpm, a full kernel patch, and a patched kernel tarball.<br/> &gt;# some recent hacking has pretty much neutered this option.<br/> &gt;# search through this file (and lbuild.old_school &#8211; but that will<br/> &gt;# be going away soon) for "-bb" and see how many places<br/> &gt;# simply don't account for this option<br/> &gt;#<br/> &gt;# DO_SRC=true</p> <p> &gt;# command line option: --work=DIR<br/> &gt;#<br/> &gt;# Directory to store work files during build process.<br/> &gt;# The current directory by default.<br/> &gt;#<br/> &gt;# WORKDIR=$PWD</p> <p> &gt;# command line option: --stage=DIR<br/> &gt;#<br/> &gt;# Directory used to stage packages for release. RPMs will be placed more<br/> &gt;# or less in DIR/&lt;target&gt;-&lt;arch&gt;, and the tarball will be placed in DIR.<br/> &gt;#<br/> &gt;# STAGEDIR=$PWD</p> <p> &gt;# command line option: --tag=TAG<br/> &gt;#<br/> &gt;# An SCM branch/tag/reference specification name to build from.<br/> &gt;# If 'TAG' begins with 'refs/' or 'HEAD:refs/', then it must be<br/> &gt;# a GIT ref spec.<br/> &gt;#<br/> &gt;# TAG=</p> <p> &gt;# command line option: --target=TARGET<br/> &gt;#<br/> &gt;# The name of the target to build. The available targets are listed<br/> &gt;# below.<br/> &gt;#<br/> &gt;# TARGET=</p> <p> &gt;# command line option: --target-arch=HOST_ARCH<br/> &gt;#<br/> &gt;# Force a local architecture to value<br/> &gt;#<br/> &gt;# TARGET_ARCH=$(uname -m)</p> <p> &gt;# command line option: --target-archs=TARGET_ARCHS<br/> &gt;#<br/> &gt;# A (space delimited) list of architectures to build. By default, all<br/> &gt;# of the archs supported by the TARGET will be built, in addition to a<br/> &gt;# .src.rpm. This option can limit those, for machines that can only<br/> &gt;# build certain archs or if you only want a certain arch built (for<br/> &gt;# testing, or a one-off kernel).<br/> &gt;#<br/> &gt;# Also note that by using a non-base arch (eg, i386) only kernels<br/> &gt;# will be built - there will be no lustre-lite-utils package.<br/> &gt;#<br/> &gt;# TARGET_ARCHS=${TARGET_ARCH}</p> <p> &gt;# command line option: --disable-datestamp<br/> &gt;#<br/> &gt;# Prevents the datestamp flag (-D) from being passed to cvs for<br/> &gt;# checkouts. This is a workaround for a problem encountered when<br/> &gt;# using lbuild with tinderbox.<br/> &gt;#<br/> &gt;# USE_DATESTAMP=1</p> <p> &gt;# command line option: --xen<br/> &gt;#<br/> &gt;# Builds a Xen domX kernel.<br/> &gt;#<br/> &gt;# XEN=false</p> <p> &gt;# command line option: --kvm<br/> &gt;#<br/> &gt;# Builds a kernel with additional KVM features.<br/> &gt;#<br/> &gt;# KVM=false</p> <p> &gt;# command line option: -D DATE | --date=DATE<br/> &gt;#<br/> &gt;# Overrides the current date.<br/> &gt;#<br/> &gt;# DATE=$(date)</p> <p> &gt;# command line option: --ofed-version=VER<br/> &gt;#<br/> &gt;# Version for the Open Fabrics EDition ??<br/> &gt;#<br/> &gt;# OFED_VERSION=</p> <p> &gt;# other configurables:<br/> &gt;#<br/> &gt;# Top build directory &#8211; the directory that contains "lbuild".<br/> &gt;# TOPDIR=$(cd $(dirname $0) &gt;/dev/null &amp;&amp; pwd)<br/> &gt;# <br/> &gt;# Some distros have many names for essentially the same target.<br/> &gt;# # used for staging directory names and download RPM selection<br/> &gt;# CANONICAL_TARGET=<br/> &gt;# <br/> &gt;# change default behavior to only build for the current arch<br/> &gt;# TARGET_ARCHS_ALL="$TARGET_ARCH"<br/> &gt;# [ "$TARGET_ARCH" = "i686" ] &amp;&amp; TARGET_ARCHS_ALL="i686 i586 i386"<br/> &gt;# <br/> &gt;# Directory for finding old build products<br/> &gt;# REUSEDIR="${WORKDIR}"<br/> &gt;# <br/> &gt;# Temporary directory<br/> &gt;# TMPDIR=${TMPDIR:-"/var/tmp"}<br/> &gt;# <br/> &gt;# should cached products be used or force rebuilding?<br/> &gt;# USE_BUILD_CACHE=true<br/> &gt;# <br/> &gt;# Pattern used to decide when to skip the diskfs RPM<br/> &gt;# SKIPLDISKFSRPM="v1_4_* b1_4"<br/> &gt;# <br/> &gt;# linux kernel "object" (executable)<br/> &gt;# LINUXOBJ=<br/> &gt;# <br/> &gt;# default to not adding <del>lustre</del> into the kernel RPM package names<br/> &gt;# KERNEL_LUSTRE_NAMING=false<br/> &gt;# <br/> &gt;# default not use kabi check.<br/> &gt;# USE_KABI=false<br/> &gt;# <br/> &gt;# patchless build<br/> &gt;# RPMSMPTYPE=<br/> &gt;# <br/> &gt;# names of patch series which must be available<br/> &gt;# SERIES=<br/> &gt;# <br/> &gt;# Extra architectures, from target file<br/> &gt;# BASE_ARCHS=<br/> &gt;# BIGMEM_ARCHS=<br/> &gt;# BOOT_ARCHS=<br/> &gt;# JENSEN_ARCHS=<br/> &gt;# SMP_ARCHS=<br/> &gt;# BIGSMP_ARCHS=<br/> &gt;# PSERIES64_ARCHS=<br/> &gt;# UP_ARCHS=<br/> &gt;# <br/> &gt;# build the lustre-tests rpm?<br/> &gt;# LUSTRE_TESTS=true<br/> &gt;# <br/> &gt;# CC=${CC:-gcc} # C-compiler</p> <p>I don't think you need to disable the trap. They just need to stop using comparison (&amp;&amp;) as control flow in that function. Unless, perhaps your bug is different then mine.</p> <p>I can't argue with your characterization of lbuild. <img class="emoticon" src="https://jira.whamcloud.com/images/icons/emoticons/smile.png" height="16" width="16" align="absmiddle" alt="" border="0"/></p> <p>I think it has gone this long without being fixed because those who do the most work on Lustre outside of Intel probably don't use lbuild. At LLNL we put together a whole Linux distro based on RHEL, which means that we build our own kernel, our own IB drivers, etc. The lbuild view of the world, i.e. Lustre owns and builds everything, just doesn't jive with a world view where Lustre is just one component of an overall system.</p> <p>I am only working on lbuild at all because I am overhauling the spec files in <a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a>, and I can't get any of my work landed until I make lbuild work with it and make the Intel build farm happy.</p> <p>No, you don't <em>need</em> to disable the trap, as long as you are careful to not have any commands "accidentally" finishing with a non-zero exit code. Still, if you have entered a function that is fail-exiting due to a discovered issue (beit just a request for "help" or misuse of options), it makes logical sense to me to disable the trap.</p> <p>I'm futzing with the thing because Xyratex has a setup similar to Intel in having automated builds get kicked off upon review submissions. You'll be surprised to learn that we've had to adapt it. Much of the adaptation we plan on pushing back to WC/Intel since the changes ought to work there as well.</p> <p>Yes, you <em>do</em> need to disable the trap. lbuild is full of constructs like: str_val=$(myfunc ...)<br/> If "myfunc" can fail, you will <b>ALWAYS</b> get a back trace, along with the error message.<br/> The correct fix is to eliminate that construct and return strings in variables. Not today.<br/> The short term fix is to set up a SIGUSR1 signal handler that disables the ERR trap. e.g.:<br/> trap 'trap "" ERR ; sleep 1 ; exit 1' USR1<br/> and then "kill -USR1 $$" from the subshells. That will disable the "unhandled error" trap and still have the parent process exit non-zero on subshell errors. Uglier than all get-out, but:</p> <p> cleanup() {<br/> set -x +e +E</p> <p> &#35; cleanup of uncaught error trap<br/> &#35;<br/> trap '' ERR TERM</p> <p> &#35; force cleanup of uncaught error trap in parent process<br/> &#35;<br/> local v=${BASH_VERSION%%.*}<br/> if test ${v:-0} -gt 3<br/> then v=${BASHPID}<br/> else v=$(bash -c 'echo $PPID')<br/> fi<br/> test ${progpid} -eq ${v} || kill -USR1 ${progpid}<br/> }</p> <blockquote> <p>Yes, you do need to disable the trap.</p></blockquote> <p>No you don't. You need to do error checking.</p> <blockquote> <p>lbuild is full of constructs like: str_val=$(myfunc ...)</p></blockquote> <p>Which should be error checked if <tt>myfunc()</tt> can return an error. If they it is not, it is an unexpected error and a stacktrace <b>should</b> be generated.</p> <blockquote> <p>If "myfunc" can fail, you will ALWAYS get a back trace, along with the error message.</p></blockquote> <p>Not if you trap (i.e. error check) the return. If <tt>myfunc()</tt> can fail then the caller must check it's status in order to avoid the stacktracing error function. That the caller did not check the error return is <em>exactly</em> what that function is supposed to call attention to.</p> <p>So yes:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">str_val=$(myfunc ...) </pre> </div></div> <p>will cause the trap to trigger if <tt>myfunc()</tt> returns an error, however:</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java"><span class="code-keyword">if</span> ! str_val=$(myfunc ...); then </pre> </div></div> <p>Will not cause a stacktrace because the error condition is checked.</p> <div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent"> <pre class="code-java">$ myfunc(){ &gt; echo <span class="code-quote">"<span class="code-keyword">return</span> value"</span> &gt; <span class="code-keyword">false</span> &gt; } $ trap <span class="code-quote">'echo <span class="code-quote">"trapped an error"</span>'</span> ERR $ <span class="code-keyword">false</span> trapped an error $ str_val=$(myfunc) trapped an error $ <span class="code-keyword">if</span> ! str_val=$(myfunc); then &gt; echo <span class="code-quote">"no error trap"</span> &gt; fi no error trap </pre> </div></div> <p>str_val=$(myfunc) || exit 1</p> <p>I think we both know how to write code that does not trap on errors.<br/> The question is not so much, "Can we make it work?" but rather<br/> "What constructs are least prone to mistakes?" Given that the<br/> lbuild code is liberally laced with val=$(myfunc) stuff that<br/> trigger stack traces and email to home whenever someone's environment<br/> causes "myfunc()" to fail, I think the "fail()" function should<br/> pretty clearly take the responsibility for:</p> <p> 1. report the error (as it does now)<br/> 2. disarm the "you have an error that I don't know about" trap</p> <p>the reasons being several fold:</p> <p> 1. "fatal()" is reporting the error, so it cannot be considered "unknown"<br/> 2. When "fatal()" is called from the parent process level, no stack<br/> trace is triggered, but it <em>is</em> triggered from subshells.<br/> This is a discrepancy that does not have a good reason.<br/> 3. fixing all the places where subshells can exit non-zero is<br/> laborious and error prone.</p> <p>The real solution is to not use subshells, except when genuinely needed.<br/> Return text results should be in myfunc_result type variables.<br/> That won't happen today. That is even more laborious and error prone,<br/> unless you are starting a new project. Subshells ought to be constrained<br/> to mostly co-processes and invoking a simple command where you need<br/> to capture stdout. Not today.</p> <p>My changes to fix the error() function and to remove the code to send email on any trapped error landed in commit 05403115a680adf51990bc9439d78947e8a7beba, "<a href="https://jira.whamcloud.com/browse/LU-1199" title="lustre build system overhaul" class="issue-link" data-issue-key="LU-1199"><del>LU-1199</del></a> lbuild: Fix error handling".</p> <p>Bruce, I would not suspect that there is something special about subshells that makes fatal() trigger a trap. I think the problem was that there was a bug in error() that caused a trap any time fatal() was called without a message. My commit fixes that.</p> <p>While I'm not necessarily opposed to turning off the trap in fatal(), I don't think there is any need to do so now.</p> <p>Furthermore, if I understand you correctly, you are complaining that "val=$(myfunc)", where "myfunc" decides to call fatal(), results in a trap and stack dump. I don't think that can be fixed by disabling the trap inside of fatal(). The <em>subshell</em> called fatal(), so the trap is only disabled in the subshell. When the parent shell sees the error code that is unhandled, it will still have its trap enabled.</p> <p>I agree that the use of subshells is less than optimal in lbuild. But as you say, that requires more of a rewrite than folks probably want to do at the moment.</p> <p>So unless I have missed something, I would say that the issue stated in the title of this ticket no longer applies, and this ticket can be closed.</p> <p>fatal exits non-zero, triggering the ERR trap.</p> <p>I tend to make submissions and not reverify their applicability after new checkins.<br/> So I have not looked at your "Fix error handling" fix.</p> <p>&gt; Furthermore, if I understand you correctly, you are complaining that "val=$(myfunc)",<br/> &gt; where "myfunc" decides to call fatal(), results in a trap and stack dump.<br/> &gt; I don't think that can be fixed by disabling the trap inside of fatal().</p> <p>Hmm. Child to parent communication is a nuisance. So there needs to be some sort of<br/> temp file lock. Create the thing and remove it when reporting an error and when<br/> exiting cleanly. If it exists inside the error trap, <b>THEN</b> create the stack dump.<br/> Probably best to leave off automated email, instead of fixing it and leaving it<br/> off makes the stack trace suppression less crucial, but still should be done.<br/> The "correct" way to do it is to put <b>all</b> the coding into a function and:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> exit_flag_file=$(mktemp ${TMPDIR:-/tmp}/err-exit-XXXXXX) unknown_err_handler() { test -f ${exit_flag_file} || return 0 rm -f ${exit_flag_file} &lt;&lt;stack trace&gt;&gt; } trap 'srcfile=${BASH_SOURCE} srcline=${BASH_LINENO] unknown_err_handler' ERR </pre> </div></div> <p>That <b>eliminates</b> the need to mess with this:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre> if [ $n = 1 ]; then let lineno-=11 fi </pre> </div></div> <p>In any event, there were other fixes in my patch, too. viz. corrections in usage text<br/> and consistency in handling various options and environment variable parameter<br/> passing. (Never ever use one name as a long option name and a completely<br/> different name as the environment variable version, and usage text really ought to<br/> match what gets parsed.)</p> <blockquote><p>fatal exits non-zero, triggering the ERR trap.</p></blockquote> <p>I'm sorry, but I'm pretty sure you have that wrong. For example:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$cat exit.sh #!/bin/bash hello () { echo hello } trap hello ERR fatal () { exit 1 } fatal $cat return.sh #!/bin/bash hello () { echo hello } trap hello ERR fatal () { return 1 } fatal $./exit.sh $./return.sh hello $ </pre> </div></div> <p>As you can see, the ERR trap is only triggered when a simple command has a non-zero exit status (see bash man page for more details). "exit" is <em>not</em> a "simple command", it is a special command that terminates the entire process. exit has no return code within the script, because it never returns.</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>#! /bin/bash typeset -r prog=$(basename "$0" .sh) typeset -r program=$(basename "$0") typeset -r progdir=$(\cd $(dirname "$0") &amp;&amp; pwd -P) typeset -r progpid=$$ typeset -r fflag=$(mktemp ${TMPDIR:-/tmp}/${prog}-fail-XXXXXX) die() { test -f $fflag || return 1 rm -f $fflag echo "${prog} error: $*" &gt;&amp;2 kill -TERM ${progpid} exit 1 } bad_copy() { echo BROKEN 1&gt;&amp;2 rm -f $fflag exit 1 } trap 'die "trap on ERR"' ERR set -e txt=$(bad_copy) echo WE SHOULD HAVE FAILED rm -f $fflag</pre> </div></div> <p>and when run:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>$ bash fail.sh BROKEN $ echo $? 1</pre> </div></div> <p>I presume we were misunderstanding each other since I am guessing we both know how to write shell scripts.</p> <p>I'd argue that you're on the path to violating the KISS principle. But frankly, I don't care that much about lbuild. I'm going to drop off this ticket.</p> <p>No more interested parties for this issue.</p> Development Rank 1|hzvk47: Rank (Obsolete) 6983 Severity