Re: error building LilyPond 2.23.7 in Frescobaldi flatpak
Federico Bruni writes: > Hi folks > > Can anybody help me with the following error? > > Making lily/out/lexer.o < cc > Making lily/out/parser.o < cc > Making lily/out/lilypond > /usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: > warning: ./out/ly-module.o has a corrupt string table index - ignoring > /usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: > error: ./out/ly-module.o: ELF section name out of range > collect2: error: ld returned 1 exit status > make[1]: *** [GNUmakefile:40: out/lilypond] Error 1 > make: *** > [/run/build/lilypond-dev/stepmake/stepmake/generic-targets.make:6: > all] Error 2 > Error: module lilypond-dev: Child process exited with code 2 Sounds like corruption to me. Either you have run out of disk space (unlikely since the file in question is pretty much in the middle), or one process wrote on a file while another process accessed it (write or read) in parallel, or you have a hardware error or some other utility has a severe bug or corruption. So I'd check how repeatable that error is. Reproducible on the same system? Reproducible on a system with the same versions of software? -- David Kastrup
Re: MR tests showing raw HTML
LGTM! On 2022-03-30 14:18, Jonas Hahnfeld wrote: On Wed, 2022-03-30 at 08:29 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: On Tue, 2022-03-29 at 18:02 -0600, Colin Campbell wrote: When I verify the results of the test stage of CI, clicking on the link ( https://gitlab.com/lilypond/lilypond/-/jobs/2261164728/artifacts/file/test-results/index.html ), I get a screenful of raw HTML. Pasting that URL directly into an address bar (Vivaldi 5.1) gives the same result. Am I chasing a change on my machine, or is this seen elsewhere? No, GitLab broke this (again, after the same happened in 2021): https://gitlab.com/gitlab-org/gitlab/-/issues/357078 At least this time, they are quick to revert the change that introduced the regression: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83917 Once that is deployed on gitlab.com, the pages should be rendered again. Should be working again. Cheers Jonas
error building LilyPond 2.23.7 in Frescobaldi flatpak
Hi folks Can anybody help me with the following error? Making lily/out/lexer.o < cc Making lily/out/parser.o < cc Making lily/out/lilypond /usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: warning: ./out/ly-module.o has a corrupt string table index - ignoring /usr/lib/gcc/x86_64-unknown-linux-gnu/10.2.0/../../../../x86_64-unknown-linux-gnu/bin/ld: error: ./out/ly-module.o: ELF section name out of range collect2: error: ld returned 1 exit status make[1]: *** [GNUmakefile:40: out/lilypond] Error 1 make: *** [/run/build/lilypond-dev/stepmake/stepmake/generic-targets.make:6: all] Error 2 Error: module lilypond-dev: Child process exited with code 2 See also the attached full log. This is the GCC version: [ org.kde.Sdk ~]$ gcc --version gcc (GCC) 10.2.0 I'm using this flatpak manifest: https://github.com/flathub/org.frescobaldi.Frescobaldi/blob/guile2/org.frescobaldi.Frescobaldi.yaml Thanks Federico Building module lilypond-dev in /var/home/fede/src/flathub.org/org.frescobaldi.Frescobaldi/.flatpak-builder/build/lilypond-dev-1 checking build system type... x86_64-pc-linux-gnu checking host system type... x86_64-pc-linux-gnu checking for gmake... no checking for make... make checking for find... find checking for tar... tar checking for python... python checking python version... 3.8.12 checking for python... /usr/bin/python checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether the compiler supports GNU C... yes checking whether gcc accepts -g... yes checking for gcc option to enable C11 features... none needed checking for stdio.h... yes checking for stdlib.h... yes checking for string.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for strings.h... yes checking for sys/stat.h... yes checking for sys/types.h... yes checking for unistd.h... yes checking for wchar.h... yes checking for minix/config.h... no checking whether it is safe to define __EXTENSIONS__... yes checking whether _XOPEN_SOURCE should be defined... no checking whether compiler understands -pipe... yes checking for fc-list... fc-list checking for TeX Gyre fonts OTF files... yes checking for URW++ OTF files... no checking for python... /usr/bin/python checking /usr/bin/python version... 3.8.12 checking for /usr/bin/python... (cached) /usr/bin/python checking for g++... g++ checking whether the compiler supports GNU C++... yes checking whether g++ accepts -g... yes checking for g++ option to enable C++11 features... none needed checking for ar... ar checking for ranlib... ranlib checking for bison... bison checking bison version... 3.6.4 checking for flex... flex checking for FlexLexer.h... yes checking for yyFlexLexer.yypop_buffer_state ()... yes checking for gettext in -lintl... no checking for gettext... yes checking for msgfmt... msgfmt checking for mf-nowin... mf-nowin checking for mpost... mpost checking for working metafont mode... ljfour checking for kpsewhich... kpsewhich checking for metapost required files... yes checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for guile-2.2 >= 2.2.0... yes checking for scm_t_hash_fold_fn... yes checking for scm_t_subr... yes checking whether g++ supports -Werror=unknown-warning-option... no checking whether g++ supports -Wcast-function-type... yes checking for bdw-gc... yes checking whether g++ supports -Wsuggest-override... yes checking for usable C++ demangler... yes checking for fontforge... fontforge checking for fontforge... /app/bin/fontforge checking /app/bin/fontforge version... 20200314 checking for t1asm... t1asm checking for t1asm... /usr/lib/sdk/texlive/bin/x86_64-linux/t1asm checking for grp.h... yes checking for pwd.h... yes checking for sys/stat.h... (cached) yes checking whether stat file-mode macros are broken... no checking for working memcmp... yes checking for vprintf... yes checking for chroot... yes checking for gettext... (cached) yes checking for pkg-config... /usr/bin/pkg-config checking /usr/bin/pkg-config version... 1.8.0 checking for rpath linkage... no checking for pangoft2 >= 1.38.0... yes checking for pango/pangoft2.h... yes checking for pango_ft2_font_map_create_context... yes checking for fontconfig >= 2.4.0... yes checking for freetype2 >= 2.3.9... yes checking for glib-2.0 >= 2.38... yes checking for gobject-2.0 >= 2.38... yes checking for some flavor of Windows... no checking for -windres... no checking for x86_64-pc-linux-gnu-windres... no checking for windres... no checking for guile... guile checking guile version... 2.2.7 checking for guile... guile checking for
Re: MR tests showing raw HTML
On Wed, 2022-03-30 at 08:29 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > On Tue, 2022-03-29 at 18:02 -0600, Colin Campbell wrote: > > When I verify the results of the test stage of CI, clicking on the link > > ( > > https://gitlab.com/lilypond/lilypond/-/jobs/2261164728/artifacts/file/test-results/index.html > > > > ), I get a screenful of raw HTML. Pasting that URL directly into an > > address bar (Vivaldi 5.1) gives the same result. Am I chasing a change > > on my machine, or is this seen elsewhere? > > No, GitLab broke this (again, after the same happened in 2021): > https://gitlab.com/gitlab-org/gitlab/-/issues/357078 At least this > time, they are quick to revert the change that introduced the > regression: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83917 > Once that is deployed on gitlab.com, the pages should be rendered > again. Should be working again. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond's 'oldEE' accordion symbol
Werner LEMBERG writes: >> in 1998 you introduced the 'oldEE' accordion symbol to LilyPond's >> Emmentaler font. Since some time we are wondering where this symbol >> comes from; we weren't able to find any reference to it. Could you >> please tell us where you got this from? > > Tom replied and sent me a PDF with a scan of the first three pages of > an accordion transcription of the 'Emperor Waltz', published in 1948 > by Alfred Music, New York. > > Attached is an image showing the first few bars; I can forward the PDF > in private e-mail on request. Accordion editions of this age did not really have standardised symbols: I suppose there is a synopsis in the first (editorial) pages of the publication? It would be really interesting to know how much use this symbol might have seen, and whether it was from more than one publisher. -- David Kastrup
Re: MR tests showing raw HTML
This doesn't solve the issue, but checking the headers, that page is shown as of type text/plain. Probably that's confusing the browser. Phil On 30/03/2022 01:02, Colin Campbell wrote: When I verify the results of the test stage of CI, clicking on the link ( https://gitlab.com/lilypond/lilypond/-/jobs/2261164728/artifacts/file/test-results/index.html ), I get a screenful of raw HTML. Pasting that URL directly into an address bar (Vivaldi 5.1) gives the same result. Am I chasing a change on my machine, or is this seen elsewhere? Cheers, Colin
Re: MR tests showing raw HTML
On Tue, 2022-03-29 at 18:02 -0600, Colin Campbell wrote: > When I verify the results of the test stage of CI, clicking on the link > ( > https://gitlab.com/lilypond/lilypond/-/jobs/2261164728/artifacts/file/test-results/index.html > > ), I get a screenful of raw HTML. Pasting that URL directly into an > address bar (Vivaldi 5.1) gives the same result. Am I chasing a change > on my machine, or is this seen elsewhere? No, GitLab broke this (again, after the same happened in 2021): https://gitlab.com/gitlab-org/gitlab/-/issues/357078 At least this time, they are quick to revert the change that introduced the regression: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83917 Once that is deployed on gitlab.com, the pages should be rendered again. Until that happens, the only possibility is to download the artifact and view the output locally... signature.asc Description: This is a digitally signed message part
