You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had to deal recently with an upstream, whose state caused one of the autodep commands to write to stderr (and not output any of the the expected deps). I think the language the autodep binary is written in allows non-blocking errors. Traces are written to stderr, but processing tries to continue anyway, even though it is usually already doomed, pretty awful for robustness, but that's the language designer choice.
rpm build logs only showed this unhelpful low-level trace, with no indication on which autodep command was erroring, and what were the arguments passed to it. Debugging proved quite tricky.
Please enhance rpm so, when an autodep/autoprov writes to stderr, rpm also prints the command call that resulted in this stderr writing, with all the parameters rpm passed to it.
The text was updated successfully, but these errors were encountered:
nim-nim
changed the title
RFE: log autodep/autoprov calls if something writes to stdout
RFE: print autodep/autoprov calls if something writes to stderr
Jan 21, 2019
In rpm >= 4.14 you can get the exact command and exact file triggering with -vv --rpmfcdebug
Rpm is not interested in the stderr of dependency generators but we could probably provide better diagnostics automatically when a depgen returns with non-zero code.
Thanks for the pointer. I'm afraid very few people know about this (me the first)!
Please don't just test for non-zero, test any write on stderr, otherwise you get those weird stderr messages appearing without any trace of what triggered them.
OK, guess having a deeper look into the error handling for the dependency generators is something we should do. Even when it is not entirely clear now what we are going end up doing about this.
I don't see us implementing stderr watching as such, so closing this in favor of #1183 - we do need to care about exit code, and emit meaningful diagnostics output in that case.
I had to deal recently with an upstream, whose state caused one of the autodep commands to write to stderr (and not output any of the the expected deps). I think the language the autodep binary is written in allows non-blocking errors. Traces are written to stderr, but processing tries to continue anyway, even though it is usually already doomed, pretty awful for robustness, but that's the language designer choice.
rpm build logs only showed this unhelpful low-level trace, with no indication on which autodep command was erroring, and what were the arguments passed to it. Debugging proved quite tricky.
Please enhance rpm so, when an autodep/autoprov writes to stderr, rpm also prints the command call that resulted in this stderr writing, with all the parameters rpm passed to it.
The text was updated successfully, but these errors were encountered: