On 2024-11-30 13:37, Jean-Charles Malahieude wrote:
On a fresh repo, make doc chokes on
input/regression/include-path-modification and I'm unable to resolve this.
Excerpt of the log:
```
Renaming input to: `include-path-modification-i.ly'
include-path-modification-i.ly:13:2: er
Hi,
On a fresh repo, make doc chokes on
input/regression/include-path-modification and I'm unable to resolve this.
The log file is attached.
Cheers,
--
Jean-CharlesGNU LilyPond 2.25.22 (running Guile 3.0)
Processing `12/lily-b0020de6.ly'
Parsing...
Renaming input to: `in
At 08:03 on 28 Nov 2024, Dan Eble wrote:
> On 2024-11-28 03:39, Mark Knoop wrote:
>> Hi,
>> Documentation and Info pages builds are currently failing
>> for me - anyone else having this problem? This is on
>> current master (6df7159). The tail of the failing log
>> file is attached - seems to be a
On 2024-11-28 03:39, Mark Knoop wrote:
Hi,
Documentation and Info pages builds are currently failing for me - anyone else
having this problem? This is on current master (6df7159). The tail of the
failing log file is attached - seems to be a font issue with NotoSerif?
The log ends with this:
Hi,
Documentation and Info pages builds are currently failing for me - anyone else
having this problem? This is on current master (6df7159). The tail of the
failing log file is attached - seems to be a font issue with NotoSerif?
`make doc` fails at collated-files.text; `make info` fails at
> While building the docs, I encounter a number of warnings
>
> WARNING: The convert command is deprecated in IMv7, use "magick"
> instead of "convert" or "magick convert"
This is new – and confusing: for example, I have ImageMagick 7.1.0-9
installed on my system (which is thus 'IMv7', too), and
Hi all,
While building the docs, I encounter a number of warnings
WARNING: The convert command is deprecated in IMv7, use "magick" instead
of "convert" or "magick convert"
when in Documentation/out-www/ly-examples/
and Documentation/out-www/pictures/
Do I have to bother about it?
Cheers,
--
Folks,
Carl wrote to me privately:
> OK, so now I have a failure:
>
> I did
>
> ```
> rm -rf build
> mkdir build
> cd build
> ../autogen.sh --currdir
> ../configure &> configure.log
> make -j10 CPU_COUNT=10 all
> make doc LANGS="en" VERBOS
> I can confirm that I get the proper HTML pages, compiling with -j10
> on both make bytecode and make doc.
Great!
> It was delightful to see the proper lilypond website on my local
> file system! Thank you so much for fixing this!
Glad that I could help. I will now poli
On Mon, Feb 12, 2024 at 9:22 AM Werner LEMBERG wrote:
>
> v2.25.13-8-gbe52228a70
>
> Please test again! Theoretically, you should now get proper HTML
> pages.
>
I can confirm that I get the proper HTML pages, compiling with -j10 on both
make bytecode and make doc.
It was
On Sat, Feb 10, 2024 at 7:20 AM Werner LEMBERG wrote:
>
> >> systems like macOS that neither have or use '/bin/bash'.
> >
> > Apple changed the default shell for new users to zsh about 5 years
> > ago, but bash is still there. I don't oppose making the build
> > scripts more portable, but let's
>> systems like macOS that neither have or use '/bin/bash'.
>
> Apple changed the default shell for new users to zsh about 5 years
> ago, but bash is still there. I don't oppose making the build
> scripts more portable, but let's not misunderstand the situation.
OK, thanks – let's see whether t
On 2024-02-10 07:52, Werner LEMBERG wrote:
systems like macOS that neither have or use '/bin/bash'.
Apple changed the default shell for new users to zsh about 5 years ago,
but bash is still there. I don't oppose making the build scripts more
portable, but let's not misunderstand the situati
y to
systems like macOS that neither have or use '/bin/bash'.
Carl, please do another run of the following commands based on the
updated 'dev/wl/build-fixes' branch, then create and upload a tarball
of your `build` directory as before and send me a link to it.
```
./configure
make by
> If I click on the Notation link from that page, I get to:
>
> out-www/offline-root/Documentation/web/notation.html
>
> which has no css, but has lots of links.
This shouldn't happen, and it means that your documentation build is
still not correct.
> I'm happy to send a tar file of my offlin
> "/Users/carl/Development/lilypond/build/out/lybook-db/
> snippet-names-c5b165525229969dd268a5b19f9f64fd.ly"' returned
> non-zero exit status 1.
Please try to find out which of the snippet files mentioned in the
above file failed. `*.log` files should be in directory
`out/lybook-db`, too, and
cOS cp and
find.
I still got errors if I tried make doc with -j12. But without -j12 it
succeeded.
There are some minor issues with either the way the documentation is built
or the way I am using it.
IIRC, in the past, I could use Documentation/out-www/index.html as a
beginning place for documentatio
> > now on to your requested steps:
>
> Ah, my steps were not intended to be used additionally but instead :-)
>
Ah, so I tried that.
```
../configure
make bytecode -j12
```
Ran without error.
```
carl@carls-mbp-2 build % make doc -j12 CPU_COUNT=12 LANGS="en"
Making inp
>> > I omitted the '-l' option in the cp calls in the patch.
>> >
>> > 'make doc' succeeded without any errors, so I thought I had success. But
>> > it turns out that
>> >
>> > a) I appear not to have the .css files co
[Carl sent me the file listing off-list, thanks! I will analyze it in
due course.]
> [...] and make test with a single job (to avoid race conditions that
> have given me trouble in the past):
Interesting. When is the 'past'? This shouldn't happen today, and it
would be great if you could try
oblem with `cp -l` on your macOS. It's
> still hard to believe.
>
Yes, and apparently it's a new bug (older versions of the OS didn't have
it, IIUC).
>
> BTW, which macOS version are you using?
>
Sonoma 14.2.1 (23C71)
>
> > I omitted the '-l'
g?
> I omitted the '-l' option in the cp calls in the patch.
>
> 'make doc' succeeded without any errors, so I thought I had success. But
> it turns out that
>
> a) I appear not to have the .css files copied (at least the output
>showed no css -- just b
`cp` calls in my patch.
>
I checked -- the results of the problem were different for me than for the
bug report. I got the error message, but the hard link was never copied
(there were not two files with the same inode -- only the original file.
I omitted the '-l' option in the cp call
> 'make doc' failed.
>
> It appears that under some conditions, we end up with a path
> including '//'.
Multiple slashes in succession are completely harmless; they are
simply equivalent to `/`.
Doing a bit of an internet search it seems this is a bug in the
7;ve encountered.
>
It seems to work, but not perfectly. 'make all' and 'make test' work.
'make doc' failed.
It appears that under some conditions, we end up with a path including '//'.
Log file attached.
Thanks,
Carl
make.doc.log.gz
Description: GNU Zip compressed data
> I've attached three compressed log files. [...]
Thanks a lot, very helpful. Please apply the attached patch to the
top-level `GNUmakefile.in` file, then retry from scratch (including
the `configure` step); it should catch all of the three problems
you've encountered.
The `-maxdepth` and `-mi
gt; Please give more details. What problems did you experience with `cp`
> and `find`? Did this happen during a call to `make ...` for LilyPond?
>
All errors happened during 'make doc'. They appeared to happen after all
of the lilypond processing was done, while creating the html docume
s, for example.
> I then get to a problem with perl: [...]
Interesting. I wasn't aware that we ever call `perl` with a long list
of arguments during `make doc`.
Please repeat this with saying
```
make doc VERBOSE=1 &> make.doc.log
```
so that we can more information in the log file. U
Still trying to get 'make doc' to complete successfully.
At this point, I think I'm through all the lilypond stuff, and now I'm
stuck in shell script errors.
I already had to install (via homebrew) gnu coreutils and gnu findutils,
since the MacOS 'cp' and 'fi
>> Aah, this looks like a bug in `typography-demo.ly`. Please try the
>> following line in `typography-demo.ly` instead of the three
>> original font lines.
>>
>> ```
>> property-defaults.fonts.serif = "Linux Libertine O, Noto Serif CJK JP, Noto
>> Serif JP, serif"
>> ```
>
> I can confirm that
On Wed, Jan 24, 2024 at 11:49 PM Werner LEMBERG wrote:
>
> >> I installed Noto Serif JP, and added it to the fontcofig cache.
> >> That got me through the previous file error. But then I got
> >> stopped on another Japanese font (I suppose this might be a Linux
> >> Libertine font, but my fc-lis
>> I installed Noto Serif JP, and added it to the fontcofig cache.
>> That got me through the previous file error. But then I got
>> stopped on another Japanese font (I suppose this might be a Linux
>> Libertine font, but my fc-list command shows that I have them
>> installed):
Interesting. Th
On Tue, Jan 23, 2024 at 4:54 AM Carl Sorensen
wrote:
>
>
> On Mon, Jan 22, 2024 at 8:37 PM Carl Sorensen
> wrote:
>
>>
>>
>> On Mon, Jan 22, 2024 at 5:58 PM Jean Abou Samra
>> wrote:
>>
>>> Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
>>> > > Looks like no error:
>>> > >
>>>
> carl@Carls-MBP-2 lilypond % tidy --version
>
> HTML Tidy for Mac OS X released on 31 October 2006 - Apple Inc. build 6141
This explains the failure, thanks: Your `tidy` version doesn't support
HTML 5. I've submitted an MR to catch this.
https://gitlab.com/lilypond/lilypond/-/merge_request
On Mon, Jan 22, 2024 at 8:37 PM Carl Sorensen
wrote:
>
>
> On Mon, Jan 22, 2024 at 5:58 PM Jean Abou Samra
> wrote:
>
>> Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
>> > > Looks like no error:
>> > >
>> > > carl@Carls-MBP-2 lilypond % build/out/bin/lilypond input/regression/
>> Can someone remind me why the build system sets the C locale in the
>> first place?
>
> Answering my own question: I guess it is because we can't assume the
> system has an en_US.UTF-8 locale or a C.UTF-8 locale?
Exactly. Some time ago (see
https://lists.gnu.org/archive/html/lilypond-devel/2
On Mon, Jan 22, 2024 at 5:58 PM Jean Abou Samra wrote:
> Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
> > > Looks like no error:
> > >
> > > carl@Carls-MBP-2 lilypond % build/out/bin/lilypond input/regression/
> pdf-copy-paste.ly
> > > GNU LilyPond 2.25.13 (running Guile 3.0)
>
> Can someone remind me why the build system sets the C locale
> in the first place?
Answering my own question: I guess it is because we can't assume the
system has an en_US.UTF-8 locale or a C.UTF-8 locale?
Maybe we ought to set only LC_MESSAGES to C? It should prevent overriding
the system loc
Ah, but, wait.
$ touch àéù.txt
$ guile3.0
scheme@(guile-user)> (open-file "àéù.txt" "r")
$1 = #
~/tmp $ LC_ALL=C guile3.0
scheme@(guile-user)> (open-file "àéù.txt" "r")
ice-9/boot-9.scm:1685:16: In procedure raise-exception:
In procedure open-file: No such file or directory: "??.txt"
OK,
Le lundi 22 janvier 2024 à 18:00 -0700, Carl Sorensen a écrit :
> So I ran the file in this log message:
>
>
> carl@carls-mbp-2 build % out/bin/lilypond out/share/lilypond/current/ly/
> init.ly
>
> GNU LilyPond 2.25.13 (running Guile 3.0)
>
> Processing `out/share/lilypond/current/ly/init.ly'
>
Le mardi 23 janvier 2024 à 01:58 +0100, Jean Abou Samra a écrit :
> The latter is basically that this regtest (pdf-copy-paste.ly)
> has Japanese text, specifying the Noto Serif JP font, but since
> you apparently don't have that font installed, Fontconfig falls
> back to some system font, and appar
uld actually try that
>> >> before running `make doc`...
>> >>
>> >
>> > Interesting -- the CG has make doc show up before make test. But I
>> > appreciate the suggestion, so I decided to restart
>> >
>> > So I did a make clean,
Le lundi 22 janvier 2024 à 16:38 -0700, Carl Sorensen a écrit :
> > Looks like no error:
> >
> > carl@Carls-MBP-2 lilypond % build/out/bin/lilypond
> > input/regression/pdf-copy-paste.ly
> > GNU LilyPond 2.25.13 (running Guile 3.0)
> > Processing `input/regression/pdf-copy-paste.ly'
> > Parsing..
On Mon, Jan 22, 2024 at 3:58 PM Jean Abou Samra wrote:
> Le lundi 22 janvier 2024 à 21:10 +, Werner LEMBERG a écrit :
> > > >
> > OK, thanks. This means that there is apparently a macOS-specific
> > problem with either Guile or LilyPond. For testing purposes I renamed
> > one of my local fo
On Sun, Jan 21, 2024 at 12:33 AM Werner LEMBERG wrote:
>
> >> You have to check the log files in `lybook-db` to find the problematic
> >> `.ly` file(s). Does `make test` succeed? You should actually try that
> >> before running `make doc`...
> >>
> >
Le lundi 22 janvier 2024 à 21:10 +, Werner LEMBERG a écrit :
> > >
> OK, thanks. This means that there is apparently a macOS-specific
> problem with either Guile or LilyPond. For testing purposes I renamed
> one of my local fonts to something containing Katakana, and my
> self-compiled LilyP
>> > In procedure open-file: No such file or directory:
>> > "/System/Library/Fonts/??? W4.ttc" [...]
>> >
>> > SO it looks to me like there's a problem with not getting UTF characters
>> > into the proper file name in the Scheme procedure. Any ideas for what to
>> > do next?
>>
>> What d
On Sun, Jan 21, 2024 at 11:05 PM Werner LEMBERG wrote:
> > In procedure open-file: No such file or directory:
> > "/System/Library/Fonts/??? W4.ttc"
> >
> > I checked out the /System/Library/Fonts directory, and found these fonts
> > listed:
> >
> > ヒラギノ角ゴシック W3.ttc
> >
> > ヒラギノ角ゴシック
> In procedure open-file: No such file or directory:
> "/System/Library/Fonts/??? W4.ttc"
>
> I checked out the /System/Library/Fonts directory, and found these fonts
> listed:
>
> ヒラギノ角ゴシック W3.ttc
>
> ヒラギノ角ゴシック W4.ttc
>
> SO it looks to me like there's a problem with not getting UTF ch
Thanks for the hint, Dan!
I got to a new log file that gave me what I believe is a helpful error
message:
carl@carls-mbp-2 build % cat out/lybook-testdb/0f/lily-acefd898.log
Processing `0f/lily-acefd898.ly'
Parsing...
Renaming input to: `/Users/carl/Development/lilypond/input/regression/
pdf-c
>> You have to check the log files in `lybook-db` to find the problematic
>> `.ly` file(s). Does `make test` succeed? You should actually try that
>> before running `make doc`...
>>
>
> Interesting -- the CG has make doc show up before make test. But I
>
On 2024-01-20 20:55, Carl Sorensen wrote:
File
"/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/subprocess.py",
line 524, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['/usr/bin/tidy', '-o',
'/dev/null', '-q', 'compare
in `lybook-db` to find the problematic
> `.ly` file(s). Does `make test` succeed? You should actually try that
> before running `make doc`...
>
Interesting -- the CG has make doc show up before make test. But I
appreciate the suggestion, so I decided to restart
So I did a make clean, an
actually try that
before running `make doc`...
BTW, if you execute `make test`, you are greeted with the following
advice:
```
To begin investigating regression-test crashes, try this:
grep -L systems.texi out/lybook-testdb/*/*log | sed s/log/ly/g | xargs grep
-H sourcefilename
Matching li
I've successfully compiled master on my MacBook with M1. I can
successfully compile some simple lilypond files.
I tried to compile the documentation using make doc.
I got this result:
carl@Carls-MBP-2 build % make doc
Making input/regression/out-www/collated-files.list < 1888 files
On Sat, 2023-07-08 at 10:20 +, Werner LEMBERG wrote:
> Currently, `make bytecode && make doc` is broken:
https://lists.gnu.org/archive/html/lilypond-devel/2023-07/msg8.html
(it's not like there are hundreds of messages every day, a duplicate
thread doesn
> Le 8 juil. 2023 à 12:21, Werner LEMBERG a écrit :
>
> ...display-lily-tests.ly:252:8: fatal error:
> Guile signaled an error for the expression beginning here
> \test #
> #[ \key e \minor #]
> ```
That sounds like the same problem as
https://lists.gnu.org/archive/html/lilypond-deve
[b30a94a7f8da18a8b08d3c4f11bb95c278a83c57]
Currently, `make bytecode && make doc` is broken:
```
Command '/home/wl/build-lilypond/out/bin/lilypond [...] \
".../out/lybook-db/snippet-names-c727b9067d4d978254fae040dfb82c3e.ly"'
returned non-zero exi
Due to
https://bugs.ghostscript.com/show_bug.cgi?id=706552
which was fixed today it is necessary to use the forthcoming gs
version 10.02 for successful LilyPond documentation builds (using
`extractpdfmark`) with the new PDF engine of GhostScript. Without
this patch, many text accents in Lily
for you on a completely fresh build, i.e.,
>
> git reset --hard
> git pull
>
> ?
>
>
> Werner
Doing all from scratch again, it works fine for master now.
I likely forgot `make doc-clean`
The glitch in my upcoming patch is corrected as well.
To check and inspect chang
>> At the beginning of `internals.texi2pdf.log`:
>>
>> {finger
>>
>> /home/hermann/lilypond-git/build/Documentation/out-www/en/internals.texi:1659:
>> Paragraph ended before @var was complete.
>>
>> @par
>> l.1659
>>
>> I guess you missed a `@`...
>>
>>
>> Wer
Am So., 29. Nov. 2020 um 19:15 Uhr schrieb Werner LEMBERG :
>
>
> > while preparing a patch, I couldn't build the docs on my local branch
> > for unknown reasons.
>
> At the beginning of `internals.texi2pdf.log`:
>
> {finger
>
> /home/hermann/lilypond-git/build/Documentation/out-www/en/interna
> while preparing a patch, I couldn't build the docs on my local branch
> for unknown reasons.
At the beginning of `internals.texi2pdf.log`:
{finger
/home/hermann/lilypond-git/build/Documentation/out-www/en/internals.texi:1659:
Paragraph ended before @var was complete.
or errors. Last 20 lines:
Underfull \hbox (badness 1) in paragraph at lines 57331--57339
@texttt . 123) (class . foo) (data-whatever . \bar"))[] @textrm will pro-duce
@texttt
It's you.
:)
I can make doc with no issues (and I am using Xetex it seems)
Also:
texi2dvi --versi
Il giorno lun 14 set 2020 alle 13:44, Han-Wen Nienhuys
ha scritto:
On Mon, Sep 14, 2020 at 12:21 PM Michael Käppler
wrote:
Hi Jean,
Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
> Hi,
>
> Towards the end of the process, `make doc` outputs warnings coming
> from fi
Am 14.09.2020 um 13:44 schrieb Han-Wen Nienhuys:
On Mon, Sep 14, 2020 at 12:21 PM Michael Käppler wrote:
Hi Jean,
Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
Hi,
Towards the end of the process, `make doc` outputs warnings coming
from fix-docsize.sh. This occurs in CI too. Any ideas
Michael Käppler writes:
> Hi Jean,
>
> Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
>> Hi,
>>
>> Towards the end of the process, `make doc` outputs warnings coming
>> from fix-docsize.sh. This occurs in CI too. Any ideas?
>>
>> Best,
>> Je
On Mon, Sep 14, 2020 at 12:21 PM Michael Käppler wrote:
>
> Hi Jean,
>
> Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
> > Hi,
> >
> > Towards the end of the process, `make doc` outputs warnings coming
> > from fix-docsize.sh. This occurs in CI too. Any id
Hi Jean,
Am 12.09.2020 um 13:28 schrieb Jean Abou Samra:
Hi,
Towards the end of the process, `make doc` outputs warnings coming
from fix-docsize.sh. This occurs in CI too. Any ideas?
Best,
Jean
IIUC this is simply due to the fact that the mentioned manuals are not
translated and therefore
Le 12/09/2020 à 13:28, Jean Abou Samra a écrit :
Hi,
Towards the end of the process, `make doc` outputs warnings coming
from fix-docsize.sh. This occurs in CI too. Any ideas?
Best,
Jean
fix-docsize.sh: changes.ca.pdf not accessible from
/builds/lilypond/lilypond/build/out-www/offline-root
Hi,
Towards the end of the process, `make doc` outputs warnings coming from
fix-docsize.sh. This occurs in CI too. Any ideas?
Best,
Jean
fix-docsize.sh: changes.ca.pdf not accessible from
/builds/lilypond/lilypond/build/out-www/offline-root/Documentation/web-big-page.ca.html
|
fix
>> I get zillions of warnings from gs, all of them in the form
>>
>> Can't find (or can't open) font file
>> /usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
>>
>> All such lines are immediately followed by
>>
>> Loading Emmentaler-XX font from
>> .../lilypond.compiled/out-fon
Am Freitag, den 14.08.2020, 19:01 +0200 schrieb Werner LEMBERG:
> Compiling the documentation (using commit 1a64f012b from today) with
>
> make doc VERBOSE=1
>
> I get zillions of warnings from gs, all of them in the form
>
> Can't find (or can't open) font fi
> Compiling the documentation (using commit 1a64f012b from today) with
>
> make doc VERBOSE=1
>
> I get zillions of warnings from gs, all of them in the form
>
> Can't find (or can't open) font file
> /usr/share/ghostscript/9.52/Resource/Font//usr/s
Compiling the documentation (using commit 1a64f012b from today) with
make doc VERBOSE=1
I get zillions of warnings from gs, all of them in the form
Can't find (or can't open) font file
/usr/share/ghostscript/9.52/Resource/Font//usr/share/gh.
All such lines are immediately f
On 31/07/2020 22:04, Daniel Benjamin Miller wrote:
It's actually quite fine. It's basically saying it can't find Gyre or
Emmentaler in GhostScript's bundled fonts. Which it shouldn't, since
they're not included with GS. It finds it instead in the LilyPond
build directory, where it well should b
Hello,
I thought I'd do a full make/make doc since the last set of merges about
5 mins ago (just because I have time) using verbose logging and I
noticed a slew of these
--snip--
...
GPL Ghostscript 9.50 (2019-10-15)
Copyright (C) 2019 Artifex Software, Inc. All rights reserved.
On 6/17/20, Valentin Villenave wrote:
> Thanks for giving me hope, even for a minute :-)
I spoke too soon; running doc-clean and _then_ “make doc” indeed fixes
the problem. (And Jonas has just merged it onto master so that
problem is fixed.)
Thanks!
Cheers,
-- V.
On 6/17/20, Michael Käppler wrote:
> Do you have
> https://gitlab.com/lilypond/lilypond/-/merge_requests/148/diffs?commit_id=c002d5e8c2e737cefbafa84f4b66e4b3bbc6d111
> in your repo? Otherwise that may well be the problem. Jonas wanted to
> push this one yesterday,
> but it seems that did not happe
Am Mittwoch, den 17.06.2020, 10:59 +0200 schrieb Michael Käppler:
> Am 17.06.2020 um 10:52 schrieb Valentin Villenave:
> > Greetings everyone,
> > I’ve noticed a recent regression with `make doc’: when it reaches
> > Documentation/ly-examples, gs fails on a bunch of files w
Am 17.06.2020 um 10:52 schrieb Valentin Villenave:
Greetings everyone,
I’ve noticed a recent regression with `make doc’: when it reaches
Documentation/ly-examples, gs fails on a bunch of files with the
following error message:
Command: /home/work/lilypond/out/bin/lilypond -dpreview
-dresolution
Greetings everyone,
I’ve noticed a recent regression with `make doc’: when it reaches
Documentation/ly-examples, gs fails on a bunch of files with the
following error message:
Command: /home/work/lilypond/out/bin/lilypond -dpreview
-dresolution=150 -o ./out-www sesto-violin.ly
Changing working
Hello,
While doing some sanity tests this morning building doc (making sure
everything works for me for testing with new infrastructure) I spent
more time looking at the terminal window than I usually do.
During the make doc part where the 'page numbers' all whiz by I noticed
oc
On 4/23/20, Federico Bruni wrote:
> I confirm it's a stale dependency file.
> I had the same problem while testing my patch before pushing and IIRC
> removing Documentation/it/out-www/web.texi fixed it.
OK, thanks! I should have thought about doc-clean.
Cheers,
- V.
Il giorno gio 23 apr 2020 alle 16:01, Jonas Hahnfeld via Discussions on
LilyPond development ha scritto:
Am Donnerstag, den 23.04.2020, 13:37 + schrieb Valentin Villenave:
Hey everybody,
For the past few days, I’ve been unable to make doc because of the
following error:
*** No
Am Donnerstag, den 23.04.2020, 13:37 + schrieb Valentin Villenave:
> Hey everybody,
> For the past few days, I’ve been unable to make doc because of the
> following error:
>
> *** No rule to make target
> '/home/work/lilypond/Documentation/it/web/news-headlines.itexi
Hey everybody,
For the past few days, I’ve been unable to make doc because of the
following error:
*** No rule to make target
'/home/work/lilypond/Documentation/it/web/news-headlines.itexi',
needed by 'out-www/web.texi'. Stop.
Federico, do you know anything about it?
Cheers,
V.
ve python3 by default since months, so I'm sure.
After I got this error I used a temporary alias to switch python to
python2, just to see if the error disappeared. But it did not.
Anyway, 'make distclean' solved the problem, as usual.
I was reluctant to clean everything because
Am Samstag, den 11.04.2020, 14:33 +0200 schrieb Federico Bruni:
> Fedora 31. /usr/bin/python points to version 3.7.6.
> I'm running `make doc` in the translation branch and I get this error:
>
> $ make -j3 doc
> GNUmakefile:30: warning: overriding recipe for target 'po
Fedora 31. /usr/bin/python points to version 3.7.6.
I'm running `make doc` in the translation branch and I get this error:
$ make -j3 doc
GNUmakefile:30: warning: overriding recipe for target 'po-update'
/home/fede/src/lilypond-translation/stepmake/stepmake/podir-targets.ma
On Mon, Feb 24, 2020 at 10:44 PM David Kastrup wrote:
> > The result is 25 minutes of purely CPU bound grinding (this is with
> > Guile 2.2). Then building the remaining docs takes about 15 minutes.
> > In this last phase, there is some inefficiency: we process the
> > documents per language direc
David Kastrup writes:
> Han-Wen Nienhuys writes:
>
>> I tried what happens if one concats all texi/tely files together, and
>> runs lp-book on them.
>>
>> The result is 25 minutes of purely CPU bound grinding (this is with
>> Guile 2.2). Then building the remaining docs takes about 15 minutes.
>
Han-Wen Nienhuys writes:
> I tried what happens if one concats all texi/tely files together, and
> runs lp-book on them.
>
> The result is 25 minutes of purely CPU bound grinding (this is with
> Guile 2.2). Then building the remaining docs takes about 15 minutes.
> In this last phase, there is so
I tried what happens if one concats all texi/tely files together, and
runs lp-book on them.
The result is 25 minutes of purely CPU bound grinding (this is with
Guile 2.2). Then building the remaining docs takes about 15 minutes.
In this last phase, there is some inefficiency: we process the
docume
Dan Eble writes:
> On Jan 30, 2020, at 14:57, David Kastrup wrote:
>>
>> os.symlink ("../../../out-baseline/share",
>> "out-www/offline-root/input/regression/out-test-baseline/share")
>>
>> What has the test baseline to do with make doc ?
On Jan 30, 2020, at 14:57, David Kastrup wrote:
>
> os.symlink ("../../../out-baseline/share",
> "out-www/offline-root/input/regression/out-test-baseline/share")
>
> What has the test baseline to do with make doc ?
💡
Try cherry-picking this:
commit dbe42
e out where stuff goes wrong with my
>> system? One thing I could do is check with current master.
>
> How about editing www_post to print the values of p and dest so we can
> see for which file os.symlink is failing?
Oh wow.
os.symlink ("../../../out-baseline/share",
"out-www/offline-root/input/regression/out-test-baseline/share")
What has the test baseline to do with make doc ?
--
David Kastrup
Dan Eble writes:
> On Jan 30, 2020, at 13:39, David Kastrup wrote:
>>
>>> I just had a successful mage -j5 doc as of commit
>>> 8a05312fd8d2a56ec724a793b313949db0cfe729
>>
>> Current stable/2.20 which failed on my system.
>
> I also am not able to reproduce the problem in a clean workspace; bu
On Jan 30, 2020, at 13:39, David Kastrup wrote:
>
>> I just had a successful mage -j5 doc as of commit
>> 8a05312fd8d2a56ec724a793b313949db0cfe729
>
> Current stable/2.20 which failed on my system.
I also am not able to reproduce the problem in a clean workspace; but I have
verified that I wan
Jean-Charles Malahieude writes:
> Le 30/01/2020 à 19:46, David Kastrup a écrit :
>> Oops.
>> dak@lola:/usr/local/tmp/lilypond$ git checkout origin
>> error: The following untracked working tree files would be overwritten by
>> checkout:
>> Documentation/snippets/non-traditional.snippet-list
1 - 100 of 709 matches
Mail list logo
