[PATCH] find-debuginfo.sh: Exit with real exit status in parallel jobs

[Mark Wielaard]

Hi Keith,

On Mon, 2024-08-19 at 12:51 -0700, Keith Seitz wrote:
> On 8/17/24 2:20 PM, Mark Wielaard wrote:
> > Good find. Code looks correct. Except don't we now also need to check
> > the result of do_file () in the non-parallel case? Something like:
> > 
> > diff --git a/scripts/find-debuginfo.in b/scripts/find-debuginfo.in
> > index f40e566f86c3..5998b9d1fa6c 100755
> > --- a/scripts/find-debuginfo.in
> > +++ b/scripts/find-debuginfo.in
> > @@ -579,6 +579,10 @@ fi
> >   if [ $n_jobs -le 1 ]; then
> >     while read nlinks inum f; do
> >       do_file "$nlinks" "$inum" "$f"
> > +    res=$?
> > +    if [ "$res" != "0" ]; then
> > +      exit $res
> > +    fi
> >     done <"$temp/primary"
> >   else
> >     for ((i = 1; i <= n_files; i++)); do
> 
> Yes, that does look appropriate. My apologies for not following through
> with the non-parallel invocation. I guess I could have (further) 
> modified my custom rpm package to specifically test this case, too,
> and submit a more complete patch.

I pushed you patch with the above change for the single-thread case.

It would be appreciated if you could incorporate it into your testing.
Sadly we don't have any script tests, so we do rely on external
testing.

> > > While at it, I've incorporated a patch for find-debuginfo/30505.
> > > Using this patch and another patch to the RPM package (submitted as
> > > github issue #3215), failures of gdb-add-index.sh will now properly fail
> > > the build instead of being swallowed. It should be much easier for
> > > developers to figure out why their builds have failed should gdb crash.
> > 
> > Thanks, that has been a long standing issue.  Smart to introduce a new
> > _find_debuginfo_exit_on_error for rpm-config. The reason errors
> > weren't reported in the past was because people would then disable
> > creating debuginfo packages completely. But these days we really
> > should report (and fix) any errors.
> > 
> > There are a couple of other places, the main debugedit invocation,
> > strip_to_debug, add_minidebug, which really should report errors
> > too. But that can wait.
> 
> Indeed. I'm selfish, so I am attempting to improve testing for
> areas for which I am directly responsible, but perhaps I can add
> that to a TODO and give it a try with my mass prebuilder some time
> to verify.

Totally understood. Lets fix them in stages, so they can be tested
separately.

Thanks,

Mark