Re: Next releases
On Thu, 2023-01-12 at 02:17 +0100, Jean Abou Samra wrote: > > Additionally I would have liked to target the last weekend of January / > > early February for a bugfix release 2.24.1. Unfortunately, I haven't > > heard back from the Debian people yet. As you may remember, the timing > > for the stable release was chosen to make it possible to include > > LilyPond 2.24.0 in the upcoming Debian Bookworm and a user also opened > > a request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026200 > > However, in answering I discovered that Debian removed guile-2.2 for > > the Bookworm release during November, after we had already branched. > > Right now, they only have guile-3.0 which LilyPond doesn't officially > > support. > > Oh n... > > Did anyone try to tell them that this was a bad idea? I mean, it's > true that Guile 3.0 is already three years old, but so far compiling > it for Windows requires trying branches that are kept more or less > alive by some volunteers but not integrated into the main tree, so > most people who want to write cross-platform software in Guile will > need to use Guile 2.2. Please have a look at the link I posted above. I already replied there some time ago. signature.asc Description: This is a digitally signed message part
Re: Next releases
Le 11/01/2023 à 22:39, Jonas Hahnfeld via Discussions on LilyPond development a écrit : Hi all, I would like to plan releasing LilyPond 2.25.1 not next weekend, but the one after that (i.e. January 21/22), unless somebody wants to have an unstable release this weekend? Fine with me. Additionally I would have liked to target the last weekend of January / early February for a bugfix release 2.24.1. Unfortunately, I haven't heard back from the Debian people yet. As you may remember, the timing for the stable release was chosen to make it possible to include LilyPond 2.24.0 in the upcoming Debian Bookworm and a user also opened a request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026200 However, in answering I discovered that Debian removed guile-2.2 for the Bookworm release during November, after we had already branched. Right now, they only have guile-3.0 which LilyPond doesn't officially support. Oh n... Did anyone try to tell them that this was a bad idea? I mean, it's true that Guile 3.0 is already three years old, but so far compiling it for Windows requires trying branches that are kept more or less alive by some volunteers but not integrated into the main tree, so most people who want to write cross-platform software in Guile will need to use Guile 2.2. I'd find it unfortunate if the next Debian didn't include the latest LilyPond, but I neither like bundling guile-2.2 with the lilypond package (as they do with Guile 1.8 right now) or having a large user base run with Guile 3.0 while we're not officially supporting it. On the other hand, I'm also hesitant on calling it "supported" if we're not testing this configuration in our CI... Opinions? We can consider it, but in my opinion, Debian should really add back 2.2. Still, if possible, please try to submit fixes for 2.24.1 soon to get them tested with the next unstable release(s) OK. OpenPGP_signature Description: OpenPGP digital signature
PATCHES - Countdown to January 13
Here is the current countdown report. The next countdown will begin on January 13th. A list of all merge requests can be found here: https://gitlab.com/lilypond/lilypond/-/merge_requests?sort=label_priority Push: !1807 Remove now needless imports of (ice-9 regex) - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1807 !1806 binaries: Minor fixes - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1806 !1805 release: Enable Unicode for PCRE - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1805 Countdown: !1809 Let Paper_book use \layout rather than \paper for global markups - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1809 !1808 Outside-staff-priority for fermatas - Martín Rincón Botero https://gitlab.com/lilypond/lilypond/-/merge_requests/1808 Review: !1810 Let \rhythm markup derive from current layout - David Kastrup https://gitlab.com/lilypond/lilypond/-/merge_requests/1810 !1787 Add PNG image support - Jean Abou Samra https://gitlab.com/lilypond/lilypond/-/merge_requests/1787 !1783 less duplicated code for Arabic and improved docs - Amir Czwink https://gitlab.com/lilypond/lilypond/-/merge_requests/1783 New: No patches in New at this time. Waiting: No patches in Waiting at this time. Cheers, Colin
Re: RFC: require librsvg to implement SVG image support
Le 11/01/2023 à 23:13, Han-Wen Nienhuys a écrit : I was initially thinking there might be a way to avoid a full-blown parser/interpreter for PDF. But that would not work in all formats, so it's probably not acceptable. So you're right. For others following the conversation, the poll is at https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00189.html See my previous posts, I posted this link and also the one to the equivalent thread on lilypond-user-fr (which also leans towards SVG). It's currently 3-0 skewed towards SVG. Regarding rsvg and rust: maybe we could try with an older version of librsvg first? Rust was only introduced in 2.41, so if we go with 2.40, we can postpone the worry about compiling Rust. I'm not super fond of this: as I said, Rust induces little difficulty to (cross-)compile. Look at the PoC branch if you're interested, it's straightforward. It's more a question of how the person running the scripts sets up their environment, which we will need to care about sooner or later if we start requiring librsvg. OpenPGP_signature Description: OpenPGP digital signature
Re: RFC: require librsvg to implement SVG image support
On Tue, Jan 10, 2023 at 11:32 PM Jean Abou Samra wrote: > > Le 10/01/2023 à 23:25, Han-Wen Nienhuys a écrit : > > On Mon, Jan 9, 2023 at 7:45 PM Jonas Hahnfeld wrote: > >> On Sun, 2023-01-08 at 23:18 +0100, Jean Abou Samra wrote: > >>> In order to keep support for vector graphics, even if not > >>> with EPS, we can add support for embedding SVG images. > >> Are we sure that this is actually what the users need? If everybody > >> just cares about including PDF (for logos), I'm not sure if we need to > >> implement support for SVG. > > PDF has much more features than SVG, so it's not obvious that that > > will be easier, and if we want to ingest the PDF graphic for output to > > SVG/PNG/PS, we'll have to interpret the PDF data, basically doing what > > Poppler does. > > > I don't understand how this is different from SVG. I was initially thinking there might be a way to avoid a full-blown parser/interpreter for PDF. But that would not work in all formats, so it's probably not acceptable. So you're right. For others following the conversation, the poll is at https://lists.gnu.org/archive/html/lilypond-user/2023-01/msg00189.html It's currently 3-0 skewed towards SVG. Regarding rsvg and rust: maybe we could try with an older version of librsvg first? Rust was only introduced in 2.41, so if we go with 2.40, we can postpone the worry about compiling Rust. -- Han-Wen Nienhuys - hanw...@gmail.com - http://www.xs4all.nl/~hanwen
Next releases
Hi all, I would like to plan releasing LilyPond 2.25.1 not next weekend, but the one after that (i.e. January 21/22), unless somebody wants to have an unstable release this weekend? Additionally I would have liked to target the last weekend of January / early February for a bugfix release 2.24.1. Unfortunately, I haven't heard back from the Debian people yet. As you may remember, the timing for the stable release was chosen to make it possible to include LilyPond 2.24.0 in the upcoming Debian Bookworm and a user also opened a request: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026200 However, in answering I discovered that Debian removed guile-2.2 for the Bookworm release during November, after we had already branched. Right now, they only have guile-3.0 which LilyPond doesn't officially support. I'd find it unfortunate if the next Debian didn't include the latest LilyPond, but I neither like bundling guile-2.2 with the lilypond package (as they do with Guile 1.8 right now) or having a large user base run with Guile 3.0 while we're not officially supporting it. On the other hand, I'm also hesitant on calling it "supported" if we're not testing this configuration in our CI... Opinions? Still, if possible, please try to submit fixes for 2.24.1 soon to get them tested with the next unstable release(s) Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: RFC: require librsvg to implement SVG image support
Le 08/01/2023 à 23:18, Jean Abou Samra a écrit : * If so, how do we manage the transition? Do we make them optional at first, and if so, for how long? Only Werner commented on this aspect so far. Are there other opinions? OpenPGP_signature Description: OpenPGP digital signature
Re: Wrong `\figured-bass` markup rendering in documentation
Le 09/01/2023 à 19:02, Werner LEMBERG a écrit : Have a look at https://lilypond.org/doc/v2.24/Documentation/notation/font and check the example for `\figured-bass`, which is wrong. If I compile this with a current lilypond binary, I get correct output (see attached image). I also get this if I build the documentation by myself on my computer (in all eight compiling modes that I discussed recently). Any idea what's going on? The same bad rendering happens in the 2.25 documentation on lilypond.org... Let's continue the discussion in an issue. https://gitlab.com/lilypond/lilypond/-/issues/6517 OpenPGP_signature Description: OpenPGP digital signature
Re: The hel-arabic.ly file story...
> The other modifications are useless, they simply make hel-arabic > dependent on arabic.ly. But hel-arabic.ly is supposed to be an > independent file from other ly files. This doesn't make sense. `hel-arabic.ly` is part of the LilyPond core files. If someone uses a recent version of LilyPond, both `hel-arabic.ly` and `arabic.ly` are *always* present. *Of course* it should share the code with `arabic.ly`! Our goal is to improve maintainability, and avoiding duplicated code is definitely such an improvement. Werner
Re: The hel-arabic.ly file story...
Hello Al the proposed changes are not justified. Until now hel-arabic is a standalone file. except élimination of 7/2 and 5/2 The other modifications are useless The other modifications are useless, they simply make hel-arabic dependent on arabic.ly. But hel-arabic.ly is supposed to be an independent file from other ly files. All makams are functional Of course it depends on other .scm files I disagree and what can I do? best regard Hassan EL FATIHI
Re: RFC: require librsvg to implement SVG image support
Le 10/01/2023 à 23:32, Jean Abou Samra a écrit : A thought in passing: whether we take Librsvg or Poppler, we will need libjpeg. This should also enable us to support JPEG in addition to PNG with not too much effort. On further thinking, I think I'm going to submit this separately as a first step. OpenPGP_signature Description: OpenPGP digital signature
Re: The hel-arabic.ly file story...
Hassan: Even if self sufficient was a good goal (sometimes it is, some times it isn't) it should be achieved by inclusion of other content, in this case probably arabic.ly, so that fixes only need to happen in one place. The objection here is to the duplication of the code, not to the functionality this code provides L On Wed, 11 Jan 2023, 08:58 , wrote: > Hello > 5/2 and 7/2 are not being used, You can delete them. > Removing nakriz, farahfaza, nawaatar, kurd, is not a good idea > The file hel-arabic.ly is complete and self-sufficient > best regard > Hassan EL FATIHI > >
