Helmut Grohne, on 2020-05-13 14:14:19 +0200:
> I fear you only implemented a partial solution (based on my
> recommendation here). In my tests, failures still go unchecked. I think
> at least one issue is the linker rule in src/c_make.gen starting with
> line 359. You added "set -e" there. The command snippet has an outer if
> branch to select the linker (C vs C++) and an inner branch that removes
> the linked file on failure. Unfortunately, the failure path does not
> propagate the failure, because it is already captured in the if. Thus
> swallowing errors. I didn't see this when writing my bug report either.
Yes, I must admit the symbols soup does not make this structure
very apparent. I modified the patch and tried to adapt the
logic here without drifting too much out of the original file,
yet it required reorganizing the commands a bit. After some
testing, error codes from the linking stage should be returned
properly; if otherwise then I would tend to think the linker
didn't return an error code in the first place.
> Beyond this, I strongly recommend implementing verbose build logs. The
> issue would have been much easier to spot with verbose build logs. Build
> logs have been a release goal. Building verbosely is also recommended
> by the Debian policy section 4.9. Unfortunately, the build system at
> hand doesn't make this possible without patching.
Agreed. I did a thorough rereading of the Makefiles, and got
rid of the "@" prefix of most commands. Build logs are now
showing what is happening, so even if changes here over are not
sufficient to close the bug yet, at least the verbosity level
should now allow to see more clearly what is happening.
I made the patch available on Salsa. If maybe you wish to have
a try and review changes, before further package upload, you can
grab it here:
Andreas Tille, on 2020-05-14 08:43:08 +0200:
> I took the freedom to just upload as is since chances are good that
> Helmut does just to do "simply nothing" which is better than forcing him
> to test and send a response. Hope this strategy is successfull.
My apologies, I was rather unsure if either it was preferable to
keep trying uploading and closing the bug again and again, or
make sure that the patch was actually addressing the problem
first. So, many thanks for your message, as it helps me seeing
that the first approach can be a perfectly valid option as well,
even preferred in many situations actually I guess.
On Thu, May 14, 2020 at 01:41:42PM +0200, Étienne Mollier wrote:
> Andreas Tille, on 2020-05-14 08:43:08 +0200:
> > I took the freedom to just upload as is since chances are good that
> > Helmut does just to do "simply nothing" which is better than forcing him
> > to test and send a response. Hope this strategy is successfull.
> My apologies, I was rather unsure if either it was preferable to
> keep trying uploading and closing the bug again and again, or
> make sure that the patch was actually addressing the problem
There is no need to apologize. There is no right or wrong between your
careful approach and mine which is a bit more pushing. I'd love to get
things from my table (and potentially from other peoples table as well).
> So, many thanks for your message, as it helps me seeing
> that the first approach can be a perfectly valid option as well,
> even preferred in many situations actually I guess.
I agree that there are situations where I'd also follow your careful