Re: ready for 2.21.80?

[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.
> > 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 +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

--
Phil Holmes