Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On Nov 1, 2019, at 02:52, Werner LEMBERG wrote: > >>> [...] because the `share' tree present in >>> >>> gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ >>> >>> is not created by the script in >>> >>> gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ >> >> This fixes the lilypond-test stage: >> https://github.com/gperciva/gub/pull/70 > > Thanks a lot! What patches shall I temporarily apply to current gub > master to test your latest fixes? I don't understand what you're asking for other than the commits in the pull request. A few minutes ago, I pushed revisions in response to your review, after verifying that a clean build still got beyond lilypond-test stage. Note that I did reorder and "fixup" some commits after testing. Regards, — Dan
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
>> [...] because the `share' tree present in >> >> gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ >> >> is not created by the script in >> >> gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ > > This fixes the lilypond-test stage: > https://github.com/gperciva/gub/pull/70 Thanks a lot! What patches shall I temporarily apply to current gub master to test your latest fixes? Werner
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > > Operand stack: > > (.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current/fonts/otf/emmentaler-20.otf) >(r) > Execution stack: [...] > Last OS error: No such file or directory > > because the `share' tree present in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ > > is not created by the script in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ This fixes the lilypond-test stage: https://github.com/gperciva/gub/pull/70 The lilypond-doc stage fails for me, but I don't think it's related. There are messages about shared library versions not being found. — Dan
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > > Operand stack: > > (.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current/fonts/otf/emmentaler-20.otf) >(r) > Execution stack: [...] > Last OS error: No such file or directory > > because the `share' tree present in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ > > is not created by the script in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ Well, I think that this change fixes the 'share' symlink; however, the otf file is still not there, so the investigation will continue. https://github.com/gperciva/gub/compare/master...DanEble:dev — Dan
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
> I installed Ubuntu 19.10 on a spare computer, installed some > necessary packages, cloned https://github.com/gperciva/gub.git, and > ran "time make -j7 PLATFORMS=‘linux-64’ lilypond". This got as far > as package linux-64::lilypond, stage pkg_install, and then exited > with error 2. The last line of target/linux-64/log/lilypond.log is > just this: > > *** Stage: pkg_install (lilypond, linux-64) > > I don't know where to go from here. This is strange. Maybe lack of disk space? Do you get more information if you add option `-d' to make? Otherwise I fear you have to use strace to find out the problematic spot. Admittedly, I have never tried to build a single platform. Maybe there are hidden dependencies. It is also possible thet the `-j7' option causes problems. Werner
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > A good test for those things IMHO is to clone the gub repository, then > saying > > make lilypond I installed Ubuntu 19.10 on a spare computer, installed some necessary packages, cloned https://github.com/gperciva/gub.git, and ran "time make -j7 PLATFORMS=‘linux-64’ lilypond". This got as far as package linux-64::lilypond, stage pkg_install, and then exited with error 2. The last line of target/linux-64/log/lilypond.log is just this: *** Stage: pkg_install (lilypond, linux-64) I don't know where to go from here. Maybe tomorrow I'll look for other logs or start learning about the makefile. — Dan
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
Dan Eble writes: > On Oct 28, 2019, at 08:12, David Kastrup wrote: >> >>> I request some help to understand how I can improve my pre-commit >>> testing procedures, and where my responsibilities begin and end. >> >> Responsibilities don't end. > > Fine. When a patch is submitted for review, there ends the > opportunity to fulfill one's responsibility to test before submitting > it. My question was how much is enough. > >> We don't have as comprehensive tests as that and don't really demand >> it. One should just be conservative. The cost of a mistake in that >> regard may well be a revert or a timely followup patch. > > This is an answer to my question, though my recent perception (which > is possibly incorrect) was that receiving some public heat was > included in the cost. Before our automated testing procedures, it happened more often. People get annoyed when their workflow is disrupted. Changes affecting the build system are a bit more prone to fall through the cracks of testing, particularly where older versions of tools (like in GUB) are possibly affected. > Anyway, I'm sorry that my recent contributions haven't worked for > everyone; it's not for lack of trying. Your track record is pretty good. The last revert was quite likely GUB-tool-version related: those are more likely than a lot of other things to fall through the cracks of testing and just become apparent before next release. It's good that more people check with GUB nowadays in time, but it's not part of our regular testing setup. Maybe that last revert (possibly only appearing with GUB) was not necessary for getting James back on track: I don't know. But given the importance of his work, I'd rather do a revert too much: they are comparatively cheap. This change needed to get dialed back in syntax at some point of time before next release, anyway, so the difference of reverting and not reverting is not all that much: one has to put some more work either way. -- David Kastrup
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
> I will attempt to build gub to reproduce and diagnose this issue. Thanks! > If you think my time would be better spent preparing a patch that > cleanly undoes the 'share' change, I'm open to hearing it. I second Carl's opinion, namely to fix the issue rather than to circumvent the problem. Werner
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On Oct 28, 2019, at 08:12, David Kastrup wrote: > >> I request some help to understand how I can improve my pre-commit >> testing procedures, and where my responsibilities begin and end. > > Responsibilities don't end. Fine. When a patch is submitted for review, there ends the opportunity to fulfill one's responsibility to test before submitting it. My question was how much is enough. > We don't have as comprehensive tests as that and don't really demand > it. One should just be conservative. The cost of a mistake in that > regard may well be a revert or a timely followup patch. This is an answer to my question, though my recent perception (which is possibly incorrect) was that receiving some public heat was included in the cost. Anyway, I'm sorry that my recent contributions haven't worked for everyone; it's not for lack of trying. Regards, — Dan
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On 10/28/19, 7:53 AM, "lilypond-devel on behalf of Dan Eble" wrote: On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > Last OS error: No such file or directory > > because the `share' tree present in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ > > is not created by the script in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ > > I seem to remember that this has worked the last time I worked on gub > (in January) … My change that made 'share' a symlink seems a likely candidate, but I hope we can avoid simply reverting that, lest it require everyone to wipe their build directories and rebuild from scratch to avoid weird side effects. I took pains to keep "make check" working with older baselines across that change, but I put no effort (or thought) into supporting a move back to the past. I will attempt to build gub to reproduce and diagnose this issue. If you think my time would be better spent preparing a patch that cleanly undoes the 'share' change, I'm open to hearing it. If you think that having the 'share' as a symlink is a net benefit, I'd prefer to have you make it work perfectly, as opposed to trying to revert it cleanly. Thanks, Carl
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On Oct 28, 2019, at 05:32, Werner LEMBERG wrote: > Last OS error: No such file or directory > > because the `share' tree present in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ > > is not created by the script in > > gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ > > I seem to remember that this has worked the last time I worked on gub > (in January) … My change that made 'share' a symlink seems a likely candidate, but I hope we can avoid simply reverting that, lest it require everyone to wipe their build directories and rebuild from scratch to avoid weird side effects. I took pains to keep "make check" working with older baselines across that change, but I put no effort (or thought) into supporting a move back to the past. I will attempt to build gub to reproduce and diagnose this issue. If you think my time would be better spent preparing a patch that cleanly undoes the 'share' change, I'm open to hearing it. — Dan
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
Dan Eble writes: > On Oct 27, 2019, at 14:06, Werner LEMBERG wrote: >>> I have no idea why the problem is only being discussed instead of >>> fixed, but I'll revert > > I can't speak for anyone else, but in my case, inaction was mainly due > to expecting affirmation from a more senior contributor. It's always good to spell out expectations. We might have had too many of those implicit expectations conflict and lead to deadlock. > Even having that, being away from home all weekend would have > prevented me from taking any action. > > I don't refer to the CG as much as I probably should, but having > looked at section 3.4.10 recently, I'll say that if you want people to > take swifter action on their own in cases like this, it might help to > revise this very cautionary language: > >> Please do not try breaking out from it by adding fixes on top of >> staging: in that case the whole sequence will end up in master after >> all, defeating the purpose of the system. The proper fix usually >> involves rewriting the staging branch and is best left to core >> developers after discussion on the developer list. That's for the case of a broken staging not passing the automated test procedures. It does not apply to a broken master. -- David Kastrup
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
Dan Eble writes: > In the past month, I've devoted many hours to testing my submissions, > but clearly the effort is not achieving the goal. If the goal is perfection, it is hard to achieve. > I request some help to understand how I can improve my pre-commit > testing procedures, and where my responsibilities begin and end. Responsibilities don't end. We are a community project: anybody who can change something to the better is advised not to consider stuff "somebody else's problem" since we don't really have _assigned_ responsibilities. In return, we don't have assigned blame. Tracking down the source of a problem may seem like that, but it's not like people aren't trying their best, and it's not like it's always easy to achieve. > I enjoy having my commits reverted as much as others enjoy having > their build broken--it is a big waste of pro-bono time--so I want to > understand the issues clearly. To put that in perspective: a revert is not a big waste of time: in contrast it puts a problem from affecting everybody's time back into a state where it only affects a single person's time. Fixes to reverted material often end up trivial, not costing much actual personal work time (though a time lag). The main resource we are trying to preserve with our procedures is mental energy and goodwill of everybody involved. Most of the time, it works out well enough. A larger part than initially planned for is done by James: this part has become larger since our automated testing procedures for individual patches have not survived the migration from Google Code to Sourceforge. Since he now does quite a bit of work manually, the reproducibility has suffered a bit: maybe we would need to provide more scripts/automation for offline testing for the case that the online test processing is not fully operative (like it is now). > How are build-breaking changes getting into the master branch? CG > section 3.4.10 says that the reason for pushing to staging is that > automated tests are run before changes are moved to master. What > specifically is being tested? Basically make, make test, and make doc. At the current point of time, the main testing platform for the staging branch testing is my personal laptop which tends to run a current or beta version of Ubuntu. GUB is usually (but not necessarily so) run on LilyDev, a virtual Ubuntu image. The tools in GUB tend to be updated as needed, so there often are older GCC and/or Python versions involved here. It has not been rare in the past that development went forward for a minor release and just at release time it was detected that the tools used in GUB would not support some of the new code. > And days before that happens, patches are announced as having been > tested with the feedback "Passes make. make check and a full make > doc." The evidence suggests that that does not include running > autogen, otherwise it should have caught the problem with "tidy" that > my own testing failed to catch. Check James' procedure: he has posted it a few times. Formalizing it would create scripts for it. > Should things such as missing optional programs and new-ish Python > syntax be rejected at either of these stages? If not, then it would > seem to fall to the submitter to set up an alternate development > environment with Python 2.4, GCC 3.4, and similarly aged versions of > other tools, and run additional tests in that environment. We don't have as comprehensive tests as that and don't really demand it. One should just be conservative. The cost of a mistake in that regard may well be a revert or a timely followup patch. -- David Kastrup
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
> In the past month, I've devoted many hours to testing my > submissions, but clearly the effort is not achieving the goal. Don't worry. Some of the problems are very hard to catch and only show up under certain circumstances. > I request some help to understand how I can improve my pre-commit > testing procedures, and where my responsibilities begin and end. IMHO, you did well. > I enjoy having my commits reverted as much as others enjoy having > their build broken--it is a big waste of pro-bono time--so I want to > understand the issues clearly. There is no waste of time, since the reversion is only temporary – your patches are definitely not rejected. However, small amendments are apparently necessary to make them work everywhere, and the problems were caught unusually late. > And days before that happens, patches are announced as having been > tested with the feedback "Passes make. make check and a full make > doc." The evidence suggests that that does not include running > autogen, otherwise it should have caught the problem with "tidy" > that my own testing failed to catch. Yes. A full run of everything is not always executed. > Should things such as missing optional programs and new-ish Python > syntax be rejected at either of these stages? If not, then it would > seem to fall to the submitter to set up an alternate development > environment with Python 2.4, GCC 3.4, and similarly aged versions of > other tools, and run additional tests in that environment. A good test for those things IMHO is to clone the gub repository, then saying make lilypond The first run takes many hours to download and build the necessary infrastructure; later on it's much faster. Somewhere in the lilypond-devel mailing list archive you can find hints how to make gub use your own clone of the git repository so that you can directly test patches; ditto for hints that explain what created stuff in gub should be manually removed in case you want to test a full lilypond build (without unnecessarily rebuilding the gub infrastructure). Apropos gub: Inspite of David K's reversions there is still a (new?) bug in `output-distance.py' (I think): The call PYTHONPATH=[...] \ PATH=[...] \ python2 test-lily/rsync-test.py \ --version-file=... \ --output-distance=.../scripts/build/output-distance.py \ --test-dir=uploads/webtest \ --gub-target-dir=... in the `unlocked-test-export' rule fails with [...] entering directory .../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1 invoking gs -sDEVICE=png16m \ [...] \ -slilypond-datadir=.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current \ [...] \ rest-positioning.eps \ -c quit Error: /undefinedfilename in --file-- Operand stack: (.../gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/share/lilypond/current/fonts/otf/emmentaler-20.otf) (r) Execution stack: [...] Last OS error: No such file or directory because the `share' tree present in gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/ is not created by the script in gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/ I seem to remember that this has worked the last time I worked on gub (in January) ... Werner
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
In the past month, I've devoted many hours to testing my submissions, but clearly the effort is not achieving the goal. I request some help to understand how I can improve my pre-commit testing procedures, and where my responsibilities begin and end. I enjoy having my commits reverted as much as others enjoy having their build broken--it is a big waste of pro-bono time--so I want to understand the issues clearly. How are build-breaking changes getting into the master branch? CG section 3.4.10 says that the reason for pushing to staging is that automated tests are run before changes are moved to master. What specifically is being tested? And days before that happens, patches are announced as having been tested with the feedback "Passes make. make check and a full make doc." The evidence suggests that that does not include running autogen, otherwise it should have caught the problem with "tidy" that my own testing failed to catch. Should things such as missing optional programs and new-ish Python syntax be rejected at either of these stages? If not, then it would seem to fall to the submitter to set up an alternate development environment with Python 2.4, GCC 3.4, and similarly aged versions of other tools, and run additional tests in that environment. Thanks, — Dan
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
>> I still cannot do make-check this morning based on current master. > > I have no idea why the problem is only being discussed instead of > fixed, but I'll revert > > commit 911788f173eb58438fc9c850a005638d053b8bba > Author: Dan Eble > Date: Thu Oct 17 18:17:44 2019 -0400 > > Issue 5578: add a button to flip between old and new regtest images > > now so that people can figure out what to do without the development > process being blocked further. > > Expect my patchy-staging to finisn in about 45 minutes. Hmm. I now get PYTHONPATH=[...] \ PATH=[...] \ python2 \ test-lily/rsync-test.py \ --version-file=[...] --output-distance=[...] --test-dir=uploads/webtest \ --gub-target-dir=/.../gub/target/linux-64 File ".../scripts/build/output-distance.py", line 913 's' if len(paired) != 1 else '')) ^ SyntaxError: invalid syntax while running gub with lilypond's current master branch (commit fd1734364). Werner
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
Werner LEMBERG writes: >>> I still cannot do make-check this morning based on current master. >> >> I have no idea why the problem is only being discussed instead of >> fixed, but I'll revert >> >> commit 911788f173eb58438fc9c850a005638d053b8bba >> Author: Dan Eble >> Date: Thu Oct 17 18:17:44 2019 -0400 >> >> Issue 5578: add a button to flip between old and new regtest images >> >> now so that people can figure out what to do without the development >> process being blocked further. >> >> Expect my patchy-staging to finisn in about 45 minutes. > > Hmm. I now get > > PYTHONPATH=[...] \ > PATH=[...] \ > python2 \ > test-lily/rsync-test.py \ > --version-file=[...] > --output-distance=[...] > --test-dir=uploads/webtest \ > --gub-target-dir=/.../gub/target/linux-64 > File ".../scripts/build/output-distance.py", line 913 > 's' if len(paired) != 1 else '')) >^ > SyntaxError: invalid syntax > > while running gub with lilypond's current master branch (commit > fd1734364). Looks like a Python3-ism (or at least some newer version Pythonism) in commit 306fc6b509a9e71e16d54e11d11d70968aa4c3ef Author: Dan Eble Date: Wed Oct 16 18:51:34 2019 -0400 Issue 5576: make output-distance less verbose by default which would be an independent problem. I'll try reverting this one as well and hope that we don't get into a dependency hell for that. -- David Kastrup
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
James writes: > On 26/10/2019 09:37, Jonas Hahnfeld wrote: >> >> I already debugged this, and assuming you don't have tidy installed (I >> don't have either), please apply >> https://sourceforge.net/p/testlilyissues/issues/5586/ first. >> >> Regards, >> Jonas > > Sorry, I don't care. > > I still cannot do make-check this morning based on current master. I have no idea why the problem is only being discussed instead of fixed, but I'll revert commit 911788f173eb58438fc9c850a005638d053b8bba Author: Dan Eble Date: Thu Oct 17 18:17:44 2019 -0400 Issue 5578: add a button to flip between old and new regtest images now so that people can figure out what to do without the development process being blocked further. Expect my patchy-staging to finisn in about 45 minutes. -- David Kastrup
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
On 26/10/2019 09:37, Jonas Hahnfeld wrote: I already debugged this, and assuming you don't have tidy installed (I don't have either), please apply https://sourceforge.net/p/testlilyissues/issues/5586/ first. Regards, Jonas Sorry, I don't care. I still cannot do make-check this morning based on current master. Look everyone, I thought we had a defined process here - we should not be 'fixing as we go'. Either master works or it doesn't as far as I am concerned. If it doesn't then it is up to the devs to decide if they are going to revert master/staging so we can test *other* patches, or if a fix is done (without me testing) and it is pushed to staging and then merged immediately - assuming whoever is running patchymerge is doing it properly - so I can continue to test based on current master. My role is not to dance about broken master branches or apply this or that patch to broken staging/master so that other devs, who have patches in the queue 'now', have to wait until that fix is counted down and pushed before I can test their patches. So please fix staging/master - whoever, again I don't really care. That is not my responsibility. I just run build commands to test patches and make sure the reg test diffs (if there are any) are OK visually or not. I am just a glorified administrator that tries to keep track of patches so that developers can get on developing. So no patch testing again today either (at least from me anyway) James P.S. Also if 'Tidy' is a 'requirement' then make sure it is not listed in the 'please consider installing..' section that 'configure' spews out, but that it actually is listed in the requirements and make sure, either way it is documented in the CG.
Re: make check is broken (again) - patch testing seeming to taking more of my time than I like
Am Samstag, den 26.10.2019, 08:43 +0100 schrieb James: > 1. ./autogen --noconfigure > > 2. mkdir build > > 3. cd build > > 4 ../configure --disable-optimising > > 5. make -j7 CPU_COUNT=7 > > 6. make -j7 CPU_COUNT=7 test-baseline > > 7. make -j7 CPU_COUNT=7 check > > 8. > > ... > > no source for input/regression/midi/out-test/dynamic-initial-1.midi > no source for input/regression/midi/out-test/tree.gittxt > no source for input/regression/midi/out-test/sequence-name-2.midi > output-distance summary: > 3 changed > 467 below threshold >3562 unchanged > writing > /home/james/lilypond-git/build/out/test-results/input/regression/out-test-baseline/test-output-distance.png > writing > /home/james/lilypond-git/build/out/test-results/input/regression/out-test/test-output-distance.png > convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on > grayscale PNG `/tmp/tmplG8Fok/crop1.png' @ > warning/png.c/MagickPNGWarningHandler/1654. > convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on > grayscale PNG `/tmp/tmplG8Fok/crop2.png' @ > warning/png.c/MagickPNGWarningHandler/1654. > writing > /home/james/lilypond-git/build/out/test-results/input/regression/out-test-baseline/rest-dot-position.png > writing > /home/james/lilypond-git/build/out/test-results/input/regression/out-test/rest-dot-position.png > convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on > grayscale PNG `/tmp/tmplG8Fok/crop1.png' @ > warning/png.c/MagickPNGWarningHandler/1654. > convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on > grayscale PNG `/tmp/tmplG8Fok/crop2.png' @ > warning/png.c/MagickPNGWarningHandler/1654. > writing /home/james/lilypond-git/build/out/test-results/index.txt > Validating > /home/james/lilypond-git/build/out/test-results/input/regression/out-test/rest-dot-position.details.html > /bin/sh: 3: -: not found > /home/james/lilypond-git/GNUmakefile.in:370: recipe for target > 'local-check' failed > make: *** [local-check] Error 1 > > ... > > > Note that I didn't apply any patches (it also breaks when you apply > patches - in case you didn't get that). > > It seems that patch testing is getting more and more unreliable and time > consuming for me these last few months - I am the only one that bothers > to do it in case you didn't get that either. Testing from a supposed > clean master is throwing up stuff that never was detected when patches > were tested before being committed. > > I am not a developer, I just run a bunch-of-commands, in sequence, line > by command line, that I have always run (for like 8+ years). > > I use a vanilla Linux install from a very standard and popular > distribution (before someone asks me for the umpteenth time what I have > installed and tells me that it works for them). > > I am not going to even bother debugging this - as if I even could. > > No patch testing today folks! (currently 4 in the queue at the moment). > > I'll check back tomorrow and see if anything has changed. I already debugged this, and assuming you don't have tidy installed (I don't have either), please apply https://sourceforge.net/p/testlilyissues/issues/5586/ first. Regards, Jonas P.S.: I'll update the patch in a second to incorporate Dan's feedback. signature.asc Description: This is a digitally signed message part
make check is broken (again) - patch testing seeming to taking more of my time than I like
1. ./autogen --noconfigure 2. mkdir build 3. cd build 4 ../configure --disable-optimising 5. make -j7 CPU_COUNT=7 6. make -j7 CPU_COUNT=7 test-baseline 7. make -j7 CPU_COUNT=7 check 8. ... no source for input/regression/midi/out-test/dynamic-initial-1.midi no source for input/regression/midi/out-test/tree.gittxt no source for input/regression/midi/out-test/sequence-name-2.midi output-distance summary: 3 changed 467 below threshold 3562 unchanged writing /home/james/lilypond-git/build/out/test-results/input/regression/out-test-baseline/test-output-distance.png writing /home/james/lilypond-git/build/out/test-results/input/regression/out-test/test-output-distance.png convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG `/tmp/tmplG8Fok/crop1.png' @ warning/png.c/MagickPNGWarningHandler/1654. convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG `/tmp/tmplG8Fok/crop2.png' @ warning/png.c/MagickPNGWarningHandler/1654. writing /home/james/lilypond-git/build/out/test-results/input/regression/out-test-baseline/rest-dot-position.png writing /home/james/lilypond-git/build/out/test-results/input/regression/out-test/rest-dot-position.png convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG `/tmp/tmplG8Fok/crop1.png' @ warning/png.c/MagickPNGWarningHandler/1654. convert-im6.q16: profile 'icc': 'RGB ': RGB color space not permitted on grayscale PNG `/tmp/tmplG8Fok/crop2.png' @ warning/png.c/MagickPNGWarningHandler/1654. writing /home/james/lilypond-git/build/out/test-results/index.txt Validating /home/james/lilypond-git/build/out/test-results/input/regression/out-test/rest-dot-position.details.html /bin/sh: 3: -: not found /home/james/lilypond-git/GNUmakefile.in:370: recipe for target 'local-check' failed make: *** [local-check] Error 1 ... Note that I didn't apply any patches (it also breaks when you apply patches - in case you didn't get that). It seems that patch testing is getting more and more unreliable and time consuming for me these last few months - I am the only one that bothers to do it in case you didn't get that either. Testing from a supposed clean master is throwing up stuff that never was detected when patches were tested before being committed. I am not a developer, I just run a bunch-of-commands, in sequence, line by command line, that I have always run (for like 8+ years). I use a vanilla Linux install from a very standard and popular distribution (before someone asks me for the umpteenth time what I have installed and tells me that it works for them). I am not going to even bother debugging this - as if I even could. No patch testing today folks! (currently 4 in the queue at the moment). I'll check back tomorrow and see if anything has changed. bye. James
