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
LilyPond 2.22.2 released
We are proud to announce the release of GNU LilyPond 2.22.2 on 2-22-22 (i.e. February the 22nd, 2022). LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version includes improvements and fixes since the release of the previous stable release in April 2021.
LilyPond 2.23.5 released
We are happy to announce the release of LilyPond 2.23.5. This is termed a development release, but these are usually reliable. If you want to use the current stable version of LilyPond, we recommend using the 2.22.1 version.
Re: Lilypond variables
On 28/11/2021 13:04, Jonas Hahnfeld wrote: Am Sonntag, dem 28.11.2021 um 12:57 + schrieb Phil Holmes: I'm trying to kick of a GUB build, but accessing my Ubuntu build machine via a different route, because of problems I had earlier with my Windows machine crashing. I'm using a Remote Desktop Connection from my Windows machine. The user interface looks fairly different, but everything seems to be there - except the variables like $LILYPOND_GIT and $LILYPOND_BUILD_DIR. I assume that the file that's run on logging in directly and which sets these variables isn't being run. Is there a way to set them manually by running the same file? If so, which would it be? Or is there a better way? Assuming you're using bash, `source .bash_profile` might do. However, I don't think the variables are needed for GUB. (In fact, I don't think LilyPond's build system uses them at all anymore.) Jonas It's getting the PO build done that fails, since it is instructed to build it from $LILY_POND_BUILD_DIR which doesn't exist. Phil
Lilypond variables
I'm trying to kick of a GUB build, but accessing my Ubuntu build machine via a different route, because of problems I had earlier with my Windows machine crashing. I'm using a Remote Desktop Connection from my Windows machine. The user interface looks fairly different, but everything seems to be there - except the variables like $LILYPOND_GIT and $LILYPOND_BUILD_DIR. I assume that the file that's run on logging in directly and which sets these variables isn't being run. Is there a way to set them manually by running the same file? If so, which would it be? Or is there a better way? Thanks in advance Phil H
Re: [RFC] Moving to Guile 2.2 and away from GUB
On 27/11/2021 17:30, Jonas Hahnfeld wrote: Am Samstag, dem 27.11.2021 um 11:13 +0100 schrieb Jonas Hahnfeld via Discussions on LilyPond development: 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 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 because we now have too many .ly files... Phil, if you want to do a release already tomorrow, we can probably merge the fixes early unless there are some immediate concerns. Jonas Can do a release tomorrow. I can pull the GUB fix before I do it if you want to push the Gitlab merge request. Phil
Re: ANN: Pygments support for LilyPond
On 22/11/2021 19:07, Jean Abou Samra wrote: Le 22/11/2021 à 20:05, Jean Abou Samra a écrit : Note that I don't intend to make it a public lilypond-book option for users, simply because it would require adding Pygments in the build process, which may be complicated (I don't know) and is in my opinion unnecessary. Sorry, the meaning of this sentence got lost in a rephrasing: I meant the build process to create the official binaries (GUB or Jonas' new system). I don't think we should be considering having a system where document builds in GUB are different from document builds in the normal development environment, for 2 reasons. 1) It could easily lead to difficult to debug problems with GUB (which is difficult as it is) and 2) it would make checking the docs before an "official" build impossible. Phil
LilyPond 2.23.3 released
We are happy to announce the release of LilyPond 2.23.3. This is termed a development release, but these are usually reliable. If you want to use the current stable version of LilyPond, we recommend using the 2.22.1 version. -- Phil Holmes
Lilypond 2.22.1 released
We are proud to announce the release of GNU LilyPond 2.22.1. This version includes improvements and fixes since the release of the previous stable release 2.22.0, in January 2021. -- Phil Holmes
LilyPond 2.23.2 released
We are happy to announce the release of LilyPond 2.23.2. This is termed a development release, but these are usually reliable. If you want to use the current stable version of LilyPond, we recommend using the 2.22.0 version. -- Phil Holmes
Re: LilyPond 2.23.1
Correction. The current stable version is 2.22.0. On 24/03/2021 09:07, Phil Holmes wrote: We are happy to announce the release of LilyPond 2.23.1. This is a development version, but these are usually reliable. If you want to use the latest stable version of LilyPond, we recommend using the 2.20.0 version. -- Phil Holmes
LilyPond 2.23.1
We are happy to announce the release of LilyPond 2.23.1. This is a development version, but these are usually reliable. If you want to use the latest stable version of LilyPond, we recommend using the 2.20.0 version. -- Phil Holmes
Re: Lilypond 2.23.0 released
Apologies. The current stable version is 2.22.0. On 25/01/2021 08:26, Phil Holmes wrote: We are happy to announce the release of LilyPond 2.23.0. This is a development version, but these are usually reliable. If you want to use the latest stable version of LilyPond, we recommend using the 2.20.0 version. -- Phil Holmes
Lilypond 2.23.0 released
We are happy to announce the release of LilyPond 2.23.0. This is a development version, but these are usually reliable. If you want to use the latest stable version of LilyPond, we recommend using the 2.20.0 version. -- Phil Holmes
LilyPond 2.22.0 released!
We are proud to announce the release of GNU LilyPond 2.22.0. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version includes improvements and fixes since the branching of the previous stable release in August 2017 (even though the final 2.20.0 was only released in March 2020). A list of added features and other user-visible changes can be found athttps://lilypond.org/doc/v2.22/Documentation/changes/ <https://lilypond.org/doc/v2.22/Documentation/changes>Behind the scenes, this release switches to Python 3 and includes a number of performance improvements that should be noticeable for larger scores. -- Phil Holmes
Re: state of the ’Pond for earnest tadpoles
It shouldn't take multiple hours unless your system is very slow. A few 10s of minutes is a more reasonable expectation. On 01/01/2021 23:00, Kieren MacMillan wrote: Hi Michael (et al.), please use http://lilypond.org/doc/v2.21/Documentation/contributor/lilydev instead. I adjusted some parts of this section last year. However, I would be happy to hear if something remains still unclear. This is great. Thanks. I have now compiled Lilypond on my machine! Took ~10 minutes (though I was doing a lot of other processor-intensive things at the same time, didn’t minimize the terminal window, etc., so I expect that can be reduced). Despite multiple attempts in the past, this is the first time I’ve ever been able to do that — thanks to all for the help to this point. The only suggestion I would have is to maybe mention that the initial build outputs *some* documentation. When I started seeing “Making Documentation/out” in the terminal output, I started to worry that I had somehow triggered the documentation build which would apparently take multiple hours. =) More soon! Kieren. Kieren MacMillan, composer (he/him/his) ‣ website: www.kierenmacmillan.info ‣ email: kie...@kierenmacmillan.info -- Phil Holmes
Removing a disk on an Ubuntu machine
The 2TB disk I used as an archive of GUB builds was reported to be failing by the BIOS SMART monitor. I managed to boot into the OS, but any attempt to read from the disk was paralysingly slow. I thought the best bet was to take it out and possibly read it with a USB interface. Successfully did that and confirmed that it was essentially unusable - very slow reads. Booted the system up. No go. It reported a fail and directed me to read the boot logfile. This seemed to show that it was still expecting that disk. Tried umount but had no effect. After a fair amount of hunting, I found a page advising editing etc/fstab. Used Nano to try that, and #'d out the apparently offending entry. It now boots. Seems a bit of a duff system that can't work out that a disk that isn't there should be ignored. On Windows swapping disks in and out causes no problems at all. That's another hour or so of my life gone. -- Phil Holmes
LilyPond 2.21.82
We released Lilypond 2.21.82 yesterday. This has a few bug fixes and documentation updates from 2.21.81 and is the latest release candidate for stable release 2.22.0. We encourage users and developers to download, use and test it. -- Phil Holmes
Lilypond 2.21.81 released
We are pleased to announce that Lilypond 2.21.81 has now been released and is available to download and install. This is the second (and hopefully final) release candidate for the next stable version: 2.22.0, so we would be grateful if as many users as possible could install and test it. Thanks in advance. -- Phil Holmes
Lilypond stable release candidate now available
We are pleased to announce that Lilypond 2.21.80 has now been released and is available to download and install. This is the first release candidate for the next stable version: 2.22.0, so we would be grateful if as many users as possible could install and test it. Thanks in advance. -- Phil Holmes
Re: ready for 2.21.80?
On 01/11/2020 12:30, Jonas Hahnfeld wrote: Am Sonntag, den 01.11.2020, 12:02 + schrieb Phil Holmes: Thanks. Now uploaded. Thanks to you for staying with us while we resolve such things! We do need to get the latest/correct VERSION into master, as well as updating the news details. That should allow the website to be rebuilt. I'm assuming that the best bet would be to cherry-pick the news updates from stable/2.22 into release/unstable, and edit and push VERSION to unstable as well, then create a merge request? Yes, though I'd use a temporary branch because that doesn't have the restriction of release/unstable that cannot be force-pushed. No worries. Be good if you could do this. I've not done a cherry-pick for ages now, but could have a go if you agree the process and are busy. I'm available today and can also do this. That would at the same time allow me to pick the commits from translation into master. Which commits do we need exactly from the release process? 168c4fac7d Release: bump VERSION_DEVEL. Think it might be easier just to update VERSION directly, since the current patch level is wrong for the updated master. 96027f94f5 Release: update news. 02a3c9de7a Release: update news with later date. Yep - need both to get the correct date and the updated old news. Anything else? We should probably also bump PATCH_LEVEL=81 in stable/2.22, right? For me, that's optional. We should probably cherry-pick an updated VERSION from master into stable/2.22 before the next pre-release, and if we do that there's not a lot of point in updating the VERSION in stable/2.22. I think the key about getting the website to rebuild correctly is to launch a pipeline when there are no other pipelines in progress - is that correct? Partly, concurrent pipelines only concern the merge request. The manual pipeline for building the website is independent. Jonas On 31/10/2020 19:13, Jonas Hahnfeld wrote: Am Samstag, den 31.10.2020, 17:55 +0100 schrieb Jonas Hahnfeld: Am Samstag, den 31.10.2020, 16:43 + schrieb Phil Holmes: GUB now almost completes, but fails making one of the German docs. It looks like this is the error: Forking into jobs: (10998 10997 10996 10995 10994 10993 10992 10991) logfile lilypond-multi-run-5.log (exit 1): ne breaks... Drawing systems... Writing ./16/lily-ec7f1c19-1.signature Layout output to `./16/lily-ec7f1c19.eps'... Converting to `./16/lily-ec7f1c19.pdf'... Converting to PNG... Layout output to `./16/lily-ec7f1c19-1.eps'... Converting to `./16/lily-ec7f1c19-1.pdf'... Writing ./16/lily-ec7f1c19-systems.texi... Writing ./16/lily-ec7f1c19-systems.tex... Writing ./16/lily-ec7f1c19-systems.count... Processing `./0d/lily-03b52edc.ly' Parsing... Interpreting music... Preprocessing graphical objects... Calculating line breaks... Drawing systems... Writing ./0d/lily-03b52edc-1.signature Layout output to `./0d/lily-03b52edc.eps'... Converting to `./0d/lily-03b52edc.pdf'... /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:282:15: In procedure make-tmpfile in expression (make-tmpfile basename (1- tries)): /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:282:15: Wrong number of arguments to # This points to the code path that is executed in case of a race where a temporary file is created by two processes. And the error message is absolutely right, that code could have never worked because it must call `inner` instead of `make-tmpfile` recursively. That should be easy to fix and while another execution of GUB might succeed (mine worked yesterday) I'd prefer to fix this problem for good in master and then backport immediately. Hopefully I can do that later this evening. Fixed by https://gitlab.com/lilypond/lilypond/-/merge_requests/490 and cherry-picked in https://gitlab.com/lilypond/lilypond/-/commit/b0dbcf35d9cba1b36c1e0210a207b5c9e226d669 Could you try again? Thanks, Jonas -- Phil Holmes
Re: ready for 2.21.80?
Thanks. Now uploaded. We do need to get the latest/correct VERSION into master, as well as updating the news details. That should allow the website to be rebuilt. I'm assuming that the best bet would be to cherry-pick the news updates from stable/2.22 into release/unstable, and edit and push VERSION to unstable as well, then create a merge request? I've not done a cherry-pick for ages now, but could have a go if you agree the process and are busy. I think the key about getting the website to rebuild correctly is to launch a pipeline when there are no other pipelines in progress - is that correct? On 31/10/2020 19:13, Jonas Hahnfeld wrote: Am Samstag, den 31.10.2020, 17:55 +0100 schrieb Jonas Hahnfeld: Am Samstag, den 31.10.2020, 16:43 + schrieb Phil Holmes: GUB now almost completes, but fails making one of the German docs. It looks like this is the error: Forking into jobs: (10998 10997 10996 10995 10994 10993 10992 10991) logfile lilypond-multi-run-5.log (exit 1): ne breaks... Drawing systems... Writing ./16/lily-ec7f1c19-1.signature Layout output to `./16/lily-ec7f1c19.eps'... Converting to `./16/lily-ec7f1c19.pdf'... Converting to PNG... Layout output to `./16/lily-ec7f1c19-1.eps'... Converting to `./16/lily-ec7f1c19-1.pdf'... Writing ./16/lily-ec7f1c19-systems.texi... Writing ./16/lily-ec7f1c19-systems.tex... Writing ./16/lily-ec7f1c19-systems.count... Processing `./0d/lily-03b52edc.ly' Parsing... Interpreting music... Preprocessing graphical objects... Calculating line breaks... Drawing systems... Writing ./0d/lily-03b52edc-1.signature Layout output to `./0d/lily-03b52edc.eps'... Converting to `./0d/lily-03b52edc.pdf'... /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:282:15: In procedure make-tmpfile in expression (make-tmpfile basename (1- tries)): /home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:282:15: Wrong number of arguments to # This points to the code path that is executed in case of a race where a temporary file is created by two processes. And the error message is absolutely right, that code could have never worked because it must call `inner` instead of `make-tmpfile` recursively. That should be easy to fix and while another execution of GUB might succeed (mine worked yesterday) I'd prefer to fix this problem for good in master and then backport immediately. Hopefully I can do that later this evening. Fixed by https://gitlab.com/lilypond/lilypond/-/merge_requests/490 and cherry-picked in https://gitlab.com/lilypond/lilypond/-/commit/b0dbcf35d9cba1b36c1e0210a207b5c9e226d669 Could you try again? Thanks, Jonas -- Phil Holmes
Re: ready for 2.21.80?
GUB now almost completes, but fails making one of the German docs. It looks
like this is the error:
Forking into jobs: (10998 10997 10996 10995 10994 10993 10992 10991)
logfile lilypond-multi-run-5.log (exit 1):
ne breaks...
Drawing systems...
Writing ./16/lily-ec7f1c19-1.signature
Layout output to `./16/lily-ec7f1c19.eps'...
Converting to `./16/lily-ec7f1c19.pdf'...
Converting to PNG...
Layout output to `./16/lily-ec7f1c19-1.eps'...
Converting to `./16/lily-ec7f1c19-1.pdf'...
Writing ./16/lily-ec7f1c19-systems.texi...
Writing ./16/lily-ec7f1c19-systems.tex...
Writing ./16/lily-ec7f1c19-systems.count...
Processing `./0d/lily-03b52edc.ly'
Parsing...
Interpreting music...
Preprocessing graphical objects...
Calculating line breaks...
Drawing systems...
Writing ./0d/lily-03b52edc-1.signature
Layout output to `./0d/lily-03b52edc.eps'...
Converting to `./0d/lily-03b52edc.pdf'...
/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:282:15:
In procedure make-tmpfile in expression (make-tmpfile basename (1- tries)):
/home/gub/NewGub/gub/target/linux-x86/root/usr/share/lilypond/current/scm/backend-library.scm:282:15:
Wrong number of arguments to #
fatal error: Children (5) exited with errors.
The lilypond source file is just:
%% Generated by lilypond-book
%% Options:
[exampleindent=10.16\mm,fragment,indent=0\mm,line-width=160\mm,quote,ragged-right]
\include "lilypond-book-preamble.ly"
%
% Start cut-&-pastable-section
%
\paper {
indent = 0\mm
line-width = 160\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.00) (* mm 1))
line-width = 160\mm - 2.0 * 10.16\mm
% offset the left padding, also add 1mm as lilypond creates cropped
% images with a little space on the right
line-width = #(- line-width (* mm 3.00) (* mm 1))
ragged-right = ##t
}
\layout {
}
{
%
% ly snippet contents follows:
%
\sourcefileline 3550
\once \override PhrasingSlur.positions = #'(2.5 . 4.5)
a'8 \( ( a''16 ) a'' \)
%
% end ly snippet
%
}
On 31/10/2020 15:16, Jonas Hahnfeld wrote:
Am Samstag, den 31.10.2020, 15:08 +0000 schrieb Phil Holmes:
Fails trying to do the PO make:
phil@ubuntu12:~/lilypond-git$ make -C $LILYPOND_BUILD_DIR po-replace
make: Entering directory '/media/IntelSSD/lilypond/lilypond-git/build'
/home/phil/lilypond-git/build/.././make/stepmake.make:116:
/home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-vars.make: No such
file or directory
/home/phil/lilypond-git/build/.././make/stepmake.make:123:
/home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-rules.make: No such
file or directory
/home/phil/lilypond-git/build/.././make/stepmake.make:125:
/home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-targets.make: No
such file or directory
make: *** No rule to make target
'/home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-targets.make'.
Stop.
make: Leaving directory '/media/IntelSSD/lilypond/lilypond-git/build'
Hm, these files are gone since August. Is that a fresh build directory,
with the source a checkout of stable/2.22? What puzzles me is that it
(apparently) worked for 2.21.7 and there has been no change to the PO
infrastructure since then (only before).
On 29/10/2020 15:52, Jonas Hahnfeld wrote:
Am Sonntag, den 25.10.2020, 14:42 +0100 schrieb Jonas Hahnfeld:
As the title says. We still need to merge the PO translations (see
https://gitlab.com/lilypond/lilypond/-/merge_requests/476 ) and pick
them to stable/2.22. If you speak one of the concerned languages that
I've been hijacking the translation for (ca, eo, es, it, nl, sv),
please consider giving it a short look. I'll also merge the translation
branch to stable/2.22 before asking Phil for a release.
All items from my list are done (above + fixing the translated snippets
when building in-tree) and stable/2.22 looks good from what I can tell.
So, I think we're ready for a first release candidate.
Phil, if you have time, could you run a build on stable/2.22? I will
stop picking fixes into the branch to avoid any interference (commits
to translation can of course continue).
Regards
Jonas
--
Phil Holmes
Re: ready for 2.21.80?
Nuked the build directory and redid configur, etc., and all now looks good, thanks. On 31/10/2020 15:16, Jonas Hahnfeld wrote: Am Samstag, den 31.10.2020, 15:08 + schrieb Phil Holmes: Fails trying to do the PO make: phil@ubuntu12:~/lilypond-git$ make -C $LILYPOND_BUILD_DIR po-replace make: Entering directory '/media/IntelSSD/lilypond/lilypond-git/build' /home/phil/lilypond-git/build/.././make/stepmake.make:116: /home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-vars.make: No such file or directory /home/phil/lilypond-git/build/.././make/stepmake.make:123: /home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-rules.make: No such file or directory /home/phil/lilypond-git/build/.././make/stepmake.make:125: /home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-targets.make: No such file or directory make: *** No rule to make target '/home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-targets.make'. Stop. make: Leaving directory '/media/IntelSSD/lilypond/lilypond-git/build' Hm, these files are gone since August. Is that a fresh build directory, with the source a checkout of stable/2.22? What puzzles me is that it (apparently) worked for 2.21.7 and there has been no change to the PO infrastructure since then (only before). On 29/10/2020 15:52, Jonas Hahnfeld wrote: Am Sonntag, den 25.10.2020, 14:42 +0100 schrieb Jonas Hahnfeld: As the title says. We still need to merge the PO translations (see https://gitlab.com/lilypond/lilypond/-/merge_requests/476 ) and pick them to stable/2.22. If you speak one of the concerned languages that I've been hijacking the translation for (ca, eo, es, it, nl, sv), please consider giving it a short look. I'll also merge the translation branch to stable/2.22 before asking Phil for a release. All items from my list are done (above + fixing the translated snippets when building in-tree) and stable/2.22 looks good from what I can tell. So, I think we're ready for a first release candidate. Phil, if you have time, could you run a build on stable/2.22? I will stop picking fixes into the branch to avoid any interference (commits to translation can of course continue). Regards Jonas -- Phil Holmes
Re: ready for 2.21.80?
Fails trying to do the PO make: phil@ubuntu12:~/lilypond-git$ make -C $LILYPOND_BUILD_DIR po-replace make: Entering directory '/media/IntelSSD/lilypond/lilypond-git/build' /home/phil/lilypond-git/build/.././make/stepmake.make:116: /home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-vars.make: No such file or directory /home/phil/lilypond-git/build/.././make/stepmake.make:123: /home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-rules.make: No such file or directory /home/phil/lilypond-git/build/.././make/stepmake.make:125: /home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-targets.make: No such file or directory make: *** No rule to make target '/home/phil/lilypond-git/build/../stepmake/stepmake/toplevel-targets.make'. Stop. make: Leaving directory '/media/IntelSSD/lilypond/lilypond-git/build' On 29/10/2020 15:52, Jonas Hahnfeld wrote: Am Sonntag, den 25.10.2020, 14:42 +0100 schrieb Jonas Hahnfeld: As the title says. We still need to merge the PO translations (see https://gitlab.com/lilypond/lilypond/-/merge_requests/476 ) and pick them to stable/2.22. If you speak one of the concerned languages that I've been hijacking the translation for (ca, eo, es, it, nl, sv), please consider giving it a short look. I'll also merge the translation branch to stable/2.22 before asking Phil for a release. All items from my list are done (above + fixing the translated snippets when building in-tree) and stable/2.22 looks good from what I can tell. So, I think we're ready for a first release candidate. Phil, if you have time, could you run a build on stable/2.22? I will stop picking fixes into the branch to avoid any interference (commits to translation can of course continue). Regards Jonas -- Phil Holmes
Re: ready for 2.21.80?
I see your confusion. My eyes obviously need testing :-( On 31/10/2020 13:31, Jonas Hahnfeld wrote: Am Samstag, den 31.10.2020, 13:23 + schrieb Phil Holmes: Looking at this now. I see that in the 2.22 branch VERSION numbers are stable 2.22.0 and devel will be 2.21.80. I've never really worked out how GUB decides to create a new stable version or a development version, but it's conceivable that it creates the highest numerical version. I'm wondering whether it would be good to have the stable version number fixed at 2.20.0 until we're ready to release 2.22.0? Not sure I can follow here, the current VERSION content is: MAJOR_VERSION=2 MINOR_VERSION=21 PATCH_LEVEL=80 MY_PATCH_LEVEL= VERSION_STABLE=2.20.0 VERSION_DEVEL=2.21.7 I think the normal release procedure should do here, ie bump VERSION_DEVEL to 2.21.80. After the release, PATCH_LEVEL in stable/2.22 should be 81 and the bump of VERSION_DEVEL needs to be applied to master. I agree that the stable version number should remain at 2.20.0 for the time being, in both stable/2.22 and master. On 29/10/2020 15:52, Jonas Hahnfeld wrote: Am Sonntag, den 25.10.2020, 14:42 +0100 schrieb Jonas Hahnfeld: As the title says. We still need to merge the PO translations (see https://gitlab.com/lilypond/lilypond/-/merge_requests/476 ) and pick them to stable/2.22. If you speak one of the concerned languages that I've been hijacking the translation for (ca, eo, es, it, nl, sv), please consider giving it a short look. I'll also merge the translation branch to stable/2.22 before asking Phil for a release. All items from my list are done (above + fixing the translated snippets when building in-tree) and stable/2.22 looks good from what I can tell. So, I think we're ready for a first release candidate. Phil, if you have time, could you run a build on stable/2.22? I will stop picking fixes into the branch to avoid any interference (commits to translation can of course continue). Regards Jonas -- Phil Holmes
Re: ready for 2.21.80?
Looking at this now. I see that in the 2.22 branch VERSION numbers are stable 2.22.0 and devel will be 2.21.80. I've never really worked out how GUB decides to create a new stable version or a development version, but it's conceivable that it creates the highest numerical version. I'm wondering whether it would be good to have the stable version number fixed at 2.20.0 until we're ready to release 2.22.0? On 29/10/2020 15:52, Jonas Hahnfeld wrote: Am Sonntag, den 25.10.2020, 14:42 +0100 schrieb Jonas Hahnfeld: As the title says. We still need to merge the PO translations (see https://gitlab.com/lilypond/lilypond/-/merge_requests/476 ) and pick them to stable/2.22. If you speak one of the concerned languages that I've been hijacking the translation for (ca, eo, es, it, nl, sv), please consider giving it a short look. I'll also merge the translation branch to stable/2.22 before asking Phil for a release. All items from my list are done (above + fixing the translated snippets when building in-tree) and stable/2.22 looks good from what I can tell. So, I think we're ready for a first release candidate. Phil, if you have time, could you run a build on stable/2.22? I will stop picking fixes into the branch to avoid any interference (commits to translation can of course continue). Regards Jonas -- Phil Holmes
Re: ready for 2.21.80?
Should get this done over the weekend. On 29/10/2020 15:52, Jonas Hahnfeld wrote: Am Sonntag, den 25.10.2020, 14:42 +0100 schrieb Jonas Hahnfeld: As the title says. We still need to merge the PO translations (see https://gitlab.com/lilypond/lilypond/-/merge_requests/476 ) and pick them to stable/2.22. If you speak one of the concerned languages that I've been hijacking the translation for (ca, eo, es, it, nl, sv), please consider giving it a short look. I'll also merge the translation branch to stable/2.22 before asking Phil for a release. All items from my list are done (above + fixing the translated snippets when building in-tree) and stable/2.22 looks good from what I can tell. So, I think we're ready for a first release candidate. Phil, if you have time, could you run a build on stable/2.22? I will stop picking fixes into the branch to avoid any interference (commits to translation can of course continue). Regards Jonas -- Phil Holmes
Re: lilypond.pot broken (SCM missing)
On 08/10/2020 16:33, Jonas Hahnfeld wrote: Am Donnerstag, den 08.10.2020, 13:58 +0200 schrieb Michael Käppler: Am 08.10.2020 um 13:35 schrieb Jonas Hahnfeld: Am Mittwoch, den 07.10.2020, 22:49 +0200 schrieb Michael Käppler: Hi all, while adding gettext calls to all warning and error messages I noticed that the strings from all SCM files are missing in lilypond.pot. Bisecting yielded that commit 5e092ee0d9b84d1948dc90e95488e8c9b58576d1 Author: Han-Wen Nienhuys Date: Sat Mar 21 23:46:14 2020 +0100 Inline scm stepmake templates caused the regression. It seems that the definition of $(SCM_FILES) in scm/GNUmakefile does not reach stepmake/stepmake/po-targets.make, where it would be needed to run xgettext on it. I do not know how to fix this correctly, any advice or MR appreciated. https://gitlab.com/lilypond/lilypond/-/merge_requests/446 should fix this and has some explanations what's going on. On the bad side, this means we've lost the translations for French, Italian, and Japanese in commit ea3ead41. The ones in Catalan, Dutch, Esperanto, Spanish, and Swedish are still there, prefixed by #~. I'm not very familiar how the translation of the po files happens, adding Jean-Charles who "fetches" and commits the files. What do we need to resurrect them? If that requires another release, I'm all for doing 2.21.7 from master before creating a stable branch. Jonas Hi Jonas, thank you very much! I will upload a MR today that fixes all warnings and errors that were not i18ned yet. I think it would be reasonable to merge that one, too, before sending the POT file to the Translation project. Posted here: https://gitlab.com/lilypond/lilypond/-/merge_requests/448 So as discussed on GitLab, we should indeed do a new unstable release to add back the erroneously removed messages and give the translators a chance to localize the other warnings and errors. Shall we short-track the fix and the above MR? Phil, would you be available to release 2.21.7 once merged? Regards Jonas No problem. Let me know when to go. -- Phil Holmes
Re: issue verification
I don't know if this isn't clear, but just to state the original point of verifying issues. If the change is claimed to fix a bug, we compile the previously buggy code with the release in which the bug is claimed fixed and check that the bug is no longer there. It it has really disappeared, we change the status of the issue from Fixed to Verified. i.e. we are certain that the bug is no longer there. If the change is to provide updated functionality, then it can be really quite hard to verify the new functionality, and in any case the patch review system should do that. So we simply check the patch was pushed into the claimed build. If it's clear that it was, we mark the status as Verified. That was the original intention of verifying issues. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Michael Käppler" ; "Jean Abou Samra" ; "lilypond-devel" Sent: Friday, September 18, 2020 7:57 AM Subject: Re: issue verification
Lilypond version display
Looks like I edited the wrong version level in my final change for yesterday's update. Think I need to edit VERSION again, push to release/unstable, create a merge request to merge into master and then a new pipeline to rebuild the web site. Everyone OK with that? Apologies. -- Phil Holmes
Lilypond build
I can't work out whether there was consensus on the next released build. Are we going with 2.21.6 and a release announcement that this is an initial pre-release for a new stable 2.22.0? Or perhaps go for 2.21.80 as a clearer sign that it's a pre-release? -- Phil Holmes
Language selection
If I go to http://lilypond.org/doc/v2.21/Documentation/notation/index.html and click any of the links, I get a page in Spanish, which I'm not. Anyone know why? -- Phil Holmes
LilyPond 2.21.5 release
We are pleased to announce the release of the latest development build of LilyPond, 2.21.5. -- Phil Holmes
2,21,4 released
Today we released build 2.21.4, the next development release of LilyPond. Amongst other updates, this corrects the problems with the documentation in the previous release. -- Phil Holmes
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
I did not start completely from scratch. I deleted /uploads and ran the rm -rf as documented in the CG. Do you have a recipe for a complete fresh build (other than be prepared for a decent wait..) -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Sunday, July 26, 2020 11:52 AM Subject: Re: GUB - today's problem
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 status make[1]: *** [out/lilypond] Error 1 -- Phil Holmes
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/gub/target/tools/root/usr/bin:/home/gub/NewGub/gub/target/tools/root/usr/bin:/home/gub/NewGub/gub/target/tools/root/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \ python2 test-lily/dist-check.py\ --branch=release/unstable \ --url=git://git.sv.gnu.org/lilypond.git \ --repository=downloads/lilypond /home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable make[4]: Entering directory `/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable' Making out/RELEASE-COMMIT make[5]: Entering directory `/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/python' make[6]: Entering directory `/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/python/auxiliar' Then about 200 lines of Entering... Leaving directories, then: make[5]: Leaving directory `/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable' tar: invalid argument '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' And that's where it stops doing anything. Anyone any ideas? -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Dan Eble" Cc: "Phil Holmes" ; "Devel" Sent: Monday, July 13, 2020 8:09 AM Subject: Re: GUB failing
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
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 <>
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
New release
I created a new release today. I know that (again) I got the news wrong and will need to fix that. However, it looks like the web docs are probably not correctly picking up a style sheet (see http://lilypond.org/doc/v2.21/Documentation/contributor/index_1#Introduction-to-contributing as a simple example) - they're certainly not presented correctly. Could anyone say what has gone wrong and what needs to be done to fix it? -- Phil Holmes
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
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
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>::dereference_scm() const [with T = const Book*; bool allow_mutation = true; ly_scm_iterator_t::private_scm = scm_unused_struct*]' without object make[1]: *** [out/book.o] Error 1 -- Phil Holmes
LilyPond 2.21.2 Released
We are happy to announce the release of LilyPond 2.21.2. This is a development version, but these are usually reliable. If you want to use the latest stable version of LilyPond, we recommend using the 2.20.0 version. -- Phil Holmes
Re: releasing 2.21.2
- Original Message -
From: "Federico Bruni"
To: "Jonas Hahnfeld"
Cc: "Phil Holmes" ; "lilypond-devel"
Sent: Sunday, June 21, 2020 3:05 PM
Subject: Re: releasing 2.21.2
Phil, while rebasing a local branch I noticed that you forgot to bump the
latest version here:
https://gitlab.com/lilypond/lilypond/-/blob/master/Documentation/web/news-headlines.itexi#L23
should be 2.21.2
Thanks.. The correction is now the subject of a merge request. I've had
issues in the past that the website doesn't always rebuild for a change like
this, so I'll keep my eye on it.
BTW, the anchors for the @uref items in news-headlines.itexi are giving me
headache. Any way to simplify them?
I don't know texinfo, it might exist a nice workaround.. the easiest
workaround could be the following.
As oy can see - me too...
1. In new-new.itexi, change the @subheading to a simple string:
@subheading Latest development version
...
@subheading Latest stable version
and move the date and versions in the paragraph, e.g.:
@emph{June 21, 2020} - We are happy to announce the release of LilyPond
2.21.2.
2. Then in news-headlines the @uref would never change (at least for the
two lilypond versions):
@uref{news.html#Latest-development-version,
LilyPond 2.21.2 released - @emph{June 21, 2020}}
@uref{news.html#Latest-stable-version,
LilyPond 2.20.0 released - @emph{March 1, 2020}}
What do you think?
Not really my area of expertise.
--
Phil Holmes
Make website problem
Just checked the output of the make website cron job, and it says: cat makeweb13.txt python3 /home/graham/lilypond/trusted-scripts/create-version-itexi.py /home/graham/lilypond/lilypond-git/ > out-website/version.itexi python3 /home/graham/lilypond/trusted-scripts/create-weblinks-itexi.py /home/graham/lilypond/lilypond-git/ > out-website/weblinks.itexi make: *** No rule to make target '/home/graham/lilypond/lilypond-git//Documentation/hu/learning/preface.itely', needed by 'out-website/learning.hu.xref-map'. Stop. Any ideas? -- Phil Holmes
Re: releasing 2.21.2
Merge request added. GitLab automatically added the labels Patch New. Does that need changing to get it into master? -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "lilypond-devel" Sent: Sunday, June 21, 2020 1:02 PM Subject: Re: releasing 2.21.2
Re: releasing 2.21.2
Looks like the tag command is hardwired in around line 185 of upload.py in test-lily. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "lilypond-devel" Sent: Sunday, June 21, 2020 1:02 PM Subject: Re: releasing 2.21.2
Re: releasing 2.21.2
Just successfully built and uploaded GUB :-) Two further questions: 1. Is there any problem with doing the final file updates (i.e. VERSION) into release/unstable and then opening a merge request from this branch? Seems simpler that creating a new branch for this: The process was (as in the CG): git fetch git checkout origin/staging git merge origin/release/unstable gedit VERSION git commit -m "Release: bump VERSION." VERSION git push origin HEAD:staging 2. The upload script adds a tag to the Savannah repo. I guess this needs adding to the GitLab repo, too. Would this be a manual step now? -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "lilypond-devel" Sent: Sunday, June 21, 2020 11:21 AM Subject: Re: releasing 2.21.2
Re: releasing 2.21.2
Just checking here. The process for pushing to release/unstable hasn't changed when using GitLab? What about synchronising release/unstable with master once the build has completed? -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "lilypond-devel" Sent: Saturday, June 20, 2020 2:01 PM Subject: Re: releasing 2.21.2
Re: releasing 2.21.2
OK. First question. Should I switch completely to GitLab for doing all the updating of news, VERSION, etc? That is - pretty much stop using Savannah for anything except GUB builds using my GUB user. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "lilypond-devel" Cc: Sent: Friday, June 19, 2020 8:05 PM Subject: Re: releasing 2.21.2
Re: remove merged branches & branches with tags
- Original Message - From: "Valentin Villenave" To: "Jonas Hahnfeld" Cc: "lilypond-devel" Sent: Wednesday, May 27, 2020 7:59 AM Subject: Re: remove merged branches & branches with tags On 5/26/20, Jonas Hahnfeld wrote: Is this OK with everyone? Fine by me. -- V. +1 -- Phil Holmes
Re: Markup vertical alignment
- Original Message - From: "Phil Holmes" To: "Devel" Sent: Wednesday, May 20, 2020 11:42 AM Subject: Markup vertical alignment Have a look at http://lilypond.org/doc/v2.21/Documentation/notation/formatting-text#text-alignment - the bit starting "Vertical alignment is a bit more complex". It says "the element to be moved needs to be preceded with an anchor point". Well - the positioning of une foret shows clearly that it doesn't. Trawling through my collection of Lilypond executable, it look like it changed between 2.17.26 and .28. I've not grasped the current process well enough to do a patch for review, but this looks trivial enough for a simple push/merge request. Could someone oblige? -- Phil Holmes The same is true of the next section on horizontal and vertical alignment. -- Phil Holmes
Markup vertical alignment
Have a look at http://lilypond.org/doc/v2.21/Documentation/notation/formatting-text#text-alignment - the bit starting "Vertical alignment is a bit more complex". It says "the element to be moved needs to be preceded with an anchor point". Well - the positioning of une foret shows clearly that it doesn't. Trawling through my collection of Lilypond executable, it look like it changed between 2.17.26 and .28. I've not grasped the current process well enough to do a patch for review, but this looks trivial enough for a simple push/merge request. Could someone oblige? -- Phil Holmes
Building the website
Currently I expect that the website is still being built from Savannah. It is updated by 2 cron jobs that run every hour, 30 minutes apart. update-git.sh updates its repository and make-website.sh makes the website. These scripts are shown on http://lilypond.org/doc/v2.21/Documentation/contributor/uploading-and-security I assume we should plan to change the server to use gitlab. I can access the server but don't feel confident to update its git repository. Could Jonas (or anyone else) confirm that we should change the server to use the new location and give me a step-by-step on how to do this? Thanks. -- Phil Holmes
Lilypond 2.21.1 released
We are pleased to announce the release of Lilypond 2.21.1. This is a development release and contains a number of updates from 2.21.0. -- Phil Holmes
Make website fails
oduction.itexi /home/graham/lilypond/lilypond-git//Documentation/fr/web/download.itexi /home/graham/lilypond/lilypond-git//Documentation/fr/included/generating-output.itexi /home/graham/lilypond/lilypond-git//Documentation/gpl.itexi /home/graham/lilypond/lilypond-git//Documentation/fr/web/manuals.itexi /home/graham/lilypond/lilypond-git//Documentation/fr/translations.itexi /home/graham/lilypond/lilypond-git//Documentation/fdl.itexi /home/graham/lilypond/lilypond-git//Documentation/fr/web/community.itexi /home/graham/lilypond/lilypond-git//Documentation/included/acknowledge.itexi /home/graham/lilypond/lilypond-git//Documentation/included/authors.itexi /home/graham/lilypond/lilypond-git//Documentation/included/gsoc.itexi /home/graham/lilypond/lilypond-git//Documentation/fr/included/helpus.itexi /home/graham/lilypond/lilypond-git//Documentation/web/news-new.itexi /home/graham/lilypond/lilypond-git//Documentation/web/news-old.itexi > out-website/web.fr.xref-map.dep ) && python3 /home/graham/lilypond/trusted-scripts/extract_texi_filenames.py -q --known-missing-files=/home/graham/lilypond/lilypond-git//scripts/build/website-known-missing-files.txt -I /home/graham/lilypond/lilypond-git//Documentation -I /home/graham/lilypond/lilypond-git//Documentation/fr/ -I out-website -o out-website --split=node /home/graham/lilypond/lilypond-git//Documentation/fr/web.texi ( mkdir -p out-website/ && echo ./out-website/web.hu.xref-map: /home/graham/lilypond/lilypond-git//Documentation/hu/macros.itexi /home/graham/lilypond/lilypond-git//Documentation/common-macros.itexi /home/graham/lilypond/lilypond-git//Documentation/cyrillic.itexi /home/graham/lilypond/lilypond-git//Documentation/web/news-headlines.itexi /home/graham/lilypond/lilypond-git//Documentation/hu/web/introduction.itexi /home/graham/lilypond/lilypond-git//Documentation/hu/web/download.itexi /home/graham/lilypond/lilypond-git//Documentation/hu/included/generating-output.itexi /home/graham/lilypond/lilypond-git//Documentation/gpl.itexi /home/graham/lilypond/lilypond-git//Documentation/hu/web/manuals.itexi /home/graham/lilypond/lilypond-git//Documentation/hu/translations.itexi /home/graham/lilypond/lilypond-git//Documentation/fdl.itexi /home/graham/lilypond/lilypond-git//Documentation/hu/web/community.itexi /home/graham/lilypond/lilypond-git//Documentation/included/authors.itexi /home/graham/lilypond/lilypond-git//Documentation/web/news-new.itexi /home/graham/lilypond/lilypond-git//Documentation/web/news-old.itexi > out-website/web.hu.xref-map.dep ) && python3 /home/graham/lilypond/trusted-scripts/extract_texi_filenames.py -q --known-missing-files=/home/graham/lilypond/lilypond-git//scripts/build/website-known-missing-files.txt -I /home/graham/lilypond/lilypond-git//Documentation -I /home/graham/lilypond/lilypond-git//Documentation/hu/ -I out-website -o out-website --split=node /home/graham/lilypond/lilypond-git//Documentation/hu/web.texi make: *** No rule to make target '/home/graham/lilypond/lilypond-git//Documentation/it/web/news-headlines.itexi', needed by 'out-website/web.it.xref-map'. Stop. -- Phil Holmes
Re: GUB help needed - fontforge error
I saw the pull request and so did give it a try. Jonas you are a magician!
However, any idea of any magic on this:
building package: linux-x86::lilypond-test
*** Stage: download (lilypond-test, linux-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-options')
{'use_re': True, 'to_name': None, 'must_succeed': False}
Traceback (most recent call last):
File "bin/gub", line 231, in exceptional_build
build (settings, options, files)
File "bin/gub", line 227, in build
b.build_source_packages (names)
File "bin/../gub/buildrunner.py", line 334, in build_source_packages
self.spec_build (spec_name)
File "bin/../gub/buildrunner.py", line 262, in spec_build
deferred_runner.execute_deferred_commands ()
File "bin/../gub/runner.py", line 167, in execute_deferred_commands
cmd.execute (self.logger)
File "bin/../gub/commands.py", line 271, in execute
loggedos.file_sub (logger, re_pairs, name, **self.kwargs)
File "bin/../gub/loggedos.py", line 52, in func_with_logging
val = logged_function (logger, func, *args, **kwargs)
File "bin/../gub/loggedos.py", line 19, in logged_function
return function (*args, **kwargs)
File "bin/../gub/misc.py", line 557, in file_sub
s = open (name).read ()
IOError: [Errno 2] No such file or directory:
'/home/gub/NewGub/gub/target/linux-x86/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable/scripts/build/out/xetex-with-options'
--
Phil Holmes
- Original Message -
From: "Jonas Hahnfeld"
To: "Phil Holmes" ; "Devel"
Sent: Monday, April 27, 2020 2:26 PM
Subject: Re: GUB help needed - fontforge error
Well, that library is *so* easy to build that it certainly can't hurt
to add it: https://github.com/gperciva/gub/pull/73
Please give it a try!
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: error: You may provide option `--without-libuninameslist` to build without this recommended feature See `config.log' for more details Command barfed: cd /home/gub/NewGub/gub/target/tools/build/fontforge-20190801 && chmod +x /home/gub/NewGub/gub/target/tools/src/fontforge-20190801/configure && sh /home/gub/NewGub/gub/target/tools/src/fontforge-20190801/configure --prefix=/home/gub/NewGub/gub/target/tools/root/usr --enable-shared --enable-static --disable-silent-rules --without-cairo --without-x --enable-python-scripting=3 CFLAGS=-I/home/gub/NewGub/gub/target/tools/root/usr/include LDFLAGS='-L/home/gub/NewGub/gub/target/tools/root/usr/lib -Wl,-rpath -Wl,\$$ORIGIN/../lib -Wl,-rpath -Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib ' Should I just add the "--without-libuninameslist" option to the fontforge command line in GUB? -- Phil Holmes
Re: Today's GUB failure
Doh. Thanks, as ever. It then failed trying to access https://pkg-config.freedesktop.org/ which appears to be off the air at present. I found an alternative at fossies.org and updated sources.py to use this location. It now gives me: 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: error: You may provide option ˋ--without-libuninameslistˋ to build without this recommended feature See `config.log' for more details Command barfed: cd /home/gub/NewGub/gub/target/tools/build/fontforge-20190801 && chmod +x /home/gub/NewGub/gub/target/tools/src/fontforge-20190801/configure && sh /home/gub/NewGub/gub/target/tools/src/fontforge-20190801/configure --prefix=/home/gub/NewGub/gub/target/tools/root/usr --enable-shared --enable-static --disable-silent-rules --without-cairo --without-x --enable-python-scripting=3 CFLAGS=-I/home/gub/NewGub/gub/target/tools/root/usr/include LDFLAGS='-L/home/gub/NewGub/gub/target/tools/root/usr/lib -Wl,-rpath -Wl,\$$ORIGIN/../lib -Wl,-rpath -Wl,/home/gub/NewGub/gub/target/tools/root/usr/lib ' -- Phil Holmes - Original Message ----- From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Sunday, April 26, 2020 12:18 PM Subject: Re: Today's GUB failure
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 Making mf/out/emmentaler-14.svg Copyright (c) 2000-2011 by George Williams. Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D. Library based on sources from 13:48 GMT 22-Feb-2011. /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-13.svg] Error 1 Copyright (c) 2000-2011 by George Williams. Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D. Library based on sources from 13:48 GMT 22-Feb-2011. /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-14.svg] Error 1 Copyright (c) 2000-2011 by George Williams. Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D. Library based on sources from 13:48 GMT 22-Feb-2011. Copyright (c) 2000-2011 by George Williams. Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D. Library based on sources from 13:48 GMT 22-Feb-2011. Copyright (c) 2000-2011 by George Williams. Executable based on sources from 13:48 GMT 22-Feb-2011-NoPython-D. Library based on sources from 13:48 GMT 22-Feb-2011. make: *** [all] Error 2 Command barfed: cd /home/gub/NewGub/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable && make -j16 TARGET_PYTHON=/usr/bin/python3 -- Phil Holmes
Re: What's up with the broken web pages?
There you go. Fixed :-) -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Han-Wen Nienhuys" ; "David Kastrup" Cc: "lilypond-devel" Sent: Sunday, April 12, 2020 3:57 PM Subject: Re: What's up with the broken web pages?
Re: What's up with the broken web pages?
I've updated the scripts on the website, but it looks like make website is not sensitive to a changed Python file and so does not rebuild the web pages. A possibility to force a rebuild would be to touch VERSION, but that would make the website out of step with master. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Han-Wen Nienhuys" ; "David Kastrup" Cc: "lilypond-devel" Sent: Sunday, April 12, 2020 1:22 PM Subject: Re: What's up with the broken web pages?
Re: bump VERSION in staging
Good catch thanks. Correct VERSION now in staging. Getting a bit rusty at doing releases -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "lilypond-devel" Cc: "Phil Holmes" Sent: Friday, April 10, 2020 10:03 AM Subject: Re: bump VERSION in staging
2.21.0 released
As it says. Many, many thanks to Jonas for helping to make this possible. It took 4 days for us to collaborate to get a successful release. -- Phil Holmes
Push direct to staging
I've pushed a very minor update to staging and release/unstable because a missing version was breaking GUB. Thanks to much help from Jonas, I'm hoping that will be the last road block. -- Phil Holmes
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/install/lilypond-2.21.0-root/usr/share/lilypond/*/python/* /home/gub/NewGub/gub/target/mingw/install/lilypond-2.21.0-root/usr/bin Traceback (most recent call last): File "bin/gub", line 231, in exceptional_build build (settings, options, files) File "bin/gub", line 227, in build b.build_source_packages (names) File "bin/../gub/buildrunner.py", line 334, in build_source_packages self.spec_build (spec_name) File "bin/../gub/buildrunner.py", line 262, in spec_build deferred_runner.execute_deferred_commands () File "bin/../gub/runner.py", line 167, in execute_deferred_commands cmd.execute (self.logger) File "bin/../gub/commands.py", line 75, in execute ignore_errors=self.ignore_errors) File "bin/../gub/loggedos.py", line 93, in system raise misc.SystemFailed (m) SystemFailed: Command barfed: cp /home/gub/NewGub/gub/target/mingw/install/lilypond-2.21.0-root/usr/share/lilypond/*/python/* /home/gub/NewGub/gub/target/mingw/install/lilypond-2.21.0-root/usr/bin -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Cc: "David Kastrup" ; "Han-Wen Nienhuys" Sent: Wednesday, April 08, 2020 10:36 AM Subject: Re: Latest GUB error
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 current master and release/unstable when installing from a separate directory. This needs a fix in LilyPond. I think we can either revert the "offending" commit (which has conflicts, see other thread on lilypond-devel) or take a minimum of https://codereview.appspot.com/549810043. I'd prefer the latter, but that would require a rather quick consensus and pushing outside of the usual review cycle. Jonas Is anyone actively opposing that patch? If it fixes the build and there is no opposition I think it should be pushed. -- Phil Holmes
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.copy2 (f, dest) File "/home/gub/NewGub/gub/target/tools/root/usr/lib/python3.7/shutil.py", line 266, in copy2 copyfile(src, dst, follow_symlinks=follow_symlinks) File "/home/gub/NewGub/gub/target/tools/root/usr/lib/python3.7/shutil.py", line 120, in copyfile with open(src, 'rb') as fsrc: FileNotFoundError: [Errno 2] No such file or directory: 'book_base.py' make[1]: *** [local-install-outfiles] Error 1 make: *** [install] Error 2 Command barfed: cd /home/gub/NewGub/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable && make TARGET_PYTHON=/usr/bin/python3 DESTDIR=/home/gub/NewGub/gub/target/linux-64/install/lilypond-2.21.0-root install Traceback (most recent call last): File "bin/gub", line 231, in exceptional_build build (settings, options, files) File "bin/gub", line 227, in build b.build_source_packages (names) File "bin/../gub/buildrunner.py", line 334, in build_source_packages self.spec_build (spec_name) File "bin/../gub/buildrunner.py", line 262, in spec_build deferred_runner.execute_deferred_commands () File "bin/../gub/runner.py", line 167, in execute_deferred_commands cmd.execute (self.logger) File "bin/../gub/commands.py", line 75, in execute ignore_errors=self.ignore_errors) File "bin/../gub/loggedos.py", line 93, in system raise misc.SystemFailed (m) SystemFailed: Command barfed: cd /home/gub/NewGub/gub/target/linux-64/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable && make TARGET_PYTHON=/usr/bin/python3 DESTDIR=/home/gub/NewGub/gub/target/linux-64/install/lilypond-2.21.0-root install -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Tuesday, April 07, 2020 1:36 PM Subject: Re: Latest GUB error
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 - From: "Jonas Hahnfeld" To: "Phil Holmes" ; "Devel" Sent: Tuesday, April 07, 2020 12:45 PM Subject: Re: Latest GUB error
Latest GUB error
Making lily/out/lilypond Making flower/out/library.a ar: `u' modifier ignored since `D' is the default (see `U') ar: out/library.a: File format is ambiguous ar: Matching formats: elf32-big elf64-big make[2]: *** [out/library.a] Error 1 make[1]: *** [out/lilypond] Error 2 make: *** [all] Error 2 Command barfed: cd /home/gub/NewGub/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable && make -j16 TARGET_PYTHON="/usr/bin/env python2" Traceback (most recent call last): File "bin/gub", line 231, in exceptional_build build (settings, options, files) File "bin/gub", line 227, in build b.build_source_packages (names) File "bin/../gub/buildrunner.py", line 334, in build_source_packages self.spec_build (spec_name) File "bin/../gub/buildrunner.py", line 262, in spec_build deferred_runner.execute_deferred_commands () File "bin/../gub/runner.py", line 167, in execute_deferred_commands cmd.execute (self.logger) File "bin/../gub/commands.py", line 75, in execute ignore_errors=self.ignore_errors) File "bin/../gub/loggedos.py", line 93, in system raise misc.SystemFailed (m) SystemFailed: Command barfed: cd /home/gub/NewGub/gub/target/darwin-ppc/build/lilypond-git.sv.gnu.org--lilypond.git-release-unstable && make -j16 TARGET_PYTHON="/usr/bin/env python2" -- Phil Holmes
Re: GUB failure
If I type python-gdbm at the terminal I get "command not found". a) is this the right way to check? b) I'd appreciate guidance on how best to install it if I don't have it. Thanks. -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Phil Holmes" Cc: "David Kastrup" ; "Devel" Sent: Tuesday, April 07, 2020 10:25 AM Subject: Re: GUB failure
Re: GUB failure
- Original Message - From: "Phil Holmes" To: "Thomas Morley" Cc: "David Kastrup" ; "Devel" Sent: Monday, April 06, 2020 5:02 PM Subject: Re: GUB failure I bit the bullet and started the upgrade to 16.04. I check that's OK then consider 18.04 later. Upgrading via the GUI software updater. Now with Ubuntu 16.04 and therefore Python 3.5, the build failed. Any help appreciated. Error was: Traceback (most recent call last): File "bin/gub", line 231, in exceptional_build build (settings, options, files) File "bin/gub", line 206, in build manager = gup.DependencyManager (settings.system_root) File "bin/../gub/gup.py", line 353, in __init__ PackageManager.__init__ (self, *args, **kwargs) File "bin/../gub/gup.py", line 314, in __init__ FileManager.__init__ (self, root, **kwargs) File "bin/../gub/gup.py", line 59, in __init__ self._file_package_db = db.open (files_db, 'c') File "/usr/lib/python2.7/anydbm.py", line 84, in open mod = __import__(result) ImportError: No module named gdbm gub.make:63: recipe for target 'packages' failed make[1]: *** [packages] Error 1 make[1]: Leaving directory '/home/gub/NewGub/gub' GNUmakefile:26: recipe for target 'lilypond' failed make: *** [lilypond] Error 2 -- Phil Holmes
Re: GUB failure
I bit the bullet and started the upgrade to 16.04. I check that's OK then consider 18.04 later. Upgrading via the GUI software updater. -- Phil Holmes - Original Message - From: "Thomas Morley" To: "Phil Holmes" Cc: "David Kastrup" ; "Devel" Sent: Monday, April 06, 2020 4:18 PM Subject: Re: GUB failure Am Mo., 6. Apr. 2020 um 16:52 Uhr schrieb Phil Holmes : As predicted, GUB has failed to build on my system. The error message shows that it's because I have Python 3.4.3 and I need at least 3.5. If anyone knows how to upgrade my Ubuntu 14 machine to the later Python version, please say. Probably http://ubuntuhandbook.org/index.php/2017/07/install-python-3-6-1-in-ubuntu-16-04-lts/ adapted to your needs may help. Otherwise I'll have to upgrade to Ubuntu 16, which I was avoiding while I still had a working installation. _If_ you need to upgrade, why not newest Ubuntu? I'll test GUB with current master on my Ubuntu 18.04, though results likely tomorrow... Cheers, Harm
GUB failure
As predicted, GUB has failed to build on my system. The error message shows that it's because I have Python 3.4.3 and I need at least 3.5. If anyone knows how to upgrade my Ubuntu 14 machine to the later Python version, please say. Otherwise I'll have to upgrade to Ubuntu 16, which I was avoiding while I still had a working installation. -- Phil Holmes
Re: 2.21.0 and announcements
- Original Message - From: "Davide Liessi" To: "lilypond-devel" Cc: "Phil Holmes" Sent: Tuesday, March 31, 2020 1:16 PM Subject: Re: 2.21.0 and announcements Il giorno mar 31 mar 2020 alle ore 12:15 Phil Holmes ha scritto: Probably expected. The website text updates automatically - it pulls git and does a "make website" every hour. However, documents and functionality only get updated with a new build via GUB. The links that remained unchanged are part of the website: the script I mentioned is run by `make website` to generate those links. The download links are present in the current website, which means, I think, that the script was run. However they are the old version of the links without my changes, which makes me think that an old version of the script was run to make the website, instead of the current one. Any ideas? I believe that the scripts are not automatically updated for security reasons. I should be able to do this manually when I next upload a build - I'm assuming that will not be too far into the future. Is that OK? -- Phil Holmes
Re: 2.21.0 and announcements
- Original Message - From: "Davide Liessi" To: "lilypond-devel" Sent: Tuesday, March 31, 2020 10:57 AM Subject: Re: 2.21.0 and announcements Il giorno mar 31 mar 2020 alle ore 10:16 ha scritto: It will eventually become part of the Website. I see that the new links are already online, while the existing links haven't changed yet. My patch changed the make_download calls in scripts/build/create-weblinks-itexi.py, but it seems like the old version of that script was run. Is this expected or did I miss anything in my patch? Best wishes. Davide Probably expected. The website text updates automatically - it pulls git and does a "make website" every hour. However, documents and functionality only get updated with a new build via GUB. -- Phil Holmes
Re: Anything missing for 2.21.0?
- Original Message - From: "David Kastrup" To: "Werner LEMBERG" Cc: Sent: Sunday, March 29, 2020 6:10 PM Subject: Re: Anything missing for 2.21.0? Werner LEMBERG writes: Anybody can think of a holdup? No holdup, but I would like to see an LSR import to synchronize documentation with snippets. I think that's standard as part of the release procedure? -- David Kastrup Probably should be, but isn't. I'll try to remember when we have the go ahead. -- Phil Holmes
Re: [translations] Changes section in stable
- Original Message - From: "Francisco Vila" To: "David Kastrup" ; "Jean-Charles Malahieude" Cc: "Translations list at lilynet" ; "LilyPond-Devel list" Sent: Monday, March 09, 2020 7:55 PM Subject: Re: [translations] Changes section in stable El 9/3/20 a las 20:37, David Kastrup escribió: Jean-Charles Malahieude writes: Le 09/03/2020 à 18:21, Francisco Vila a écrit : Anyway. I expected wrongly to see translated es/changes showing online, but this will only happpen when the second stable minor version occurrs. Right? Wrong! translation has to be merged into master and then the website regenerated. I think Francisco is talking about 2.18–2.20 changes, not 2.20–2.22 changes. True, the latter is devel- , but devel now in the page is 2.19 (= future 2.20) so changes page in devel section is still "2.20 since 2.18". 404 also for me in http://lilypond.org/website/development.es.html BTW. I really have no clue just when and how the _stable_ documentation makes it into our web pages. Mmm, tricky. It shouldn't be an obscure manual process. It's not an obscure manual process, it's an obscure automatic process. I built 2.20 with GUB, uploaded it with GUB and it automatically created the "stable" docs and opposed to the unstable ones. -- Phil Holmes
Re: Missing link
Yep. http://git.savannah.gnu.org/cgit/lilypond.git/commit/?id=ed1c70f3a7704253cf93c5c031d6f9ce5408f26c -- Phil Holmes - Original Message - From: To: "Trevor" ; "Lily-Devel List" Sent: Monday, March 09, 2020 1:49 PM Subject: Re: Missing link Hello On 01/03/2020 23:10, Trevor wrote: Congratulations to all involved in getting 2.20 out the door! This is a big step forward. One minor glitch I noticed: in http://lilypond.org/website/all.html the link to the 2.18 documentation in the list of previous stable versions has gone AWOL, although the documentation itself is still in the correct place in http://lilypond.org/doc/v2.18/Documentation/web/manuals Current users of 2.18 will still need this until they get around to migrating. Trevor This looks fixed / correct now. James
Re: Linking 64-bit Mac builds from website
> Why would there be a synchronization issue? I’m not sure I under stand the
> problem you’re envisioning.
Because I'd be building the documentation and the website and all the other
binaries, and you'd be building 64-bit Mac. If I release 2.21.2 (for instance)
and it's not already on the website as a 64-bit Mac build, it will be a dead
link. So we would need a system to synchronise GUB builds and 64-bit Mac
builds.
At present, you can't upload to lilypond.org. Han Wen could change that if
necessary.
--
Phil Holmes
- Original Message -
From: Marnen Laibow-Koser
To: Phil Holmes
Cc: LilyPond ; pkx1...@posteo.net
Sent: Sunday, March 08, 2020 6:23 PM
Subject: Re: Linking 64-bit Mac builds from website
On Sun, Mar 8, 2020 at 2:07 PM Phil Holmes wrote:
> Would adding the links require manual intervention? If possible I’d like
to avoid that so that there’s minimal friction when a new build is released.
I don't see why, once they have initially been established. The only issue
might be timing synchronisation. If the website is updated with a new version,
it would be good to have the Mac binaries already there, rather than a dead
link for a while.
Why would there be a synchronization issue? I’m not sure I under stand the
problem you’re envisioning.
> The zipped .app bundles have been about 35–56 MB. Have a look here:
Too big to email. Can you ftp them to a website, or would you propose
getting them to me with a file transfer site?
I’d propose having GitLab CI (or whatever automated builder I wind up with)
post them directly to an API or FTP/SCP them to the appropriate place, or
alternatively to host then externally (on Bintray or GitLab, say) and just
provide links. But whatever we decide, it should be automatic just as I gather
it currently is with GUB.
The idea I have:
1. Every tag, or even every Git commit, automatically triggers a build.
2. The completed build is automatically pushed to some download server.
3. The website automatically provides a link to the completed build.
Right now I already have a usable Makefile and build environment; I just need
get some final kinks out and automate step 1 with GitLab CI or similar. Once
that happens, if we can automate steps 2 and 3 as well, we will have a fully
automatic pipeline for the 64-bit Mac builds. I don’t want any human
(including myself) to be a single point of failure in the pipeline.
--
Phil Holmes
Best,
--
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile
Re: Linking 64-bit Mac builds from website
> Would adding the links require manual intervention? If possible I’d like to
> avoid that so that there’s minimal friction when a new build is released.
I don't see why, once they have initially been established. The only issue
might be timing synchronisation. If the website is updated with a new version,
it would be good to have the Mac binaries already there, rather than a dead
link for a while.
> The zipped .app bundles have been about 35–56 MB. Have a look here:
Too big to email. Can you ftp them to a website, or would you propose getting
them to me with a file transfer site?
--
Phil Holmes
- Original Message -
From: Marnen Laibow-Koser
To: Phil Holmes
Cc: LilyPond ; pkx1...@posteo.net
Sent: Sunday, March 08, 2020 4:28 PM
Subject: Re: Linking 64-bit Mac builds from website
On Sun, Mar 8, 2020 at 12:14 PM Phil Holmes wrote:
I ought to be able to scp them to the downloads directory and then we could
put an appropriate link into the docs that build the website.
Would adding the links require manual intervention? If possible I’d like to
avoid that so that there’s minimal friction when a new build is released.
How big is the file?
The zipped .app bundles have been about 35–56 MB. Have a look here:
https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83#files
--
Phil Holmes
Best,
--
Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail
Mobile
Re: Linking 64-bit Mac builds from website
I ought to be able to scp them to the downloads directory and then we could put an appropriate link into the docs that build the website. How big is the file? -- Phil Holmes - Original Message - From: Marnen Laibow-Koser To: Phil Holmes Cc: LilyPond ; pkx1...@posteo.net Sent: Sunday, March 08, 2020 3:05 PM Subject: Re: Linking 64-bit Mac builds from website On Sun, Mar 8, 2020 at 6:49 AM Phil Holmes wrote: [...] I do that. The downloads section is automagically managed by GUB and I do the builds and upload the updates. So when the time comes (which isn’t quite yet, but should be soon if all goes well), what’s a good way of getting the non-GUB 64-bit Mac builds onto the website? (There will be an automated process building them, probably GitLab CI, if that’s helpful to know.) Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org Sent from Gmail Mobile
Re: Linking 64-bit Mac builds from website
- Original Message - From: To: "Marnen Laibow-Koser" ; "LilyPond" Sent: Sunday, March 08, 2020 10:43 AM Subject: Re: Linking 64-bit Mac builds from website Marnen, On 02/03/2020 20:23, Marnen Laibow-Koser wrote: Folks-- It seems that I've got a working process for 64-bit Mac builds of LilyPond, and I will soon automate the process to build Mac .app bundles for every tagged release. Which brings me to the next question: what is the process to update the LilyPond website so that download links for these builds are directly available? The website is (re)generated from the LP source code periodically by a few developers who push the changes up. Editing the website is similar to editing our main documentation - i.e. via patches which get tested and merged into the main source code. However I am not sure who manages the download site where the stable and unstable binaries are held. http://lilypond.org/download/binaries/ Hopefully someone will be able to expand on this from the developers. Also see: http://lilypond.org/doc/v2.19/Documentation/contributor-big-page#website-work Regards James I do that. The downloads section is automagically managed by GUB and I do the builds and upload the updates. -- Phil Holmes
Re: 2.21.0 release plans and considerations
If you're ever desperate to get a pull request accepted into GUB, and are sure it's OK, please email me. I normally only pull them when I'm about to make a build -- Phil Holmes - Original Message - From: "Jonas Hahnfeld" To: "Han-Wen Nienhuys" Cc: "David Kastrup" ; "lilypond-devel" Sent: Thursday, March 05, 2020 6:54 PM Subject: Re: 2.21.0 release plans and considerations
Re: Missing link
I've just put an update in staging. -- Phil Holmes - Original Message - From: "Trevor" To: "Lily-Devel List" Sent: Sunday, March 01, 2020 11:10 PM Subject: Missing link Congratulations to all involved in getting 2.20 out the door! This is a big step forward. One minor glitch I noticed: in http://lilypond.org/website/all.html the link to the 2.18 documentation in the list of previous stable versions has gone AWOL, although the documentation itself is still in the correct place in http://lilypond.org/doc/v2.18/Documentation/web/manuals Current users of 2.18 will still need this until they get around to migrating. Trevor
Re: 2.20.0 release coordination with translation. Other showstoppers?
But it doesn't make sense to point VERSION_DEVEL to documentation that is actually older than that of 2.20, does it? I do not really know what is correct here with respect to our semi-automatic webpage update mechanism. I just remember that we had problems last time round. -- David Kastrup I think it needs to point to documentation that actually exists, since we won't be building for the development version. There's no reason not to launch a 2.21 fairly soon afterwards, and the problem you're citing would then go away. -- Phil Holmes
Re: 2.20.0 release coordination with translation. Other showstoppers?
- Original Message - From: "David Kastrup" To: "Federico Bruni" Cc: ; ; "Phil Holmes" Sent: Saturday, February 22, 2020 10:54 PM Subject: Re: 2.20.0 release coordination with translation. Other showstoppers? Federico Bruni writes: Il giorno sab 22 feb 2020 alle 19:25, David Kastrup ha scritto: German Changes file has been added by now. Where are we with regard to the other translations? Federico? I'm still working on it. My spare time is limited and the changes by Werner requires a lot of meticulous edits. If you want to release tomorrow, let me know and I'll push tonight what I manage to do. Then the rest of the update might be included in 2.20.2. Or, if you prefer waiting for the whole italian update, I will advise when I've completed it. I cannot say now how long it will take exactly. Probably not before tomorrow night. My principle plan would be to tell Phil to go ahead (after receiving the last OK from people doing last-minute work) at a point of time where he thinks he may be somewhat responsive in the followup days, just in case something hits the fan. One interesting consideration is that the VERSION file upon release should look like PACKAGE_NAME=LilyPond MAJOR_VERSION=2 MINOR_VERSION=20 PATCH_LEVEL=0 MY_PATCH_LEVEL= VERSION_STABLE=2.20.0 VERSION_DEVEL=2.20.0 basically announcing the same versions as stable and unstable since 2.20.0 will both be the latest stable release as well as the latest release altogether. Things will normalise once we get a followup unstable release. I seem to remember that if we declared VERSION_DEVEL to point to a yet unreleased 2.21.0, the links would essentially end up dead. So there are little quirks like that accompanying a stable release that might cause followup work. So "last day of weekend" sounds only sensible if Phil is not considerably unavailable afterwards. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive". I am generally available for the next few weeks. I would think it better to wait a few days to get the translations stable, since it will take me a little while to get my head round what's needed for a new stable release. I think that VERSION_DEVEL will need to be 2.19.84 for this release, otherwise we won't have any links to "development" documentation. -- Phil Holmes
Re: Add Code of Conduct [Another RFC or not now?]
- Original Message - From: "Werner LEMBERG" To: Cc: ; ; ; ; Sent: Saturday, February 08, 2020 5:50 PM Subject: Re: Add Code of Conduct [Another RFC or not now?] However, I'd like to hear from David Kastrup and James Lowe first. To me, their opposition registered as the strongest. I remain strongly opposed to a CoC. Hmm. What about simply using the GNU Kind Communication Guidelines, maybe adding 'LilyPond' at some strategic places? Werner I've not read them, so can't immediately comment. FWIW I had substantial experience of managing commercial developments (1,500 developers, over $200M annual budget). Every now and then HR would tell us we needed things like this, and force us all onto training courses. It just wasted time. The best solution is always understanding and taking things easy. -- Phil Holmes
Re: Add Code of Conduct [Another RFC or not now?]
- Original Message - From: "Karlin High" However, I'd like to hear from David Kastrup and James Lowe first. To me, their opposition registered as the strongest. I remain strongly opposed to a CoC. -- Phil Holmes
Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)
- Original Message - From: To: ; ; ; ; ; ; ; Cc: ; Sent: Wednesday, February 05, 2020 7:08 PM Subject: Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com) On 2020/02/05 18:17:25, c_sorensen wrote: I recognize that Mike Solomon has a different opinion. I mean no disrespect to Mike, Janek, Han-Wen, or any other member of the LilyPond team. I highly value the team spirit of the LilyPond team. Well said. Here's the current tally as I understand it: For: Han-Wen, Janek, Mike, Urs, Werner Against: Carl, Dan, David K., Trevor Mixed: David N. Mike, you asked, What are the blockers to making a decision about this patch? Does it need more discussion or more buy in? 5-4 halfway through the first day doesn't look like buy-in to me. https://codereview.appspot.com/575620043/ I've kept out of this debate for a long time because a) I've only been peripherally involved lately and b) there's been too much communication for me to read, but As one of the earlier regular committers, and as the only person who makes builds and updates the websites, I'd vote for no change. No CoC (not needed); keep the current workflow (easy to do if follow the instructions), and make builds work -- Phil Holmes
Re: New build:
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: Sent: Wednesday, February 05, 2020 3:50 PM Subject: Re: New build: "Phil Holmes" writes: The web site is now fairly up-to-date. I say "fairly" because "news" has not been updated. I believe this is because the website is actually built automatically from master, whereas I updated news in stable/2.20. I guess the simplest option is to cherry-pick my updates to the news files into staging. I remain a bit uncertain about git (and fairly out of practice). Could someone (David?) skilled in the art update staging from stable/2.20? On the way. -- David Kastrup LGTM. Website now up-to-date. -- Phil Holmes
Re: New build:
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: ; Sent: Wednesday, February 05, 2020 3:05 PM Subject: Re: New build: David Kastrup writes: "Phil Holmes" writes: The build completed successfully, as did the upload, so anyone looking at the manuals on lilypond.org will see 19.84 information. However, the website has not built, I think because VERSION in master has not been updated. I've pushed an updated VERSION to staging, but my patchy refuses to run because I have a too -old version of Python. Python -V gives 2.7.6. Could someone: 1. Tell me a safe method for getting Python >3.5 on Ubuntu 14.04, please? No idea. You have backports already enabled in your update sources? In case it may be available from there? Should be checkable as "settings and ???" when calling sudo update-manager 2. Possibly run patchy-staging On its way. patchy-staging completed. -- David Kastrup The web site is now fairly up-to-date. I say "fairly" because "news" has not been updated. I believe this is because the website is actually built automatically from master, whereas I updated news in stable/2.20. I guess the simplest option is to cherry-pick my updates to the news files into staging. I remain a bit uncertain about git (and fairly out of practice). Could someone (David?) skilled in the art update staging from stable/2.20? Thanks again. -- Phil Holmes
New build: was:Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)
- Original Message - From: "David Kastrup" To: "Phil Holmes" Cc: "Jonas Hahnfeld" ; "Dan Eble" ; "Masamichi Hosoda" ; ; Sent: Tuesday, February 04, 2020 5:34 PM Subject: Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com) "Phil Holmes" writes: - Original Message - From: "David Kastrup" Wow. Ok, maybe I'll just apply this patch then (though I'll at least remove the conditioning on Apple here as the problem is rather likely platform independent) and Phil may have another round. -- David Kastrup Will kick this off again tomorrow. Thanks! -- David Kastrup The build completed successfully, as did the upload, so anyone looking at the manuals on lilypond.org will see 19.84 information. However, the website has not built, I think because VERSION in master has not been updated. I've pushed an updated VERSION to staging, but my patchy refuses to run because I have a too -old version of Python. Python -V gives 2.7.6. Could someone: 1. Tell me a safe method for getting Python >3.5 on Ubuntu 14.04, please? 2. Possibly run patchy-staging Thanks -- Phil Holmes
Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)
- Original Message - From: "David Kastrup" Wow. Ok, maybe I'll just apply this patch then (though I'll at least remove the conditioning on Apple here as the problem is rather likely platform independent) and Phil may have another round. -- David Kastrup Will kick this off again tomorrow. -- Phil Holmes
Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com)
- Original Message - From: "David Kastrup" To: "Masamichi Hosoda" Cc: ; Sent: Tuesday, February 04, 2020 2:56 PM Subject: Re: Inline assembler fallback for _FPU_SETCW() missing in MINGW libraries (issue 577450043 by thomasmorle...@gmail.com) Wouldn't the same problem occur on Windows? We have 32bit executables there as well. Or is the compiler version we use there not afflicted? -- David Kastrup I'd suggest applying Hosoda-san's patch to stable/2.20 and I'll run Gub again. If it runs OK, we're good. If not, we can revert and rethink? -- Phil Holmes
GUB fail
David K warned me this morning that my attempt to build 2.19.84 might fail
with a compiler error. It did. The error output is:
/home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/rational.cc:43:1:
internal compiler error: in gen_reg_rtx, at emit-rtl.c:838
}
^
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/libexec/gcc/i686-apple-darwin8/4.9.4/cc1plus:
tried to open () file
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
/home/gub/NewGub/gub/target/darwin-x86/src/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower/rational.cc:43:1:
internal compiler error: Aborted
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/libexec/gcc/i686-apple-darwin8/4.9.4/cc1plus:
tried to open () file
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
{standard input}:unknown:Undefined local symbol
L__ZNSs4_Rep10_M_destroyERKSaIcE$stub
i686-apple-darwin8-g++: internal compiler error: Aborted (program cc1plus)
librestrict:error:/home/gub/NewGub/gub/target/darwin-x86/root/usr/cross/bin/i686-apple-darwin8-g++:
tried to open () file
/home/gub/NewGub/gub/target/tools/root/usr/lib/librestrict.so
librestrict:allowed:
/home/gub/NewGub/gub/target/darwin-x86
/tmp
/dev/null
/dev/urandom
/proc/self
Aborted (core dumped)
make[1]: *** [out/rational.o] Error 134
make[1]: Leaving directory
`/home/gub/NewGub/gub/target/darwin-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20/flower'
make: *** [all] Error 2
Command barfed: cd
/home/gub/NewGub/gub/target/darwin-x86/build/lilypond-git.sv.gnu.org--lilypond.git-stable-2.20
&& make -j16 TARGET_PYTHON="/usr/bin/env python"
--
Phil Holmes
