[bug#58336] [PATCH] HACKING: allow backward compatibilities again
Subject: [PATCH] HACKING: allow backward compatibilities again :) Thanks, I applied the fix.
Re: make check(s) pre-release problems
No errors on RHEL7+autoconf2.71 Puzzling. Can you easily try RHEL8 or one of its derivatives? It surprises me that that is the culprit, but it seems possible. I'm using autoconf-2.71, make-4.3, etc., compiled from source, but am using the OS-provided coreutils. I think I'll try compiling that from source. Thanks to everyone for the suggestions and help. -k
Re: make check(s) pre-release problems
On Thu, Oct 6, 2022, at 1:04 PM, Zack Weinberg wrote: > On 2022-10-04 6:58 PM, Karl Berry wrote: >> Perhaps easier to debug: there are two targets to be run before making a >> release, check-no-trailing-backslash-in-recipes and check-cc-no-c-o, >> to try to ensure no reversion wrt these features. A special shell and >> compiler are configured, respectively (shell scripts that check the >> behavior). > > I'm running these targets now and will report what I get. No errors on RHEL7+autoconf2.71 (same environment I used for the Python fixes) from a serial "make check-no-trailing-backslash-in-recipes". The other one is running now. zw
Re: make check(s) pre-release problems
On 2022-10-04 6:58 PM, Karl Berry wrote: With Zack's latest Python fixes, I was hoping to move towards an Automake release, but I find myself stymied by apparently random and unreproducible test failures. I haven't exhausted every conceivable avenue yet, but I thought I would write in hopes that others (Zack, past Automake developers, anyone else ...) could give it a try, and/or have some insights. For me, running a parallel make check (with or without parallelizing the "internal" makes), or make distcheck, fails some tests, e.g., nodef, nodef2, testsuite-summary-reference-log. The exact tests that fail changes from run to run. Running the tests on their own succeeds. Ok, so it's something in the parallelism. But why? And how to debug? I can't reproduce this problem myself, but my first thought is that some of the tests, when run concurrently, could be overwriting each other's files somehow. I can think of two ways to investigate that hypothesis: look for tests that write files outside a directory dedicated to that test, and, after a failed test run, look for files that are corrupted, then try to figure out which tests would be stomping on those files. Perhaps easier to debug: there are two targets to be run before making a release, check-no-trailing-backslash-in-recipes and check-cc-no-c-o, to try to ensure no reversion wrt these features. A special shell and compiler are configured, respectively (shell scripts that check the behavior). I'm running these targets now and will report what I get. zw
[bug#58336] [PATCH] HACKING: allow backward compatibilities again
See commit v1.16.3-20-g0c8100cb6 ("doc: HACKING updates.", 2021-05-12).
Copyright-paperwork-exempt: yes
---
HACKING | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/HACKING b/HACKING
index 248fd4b03..88d5274a9 100644
--- a/HACKING
+++ b/HACKING
@@ -174,7 +174,7 @@
* Major releases can introduce backward-incompatibilities (albeit such
incompatibilities should be announced well in advance, and a smooth
transition plan prepared for them), and try more risky and daring
- refactorings and code cleanups. Still, backward compatibilities are
+ refactorings and code cleanups. Still, backward incompatibilities are
extremely undesirable and should be avoided at all costs.
* For more information, refer to the extensive discussion associated
--
2.38.0
Re: make check(s) pre-release problems
> On 4 Oct 2022, at 23:58, Karl Berry wrote: > > With Zack's latest Python fixes, I was hoping to move towards an > Automake release, but I find myself stymied by apparently random and > unreproducible test failures. I haven't exhausted every conceivable > avenue yet, but I thought I would write in hopes that others (Zack, past > Automake developers, anyone else ...) could give it a try, and/or have > some insights. > > For me, running a parallel make check (with or without parallelizing the > "internal" makes), or make distcheck, fails some tests, e.g., nodef, > nodef2, testsuite-summary-reference-log. The exact tests that fail > changes from run to run. Running the tests on their own succeeds. Ok, so > it's something in the parallelism. But why? And how to debug? > > Nothing has changed in the tests. Nothing has changed in the automake > infrastructure. Everything worked for me a few weeks ago. Furthermore, > Jim ran make check with much more parallelism than my machine can > muster, and everything succeeded for him. That was with: > make check TESTSUITEFLAGS=-j20 > > Any ideas, directions, fixes, greatly appreciated. --thanks, karl. > Is there a way to ask your distribution's package manager which upgrades/downgrades were done in the last N weeks? It'd also be helpful to see the actual failures, although as Paul notes, make --shuffle with latest non-released make could help debugging. signature.asc Description: Message signed with OpenPGP
Re: make check(s) pre-release problems
On Wed, 2022-10-05 at 15:24 -0600, Karl Berry wrote: > What troubles me most is that there's no obvious way to debug any > test failure involving parallelism, since they go away with serial > execution. Any ideas about how to determine what is going wrong in > the parallel make? Any way to make parallel failures more > reproducible? I don't have any great ideas myself. In the new prerelease of GNU make there's a --shuffle option which will randomize (or just reverse) the order in which prerequisites are built. Often if you have a timing-dependent failure, forcing the prerequisites to build in a different order can make the failure more obvious. In general, though, the best way to attack the issue is to try to understand why the failure happens: what goes wrong that causes the failure. If that can be understood then often we can envision a way that parallel or "out of order" builds might cause that problem. Alternatively since you seem to have relatively well-defined "good" and "bad" commits you could use git bisect to figure out which commit actually causes the problem (obviously you need to be able to force the failure, if not every time then at least often enough to detect a "bad" commit). Maybe that will shed some light. But I expect there's nothing here you haven't already thought of yourself :( :).
Re: make check(s) pre-release problems
On Wednesday 2022-10-05 23:24, Karl Berry wrote: > >What troubles me most is that there's no obvious way to debug any test >failure involving parallelism, since they go away with serial execution. >Any ideas about how to determine what is going wrong in the parallel >make? Any way to make parallel failures more reproducible? 1. Throw more processes in the mix (make -jN with more-than-normal N) so that either - for each (single) process the "critical section" execution time goes up - for the whole job set, the total time spent in/around critical sections goes up 2. determine which exact (sub-)program and syscall failed in what process in what job (strace), then construct a hypothesis around that failure 3. watch if any one job is somehow executed twice, or a file is written to concurrently foo: foo.c foo.h ld -o foo ... foo.c foo.h: generate_from_somewhere 3b. or a file is read and written to concurrently %.o: %.c generate_version.h cc -o $@ $< foo: foo.o bar.o (and foo.c, bar.c, nongenerated, have a #include "version.h") I've seen something like that in libtracefs commit b64dc07ca44ccfed40eae8d345867fd938ce6e0e
