Jonas Hahnfeld <hah...@hahnjo.de> writes:
> Am Sonntag, den 19.04.2020, 19:07 +0200 schrieb David Kastrup:
>> Jonas Hahnfeld <
>> hah...@hahnjo.de
>> > writes:
>>
>> > Am Sonntag, den 19.04.2020, 18:59 +0200 schrieb David Kastrup:
>> > > pat...@gnu.org
>> > >
>> > > writes:
>> > >
>> > > > 16:36:18 (UTC) Begin LilyPond compile, previous commit at
>> > > > 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > > > 16:36:21 From ssh://git.sv.gnu.org/srv/git/lilypond
>> > > > 12bf65758f..0cfef7069e master -> origin/master
>> > > > 12bf65758f..0cfef7069e staging -> origin/staging
>> > > > 16:36:27 Merged staging, now at:
>> > > > 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > > > 16:36:28 Success: ./autogen.sh --noconfigure
>> > > > 16:36:40 Success:
>> > > > /tmp/lilypond-autobuild/configure --enable-checking
>> > > > 16:36:43 Success: nice make clean
>> > > > 16:40:45 Success: nice make -j9 CPU_COUNT=9
>> > > > 16:42:04 *** FAILED BUILD ***
>> > > > nice make test -j9 CPU_COUNT=9
>> > > > Previous good commit: 12bf65758f33510e6b8e6e4d4a91bb1ebb459248
>> > > > Current broken commit: 0cfef7069e86f85ad392f5c4bc63f6c4801aa2c9
>> > > > 16:42:04 *** FAILED STEP ***
>> > > > merge from staging
>> > > > Failed runner: nice make test -j9 CPU_COUNT=9
>> > > > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>> > > > 16:42:04 Traceback (most recent call last):
>> > > > File
>> > > > "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> > > > line 528, in handle_staging
>> > > > self.build (issue_id=issue_id)
>> > > > File
>> > > > "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> > > > line 328, in build
>> > > > issue_id)
>> > > > File
>> > > > "/usr/local/tmp/lilypond-extra/patches/compile_lilypond_test/__init__.py",
>> > > > line 266, in runner
>> > > > raise FailedCommand ("Failed runner: %s\nSee the log file %s" %
>> > > > (command, this_logfilename))
>> > > > FailedCommand: Failed runner: nice make test -j9 CPU_COUNT=9
>> > > > See the log file log-staging-nice-make-test--j9-CPU_COUNT=9.txt
>> > >
>> > > That's again font-name-add-files.ly .
>> >
>> > Could you maybe share the exact error from make? I've been running this
>> > patch during the countdown and it also passes James' testing...
>>
>> I just get the filename so far. However, there is the following:
>>
>> dak@lola:/usr/local/tmp/lilypond$ guile
>> GNU Guile 2.2.7
>> Copyright (C) 1995-2019 Free Software Foundation, Inc.
>>
>> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
>> This program is free software, and you are welcome to redistribute it
>> under certain conditions; type `,show c' for details.
>>
>> Enter `,help' for help.
>> scheme@(guile-user)> (define bla (mkstemp! "kaka-XXXXXX"))
>> ERROR: In procedure mkstemp!:
>> string is read-only: "kaka-XXXXXX"
>>
>> Entering a new prompt. Type `,bt' for a backtrace or `,q' to continue.
>> scheme@(guile-user) [1]>
>>
>> I use Guile-1.8 in my Patchy (I hope) which should not detect this bug
>> but it still seems worth fixing as it breaks with Guile-2 at the latest.
>>
>> Also the file that is being created is not being created in some
>> temporary directory but in the _current_ directory. Not sure whether
>> that has something to do with it.
>
> It's passing right now with "my" Guile 1.8 and I gave it a try last
> week with Guile 2.2, without seeing an issue. Weird
There is also
\book {
#(let* ((port (open-output-file dummyfontfile)))
(base64-decode port dummyfont)
(close port))
#(ly:font-config-add-font dummyfontfile)
\markup \fontsize #20 \override #'(font-name . "DummyGPL") "A"
#(mkdir dummyfontdir)
#(let* ((port (open-output-file dummyfontfileInSubdir)))
(base64-decode port dummyfontAlt)
(close port))
#(ly:font-config-add-directory dummyfontdir)
\markup \fontsize #20 \override #'(font-name . "DummyGFDL") "A"
}
%% This will not appear in collated files:
\book {
#(delete-file dummyname)
#(delete-file dummyfontfile)
#(delete-file dummyfontfileInSubdir)
#(rmdir dummyfontdir)
\markup { These files and directories should have been removed:}
Note that the delete-file instructions are executed while the book is
being read in while markup is typeset when the books are being processed
at the end of the input file. No idea whether the fonts made it into
LilyPond at that point of time, or how happy LilyPond is with them
appearing. It might be appending to the font directory after it already
has been deleted?
There may well be race conditions here.
--
David Kastrup
