PATCHES - Countdown to September 16
Here is the current countdown report. The next countdown will begin on September 16th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1620 New flute slap snippet - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1620 !1617 remove barAlways - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1617 !1613 RFC: Switch to clang-format for C++ formatting - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1613 Countdown: !1621 doc: Remove flageolet size tweak from snippet - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1621 !1619 Prepare Changes document for release - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1619 !1615 Document \caesura - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1615 !1614 Adjust GregorianTranscription contexts and update docs - Dan Eble https://gitlab.com/lilypond/lilypond/-/merge_requests/1614 Review: !1625 Remove translation-status - Jonas Hahnfeld https://gitlab.com/lilypond/lilypond/-/merge_requests/1625 !1624 Fix ly:position-on-line? - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1624 !1623 Store accidental glyph name in 'glyph-name property - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1623 !1622 Slur should only care for first dotted note - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1622 !1616 Add text marks - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1616 !1611 slur-configuration.cc: fine-tune penalty for dots - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1611 !1510 Better source locations for Scheme errors - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1510 New: No patches in New at this time. Waiting: !1610 RFC: Require Cairo for building - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1610 !1578 New margins by default - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1578 Cheers, Colin
Re: Fixing regressions and serious issues
Le 14/09/2022 à 22:16, Jonas Hahnfeld a écrit : On Wed, 2022-07-20 at 11:39 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: What do we do about this one? Over the past couple of weeks, I tried quite a number of ideas, with no success so far. Thanks a lot for working on this even if it didn't succeed so far. Just in case for others: Jonas shared some details about what he tried in https://github.com/ivmai/bdwgc/issues/454#issuecomment-1244375504 Questions: a) Do we stick to the plan of branching next week, after the planned release of 2.23.13 this weekend? b) If we decide to branch and eventually arrive in December without a fix, do we block the release? At the current moment, branching without a "guaranteed" release date bears a certain risk that we will end up with something half-finished while blocking progress before resuming a new cycle of development releases. What do people think? b) I would say yes. It would be sad, but for better or worse, our significant part of our user base is on Windows, as far as I know. a) I don't know. One thing I can say is that finalizing !1510 (-dcompile-scheme-code) is going to take me a day or two (not helped by being sick of working on that problem), and it wouldn't be unreasonable to have it in the unstable release before branching, as it changes the execution of Scheme code in some significant respects (compiling is optional, but the new error handling isn't). So I'd consider it reasonable to delay the release to next week-end for now, and see what happens for the Windows crashes. I might manage to spend some time on that next week, but I'm not sure, and it's not like I'm particularly good at that kind of low-level work. One thing we could try is biting the bullet and attempting to cross-compile Guile 3 for MinGW. We might have a slight chance that the problem goes away, or becomes different in a way that makes it easier to understand. And this is something we want to do on the long term anyway. Jean
Re: Fixing regressions and serious issues
On Wed, 2022-07-20 at 11:39 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > On Thu, 2022-07-14 at 17:38 +0200, Jean Abou Samra wrote: > > > * “Heisen-crashes on Windows with large scores” > > > > https://gitlab.com/lilypond/lilypond/-/issues/6361 > > > > A nasty and poorly understood GC problem on Windows, > > needs some tough debugging. > > This is currently the only issue marked ~Critical, and I agree this > must be addressed before a stable release. I hope I can come back to > this in the next weeks. What do we do about this one? Over the past couple of weeks, I tried quite a number of ideas, with no success so far. Questions: a) Do we stick to the plan of branching next week, after the planned release of 2.23.13 this weekend? b) If we decide to branch and eventually arrive in December without a fix, do we block the release? At the current moment, branching without a "guaranteed" release date bears a certain risk that we will end up with something half-finished while blocking progress before resuming a new cycle of development releases. What do people think? Jonas signature.asc Description: This is a digitally signed message part
Re: NR: no working links in included PDFs
Sorry, I'm too late.
As with the Java part of `pax`,
it may be possible to extract annotations from PDFs with a C/C++ program.
But, it looks like `latex-pax` is adding the extracted annotations
to the PDF using `pax.sty`.
The `pax.sty` is for LaTeX, and it looks like it is for pdfLaTeX only.
It would be quite difficult to get it to work with Texinfo on XeTeX/pdfTeX.
Alternatively, you could ask the xdvipdfmx developer
to add an option to keep the links and the annotations.
> Look at the documention of `\with-url` in the PDF version of the NR:
> The link in the included snippet (to 'lilypond.org') doesn't work.
> This is a limitation of pdfTeX (or XeTeX), which drops all links and
> annotations for included PDF files.
>
> Masamichi-san, is it possible to extend `extractpdfmark` to cover
> this, too? Looking around it seems that the tool 'pax'
> ('PDFAnnotExtractor') in TeXLive can do that. However, it is based on
> Java...
>
> https://github.com/bastien-roucaries/latex-pax
>
> The reason why I ask is the planned inclusion of the Visual Grob Index
> in the NR – all grobs shown have links to the corresponding
> documentation. If these links are lost the value of the index is
> reduced enormously, and it would be probably better to not include it
> at all but to have a stand-alone, simple, two-page document instead.
Re: Stale branches in Savannah repository
On Thu, 2022-09-01 at 20:54 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > Hi all, > > it's been 2 years now that development has moved to GitLab. In the very > beginning, we agreed to keep existing branches on Savannah, but I'd > like to revisit that decision and propose that we make it a mirror of > only the master and stable/* branches, just as GitHub is. The migrated > branches continue to be available on GitLab. I went ahead here as well: $ git push --delete savannah $(git branch -rl 'savannah/dev/*' | sed 's|savannah/||') To ssh://git.savannah.gnu.org/srv/git/lilypond.git - [deleted] dev/benko/metafont-cleanup - [deleted] dev/dak/translator-ctors - [deleted] dev/frax/colorful-make - [deleted] dev/janek/accidentals-short - [deleted] dev/janek/cg-cleanup - [deleted] dev/janek/experimental-fix-for-issue-2462 - [deleted] dev/janek/feta-modification - [deleted] dev/janneke/wip-guile2 - [deleted] dev/knupero/lilypy3devel - [deleted] dev/rlittle - [deleted] dev/rune - [deleted] dev/tie-crusade/comments - [deleted] dev/urs/beaming-pattern - [deleted] dev/urs/font-exists - [deleted] dev/urs/font-handling - [deleted] dev/urs/font-selection As a reminder, (some of) these branches continue to be available on GitLab (unless deleted otherwise). Cheers Jonas signature.asc Description: This is a digitally signed message part
