Re: ready for 2.21.80?

[Jonas Hahnfeld]

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.

> 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.
96027f94f5 Release: update news.
02a3c9de7a Release: update news with later date.

Anything else?
We should probably also bump PATCH_LEVEL=81 in stable/2.22, right?

> 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