Re: GUB issues in the tracker

Le 14/04/2022 à 22:45, Jonas Hahnfeld a écrit : On Thu, 2022-04-14 at 22:26 +0200, Jean Abou Samra wrote: Le 14/04/2022 à 22:14, Jonas Hahnfeld a écrit : On Thu, 2022-04-14 at 21:59 +0200, Jean Abou Samra wrote: I still see 4 issues with the GUB label in the issue tracker. Should we close

Re: GUB issues in the tracker

On Thu, 2022-04-14 at 22:26 +0200, Jean Abou Samra wrote: > > Le 14/04/2022 à 22:14, Jonas Hahnfeld a écrit : > > On Thu, 2022-04-14 at 21:59 +0200, Jean Abou Samra wrote: > > > I still see 4 issues with the GUB label in the issue tracker. Should we > > > close

Re: GUB issues in the tracker

Le 14/04/2022 à 22:14, Jonas Hahnfeld a écrit : On Thu, 2022-04-14 at 21:59 +0200, Jean Abou Samra wrote: I still see 4 issues with the GUB label in the issue tracker. Should we close them? Probably. I already closed the few issues that were related to how GUB worked internally. For the

Re: GUB issues in the tracker

On Thu, 2022-04-14 at 21:59 +0200, Jean Abou Samra wrote: > I still see 4 issues with the GUB label in the issue tracker. Should we > close them? Probably. I already closed the few issues that were related to how GUB worked internally. For the rest, it would be good to go over the repor

GUB issues in the tracker

I still see 4 issues with the GUB label in the issue tracker. Should we close them? Jean

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Sonntag, dem 28.11.2021 um 12:07 +0100 schrieb Han-Wen Nienhuys: > Semi related - it looks like GUILE 2.2 is a ~30% slowdown relative to > 1.8. I don't have the numbers in my head anymore; does that sound > right? Depending on what exactly you are testing, that sounds about right; see https://l

Re: [RFC] Moving to Guile 2.2 and away from GUB

On Sat, Nov 27, 2021 at 11:27 PM Han-Wen Nienhuys wrote: > > On Fri, Nov 26, 2021 at 12:54 PM Jonas Hahnfeld wrote: > > A build without optimizations crashed more or less immediately upon > > compiling the regression tests. That said, I'm not really interested in > > debugging advice - if you hav

Re: [RFC] Moving to Guile 2.2 and away from GUB

On Fri, Nov 26, 2021 at 12:54 PM Jonas Hahnfeld wrote: > A build without optimizations crashed more or less immediately upon > compiling the regression tests. That said, I'm not really interested in > debugging advice - if you have ideas, please reproduce the problem on > your end (shouldn't be to

Re: [RFC] Moving to Guile 2.2 and away from GUB

lease 2.23.5 relatively soon (as Phil has time) using GUB [...] Okay, scratch that: GUB is currently broken building for mingw, who would have guessed... Oh how I hate it! https://gitlab.com/lilypond/lilypond/-/merge_requests/1032 for mingw, and https://github.com/gperciva/gub/pull/88 for fixin

Re: [RFC] Moving to Guile 2.2 and away from GUB

soon (as Phil has > > time) using GUB [...] > > Okay, scratch that: GUB is currently broken building for mingw, who > would have guessed... Oh how I hate it! https://gitlab.com/lilypond/lilypond/-/merge_requests/1032 for mingw, and https://github.com/gperciva/gub/pull/88 for fixing GUB

Re: [RFC] Moving to Guile 2.2 and away from GUB

he same time. > that would be quite some work, but then it could benefit many. So, how many open source projects would benefit from such work? I know that we are the only ones using GUB, is that now different with Guix? Because doing the work in a general fashion for nobody to use it, is a waste IM

Re: [RFC] Moving to Guile 2.2 and away from GUB

excellent cross > > > build system and creation of universal binaries. > > > > At this point, it's a bit too late to discuss other solutions > > in my opinion. Jonas obviously invested a ton of work in > > this > > Ah, my bad. Then that's great or too

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Samstag, dem 27.11.2021 um 13:54 +0100 schrieb David Kastrup: > Jonas Hahnfeld via Discussions on LilyPond development > writes: > > > Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: > > > I already proposed using GNU Guix, making use of its excellent cross > > > build sys

