[pacman-dev] [RFC] makepkg: output commands ran in build/check/package functions
This might help to locate a failing command which causes makepkg to abort. Signed-off-by: Florian Pritz <bluewind@xinu.at> --- This is a request for comments and not a final patch. It's only been tested shortly. I just want to know if people like the idea. scripts/makepkg.sh.in | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 6304a25..409c4cc 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -851,6 +851,7 @@ extract_sources() { } error_function() { + set +x if [[ -p $logpipe ]]; then rm "$logpipe" fi @@ -912,7 +913,9 @@ run_function() { restoretrap=$(trap -p ERR) trap 'error_function $pkgfunc' ERR + set -x $pkgfunc &>"$logpipe" + set +x eval $restoretrap wait $teepid @@ -920,7 +923,9 @@ run_function() { else restoretrap=$(trap -p ERR) trap 'error_function $pkgfunc' ERR + set -x $pkgfunc 2>&1 + set +x eval $restoretrap fi # reset our shell options -- 1.7.6.1
On Tue, Sep 20, 2011 at 9:11 AM, Florian Pritz <bluewind@xinu.at> wrote:
This might help to locate a failing command which causes makepkg to abort.
Signed-off-by: Florian Pritz <bluewind@xinu.at> --- This is a request for comments and not a final patch. It's only been tested shortly. I just want to know if people like the idea.
I'm a +0 on this- mainly because I don't build enough to know whether people would find this helpful. People that package more than I, please speak up.
scripts/makepkg.sh.in | 5 +++++ 1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/scripts/makepkg.sh.in b/scripts/makepkg.sh.in index 6304a25..409c4cc 100644 --- a/scripts/makepkg.sh.in +++ b/scripts/makepkg.sh.in @@ -851,6 +851,7 @@ extract_sources() { }
error_function() { + set +x if [[ -p $logpipe ]]; then rm "$logpipe" fi @@ -912,7 +913,9 @@ run_function() {
restoretrap=$(trap -p ERR) trap 'error_function $pkgfunc' ERR + set -x $pkgfunc &>"$logpipe" + set +x eval $restoretrap
wait $teepid @@ -920,7 +923,9 @@ run_function() { else restoretrap=$(trap -p ERR) trap 'error_function $pkgfunc' ERR + set -x $pkgfunc 2>&1 + set +x eval $restoretrap fi # reset our shell options -- 1.7.6.1
On 21/09/11 09:49, Dan McGee wrote:
On Tue, Sep 20, 2011 at 9:11 AM, Florian Pritz<bluewind@xinu.at> wrote:
This might help to locate a failing command which causes makepkg to abort.
Signed-off-by: Florian Pritz<bluewind@xinu.at> --- This is a request for comments and not a final patch. It's only been tested shortly. I just want to know if people like the idea.
I'm a +0 on this- mainly because I don't build enough to know whether people would find this helpful. People that package more than I, please speak up.
I'm also +0, but that might be because I am quite familiar with the packaging process and find where errors occur somewhat obvious. So... waiting to hear from people who package more than Dan but less than me! Allan
On Tue, Sep 20, 2011 at 11:40 PM, Allan McRae <allan@archlinux.org> wrote:
On 21/09/11 09:49, Dan McGee wrote:
On Tue, Sep 20, 2011 at 9:11 AM, Florian Pritz<bluewind@xinu.at> wrote:
This might help to locate a failing command which causes makepkg to abort.
Signed-off-by: Florian Pritz<bluewind@xinu.at> --- This is a request for comments and not a final patch. It's only been tested shortly. I just want to know if people like the idea.
I'm a +0 on this- mainly because I don't build enough to know whether people would find this helpful. People that package more than I, please speak up.
I'm also +0, but that might be because I am quite familiar with the packaging process and find where errors occur somewhat obvious.
Same here. For the few cases where it's not obvious, it's quite easy to pin-point the problematic line with some echo or 'return 1' statement.
So... waiting to hear from people who package more than Dan but less than me!
Allan
On Wed, Sep 21, 2011 at 01:40:41AM -0400, Eric Bélanger wrote:
On Tue, Sep 20, 2011 at 11:40 PM, Allan McRae <allan@archlinux.org> wrote:
On 21/09/11 09:49, Dan McGee wrote:
On Tue, Sep 20, 2011 at 9:11 AM, Florian Pritz<bluewind@xinu.at> wrote:
This might help to locate a failing command which causes makepkg to abort.
Signed-off-by: Florian Pritz<bluewind@xinu.at> --- This is a request for comments and not a final patch. It's only been tested shortly. I just want to know if people like the idea.
I'm a +0 on this- mainly because I don't build enough to know whether people would find this helpful. People that package more than I, please speak up.
I'm also +0, but that might be because I am quite familiar with the packaging process and find where errors occur somewhat obvious.
Same here. For the few cases where it's not obvious, it's quite easy to pin-point the problematic line with some echo or 'return 1' statement.
And same here. I actually never really had the problem of not knowing where some build error originates from. It is kind of obvious in most cases and the error messages are often helpful enough. In case of doubt, you can always add "set -x" to the build() and package() functions manually as well.
On Wed, Sep 21, 2011 at 01:40:50PM +1000, Allan McRae wrote:
On 21/09/11 09:49, Dan McGee wrote:
On Tue, Sep 20, 2011 at 9:11 AM, Florian Pritz<bluewind@xinu.at> wrote:
This might help to locate a failing command which causes makepkg to abort.
Signed-off-by: Florian Pritz<bluewind@xinu.at> --- This is a request for comments and not a final patch. It's only been tested shortly. I just want to know if people like the idea.
I'm a +0 on this- mainly because I don't build enough to know whether people would find this helpful. People that package more than I, please speak up.
I'm also +0, but that might be because I am quite familiar with the packaging process and find where errors occur somewhat obvious.
So... waiting to hear from people who package more than Dan but less than me!
Allan
I find that most PKGBUILDs are simple enough that the error often stands out. I'm not really for or against this, but I'd be more for than against if there were a clean way to implement this without getting some strange messages on the tail end and/or failing to unset it entirely. d
participants (6)
-
Allan McRae
-
Dan McGee
-
Dave Reisner
-
Eric Bélanger
-
Florian Pritz
-
Lukas Fleischer