Am Sonntag, den 01.11.2020, 12:36 +0000 schrieb Phil Holmes: > On 01/11/2020 12:30, Jonas Hahnfeld wrote: > > Am Sonntag, den 01.11.2020, 12:02 +0000 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.
Ok, will do. > > > 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. Yeah, that could give conflicts. I'll see what git does for me 😄 > > 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. Hm, but master is currently at 2.23.0. Am I missing something? Anyway, we can figure this out later. As long as we move from one consistent state to another, we should be good. Jonas > > > > > 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 +0000 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 #<procedure make-tmpfile (basename)> > > > > > 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 >
signature.asc
Description: This is a digitally signed message part