Re: [RFC] Moving to Guile 2.2 and away from GUB

Jonas Hahnfeld writes: > Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: >> Carl Sorensen writes: >> >> > I think GUB was a great idea, but it has proven difficult to maintain. >> > And the creator of GUB (Jan), has indicated that he thinks i

Re: [RFC] Moving to Guile 2.2 and away from GUB

#x27;s a bit too late to discuss other solutions > in my opinion. Jonas obviously invested a ton of work in > this Ah, my bad. Then that's great or too bad, depending on your viewpoint. After GUB (already when working on GUB, ftm) my hope was to avoid duplicating efforts of maintaining

Re: [RFC] Moving to Guile 2.2 and away from GUB

Le 27/11/2021 à 12:43, Jan Nieuwenhuizen a écrit : But yeah, some 5 years ago https://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00204.html I already proposed using GNU Guix, making use of its excellent cross build system and creation of universal binaries. Greetings, Janneke

Re: [RFC] Moving to Guile 2.2 and away from GUB

Jonas Hahnfeld via Discussions on LilyPond development writes: > Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: >> Carl Sorensen writes: >> >> Hi, >> >> > I think GUB was a great idea, but it has proven difficult to maintain. &g

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Samstag, dem 27.11.2021 um 12:43 +0100 schrieb Jan Nieuwenhuizen: > Carl Sorensen writes: > > Hi, > > > I think GUB was a great idea, but it has proven difficult to maintain. > > And the creator of GUB (Jan), has indicated that he thinks it is not > > worth cont

Re: [RFC] Moving to Guile 2.2 and away from GUB

Carl Sorensen writes: Hi, > I think GUB was a great idea, but it has proven difficult to maintain. > And the creator of GUB (Jan), has indicated that he thinks it is not > worth continuing to work on. So GUB has been a dead man walking for > some time. FWIW, Han-Wen is the initi

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Mittwoch, dem 24.11.2021 um 20:13 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: > I'd like to propose that we release 2.23.5 relatively soon (as Phil has time) > using GUB [...] Okay, scratch that: GUB is currently broken building for mingw, who would h

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Freitag, dem 26.11.2021 um 08:44 +0100 schrieb Han-Wen Nienhuys: > On Thu, Nov 25, 2021 at 7:49 PM Jonas Hahnfeld via Discussions on > LilyPond development wrote: > > > > Check out > > > if you can trigger this with some frequency. >

Re: [RFC] Moving to Guile 2.2 and away from GUB

On Thu, Nov 25, 2021 at 7:49 PM Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Check out > > if you can trigger this with some frequency. > > Nope, still crashes in the same place. Would be interesting to see if you

Re: [RFC] Moving to Guile 2.2 and away from GUB

On Thu, Nov 25, 2021 at 10:08 PM Jonas Hahnfeld via Discussions on LilyPond development wrote: > Fun fact: Did you try placing the compiled file (with only the > extension .go) into out/lib/lilypond/current/ccache/lily and make > lilypond load it? It results in "Unbound variable: all-grob- > desc

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Donnerstag, dem 25.11.2021 um 20:51 +0100 schrieb Jean Abou Samra: > Le 25/11/2021 à 20:06, Jonas Hahnfeld a écrit : > > Am Donnerstag, dem 25.11.2021 um 19:51 +0100 schrieb Jean Abou Samra: > > > Le 24/11/2021 à 22:41, Jonas Hahnfeld via Discussions on LilyPond > > > development a écrit : > > >

Re: [RFC] Moving to Guile 2.2 and away from GUB

Le 25/11/2021 à 20:06, Jonas Hahnfeld a écrit : Am Donnerstag, dem 25.11.2021 um 19:51 +0100 schrieb Jean Abou Samra: Le 24/11/2021 à 22:41, Jonas Hahnfeld via Discussions on LilyPond development a écrit : This improves with compiled bytecode, as Jean replied, but this won't be included initial

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Donnerstag, dem 25.11.2021 um 19:51 +0100 schrieb Jean Abou Samra: > Le 24/11/2021 à 22:41, Jonas Hahnfeld via Discussions on LilyPond > development a écrit : > > This improves with compiled bytecode, as Jean replied, but this won't > > be included initially (I > > forgot to mention this). We

Re: [RFC] Moving to Guile 2.2 and away from GUB

Jonas Hahnfeld writes: > Am Donnerstag, dem 25.11.2021 um 16:18 +0100 schrieb David Kastrup: >> > System::init_elements has >> > >> > set_object (this, "all-elements", scm_arr); >> > >> > So *all_elements_ is protected as part of being a Spanner. As long as >> > the spanner has not committe

Re: [RFC] Moving to Guile 2.2 and away from GUB

Le 24/11/2021 à 22:41, Jonas Hahnfeld via Discussions on LilyPond development a écrit : This improves with compiled bytecode, as Jean replied, but this won't be included initially (I forgot to mention this). We should definitely have it for the next stable release, but I'm optimistic that this i

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Donnerstag, dem 25.11.2021 um 16:18 +0100 schrieb David Kastrup: > David Kastrup writes: > > David Kastrup writes: > > > > > David Kastrup writes: > > > > > It's relatively reproducible, I get it every 2nd-3rd time for full > > > > > 'make doc's. Looking at the core dump, it's crashing in >

Re: [RFC] Moving to Guile 2.2 and away from GUB

;>> Discussions on LilyPond development: >>>>> Am Mittwoch, dem 24.11.2021 um 23:01 +0100 schrieb Han-Wen Nienhuys: >>>>> > On Wed, Nov 24, 2021 at 8:13 PM Jonas Hahnfeld via Discussions on >>>>> > LilyPond development wrote: >>>&g

Re: [RFC] Moving to Guile 2.2 and away from GUB

gt; Am Mittwoch, dem 24.11.2021 um 23:01 +0100 schrieb Han-Wen Nienhuys: >>>> > On Wed, Nov 24, 2021 at 8:13 PM Jonas Hahnfeld via Discussions on >>>> > LilyPond development wrote: >>>> > > Assuming no major problems are found, we could then move co

Re: [RFC] Moving to Guile 2.2 and away from GUB

Han-Wen Nienhuys: >>> > On Wed, Nov 24, 2021 at 8:13 PM Jonas Hahnfeld via Discussions on >>> > LilyPond development wrote: >>> > > Assuming no major problems are found, we could then move completely to >>> > > Guile 2.2 and do releases without GUB

Re: [RFC] Moving to Guile 2.2 and away from GUB

2021 at 8:13 PM Jonas Hahnfeld via Discussions on >> > LilyPond development wrote: >> > > Assuming no major problems are found, we could then move completely to >> > > Guile 2.2 and do releases without GUB. Both steps still require a bit >> > > of w

Re: [RFC] Moving to Guile 2.2 and away from GUB

> > > Assuming no major problems are found, we could then move completely to > > > Guile 2.2 and do releases without GUB. Both steps still require a bit > > > of work; I'm relatively sure there is still a GC related issue causing > > > (very rare) cra

Re: [RFC] Moving to Guile 2.2 and away from GUB

Am Mittwoch, dem 24.11.2021 um 23:01 +0100 schrieb Han-Wen Nienhuys: > On Wed, Nov 24, 2021 at 8:13 PM Jonas Hahnfeld via Discussions on > LilyPond development wrote: > > Assuming no major problems are found, we could then move completely to > > Guile 2.2 and do releases witho

Re: [RFC] Moving to Guile 2.2 and away from GUB

> What do you think? +1 Werner

Re: [RFC] Moving to Guile 2.2 and away from GUB

On Wed, Nov 24, 2021 at 8:13 PM Jonas Hahnfeld via Discussions on LilyPond development wrote: > Assuming no major problems are found, we could then move completely to > Guile 2.2 and do releases without GUB. Both steps still require a bit > of work; I'm relatively sure there is stil

Re: [RFC] Moving to Guile 2.2 and away from GUB

