Re: Today's problem with GUB build
Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: > Here's the logfile and the ly file. > > Once we understand the issue, I'll wait until you say "go" for 21.4. Okay, we have the two doc fixes (mine for HTML and Masamichi's for PDF) and Han-Wen's renaming fix in master. This does not include the improvements for temp files (!254), but I think we should release 2.21.4 from what we have right now with the most pressing things fixed. So, release/unstable already contains the version bump - do we just merge master into the branch? Otherwise I can try figure out what it takes to force-push release/unstable; but I'd rather avoid that... Jonas signature.asc Description: This is a digitally signed message part
Re: Today's problem with GUB build
On Fri, Jul 17, 2020 at 5:05 PM Han-Wen Nienhuys wrote: > > On Fri, Jul 17, 2020 at 4:47 PM Han-Wen Nienhuys wrote: > > Maybe something is off with the init after fork, but GUILE's random > > initialization also doesn't look very reliable: > > > > https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/random.c/?id=5f22d1090bef72639f2744402c0466d8dbf8f8ac#n121 > > It gets better... if you pass a 64-bit number as seed, instead of > using that directly, the RNG will ... convert that to decimal and then > use that string to initialize. See https://gitlab.com/lilypond/lilypond/-/merge_requests/254 -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Today's problem with GUB build
On Fri, Jul 17, 2020 at 4:47 PM Han-Wen Nienhuys wrote: > Maybe something is off with the init after fork, but GUILE's random > initialization also doesn't look very reliable: > > https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/random.c/?id=5f22d1090bef72639f2744402c0466d8dbf8f8ac#n121 It gets better... if you pass a 64-bit number as seed, instead of using that directly, the RNG will ... convert that to decimal and then use that string to initialize. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Today's problem with GUB build
On Thu, Jul 16, 2020 at 10:58 AM David Kastrup wrote: > > Han-Wen Nienhuys writes: > > > On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote: > > > >> Well ok. But only 100 random numbers are being used (there is > >> another call using 1000 instead, the choice appearing random). > >> Let's assume we have 10 processes going through 138 files each. The > >> processes are going to switch to the next output file asynchronously, so > >> with any change, there is a chance of the old number colliding with the > >> other processes' numbers, and the new number colliding. The probability > >> that a new number is different from an existing set of 9 is > >> 91/100. If we do this switch 1380 times, the probability of a > >> collision during one run is 1-(91/100)^1380, about 1 in 80. > > > > I don't think this analysis is correct. In order for two numbers to > > meaningfully collide, they have to be picked at the same time (since > > we rename the files afterwards.). > > And 10 numbers are picked at the same time since 10 processes work on > their temporary files at the same time. My apologies, your analysis correct. That said, I am still skeptical of this being the explanation. 100 as a random number was actually used for midi output, which uses the input as a basename. So you'd need to have1000 parallel instances working on the same file to get a 50% chance of collision. The /tmp version used 10M , which -according to your calculation- would yield a 0.01% chance of colliding. Maybe something is off with the init after fork, but GUILE's random initialization also doesn't look very reliable: https://git.savannah.nongnu.org/cgit/guile.git//tree/libguile/random.c/?id=5f22d1090bef72639f2744402c0466d8dbf8f8ac#n121 if you permute bytes at distance 8 in the seed, you'll get the same seed. I'll just add a loop to retry. Note that the original version of this MR used the final destination as the basename for the temp file, which was why I didn't use a loop in the first place. (I still think that is the better design.) > > The birthday attack says you need 1000 parallel instances to get a 50% > > of collision. > > For a single occasion of collision. Not for 1300 occasions in sequence. > How about addressing my actual argument? > > >> Now if I remember correctly, there were some changes in how > >> lilypond-book worked that typically resulted in double the number of > >> processes getting spawned than asked for which would give us 19 instead > >> of 9 possibilities for collision. That would raise the probability of a > >> collision to about 1 in 40 runs. > > > > I think you misremember. The command > > > > make -jN CPU_COUNT=N > > > > will potentially spawn 2*N -1 processes: 1 x lilypond-book with N > > children and N- 1 other processes. > > So back to 1 in 80. Still not the best odds if a collision is fatal. > > -- > David Kastrup -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Today's problem with GUB build
Han-Wen Nienhuys writes: > On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote: > >> Well ok. But only 100 random numbers are being used (there is >> another call using 1000 instead, the choice appearing random). >> Let's assume we have 10 processes going through 138 files each. The >> processes are going to switch to the next output file asynchronously, so >> with any change, there is a chance of the old number colliding with the >> other processes' numbers, and the new number colliding. The probability >> that a new number is different from an existing set of 9 is >> 91/100. If we do this switch 1380 times, the probability of a >> collision during one run is 1-(91/100)^1380, about 1 in 80. > > I don't think this analysis is correct. In order for two numbers to > meaningfully collide, they have to be picked at the same time (since > we rename the files afterwards.). And 10 numbers are picked at the same time since 10 processes work on their temporary files at the same time. > The birthday attack says you need 1000 parallel instances to get a 50% > of collision. For a single occasion of collision. Not for 1300 occasions in sequence. How about addressing my actual argument? >> Now if I remember correctly, there were some changes in how >> lilypond-book worked that typically resulted in double the number of >> processes getting spawned than asked for which would give us 19 instead >> of 9 possibilities for collision. That would raise the probability of a >> collision to about 1 in 40 runs. > > I think you misremember. The command > > make -jN CPU_COUNT=N > > will potentially spawn 2*N -1 processes: 1 x lilypond-book with N > children and N- 1 other processes. So back to 1 in 80. Still not the best odds if a collision is fatal. -- David Kastrup
Re: Today's problem with GUB build
On Wed, Jul 15, 2020 at 10:48 PM David Kastrup wrote: > Well ok. But only 100 random numbers are being used (there is > another call using 1000 instead, the choice appearing random). > Let's assume we have 10 processes going through 138 files each. The > processes are going to switch to the next output file asynchronously, so > with any change, there is a chance of the old number colliding with the > other processes' numbers, and the new number colliding. The probability > that a new number is different from an existing set of 9 is > 91/100. If we do this switch 1380 times, the probability of a > collision during one run is 1-(91/100)^1380, about 1 in 80. I don't think this analysis is correct. In order for two numbers to meaningfully collide, they have to be picked at the same time (since we rename the files afterwards.). The birthday attack says you need 1000 parallel instances to get a 50% of collision. > Now if I remember correctly, there were some changes in how > lilypond-book worked that typically resulted in double the number of > processes getting spawned than asked for which would give us 19 instead > of 9 possibilities for collision. That would raise the probability of a > collision to about 1 in 40 runs. I think you misremember. The command make -jN CPU_COUNT=N will potentially spawn 2*N -1 processes: 1 x lilypond-book with N children and N- 1 other processes. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Re: Today's problem with GUB build
Le 15/07/2020 à 22:48, David Kastrup a écrit : Now if I remember correctly, there were some changes in how lilypond-book worked that typically resulted in double the number of processes getting spawned than asked for which would give us 19 instead of 9 possibilities for collision. That would raise the probability of a collision to about 1 in 40 runs. Can you point to the MR? I don't see that in the code and I was actually under the impression that lilypond-book did not do any parallel processing currently. Jean
Re: Today's problem with GUB build
Hi David, Le 15/07/2020 à 23:01, David Kastrup a écrit : Not using random at all but using the pid, in contrast, should be collision-proof, assuming that we are not working on a shared file system accessed by multiple computers with separate process id pools. But then locking is likely to be non-working anyway. The async I/O approach that I'd like to introduce in lilypond-book if I manage to should fix the collision risk. Best, Jean
Re: Today's problem with GUB build
David Kastrup writes: > Jonas Hahnfeld writes: > >> Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup: >>> Jonas Hahnfeld writes: >>> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: >>> > > Here's the logfile and the ly file. >>> > >>> > Could this be collisions of the random file names generated for >>> > temporary files? The argument to backend-library.scm:248 comes >>> > from create-file-exclusive which returns #f if the file already exists >>> > (or could not be created). >>> >>> I had commented on the respective issue without response that the >>> parallel processes, without taking additional measures, will generate >>> the same "random" sequence, making this no better than just using >>> sequential numbers. >> >> "additional measures" are in place: multi-fork calls randomize-rand- >> seed *after* forking. The seed is initialized based on the current >> timestamp (might be the same) and the pid (different in the course of >> one run). We can still have collisions, but the amount of trouble (or >> rather the lack of reports until now) indicates that it is better than >> sequential numbers. This was discussed (and answered) in the review. > > Well ok. But only 100 random numbers are being used (there is > another call using 1000 instead, the choice appearing random). > Let's assume we have 10 processes going through 138 files each. The > processes are going to switch to the next output file asynchronously, so > with any change, there is a chance of the old number colliding with the > other processes' numbers, and the new number colliding. The probability > that a new number is different from an existing set of 9 is > 91/100. If we do this switch 1380 times, the probability of a > collision during one run is 1-(91/100)^1380, about 1 in 80. > > Now if I remember correctly, there were some changes in how > lilypond-book worked that typically resulted in double the number of > processes getting spawned than asked for which would give us 19 instead > of 9 possibilities for collision. That would raise the probability of a > collision to about 1 in 40 runs. Not using random at all but using the pid, in contrast, should be collision-proof, assuming that we are not working on a shared file system accessed by multiple computers with separate process id pools. But then locking is likely to be non-working anyway. -- David Kastrup
Re: Today's problem with GUB build
Jonas Hahnfeld writes: > Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup: >> Jonas Hahnfeld writes: >> > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: >> > > Here's the logfile and the ly file. >> > >> > Could this be collisions of the random file names generated for >> > temporary files? The argument to backend-library.scm:248 comes >> > from create-file-exclusive which returns #f if the file already exists >> > (or could not be created). >> >> I had commented on the respective issue without response that the >> parallel processes, without taking additional measures, will generate >> the same "random" sequence, making this no better than just using >> sequential numbers. > > "additional measures" are in place: multi-fork calls randomize-rand- > seed *after* forking. The seed is initialized based on the current > timestamp (might be the same) and the pid (different in the course of > one run). We can still have collisions, but the amount of trouble (or > rather the lack of reports until now) indicates that it is better than > sequential numbers. This was discussed (and answered) in the review. Well ok. But only 100 random numbers are being used (there is another call using 1000 instead, the choice appearing random). Let's assume we have 10 processes going through 138 files each. The processes are going to switch to the next output file asynchronously, so with any change, there is a chance of the old number colliding with the other processes' numbers, and the new number colliding. The probability that a new number is different from an existing set of 9 is 91/100. If we do this switch 1380 times, the probability of a collision during one run is 1-(91/100)^1380, about 1 in 80. Now if I remember correctly, there were some changes in how lilypond-book worked that typically resulted in double the number of processes getting spawned than asked for which would give us 19 instead of 9 possibilities for collision. That would raise the probability of a collision to about 1 in 40 runs. -- David Kastrup
Re: Today's problem with GUB build
Am Mittwoch, den 15.07.2020, 21:35 +0200 schrieb David Kastrup: > Jonas Hahnfeld writes: > > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: > > > Here's the logfile and the ly file. > > > > Could this be collisions of the random file names generated for > > temporary files? The argument to backend-library.scm:248 comes > > from create-file-exclusive which returns #f if the file already exists > > (or could not be created). > > I had commented on the respective issue without response that the > parallel processes, without taking additional measures, will generate > the same "random" sequence, making this no better than just using > sequential numbers. "additional measures" are in place: multi-fork calls randomize-rand- seed *after* forking. The seed is initialized based on the current timestamp (might be the same) and the pid (different in the course of one run). We can still have collisions, but the amount of trouble (or rather the lack of reports until now) indicates that it is better than sequential numbers. This was discussed (and answered) in the review. signature.asc Description: This is a digitally signed message part
Re: Today's problem with GUB build
Jonas Hahnfeld writes: > Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: >> Here's the logfile and the ly file. > > Could this be collisions of the random file names generated for > temporary files? The argument to backend-library.scm:248 comes > from create-file-exclusive which returns #f if the file already exists > (or could not be created). I had commented on the respective issue without response that the parallel processes, without taking additional measures, will generate the same "random" sequence, making this no better than just using sequential numbers. -- David Kastrup
Re: Today's problem with GUB build
Le 15/07/2020 à 19:44, Jean Abou Samra a écrit :
Hi,
Le 15/07/2020 à 18:31, Phil Holmes a écrit :
Here's the logfile and the ly file.
/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5:
In procedure close-port in expression (close-port port):
/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5:
Wrong type argument in position 1 (expecting port): #f
I recall having seen a failure of the same kind yesterday in a make
test. After a make test-clean, it all went fine. Could it be that you
need to clean the tree somehow like a make doc-clean?
Okay, I was plain wrong. Just got this after a make test-clean && make test:
testing /home/jean/repos/lilypond/scripts/build/output-distance.py
Making ly/out/welcome.pdf < Welcome_to_LilyPond.ly
Making ly/out/welcome.png < Welcome_to_LilyPond.ly
Making ly/out/welcome.svg < Welcome_to_LilyPond.ly
Making ly/out/welcome_eps.pdf < Welcome_to_LilyPond.ly
Please check the logfile
/home/jean/repos/lilypond/build/ly/welcome.pdf.log
for errors. Last 20 lines:
?: 9* [#]
In /home/jean/repos/lilypond/build/out/share/lilypond/current/scm/lily.scm:
1114: 10* [ly:parse-file
"/home/jean/repos/lilypond/ly/Welcome_to_LilyPond.ly"]
In /home/jean/repos/lilypond/build/out/share/lilypond/current/ly/init.ly:
76: 11* (let* ((book-handler #)) (cond (# #) (# #)))
79: 12 (cond (# #) (# #))
In
/home/jean/repos/lilypond/build/out/share/lilypond/current/scm/lily-library.scm:
...
247: 13 [ly:book-process # #< Output_def> #< Output_def> "welcome"]
In unknown file:
?: 14* [output-framework "welcome" # (#7fc20d78af60>) ()]
In
/home/jean/repos/lilypond/build/out/share/lilypond/current/scm/framework-ps.scm:
738: 15* (let* (# # # # ...) (if # #) (initialize-font-embedding) ...)
738: 16* [make-tmpfile "welcome"]
In
/home/jean/repos/lilypond/build/out/share/lilypond/current/scm/backend-library.scm:
244: 17 (let* ((name #) (port #) (bport #)) (close-port port) bport)
248: 18* [close-port {#f}]
/home/jean/repos/lilypond/build/out/share/lilypond/current/scm/backend-library.scm:248:5:
In procedure close-port in expression (close-port port):
/home/jean/repos/lilypond/build/out/share/lilypond/current/scm/backend-library.scm:248:5:
Wrong type argument in position 1 (expecting port): #f
make[1]: *** [/home/jean/repos/lilypond/build/.././ly/GNUmakefile:20:
welcome.pdf] Error 1
make[1]: *** Waiting for unfinished jobs
make: *** [/home/jean/repos/lilypond/build/../GNUmakefile.in:292 : test]
Erreur 2
The actual fix was… err… git clean -xdf and building from scratch.
Hope that helps in some way.
Jean
Re: Today's problem with GUB build
Hi, Le 15/07/2020 à 18:31, Phil Holmes a écrit : Here's the logfile and the ly file. /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5: In procedure close-port in expression (close-port port): /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5: Wrong type argument in position 1 (expecting port): #f I recall having seen a failure of the same kind yesterday in a make test. After a make test-clean, it all went fine. Could it be that you need to clean the tree somehow like a make doc-clean? Cheers, Jean
Re: Today's problem with GUB build
Am Mittwoch, den 15.07.2020, 17:31 +0100 schrieb Phil Holmes: > Here's the logfile and the ly file. Could this be collisions of the random file names generated for temporary files? The argument to backend-library.scm:248 comes from create-file-exclusive which returns #f if the file already exists (or could not be created). Forking into jobs: (21124 21123 21122 21121 21120 21119 21118 21117) logfile lilypond-multi-run-3.log (exit 1): Processing `./c4/lily-b2be0729.ly' Parsing... Interpreting music... Preprocessing graphical objects... Calculating line breaks... Drawing systems... Writing ./c4/lily-b2be0729-1.signature Layout output to `./c4/lily-b2be0729.eps'... Converting to `./c4/lily-b2be0729.pdf'... /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5: In procedure close-port in expression (close-port port): /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:248:5: Wrong type argument in position 1 (expecting port): #f logfile lilypond-multi-run-1.log (exit 1): Processing `./c9/lily-745608fe.ly' Parsing... Interpreting music... Preprocessing graphical objects... Calculating line breaks... Drawing systems... Writing ./c9/lily-745608fe-1.signature Layout output to `./c9/lily-745608fe.eps'... Converting to `./c9/lily-745608fe.pdf'... /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:108:5: In procedure rename-file in expression (rename-file pdf-name dest): /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:108:5: No such file or directory fatal error: Children (3 1) exited with errors. signature.asc Description: This is a digitally signed message part
Re: Today's problem with GUB build
Here's the logfile and the ly file. Once we understand the issue, I'll wait until you say "go" for 21.4. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Wednesday, July 15, 2020 4:31 PM Subject: Re: Today's problem with GUB build snippet-map-bcc309d5e1e5a6301f36814c1d4d872c.ly 03/lily-fe271a83.ly 1a/lily-8bf6a717.ly 1b/lily-078e147a.ly 2d/lily-6aba4240.ly 2f/lily-dfa3e9b3.ly 32/lily-6a5101eb.ly 3a/lily-6be5f72e.ly 3e/lily-8cc6ae6f.ly 3e/lily-c910bcd3.ly 4a/lily-53e1472d.ly 4b/lily-1cae6603.ly 4d/lily-81647c29.ly 4d/lily-b68bee77.ly 4f/lily-528ba80b.ly 5d/lily-00a8e953.ly 68/lily-0719c095.ly 69/lily-0c146c35.ly 73/lily-501a5a38.ly 75/lily-c07b1519.ly 77/lily-9e016ba0.ly 90/lily-558e4780.ly 94/lily-dec79207.ly 98/lily-d0ac7612.ly b2/lily-1446d680.ly b2/lily-26dfe8f9.ly b3/lily-cac0e6d3.ly c4/lily-8d95e596.ly c4/lily-b2be0729.ly c9/lily-3a3639cf.ly c9/lily-745608fe.ly d2/lily-61c512af.ly e7/lily-46341530.ly e7/lily-9d77bd0c.ly snippet-names-bcc309d5e1e5a6301f36814c1d4d872c.log Description: Binary data
Re: Today's problem with GUB build
Am Mittwoch, den 15.07.2020, 16:26 +0100 schrieb Phil Holmes: > Here's the lilypond-doc.log zipped. Do you happen to still have out/lybook-db/snippet-names- bcc309d5e1e5a6301f36814c1d4d872c.log around? In any case, it's odd that you're seeing issues with the very same base commit as 2.21.3 > I was doing a new release to get the documentation on the website looking > correct again. As I said: This won't be the case with the current release/unstable because it doesn't have my fix merged. In my opinion, we need to merge https://gitlab.com/lilypond/lilypond/-/merge_requests/246 to master and then do another release from there. > We've had problems in the past if the build number is not > incremented. > > If I don't get problems I can easily do another release with the updates you > mentioned. If I get me act together, I plan to do a release every couple of > weeks anyway. > > -- > Phil Holmes > > > - Original Message - > From: "Jonas Hahnfeld" < > hah...@hahnjo.de > > > To: "Phil Holmes" < > em...@philholmes.net > >; "Devel" < > lilypond-devel@gnu.org > > > Sent: Wednesday, July 15, 2020 4:09 PM > Subject: Re: Today's problem with GUB build > > signature.asc Description: This is a digitally signed message part
Re: Today's problem with GUB build
Here's the lilypond-doc.log zipped. I was doing a new release to get the documentation on the website looking correct again. We've had problems in the past if the build number is not incremented. If I don't get problems I can easily do another release with the updates you mentioned. If I get me act together, I plan to do a release every couple of weeks anyway. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Wednesday, July 15, 2020 4:09 PM Subject: Re: Today's problem with GUB build <>
Re: Today's problem with GUB build
Am Mittwoch, den 15.07.2020, 15:04 +0100 schrieb Phil Holmes: > I get this: > > Making Documentation/out-www/web.texi (copy) > Command '/home/gub/NewGub/gub/target/linux-x86/root/usr/bin/lilypond \ > -dbackend=eps --formats=ps,png,pdf -djob-count=8 -dinclude-eps-fonts > -dgs-load-fonts > --header=doctitle --header=doctitleca --header=doctitlecs > --header=doctitlede > --header=doctitlees --header=doctitlefr --header=doctitlehu > --header=doctitleit > --header=doctitleja --header=doctitlenl --header=doctitlept > --header=doctitlezh > --header=texidoc --header=texidocca --header=texidoccs --header=texidocde > --header=texidoces > --header=texidocfr --header=texidochu --header=texidocit --header=texidocja > --header=texidocnl --header=texidocpt --header=texidoczh > -dcheck-internal-types > -ddump-signatures -danti-alias-factor=2 > -dfont-ps-resdir=/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/out-fonts > > -O TeX-GS -I "./" -I > "/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation" > > -I > "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation" > > -I > "/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/out-www" > > -I > "/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/snippets/out" > > -I > "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/included" > > -I > "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/pictures" > > -I > "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation" > > -I > "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression" > > --formats=eps -deps-box-padding=3.00 -dread-file-list > -dno-strip-output-dir > /home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/out/lybook-db/snippet-names-bcc309d5e1e5a6301f36814c1d4d872c.ly' > > returned non-zero exit status 1. > make[2]: *** [out-www/notation.texi] Error 1 > make[2]: *** Deleting file `out-www/notation.texi' > make[2]: *** Waiting for unfinished jobs > make[1]: *** [WWW-1] Error 2 > make: *** [doc-stage-1] Error 2 Without more detailed logs, that will be hard to guess. However, I don't get the purpose of releasing 2.21.4 from the same base commit as 2.21.3? release/unstable doesn't have the merged translations nor the fix for the documentation build in GUB. Did I miss something? (The reduction of PDF sizes by Masamichi-san would also be good to have in the next release.) (Part of the confusion might be my Pull Request for GUB, see https://github.com/gperciva/gub/pull/75. This has nothing to do with the documentation build which is related to the version of Perl.) Jonas signature.asc Description: This is a digitally signed message part
Today's problem with GUB build
I get this: Making Documentation/out-www/web.texi (copy) Command '/home/gub/NewGub/gub/target/linux-x86/root/usr/bin/lilypond \ -dbackend=eps --formats=ps,png,pdf -djob-count=8 -dinclude-eps-fonts -dgs-load-fonts --header=doctitle --header=doctitleca --header=doctitlecs --header=doctitlede --header=doctitlees --header=doctitlefr --header=doctitlehu --header=doctitleit --header=doctitleja --header=doctitlenl --header=doctitlept --header=doctitlezh --header=texidoc --header=texidocca --header=texidoccs --header=texidocde --header=texidoces --header=texidocfr --header=texidochu --header=texidocit --header=texidocja --header=texidocnl --header=texidocpt --header=texidoczh -dcheck-internal-types -ddump-signatures -danti-alias-factor=2 -dfont-ps-resdir=/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/out-fonts -O TeX-GS -I "./" -I "/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation" -I "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation" -I "/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/out-www" -I "/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/snippets/out" -I "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/included" -I "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation/pictures" -I "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/Documentation" -I "/home/gub/NewGub/gub/target/linux-x86/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/input/regression" --formats=eps -deps-box-padding=3.00 -dread-file-list -dno-strip-output-dir /home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/out/lybook-db/snippet-names-bcc309d5e1e5a6301f36814c1d4d872c.ly' returned non-zero exit status 1. make[2]: *** [out-www/notation.texi] Error 1 make[2]: *** Deleting file `out-www/notation.texi' make[2]: *** Waiting for unfinished jobs make[1]: *** [WWW-1] Error 2 make: *** [doc-stage-1] Error 2 -- Phil Holmes
