Re: ready for 2.21.80?

[Jonas Hahnfeld]

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