fine before any commit lands in the master branch. > I love the idea of static binaries, instead of dynamic linking. > > The risk of your proposal is pretty low in the short term is pretty low, > because if the Guile 2.2/new script package blows up, we can always go > back to G

Re: [RFC] Moving to Guile 2.2 and away from GUB

On 11/24/21, 1:17 PM, "Jean Abou Samra" wrote: Le 24/11/2021 à 20:54, Carl Sorensen a écrit : > IIRC, it has some start-up overhead, but runs almost as fast as 1.8 if you discount the overhead. The current major problem with 2.2 as far as I understand it is that it is very slow in

Re: [RFC] Moving to Guile 2.2 and away from GUB

Le 24/11/2021 à 20:54, Carl Sorensen a écrit : IIRC, it has some start-up overhead, but runs almost as fast as 1.8 if you discount the overhead. The current major problem with 2.2 as far as I understand it is that it is very slow in building docs, because the start-up overhead happens for ev

Re: [RFC] Moving to Guile 2.2 and away from GUB

Hi, Jonas, I think your plan sounds good. I think GUB was a great idea, but it has proven difficult to maintain. And the creator of GUB (Jan), has indicated that he thinks it is not worth continuing to work on. So GUB has been a dead man walking for some time. I LOVE the idea of build

Re: [RFC] Moving to Guile 2.2 and away from GUB

'd like to propose that we release 2.23.5 relatively soon (as Phil has time) using GUB, including the cross-compiled binaries distributed so far. In addition, I can take the official source tar (produced by GUB) and build binaries for Linux, macOS, and Windows which we can test and compare to those

[RFC] Moving to Guile 2.2 and away from GUB

Hi all, with the landing of !1009, the "new" scripts for building binaries are now complete, or at least ready to be used and where I planed to take them for the beginning. For the next step, I'd like to propose that we release 2.23.5 relatively soon (as Phil has time) using GUB

Re: GUB / ghostscript

Am Mittwoch, dem 11.08.2021 um 08:32 +0200 schrieb Han-Wen Nienhuys: > On Mon, Aug 9, 2021 at 12:23 PM Knut Petersen wrote: > > > > Hi everybody, > > > > is there any reason that we still use very ancient versions of ghostscript > > for our installers prepared

Re: GUB / ghostscript

On Mon, Aug 9, 2021 at 12:23 PM Knut Petersen wrote: > > Hi everybody, > > is there any reason that we still use very ancient versions of ghostscript > for our installers prepared via GUB? in gub, there is a comment. # ***FIXME*** Ghostscript 9.20 for freebsd-x86 raises seg

GUB / ghostscript

Hi everybody, is there any reason that we still use very ancient versions of ghostscript for our installers prepared via GUB? A number of vulnerabilities have been found, and it's easy to find detailed descriptions of exploits ... see e.g. https://www.openwall.com/lists/oss-security/20

Re: GUB mingw pixman 0.40 linking problem

Hi everybody, It's also a linker problem with mingw, but this problem proves to be hard for me. I solved the problem. Knut

GUB mingw pixman 0.40 linking problem

Hi everybody, My efforts to make GUB fit for the Cairo backend patch came to the following result: Building  of LilyPond with the cairo backend code and the old versions of Pixman and Cairo included in Gub works fine. Old Cairo means that pdfs are generated without hyperlinks and without

Re: GUB - today's problem

Deleted target, but the build failed at the same spot with the same error. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Sunday, July 26, 2020 12:18 PM Subject: Re: GUB - today's problem

Re: GUB - today's problem

d-test which for me runs in linux-64. If this uses a library from tools, that could be missing. I have the library in target/linux-64/root/usr/lib/libffi.so, but lilypond-test never really worked for me so my GUB is not the best reference... Jonas > > -- > Phil Holmes > > >

Re: GUB - today's problem

uot;Phil Holmes" ; "Devel" Sent: Sunday, July 26, 2020 11:52 AM Subject: Re: GUB - today's problem

Re: GUB - today's problem

Am Sonntag, den 26.07.2020, 11:34 +0100 schrieb Phil Holmes: > From lilypond-test.log: > > /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undefined > reference to `__stack_chk_fail@GLIBC_2.4' > /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undef

GUB - today's problem

From lilypond-test.log: /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undefined reference to `__stack_chk_fail@GLIBC_2.4' /home/gub/NewGub/gub/target/tools/root/usr/lib/libffi.so.6: undefined reference to `mkostemp@GLIBC_2.7' collect2: error: ld returned 1 exit sta

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

Re: GUB failing

"Phil Holmes" writes: > Not sure it's working. It ran happily for just over 15 minutes and > seems to have stalled for the last hour. It's not consuming CPU but > hasn't returned. The log has: > > unlocked-dist-check rule > make[3]: Entering di

Re: GUB failing

Not sure it's working. It ran happily for just over 15 minutes and seems to have stalled for the last hour. It's not consuming CPU but hasn't returned. The log has: unlocked-dist-check rule make[3]: Entering directory `/home/gub/NewGub/gub' PATH=/home/gub/NewGub/g

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//t

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#n1

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). > >>

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 >

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

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 ra

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

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

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

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 arg

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 ret

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

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/roo

Re: Today's problem with GUB build

s... 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

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

Re: Today's problem with GUB build

her, 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"

Re: Today's problem with GUB build

entioned. 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-font

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=docti

Re: GUB failing

Thanks. I've now pulled your GUB update so that bit should be OK next time. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" Cc: "Devel" Sent: Monday, July 13, 2020 5:34 PM Subject: Re: GUB failing

Re: GUB failing

Am Montag, den 13.07.2020, 15:39 +0100 schrieb Phil Holmes: > Seems to be proceeding. I repeat my view that you are a miracle worker :-) Hehe thanks, I'm pretty good at guessing 😉 I accepted the merge request and also pushed the tag from Savannah to GitLab - maybe you forgot to get my PR from Gi

Re: GUB failing

Seems to be proceeding. I repeat my view that you are a miracle worker :-) -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" Cc: "Devel" Sent: Monday, July 13, 2020 3:09 PM Subject: Re: GUB failing

Re: GUB failing

ment 'order' for '--sort' > Valid arguments are: > - 'none' > - 'name' > - 'inode' > make[4]: Leaving directory > `/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable' > >

Re: GUB failing

Ok, pushed as commit f5aee54cc11ea28b317d01384db182277926175a with a reference to version 4.9. I didn't have the time to check that it actually fixes the build with GUB, I hope it does. Phil, could you try again? Jonas signature.asc Description: This is a digitally signed message part

Re: GUB failing

On Jul 12, 2020, at 11:09, Jonas Hahnfeld wrote: > > Dan, ok to do the following? (I'd push directly to release/unstable…) ... > - auto operator * () const->decltype (from_scm (dereference_scm ())) > + // (Explicit 'this' in trailing decltype needed because of bug in GCC, see > + // https://gc

Re: GUB failing

Am Sonntag, den 12.07.2020, 13:46 +0100 schrieb Phil Holmes: > Getting this error: > > /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/include/ly-scm-list.hh:166:69: > > error: cannot call member function 'ly_scm_itera

GUB failing

Getting this error: /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/lily/include/ly-scm-list.hh:166:69: error: cannot call member function 'ly_scm_iterator_tallow_mutation>::private_scm& ly_scm_iterator_tallow_mutation>::derefere

Re: GUB help needed - fontforge error

x-x86) > *** Stage: compile (lilypond-test, linux-x86) > Running file_sub > ([('^exec xetex ', 'LD_LIBRARY_PATH= exec xetex ')], > '/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/out/xetex-with-opti

Re: GUB help needed - fontforge error

xetex ', 'LD_LIBRARY_PATH= exec xetex ')], '/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/out/xetex-with-options') {'use_re': True, 'to_name': None, 'must_succeed': False} Tra

Re: GUB help needed - fontforge error

gt; stopped pushing to staging / master and complicating the release. > > Am Montag, den 27.04.2020, 07:46 +0100 schrieb Phil Holmes: > > I am currently getting this error when trying to build GUB: > > > > Tail of target/tools/log/fontforge.log >>>>>>>>

Re: GUB help needed - fontforge error

27.04.2020, 07:46 +0100 schrieb Phil Holmes: > I am currently getting this error when trying to build GUB: > > Tail of target/tools/log/fontforge.log >>>>>>>> > checking Build with LibUniNamesList Unicode support?... configure: error: in > `/home/gub

GUB help needed - fontforge error

I am currently getting this error when trying to build GUB: Tail of target/tools/log/fontforge.log >>>>>>>> checking Build with LibUniNamesList Unicode support?... configure: error: in `/home/gub/NewGub/gub/target/tools/build/fontforge-20190801': configure:

Re: Today's GUB failure

>>>>>>>> checking Build with LibUniNamesList Unicode support?... configure: error: in `/home/gub/NewGub/gub/target/tools/build/fontforge-20190801': configure: error: You may provide option ˋ--without-libuninameslistˋ to build without this recommended feature See `config.log' f

Re: Today's GUB failure

Am Sonntag, den 26.04.2020, 11:25 +0100 schrieb Phil Holmes: > Can anyone help? I'm getting this > > /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py > > line: 2 Undefined variable: import

Today's GUB failure

Can anyone help? I'm getting this /home/gub/NewGub/gub/target/linux-64/src/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/mf/gen-emmentaler.fontforge.py line: 2 Undefined variable: import make[1]: *** [out/emmentaler-11.svg] Error 1 make[1]: *** Waiting for unfinished jobs M

Re: Latest GUB error

Am Mittwoch, den 08.04.2020, 13:33 +0100 schrieb Phil Holmes: > Merged master and restarted the build. Got a different but apparently > related error: > > > cp: omitting directory > '/home/gub/NewGub/gub/target/mingw/install/lilypond-2.21.0-root/usr/share/lilypond/cur

Re: Latest GUB error

Merged master and restarted the build. Got a different but apparently related error: cp: omitting directory '/home/gub/NewGub/gub/target/mingw/install/lilypond-2.21.0-root/usr/share/lilypond/current/python/__pycache__' Command barfed: cp /home/gub/NewGub/gub/target/mingw/instal

Re: Latest GUB error

hil Holmes" < > > m...@philholmes.net > > > > > ; "Devel" < > > > > lilypond-devel@gnu.org > > > > > > Cc: "David Kastrup" < > > d...@gnu.org > > > > > ; "Han-Wen Nienhuys" < >

Re: Latest GUB error

org > > > Cc: "David Kastrup" < > d...@gnu.org > >; "Han-Wen Nienhuys" < > hanw...@gmail.com > > > Sent: Tuesday, April 07, 2020 3:55 PM > Subject: Re: Latest GUB error > > > Okay, so this is finally the foreseen problem in current mast

Re: Latest GUB error

- Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Cc: "David Kastrup" ; "Han-Wen Nienhuys" Sent: Tuesday, April 07, 2020 3:55 PM Subject: Re: Latest GUB error Okay, so this is finally the foreseen problem in c

Re: Latest GUB error

Am Dienstag, den 07.04.2020, 15:18 +0100 schrieb Phil Holmes: > We're getting further now. Again, thanks for all your help so far. This > time I get: > > Traceback (most recent call last): > File > "/home/gub/NewGub/gub/target/linux-64/build/lilypond-git.sv.g

Re: Latest GUB error

We're getting further now. Again, thanks for all your help so far. This time I get: Traceback (most recent call last): File "/home/gub/NewGub/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/out/install", line 77, in shutil

Re: Latest GUB error

Am Dienstag, den 07.04.2020, 13:33 +0100 schrieb Phil Holmes: > Thanks. Sorry - I forgot the pull request. Now merged, but it still fails > trying to build darwin-ppc. AFAIR gub automatically updates itself from > github, so I don't think I need to pull it. Could you off

Re: Latest GUB error

Thanks. Sorry - I forgot the pull request. Now merged, but it still fails trying to build darwin-ppc. AFAIR gub automatically updates itself from github, so I don't think I need to pull it. Could you offer any further advice, please? -- Phil Holmes - Original Message -

  1   2   3   4   5   6   7   8   9   10   >