LilyPond 2.25.20
We are happy to announce the release of LilyPond 2.25.20. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.4, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
LilyPond 2.25.19
We are happy to announce the release of LilyPond 2.25.19. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.4, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: Joining the development team
On Sat, 2024-08-03 at 20:52 +0200, Johannes Feulner wrote: > Hi there, > > I would like to join the development team. Please set permissions on > gitlab for me (jofeu, @jofeux) so that I could upload dev branches. Done, welcome! Please note though that uploading dev branches to https://gitlab.com/lilypond/lilypond/ is not strictly necessary, you can just push branches to your fork and open merge requests from there. (In fact, that's how I work all the time because I find it "cleaner".) > I have ready a fix for issue #6202 including a regtest. And I plan on > providing more fixes, we have developed for our scorio platform. Great. If you are familiar with git, please proceed to open a first merge request and get yourself familiar with the development process 😉 > If anyone could volunteer as a mentor for me, I'd definitely appreciate it. I personally can't commit to mentoring contributors right now, but so far it has always worked to ask (developer) questions on lilypond- devel. Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.24.4 released!
We are proud to announce the release of GNU LilyPond 2.24.4. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version contains a number of fixes since the release of the previous stable version in November 2023. We recommend all users to update. Scores converted to or written for 2.24.0 will continue to work with this release. A list of added features and other user-visible changes for 2.24 can be found at https://lilypond.org/doc/v2.24/Documentation/changes/. Among others, version 2.24.0 switched to Guile 2.2 and features a completely rewritten infrastructure for creating the official packages, finally allowing us to offer 64-bit binaries for macOS and Windows. These pre- built binaries are linked from https://lilypond.org/download.html and available from GitLab: https://gitlab.com/lilypond/lilypond/-/releases/v2.24.4 For distributions, Guile 3.0 is officially supported since the previous LilyPond 2.24.3, even though the recommended version will remain Guile 2.2 for the LilyPond 2.24 series. signature.asc Description: This is a digitally signed message part
Re: Thoughts on next stable release(s)
On Mon, 2024-07-08 at 22:30 +0200, Jonas Hahnfeld wrote: > On Sun, 2024-06-16 at 22:24 +0200, Jonas Hahnfeld wrote: > > Hi all, > > > > it's been 7 months since the last stable (bugfix) release, LilyPond > > 2.24.3. Today I went through the list of all (smaller) merge requests > > and marked those that we might want to apply to the stable/2.24 branch > > with the Backport label: > > https://gitlab.com/lilypond/lilypond/-/merge_requests?state=merged&label_name[]=Backport > > > > It's not many and they are each small, but in my opinion we could think > > about having LilyPond 2.24.4 in early / mid July. What do you think? If > > there are other changes that you would like to see backported and I > > missed so far, or you are unsure about, please ping me on GitLab or > > reply to this message. > > I backported the fixes collected so far, except for > https://gitlab.com/lilypond/lilypond/-/merge_requests/2231 which > doesn't apply and I believe is not needed for stable/2.24. > > The tentative plan would be to release 2.25.18 next weekend and then > 2.24.4 the week after, maybe again with binaries produced on Wednesday > or Thursday (to be seen). So "Wednesday or Thursday" didn't happen (too busy), but the binaries (as well as the source code) are now available from GitLab: https://gitlab.com/lilypond/lilypond/-/packages/27483288 I tested the binaries on my end, as best as I could, and they seem to work well. Give them a try if you want on your end (bonus points for testing on macOS, I can only check on the same machine that also built the binaries, which might hide some problems). Unless I hear something really terrible before tomorrow, I will officially announce the release then. Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.18
We are happy to announce the release of LilyPond 2.25.18. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: PGP key rollover
On Sun, 2024-07-14 at 10:54 +0200, Jonas Hahnfeld wrote: > Hi all, > > heads-up for people verifying my emails: I generated a new PGP key, > attached to this message and uploaded to keyservers, that I will use > to sign my future emails. The old key has not been compromised, I > only took the opportunity to use newer cryptography options. ... and this message is signed by the new key 😉 > Cheers > Jonas signature.asc Description: This is a digitally signed message part
PGP key rollover
Hi all, heads-up for people verifying my emails: I generated a new PGP key, attached to this message and uploaded to keyservers, that I will use to sign my future emails. The old key has not been compromised, I only took the opportunity to use newer cryptography options. Cheers Jonas 621780CB46FA27D6FC396E209C54E998FFA3840F.signed.asc Description: application/pgp-keys signature.asc Description: This is a digitally signed message part
Re: Thoughts on next stable release(s)
On Tue, 2024-07-09 at 14:22 +0200, Thomas Morley wrote: > Please have a look at https://gitlab.com/lilypond/lilypond/-/issues/6726 > A showstopper for next stable? Thanks for the heads-up. As far as I can tell, and from local testing, this only affects the current master / unstable releases. So yes, it's a blocker for an eventual 2.26, but I think there is nothing to do for 2.24 and therefore should not impact the schedule for 2.24.4. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: Thoughts on next stable release(s)
On Mon, 2024-06-17 at 19:37 +, Werner LEMBERG wrote: > > > I also suggest !2359. > > > > So far I didn't backport any documentation improvements to > > stable/2.24. Is there anything special about this one? > > I think these index entries complete the list of essential syntax > elements in the NR. I had a quick look through the git history since branching stable/2.24 and it seems there were many other index entries added since then, for example https://gitlab.com/lilypond/lilypond/-/commit/63da9aaeb6ed0c4e79169cdf41350a3a9244ba6e https://gitlab.com/lilypond/lilypond/-/commit/7b4951a5f9ab08b6c7dddb70bfebf86bcc4fd359 https://gitlab.com/lilypond/lilypond/-/commit/fc7c539b14176df781728f77aceee3576f5ac5e4 https://gitlab.com/lilypond/lilypond/-/commit/3a929840508a77539b3e56cce7e5f3fd052583c3 I think I tend towards skipping all of them for stable/2.24 at the current state. Jonas signature.asc Description: This is a digitally signed message part
Re: Thoughts on next stable release(s)
On Sun, 2024-06-16 at 22:24 +0200, Jonas Hahnfeld wrote: > Hi all, > > it's been 7 months since the last stable (bugfix) release, LilyPond > 2.24.3. Today I went through the list of all (smaller) merge requests > and marked those that we might want to apply to the stable/2.24 branch > with the Backport label: > https://gitlab.com/lilypond/lilypond/-/merge_requests?state=merged&label_name[]=Backport > > It's not many and they are each small, but in my opinion we could think > about having LilyPond 2.24.4 in early / mid July. What do you think? If > there are other changes that you would like to see backported and I > missed so far, or you are unsure about, please ping me on GitLab or > reply to this message. I backported the fixes collected so far, except for https://gitlab.com/lilypond/lilypond/-/merge_requests/2231 which doesn't apply and I believe is not needed for stable/2.24. The tentative plan would be to release 2.25.18 next weekend and then 2.24.4 the week after, maybe again with binaries produced on Wednesday or Thursday (to be seen). Cheers, Jonas signature.asc Description: This is a digitally signed message part
Re: Thoughts on next stable release(s)
On Mon, 2024-06-17 at 03:16 +, Werner LEMBERG wrote: > > [...] we could think about having LilyPond 2.24.4 in early / mid > > July. What do you think? > > +1 > > I also suggest !2359. So far I didn't backport any documentation improvements to stable/2.24. Is there anything special about this one? Jonas signature.asc Description: This is a digitally signed message part
Thoughts on next stable release(s)
Hi all, it's been 7 months since the last stable (bugfix) release, LilyPond 2.24.3. Today I went through the list of all (smaller) merge requests and marked those that we might want to apply to the stable/2.24 branch with the Backport label: https://gitlab.com/lilypond/lilypond/-/merge_requests?state=merged&label_name[]=Backport It's not many and they are each small, but in my opinion we could think about having LilyPond 2.24.4 in early / mid July. What do you think? If there are other changes that you would like to see backported and I missed so far, or you are unsure about, please ping me on GitLab or reply to this message. Looking at the bigger picture, we released LilyPond 2.22.0 in early 2021 (it slipped from late 2020) and version 2.24.0 in late 2022. That said, I'm not sure there is already "enough" to plan for 2.26.0 and maybe we should not try to squeeze it into this year. As a result, if Debian stays at the two-year release cadence, Debian 13 "Trixie" next year would continue to provide LilyPond 2.24. I personally think that's acceptable, but please voice your opinion. Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.17
We are happy to announce the release of LilyPond 2.25.17. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
LilyPond 2.25.16
We are happy to announce the release of LilyPond 2.25.16. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: [RFC] Move GitLab testing to Ubuntu 22.04
On Wed, 2024-05-01 at 22:20 +0200, Michael Käppler wrote: > > > There is one caveat here that I would like to mention: During initial > > testing in my fork, one test job unexpectedly hang during a lilypond > > execution, using 100% CPU and eventually being killed after 60 minutes. > > Subsequent runs were fine, so this needs to be monitored and > > investigated if it happens again... > > Do you have a clue what was happening there? No, nothing conclusive. > > As noted in the MR summary, switching to Ubuntu 22.04 will give us > > testing with the more recent Guile 3.0.7, and I would like to bump the > > requirement to that version, after the switch had some time to settle. > > Likewise I think we should bump the requirement to Texinfo 6.8 (which > > will allow us to drop quite some compatibility code in lilypond.init) > > and Python 3.10 (because Python scripts are notoriously easy to break > > if only tested with more recent interpreter versions). > > > > > > I'm not sure if I get what you say about the Python scripts. > "Python scripts are notoriously easy to break > if only tested with more recent interpreter versions" - you mean > backwards-incompatible changes > would not be noticed? Yes, in my experience it's very hard to claim a script works with a given Python version without actually testing it. Given that most developers will be on newer distributions, our CI is effectively our minimum Python requirement. > Just out of interest, what is the reason that we use different environments > for CI and > for doing releases? As an example, we are using Guile 3.0.9 now for the > releases and Ubuntu 22.04 will have > only 3.0.7. For releases, we have to build all dependencies ourselves, including Guile, on all supported platforms (Linux, macOS, cross-compilation for Windows). Jonas P.S.: your emails are really hard to reply to in text-only mode, sorry for the partially mangled quotation; I'm not sure if that's your messages containing a weird formatting or my mail client acting up... signature.asc Description: This is a digitally signed message part
[RFC] Move GitLab testing to Ubuntu 22.04
Hi all, I mentioned this during the transition to Guile 3.0, and now I had the time to prepare the required changes to move the base of our GitLab testing to Ubuntu 22.04. The merge request to do so is here: https://gitlab.com/lilypond/lilypond/-/merge_requests/2318 There is one caveat here that I would like to mention: During initial testing in my fork, one test job unexpectedly hang during a lilypond execution, using 100% CPU and eventually being killed after 60 minutes. Subsequent runs were fine, so this needs to be monitored and investigated if it happens again... As noted in the MR summary, switching to Ubuntu 22.04 will give us testing with the more recent Guile 3.0.7, and I would like to bump the requirement to that version, after the switch had some time to settle. Likewise I think we should bump the requirement to Texinfo 6.8 (which will allow us to drop quite some compatibility code in lilypond.init) and Python 3.10 (because Python scripts are notoriously easy to break if only tested with more recent interpreter versions). The only downside of this is that LilyPond master will not compile anymore on older distributions, including Ubuntu 20.04. I personally think this is fine, for example Ubuntu 24.04 was just released, but let me know if you disagree. Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.15
We are happy to announce the release of LilyPond 2.25.15. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Tue, 2024-04-02 at 16:40 +0200, Michael Käppler wrote: > Am 01.04.2024 um 22:03 schrieb Jonas Hahnfeld via Discussions on LilyPond > development: > > As pointed out by Han-Wen in November, this is actually fairly little > > code that gets dropped; we need to keep some related to optimizations > > for compatibility with 3.0.0 up to 3.0.2; see also below. > > Just to share some numbers: It is still the case with current Guile master, > that bytecode compilation is nearly 10x slower with the default optimization > level than > with optimizations switched off. > > make bytecode with default optimization level: > real 2m0,875s > user 1m59,989s > sys 0m0,796s > > make bytecode without optimizations: > real 0m16,535s > user 0m14,209s > sys 0m0,810s > > What concerns LilyPond processing speed, I did a comparison with the > medium-sized score > I also used for the JIT vs. non-JIT timings on Windows and got for 10 > subsequent runs: > > Without optimizations: > real 9m1,511s > user 8m52,375s > sys 0m11,423s > > With default optimization level: > real 8m34,762s > user 8m23,027s > sys 0m14,562s > > That would be -5% in compilation time. Does not pay off, I think. Thanks for testing! I assume this is also enabling Guile optimizations during LilyPond runtime? It would be interesting to see if there's a gain from just compiling the bytecode with optimizations. That would be a one-time cost that may be worth paying, especially if we had proper standalone bytecode compilation that parallelizes... Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > Step 4: Remove compatibility code for Guile 2.2 > This can happen after we made one or two releases with only Guile 3.0. This is now up for review in the following merge request: https://gitlab.com/lilypond/lilypond/-/merge_requests/2293 As pointed out by Han-Wen in November, this is actually fairly little code that gets dropped; we need to keep some related to optimizations for compatibility with 3.0.0 up to 3.0.2; see also below. > Step 5? Move to Ubuntu 22.04 for testing and bump requirement to Guile > 3.0.7? Then we could remove some more compatibility code, but let's > discuss this at some later point. I still want to go there, pending concrete assessment and implementation. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 23:03 +0100, Michael Käppler wrote: > Hi Jonas, > thanks for working on this! > > > Windows build with Guile JIT: https://cloud.hahnjo.de/s/Ek5x9rybpiPNtoj > > This turns on just-in-time compilation that was added in Guile 3.0, but > > we had to keep disabled on Windows until now. Please test, especially > > on larger scores where this should provide a performance advantage. > > I gave it a try with a medium-sized score (appr. 60 pages A4), > 10 times in a row: > > with JIT: > real 4m42.513s > user 0m0.090s > sys 0m0.185s > > without JIT: > real 4m45.295s > user 0m0.046s > sys 0m0.277s Thanks for testing on a larger score! > Just out of interest, do we tweak the JIT_THRESHOLD somewhere or do we > use the default value? I don't think we change it from LilyPond, so likely using the default value. Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 14:08 -0700, Kenneth Wolcott wrote: > Hi Jonas; > > I hope that the following information is useful: > > Lilypond performance stats for the engraving of one very small and one > medium sized pieces > > native = Apple Silicon build > foreign = x86_64 > other = MacPorts LP 2.24.3 > > ~/Downloads/native_lilypond-2.25.14/bin/lilypond > ./Danny_Boy_updated.ly 0.53s user 0.06s system 87% cpu 0.683 total > ~/Downloads/foreign_lilypond-2.25.14/bin/lilypond > ./Danny_Boy_updated.ly 0.93s user 0.09s system 101% cpu 1.010 total > /opt/local/bin/lilypond ./Danny_Boy.ly 0.48s user 0.06s system 104% > cpu 0.515 total > > ~/Downloads/native_lilypond-2.25.14/bin/lilypond > ./Waltz_Nr2_updated.ly 1.07s user 0.10s system 102% cpu 1.145 total > ~/Downloads/foreign_lilypond-2.25.14/bin/lilypond > ./Waltz_Nr2_updated.ly 1.76s user 0.15s system 100% cpu 1.907 total > /opt/local/bin/lilypond ./Waltz_Nr2.ly 1.06s user 0.12s system 103% > cpu 1.140 total > > for i in ./Danny_Boy.ly ./Danny_Boy_updated.ly ./Waltz_Nr2.ly > ./Waltz_Nr2_updated.ly > for> do > for> wc $i > for> done > 232 8144641 ./Danny_Boy.ly > 232 8144642 ./Danny_Boy_updated.ly > 9393892 19981 ./Waltz_Nr2.ly > 9393892 19982 ./Waltz_Nr2_updated.ly Great, winning more than a factor 1.5x compared to the x86_64 binaries sounds reasonable 🙂 signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 14:24 -0500, Karlin High wrote: > On 3/23/2024 2:00 PM, Jonas Hahnfeld wrote: > > Would be interesting to see how this compares to the "vanilla" package > > I tried it, 3 runs. First one maybe unfair because font cache > initialization or something. > > real0m48.643s > user0m0.000s > sys 0m0.031s > > real0m31.457s > user0m0.015s > sys 0m0.000s > > real0m31.591s > user0m0.000s > sys 0m0.031s > > The another with the JIT version: > > real0m32.319s > user0m0.000s > sys 0m0.030s > > But I expect I should get the computer otherwise idle as far as possible > for this. I had other software running, but nothing with heavy loads. Thanks for testing! Not as good as I had hoped, but also not (much) worse than before... signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sun, 2024-03-24 at 03:20 -0700, Aaron Hill wrote: > The error occurred from my WSL1 environment running Ubuntu 18.04. > Probably my own fault for keeping bionic around. Ah ok; yes, Ubuntu 18.04 is end-of-life since last year already, so I didn't check its versions. > I do have Ubuntu 20.04 under WSL2. I can confirm 2.25.14 runs under > focal without complaining about glibc. Good. > Based on the email thread you linked, perhaps I should nuke all my WSL > distros at this point and start from scratch with the latest Ubuntu (22, > I gather). Not sure if Alma is an option for WSL. You don't need Alma, the binaries should run on any distribution that is newer than that. Ubuntu is perfectly fine, and likely better tested with WSL (but I don't have experience with it myself). Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 18:18 -0700, Aaron Hill wrote: > On 2024-03-23 6:25 am, Jonas Hahnfeld wrote: > > We are happy to announce the release of LilyPond 2.25.14. This is > > termed a development release, but these are usually reliable for > > testing new features and recent bug fixes. However, if you require > > stability, we recommend using version 2.24.3, the current stable > > release. > > Please refer to the Installing section in the Learning Manual for > > instructions how to set up the provided binaries: > > https://lilypond.org/doc/v2.25/Documentation/learning/installing > > > /opt/lilypond/2.25.14/bin/lilypond: /lib/x86_64-linux-gnu/libc.so.6: > version `GLIBC_2.28' not found (required by > /opt/lilypond/2.25.14/bin/lilypond) > > > Something changed from .13 to .14? I'm presuming my system is just > out-of-date, and this might be expected. Yes, 2.25.14 is built in Alma Linux 8 instead of CentOS 7 which raises the glibc requirement. I didn't mention it in the release email because I thought it wouldn't make a practical difference as outlined in https://lists.gnu.org/archive/html/lilypond-devel/2024-02/msg00052.html Which distribution are you running? Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 11:39 -0700, Kenneth Wolcott wrote: > Hi Jonas; > > I've tried engraving a couple of randomly chosen previous engravings > (using LP 2.24.x) using the new LP 2.25.14 version on my Mac (Apple > Silicon). > > Since none of my engravings are large, most of them are one to two > pages in length, I thought there would be no noticable decrease in > engraving time, but I was wrong! It IS noticably faster for even > small files :-) > > One thing I noticed is what one of my engravings had significant > change in apperance in the second and third page, as if I had inserted > a forced page break in two or three places. There were no conversion > errors or warnings in any of my engravings. > > I don't know what was the cause of the speedup, but it is > appreciated! I have been using the MacPorts version of Lilypond 2.24.3 > compared to this recent test release. Thanks for testing! The performance advantage probably comes from Guile 3.0 in our binaries of 2.25.14 versus Guile 2.2 with the MacPorts version, having a faster startup time which matters especially for smaller files. If you have some time, I would be really interested in seeing a comparison with LilyPond 2.25.14 from https://gitlab.com/lilypond/lilypond/-/packages/23923980 when the x86_64 executable is run through Rosetta on Apple Silicon... Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 17:46 +0100, Jean Abou Samra wrote: > Le samedi 23 mars 2024 à 16:02 +0100, Jonas Hahnfeld via Discussions on > LilyPond development a écrit : > > Native Apple Silicon build: https://cloud.hahnjo.de/s/x9D62eASSn6Ng7D > > This is a native arm64 version for macOS 12+ > > Great! OOI, what machine did you use for that? Ah yes, I forgot to mention I used the one macOS node (Mac mini 2020, Apple M1) from https://portal.cfarm.net/ This could be very nice going forward because anybody can just request an account. signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 11:41 -0500, Karlin High wrote: > On 3/23/2024 10:02 AM, Jonas Hahnfeld via LilyPond user discussion wrote: > > Windows build with Guile JIT: https://cloud.hahnjo.de/s/Ek5x9rybpiPNtoj > > This turns on just-in-time compilation that was added in Guile 3.0, but > > we had to keep disabled on Windows until now. Please test, especially on > > larger scores where this should provide a performance advantage. > > Carver MSDM.ly, subject of many past performance-test posts. > > Inte Core i5-3450 > 24 GB RAM > Windows 10 22H2 > > real 0m32.109s > user 0m0.000s > sys 0m0.015s Would be interesting to see how this compares to the "vanilla" package here: https://gitlab.com/lilypond/lilypond/-/packages/23923980 ... But I guess I can also do this test on my end since the score is public. signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.14
On Sat, 2024-03-23 at 14:25 +0100, Jonas Hahnfeld wrote: > We are happy to announce the release of LilyPond 2.25.14. This is > termed a development release, but these are usually reliable for > testing new features and recent bug fixes. Following this release, I made two special builds with the changes proposed in https://gitlab.com/lilypond/lilypond/-/merge_requests/2283 that would be great to get more widespread testing: Native Apple Silicon build: https://cloud.hahnjo.de/s/x9D62eASSn6Ng7D This is a native arm64 version for macOS 12+; if you have a Mac, please test and (hopefully) confirm the performance advantage over running the x86_64 build via Rosetta 2 🙂 Windows build with Guile JIT: https://cloud.hahnjo.de/s/Ek5x9rybpiPNtoj This turns on just-in-time compilation that was added in Guile 3.0, but we had to keep disabled on Windows until now. Please test, especially on larger scores where this should provide a performance advantage. Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.14
We are happy to announce the release of LilyPond 2.25.14. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
[RFC] Upgrade platforms for official binaries
Hi all, as noted in https://gitlab.com/lilypond/lilypond/-/merge_requests/2246, we are starting to run into some issues because of dated software in CentOS 7 and Ubuntu 20.04. For that reason, I'm proposing in https://gitlab.com/lilypond/lilypond/-/merge_requests/2261 to upgrade our platforms used to build the official binaries. For the Linux binaries, the choice of distribution and its version of glibc effectively determines on which systems our binaries can run. As CentOS 8 is no more, I think we should go to Alma Linux 8 with glibc 2.28 which only loses us CentOS 7 that will go end-of-life in June anyway. An alternative would be Debian 10, which also has glibc 2.28 but will enter its (partial) extended LTS phase already in June (while Alma Linux is planned to be supported until 2029). For the Windows binaries, cross-built using mingw, we are more flexible but given the experience with the bundled mingw compiler in Ubuntu, I think we should just stay on that platform. Please let me know if there are any objections. Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.13
We are happy to announce the release of LilyPond 2.25.13. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Mon, 2023-12-04 at 21:55 +0100, Jonas Hahnfeld wrote: > On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > > > then remove automatic detection of Guile 2.2 from configure. > > I did not yet upload a merge request to make Guile 3.0 the default for > all builds: After more thought, I believe it's better to do this > together with the removal of automatic configure support for Guile 2.2, > to avoid the situation where we assume that Guile 3.0 is the default, > but building from source will gracefully configure with Guile 2.2, for > example because the system is missing the development package for Guile > 3.0... This next step (requiring Guile 3.0 and removing automatic detection of Guile 2.2 from configure) is now available as https://gitlab.com/lilypond/lilypond/-/merge_requests/2228 Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.12
We are happy to announce the release of LilyPond 2.25.12. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: Can't automatically merge
On Thu, 2023-12-14 at 17:43 +, Werner LEMBERG wrote: > > > > Looks like it was fixed? > > > > https://status.gitlab.com/pages/history/5b36dc6502d06804c08349f7 > > > > > > Yep, thanks. > > > > I spoke too early – it's still not working properly. > > On this page I read: > > For self-hosted runners, the previous workaround may need to be > re-applied as we have updated GitLab.com certificate. Please see > possible workarounds in > gitlab.com/gitlab-com/gl-infra/production/-/issues/17265 > > Jonas? (In cases like these, please cc me directly; then the email will land in my inbox and I may react faster...) I disabled Dan's and Karlin's runner. Can you please restart it and then ping me so I can re-enable? If possible, maybe also update the runner version... It's not fully clear to me why my runner isn't affected (I didn't need to restart) ... For now I reduced the check_interval so it picks up jobs immediately. It will be slower though, but I'm not sure going back to the SaaS runners for now would be an improvement. Thanks, Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.11
We are happy to announce the release of LilyPond 2.25.11. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.3, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing Starting with this release, the binaries are built with Guile 3.0. Please report back if there are any problems caused by this. At a later point, we will switch to requiring Guile 3.0 and eventually drop support for Guile 2.2. signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > Step 3: Switch to Guile 3.0 > Afterwards, we can merge > https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 I put the merge request back on Patch::review, along with https://gitlab.com/lilypond/lilypond/-/merge_requests/2170 for the documentation build. Then we could have a release next weekend or the one after. If next weekend, the first release in January might be a bit bigger, we'll have to see... > then remove automatic detection of Guile 2.2 from configure. I did not yet upload a merge request to make Guile 3.0 the default for all builds: After more thought, I believe it's better to do this together with the removal of automatic configure support for Guile 2.2, to avoid the situation where we assume that Guile 3.0 is the default, but building from source will gracefully configure with Guile 2.2, for example because the system is missing the development package for Guile 3.0... Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.24.3 released!
We are proud to announce the release of GNU LilyPond 2.24.3. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version contains a number of fixes since the release of the previous stable version in August 2023. We recommend all users to update. Scores converted to or written for 2.24.0 will continue to work with this release. A list of added features and other user-visible changes for 2.24 can be found at https://lilypond.org/doc/v2.24/Documentation/changes/. Among others, version 2.24.0 switched to Guile 2.2 and features a completely rewritten infrastructure for creating the official packages, finally allowing us to offer 64-bit binaries for macOS and Windows. These pre- built binaries are linked from https://lilypond.org/download.html and available from GitLab: https://gitlab.com/lilypond/lilypond/-/releases/v2.24.3 For distributions, LilyPond 2.24.3 most notably includes a fix to restore PDF conversion with the recent Ghostscript 10.02.1. Also Guile 3.0 is now officially supported, even though the recommended version will remain Guile 2.2 for the LilyPond 2.24 series. signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.3
On Wed, 2023-11-15 at 23:06 +0100, Jonas Hahnfeld wrote: > Hi all, > > I backported the first batch of commits yesterday, some more merge > requests are still tagged with the Backport label that I will take care > of later (including "official" support for Guile 3.0 unless somebody > objects until then). I plan to build the binaries on Saturday, November > 18, and the final release on Sunday, November 19 - in the worst case > this may slip to Monday, but I don't really have much time then so > hopefully not... I built and uploaded the binaries, in case anybody wants to test before the official announcement tomorrow (evening): https://gitlab.com/lilypond/lilypond/-/packages/20395285 Cheers, Jonas signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.10 with Guile 3.0
On Thu, 2023-11-16 at 11:11 -0600, Karlin High wrote: > On Sun, Nov 12, 2023 at 6:26 AM Jonas Hahnfeld via LilyPond user > discussion wrote: > > If you have some time, please test them in your setups and report back in > > case of problems! > > Seems OK so far. Windows 11 21H2, Intel Core i5-1135G7. > > " > > lilypond.exe scheme-sandbox > GNU LilyPond 2.25.10 (running Guile 3.0) > Processing > `C:/Users/owner/AppData/Local/frescobaldi/frescobaldi/lilypond-binaries/lilypond-2.25.10/share/lilypond/2.25.10/ly/scheme-sandbox.ly' > Parsing... > GNU Guile 3.0.9 > " Great, thanks for testing! > When I run convert-ly, it makes version statements "2.25.9". I can't > remember if that is expected or not for the 2.25.10 binaries. No > warnings of outdated versions are given when compiling the results. Yes, that's expected because there were no conversion rules for 2.25.10 and convert-ly doesn't force-update the version number (unless -- current-version is passed). Jonas signature.asc Description: This is a digitally signed message part
Plan for LilyPond 2.24.3
Hi all, I backported the first batch of commits yesterday, some more merge requests are still tagged with the Backport label that I will take care of later (including "official" support for Guile 3.0 unless somebody objects until then). I plan to build the binaries on Saturday, November 18, and the final release on Sunday, November 19 - in the worst case this may slip to Monday, but I don't really have much time then so hopefully not... The draft release announcement text is: --- We are proud to announce the release of GNU LilyPond 2.24.3. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version contains a number of fixes since the release of the previous stable version in August 2023. We recommend all users to update. Scores converted to or written for 2.24.0 will continue to work with this release. A list of added features and other user-visible changes for 2.24 can be found at https://lilypond.org/doc/v2.24/Documentation/changes/. Among others, version 2.24.0 switched to Guile 2.2 and features a completely rewritten infrastructure for creating the official packages, finally allowing us to offer 64-bit binaries for macOS and Windows. These pre- built binaries are linked from https://lilypond.org/download.html and available from GitLab: https://gitlab.com/lilypond/lilypond/-/releases/v2.24.3 For distributions, LilyPond 2.24.3 most notably includes a fix to restore PDF conversion with the recent Ghostscript 10.02.1. Also Guile 3.0 is now officially supported, even though the recommended version will remain Guile 2.2 for the LilyPond 2.24 series. --- Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.10 with Guile 3.0
On Sat, 2023-11-11 at 19:37 +0100, Jonas Hahnfeld wrote: > We are happy to announce the release of LilyPond 2.25.10. And here are the binaries with Guile 3.0, built using https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and https://gitlab.com/lilypond/lilypond/-/merge_requests/2170 : https://gitlab.com/lilypond/lilypond/-/packages/20197593 If you have some time, please test them in your setups and report back in case of problems! Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Sat, 2023-11-11 at 18:37 +0100, Han-Wen Nienhuys wrote: > On Sun, Nov 5, 2023 at 10:36 PM Jonas Hahnfeld wrote: > > Hi all, > > > > I hear LilyPond hasn't changed its Guile version since some time (more > > than 18 months). So before we get too comfortable with the current > > situation, let me propose to move to Guile 3.0. Below is a plan for > > that switch, with a transition period to test the official binaries. > > Last time, when going from Guile 1.8 to version 2.2, the switch had to > > coincide with moving away from GUB. Between Guile 2.2 and 3.0, we could > > in principle support both versions for a longer period. However, I > > personally think that a full transition and dropping support for Guile > > 2.2 is the more reasonable approach: It will reduce testing > > configurations (both for development and user reports) and hopefully > > enable some future cleanups in the code. > > Could you say a bit more about the benefits/disadvantages for the user? > I had the impression that Guile 3 had different (worse?) performance > characteristics relative to 2.2, but it's been a while. As far as I can tell from my limited tests so far, LilyPond built against Guile 2.2 or 3.0 has similar speeds. At least if you have compiled bytecode (that generates faster with Guile 3.0, but that's not really an advantage for users). The build with Guile 3.0 seems to have a slightly lower startup time, which is good for small scores, but we will be able to test in full tomorrow when I build the other binaries. > IIRC, one of the arguments to drop 1.8 is that Guile pre-2.x did not > support installing multiple versions alongside each other, which forced > distributions to choose whether to ship LilyPond or a recent version of > Guile. With 2.2 and later, that dilemma disappeared. Not quite: While it's true that Guile 1.8 was not prepared to be co- installed with later versions, it worked in practice because Guile 2.0 had the necessary modifications. What happened instead is that Linux distributions wanted to get rid of Guile 1.8, and some did before LilyPond was able to fully work with Guile 2.2. The same is currently happening again, for example we had to do quite some convincing to keep Guile 2.2 in Debian 12 Bookworm released this summer. So IMHO we really want to support Guile 3.0; Jean already did the hard work here last year, up to the point that some already build LilyPond 2.24.x with Guile 3.0 right now. > I quickly grepped over the source (grepping for SCM_MAJOR_VERSION), > but the bifurcations look very modest. In principle yes, we could continue to support Guile 2.2 and it wouldn't cause too many issues at first. However, we know from experience that supporting two versions of Guile has a certain cost, and I think we are better off just supporting Guile 3.0 going forward. Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.10
We are happy to announce the release of LilyPond 2.25.10. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.2, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Plan for LilyPond 2.24.3 and Transition to Guile 3.0
On Sun, 2023-11-05 at 22:36 +0100, Jonas Hahnfeld wrote: > Step 1: Officially support Guile 3.0 and add optional CI testing > I opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 to > add some compatibility with earlier versions of Guile 3.0 and then > implement detection support in configure. It also creates Docker images > and adds optional CI testing, as we had it for the transition to Guile > 2.2. The MR is nominally on countdown right now, do we have a consensus on this? I'm fully ok with delaying this, but then it will miss the next unstable release that I would like to do this weekend, and the backport to the stable version tentatively planned for the next weekend (see below). > Step 2a: Assuming this testing goes fine, I would like to backport the > changes from the first step to stable/2.24 and release a new stable > version. The idea is that distributions wanting to drop their package > for Guile 2.2 can switch LilyPond 2.24 to Guile 3.0. Note that the > official binaries will stay Guile 2.2 for future bug fix releases, it's > only about officially supporting the later version. However, we also > have to see how the situation develops with Ghostscript 10.02.1, so > let's postpone discussion on this topic for now... So https://gitlab.com/lilypond/lilypond/-/merge_requests/2160 seems to work now, and I think we should get this out in an unstable release (next weekend) and then a bug fix release the weekend after. For other bug fixes, I marked a number of merge requests with the Backport label: https://gitlab.com/lilypond/lilypond/-/merge_requests?scope=all&state=merged&label_name[]=Backport Please ping me on other fixes that you think should be part of 2.24.3, or any of the above that should not be backported. For the support of Guile 3.0, it depends on whether we merge it for 2.25.10 and if people think it should be backported. Cheers, Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Transition to Guile 3.0
On Sun, 2023-11-05 at 22:48 +0100, Jean Abou Samra wrote: > What I don't really understand is why you want to add compatibility > with Guile 3.0.x for small x. Upstream completely breaks the normal > expectation from what you would find in a point release, by putting > features and even severely backwards incompatible changes (like > cross-module inlining in 3.0.8 *cough*), so I think this is definitely > going to be more work to keep supporting (in particular: testing) than > with dependencies that don't have this peculiarity. I'd rather define > a minimum version in the 3.0.x series that we want to support. Sure, but that is currently defined by Ubuntu 20.04 having Guile 3.0.1. We could of course move "Step 5" earlier in the process, but then I argue we still need to pay attention to what versions of Guile are in the wild, the next one probably being Guile 3.0.5 in Debian Bullseye... signature.asc Description: This is a digitally signed message part
[RFC] Transition to Guile 3.0
Hi all, I hear LilyPond hasn't changed its Guile version since some time (more than 18 months). So before we get too comfortable with the current situation, let me propose to move to Guile 3.0. Below is a plan for that switch, with a transition period to test the official binaries. Last time, when going from Guile 1.8 to version 2.2, the switch had to coincide with moving away from GUB. Between Guile 2.2 and 3.0, we could in principle support both versions for a longer period. However, I personally think that a full transition and dropping support for Guile 2.2 is the more reasonable approach: It will reduce testing configurations (both for development and user reports) and hopefully enable some future cleanups in the code. Step 1: Officially support Guile 3.0 and add optional CI testing I opened https://gitlab.com/lilypond/lilypond/-/merge_requests/2162 to add some compatibility with earlier versions of Guile 3.0 and then implement detection support in configure. It also creates Docker images and adds optional CI testing, as we had it for the transition to Guile 2.2. Step 2: Release unstable version and test new binaries https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 has the changes to produce official binaries with Guile 3.0(.9). For Windows, it currently relies on a number of patches that I also sent upstream. In some sense, the situation is not worse than Guile 2.2 where we also had patches. Or arguably it is better because there is the possibility that the changes will be merged upstream... I propose to not merge the changes for our binaries immediately, but instead produce an additional set of binaries with the next unstable release. That way, users can test on all platforms and make sure the setup works. Again, this is similar to what we had in LilyPond 2.23.6 when switching to Guile 2.2. Step 2a: Assuming this testing goes fine, I would like to backport the changes from the first step to stable/2.24 and release a new stable version. The idea is that distributions wanting to drop their package for Guile 2.2 can switch LilyPond 2.24 to Guile 3.0. Note that the official binaries will stay Guile 2.2 for future bug fix releases, it's only about officially supporting the later version. However, we also have to see how the situation develops with Ghostscript 10.02.1, so let's postpone discussion on this topic for now... Step 3: Switch to Guile 3.0 Afterwards, we can merge https://gitlab.com/lilypond/lilypond/-/merge_requests/2163 and then remove automatic detection of Guile 2.2 from configure. It would still be possible to build LilyPond with GUILE_FLAVOR=guile-2.2 for some limited time, until ... Step 4: Remove compatibility code for Guile 2.2 This can happen after we made one or two releases with only Guile 3.0. Step 5? Move to Ubuntu 22.04 for testing and bump requirement to Guile 3.0.7? Then we could remove some more compatibility code, but let's discuss this at some later point. Please let me know of your comments! Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.9
We are happy to announce the release of LilyPond 2.25.9. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.2, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing With this release, LilyPond's HTML documentation switches (back) to texi2any. While we tried to make sure that existing links will continue to work, please report back if that is not the case. Also please let us know if, after clearing your browser's cache, something looks significantly worse than before (compared to the documentation for v2.24, for example). signature.asc Description: This is a digitally signed message part
Re: [RFC] HTML documentation with texi2any
On Sun, 2023-09-03 at 14:40 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > For a possible timeline, we could wait for the release of LilyPond > 2.25.8 (probably September 16/17 because I'm travelling next weekend, > unless Jean wants to do it again) and then merge the changes right > after. This happened on Sunday 17. > This would still allow us to maybe shake out some first problems > and also clean up some workarounds remaining from texi2html. The first two big follow-up merge requests went in the week after. Given no major complaints from developers so far, I will likely go ahead and release a new unstable version next weekend (October 7/8) so that users also get to see it and report problems, if there are any. Plus many other fixes are lining up as well 😉 Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] HTML documentation with texi2any
On Sun, 2023-09-03 at 14:40 +0200, Jonas Hahnfeld wrote: > For a possible timeline, we could wait for the release of LilyPond > 2.25.8 (probably September 16/17 because I'm travelling next weekend, > unless Jean wants to do it again) and then merge the changes right > after. Following the proposal above, I'm planning to merge https://gitlab.com/lilypond/lilypond/-/merge_requests/2089 tomorrow (even if it's officially on Patch::Countdown right now). In case you don't agree, please object. Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.8
We are happy to announce the release of LilyPond 2.25.8. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.2, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: Source tarballs on lilypond.org
On Sun, 2023-09-03 at 15:18 +0200, Jean Abou Samra wrote: > Le dimanche 03 septembre 2023 à 14:48 +0200, Jonas Hahnfeld a écrit : > > Can you please > > change it to something more like: > > "IMPORTANT: Binaries and documentation archives are NOT updated on > > lilypond.org anymore, please refer to releases on GitLab instead." > > Done. Perfect, thanks! signature.asc Description: This is a digitally signed message part
Re: Source tarballs on lilypond.org
On Sun, 2023-09-03 at 14:29 +0200, Jean Abou Samra wrote: > Le vendredi 01 septembre 2023 à 19:56 +0200, Jonas Hahnfeld a écrit : > > Yes, could be a good idea. Looking at the directory, it seems like the > > contents of README.html are displayed below the list of directories, > > maybe we should use that? If not, we can probably come up with a custom > > solution to show the notice prominently. > > > I went ahead and added a warning on these directories: > > https://lilypond.org/download > https://lilypond.org/download/binaries > https://lilypond.org/download/binaries/linux-x86 > https://lilypond.org/download/binaries/linux-64 > https://lilypond.org/download/binaries/mingw > https://lilypond.org/download/binaries/darwin-x86 > https://lilypond.org/download/binaries/documentation > > Let me know how that looks. I plan to close #6648 > in a few days. I don't like the text, the first sentence really much sounds like the entire downloads directory is obsolete and people should also get the sources from GitLab, which is very much not the case. Can you please change it to something more like: "IMPORTANT: Binaries and documentation archives are NOT updated on lilypond.org anymore, please refer to releases on GitLab instead." (the link is good though, I wasn't sure if that is possible) *If* we want to say something about the source tarballs, I believe it should only be mentioned in the topmost directory and not below "binaries/" to not confuse average users. We may even want to vary the message to only talk about the documentation archives in "binaries/documentation/" etc. signature.asc Description: This is a digitally signed message part
[RFC] HTML documentation with texi2any
Hi all, after some more work, I think I have resolved most details for generating LilyPond's HTML documentation with texi2any. The only minor detail I would like to call out (for transparency) is that we will again have "see section" when building with Texinfo 6.7, essentially reverting https://gitlab.com/lilypond/lilypond/-/merge_requests/1109 It is (in my opinion) a very minor cosmetic change and, as you can read up in that merge request, it already hit some objections when it was introduced one and a half years ago. With texi2any, we do not have the same customization hook and would have to format all references ourselves. Additionally, "see section" will again disappear with Texinfo 6.8 because of upstream changes, so I propose we just live with that for now. There will certainly be other (hopefully smaller) problems, but I believe there aren't major blockers anymore. I would therefore like to propose that we switch to texi2any reasonably soon. Please note that the only really critical part is the website because it's generated from master, and that one should be in fairly good shape. Minor problems in the other manuals "only" affect the unstable releases and can probably be dealt with as they are discovered. For a possible timeline, we could wait for the release of LilyPond 2.25.8 (probably September 16/17 because I'm travelling next weekend, unless Jean wants to do it again) and then merge the changes right after. This would still allow us to maybe shake out some first problems and also clean up some workarounds remaining from texi2html. What do you think? Jonas signature.asc Description: This is a digitally signed message part
Re: Source tarballs on lilypond.org
On Fri, 2023-09-01 at 16:25 +0200, Jean Abou Samra wrote: > > As for the issue, I consider that somewhat of an outlier: Most users > > will follow the links on the website, and everything will work for > > them. A small fraction tries to find the binaries where they used to be > > (and I'm surprised there are still questions about the installer > > scripts...), but I find it highly unlikely that those people check the > > directory with the sources, so not uploading them doesn't really change > > anything for those users, does it? > > I think we could add a "README" or "IMPORTANT-NOTICE" file in > directories like http://lilypond.org/download/binaries/documentation/, > stating that new releases are on GitLab, and call the issue done. > WDYT? Yes, could be a good idea. Looking at the directory, it seems like the contents of README.html are displayed below the list of directories, maybe we should use that? If not, we can probably come up with a custom solution to show the notice prominently. Jonas signature.asc Description: This is a digitally signed message part
Re: Source tarballs on lilypond.org
On Fri, 2023-09-01 at 14:31 +0200, Jean Abou Samra wrote: > Hi, > > Per the release procedure > https://lilypond.org/doc/v2.25/Documentation/contributor/release-checklist , > GitLab releases for LilyPond contain both binaries + doc tarballs and source > tarballs generate by "make dist", while the old download site > lilypond.org/download, which used to host all of these, now only has source > tarballs. > > https://gitlab.com/lilypond/lilypond/-/issues/6648 is the result of someone > being confused by not finding doc tarballs next to source tarballs on > lilypond.org/download, as it was in the past. > > I couldn't find the reason for this in the archives. What's the purpose of > serving the source tarballs from two different places? IIRC it was alluded to when I proposed uploading only the binaries (and the documentation) to GitLab: the source archive is used to build for various distributions (Linux, Homebrew, MacPorts). They all had (and still have) the "old" link in their setups, so it was (and still is) easier to keep uploading them there. Plus they are relatively small and don't require that much resources, so I think the benefit of providing the sources from the official website outweighs the extra step. As for the issue, I consider that somewhat of an outlier: Most users will follow the links on the website, and everything will work for them. A small fraction tries to find the binaries where they used to be (and I'm surprised there are still questions about the installer scripts...), but I find it highly unlikely that those people check the directory with the sources, so not uploading them doesn't really change anything for those users, does it? Jonas signature.asc Description: This is a digitally signed message part
Prototype for HTML documentation with texi2any
Hi all, after months of preparations (if not years) and actual implementation work during the last few weekends, I would like to share the first complete prototype for generating LilyPond's HTML documentation with texi2any: https://gitlab.com/lilypond/lilypond/-/merge_requests/2089 Before you get too excited, let me make it clear that there are still discussions to be held, decisions to be taken, and work to be done. For example, while there already is quite some compatibility code for Texinfo 6.7, I haven't yet found a way to honor @xrefautomaticsectiontitle for the navigation panel. If it turns out that there is no (good) solution for that (which I'm not sure yet), there are a couple of options for how we generate the official documentation during the releases (because that's where it matters eventually). But I haven't made up my mind on some points yet and no concrete proposals for now, so it's too early for meaningful discussions. Also, take the shared merge request as strictly work-in-progress. If you find a problem and get down to coding a solution, I would like to reserve full authority on whether to take that solution and / or what degree to rework it. This is to make sure we at least start with a reasonably clean customization file, which really has been a mess to clean up... Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.24.2 released!
We are proud to announce the release of GNU LilyPond 2.24.2. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version contains a number of fixes since the release of the previous stable version in February 2023. This includes an update of the library for garbage collection, addressing crashes when compiling very large scores (several hundreds of pages) on Windows. We recommend all users to update. Scores converted to or written for 2.24.0 will continue to work with this release. A list of added features and other user-visible changes for 2.24 can be found at https://lilypond.org/doc/v2.24/Documentation/changes/. Among others, version 2.24.0 switched to Guile 2.2 and features a completely rewritten infrastructure for creating the official packages, finally allowing us to offer 64-bit binaries for macOS and Windows. These pre- built binaries are linked from https://lilypond.org/download.html and available from GitLab: https://gitlab.com/lilypond/lilypond/-/releases/v2.24.2 signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.2
On Tue, 2023-08-08 at 10:57 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > I finally have (fixed) internet again! With that, the plan would be to > first check for additional backports and then build the binaries during > the week, probably tomorrow or Thursday. The final release would be on > Saturday, August 12th - exactly one month after the originally planned > date... I finished building and uploading the binaries to https://gitlab.com/lilypond/lilypond/-/packages/16672215 If you have time, please give it some short smoke testing in your favorite setup. As a reminder, the official tag and announcement will happen on Saturday, August 12th. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.2
Hi all, On Fri, 2023-07-28 at 08:28 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > On Sat, 2023-07-08 at 15:29 +0200, Jonas Hahnfeld via Discussions on > LilyPond development wrote: > > On Sat, 2023-07-01 at 15:02 +0200, Jonas Hahnfeld via Discussions on > > LilyPond development wrote: > > > I plan to build the binaries next weekend, July 8th or 9th, for > > > the final release on Wednesday, July 12th. > > > > Unfortunately, this won't happen: My fiber is cut and I don't have > > (fixed) internet 😞 and while I could work around this by using my > > phone and / or driving to work (that's what I did for 2.25.4), I would > > prefer not to for a stable release. > > Quick update: I still have no (fixed) internet and no time estimate at > the moment. I finally have (fixed) internet again! With that, the plan would be to first check for additional backports and then build the binaries during the week, probably tomorrow or Thursday. The final release would be on Saturday, August 12th - exactly one month after the originally planned date... Jonas signature.asc Description: This is a digitally signed message part
Re: Flex on macOS
On Mon, 2023-07-31 at 09:54 +0200, Jean Abou Samra wrote: > > Yes, but flex has always been there as a dependency of some other > > package I think, only not added in your environment variables. We can > > explicitly add it to the Brewfile if you think that's better, but it > > shouldn't change the set of already installed packages. > > Hm, I just SSHed into the MacStadium node again and ran "brew uninstall flex". > This did not uninstall any other package as depending on flex. Right, it also comes up with "brew bundle cleanup"... Did you manually install it for your environment during the weekend? I'm relatively sure I didn't, it may have come in as a dependency in the past (even though I couldn't find it in the history of homebrew-core). But yes, then we should add it to the Brewfile, sorry for not realizing this when doing the previous release. Jonas signature.asc Description: This is a digitally signed message part
Re: Flex on macOS
On Mon, 2023-07-31 at 01:15 +0200, Jean Abou Samra wrote: > Hi, > > As a follow-up to the release: on macOS I encountered a quirk which is > that the compiler spit out build errors on the Flex-generated lexer > out/lexer.cc. (Now I find myself stupid for not saving the error messages > somewhere.) IIRC it complains about the 'register' keyword which is an error with C++17, ie since the last release. > I noticed that the macOS-provided flex version (on the MacStadium node > provided by Marnen, which runs the unsupported macOS Catalina) was > ~10 years old, so I installed Flex from Homebrew (required setting > CPPFLAGS + LDFLAGS + PATH as advised in the Homebrew log messages), > and it went fine. Should we add "flex" to release/binaries/Brewfile? > Jonas, did you already encounter that problem? Did you do the same? Yes, but flex has always been there as a dependency of some other package I think, only not added in your environment variables. We can explicitly add it to the Brewfile if you think that's better, but it shouldn't change the set of already installed packages. Jonas signature.asc Description: This is a digitally signed message part
Re: fix-docsize errors in build-doc.sh
On Sun, 2023-07-30 at 18:31 +0200, Jean Abou Samra wrote: > Trying to do the release, I got these messages during "./build-doc.sh": > > [...] > > Is that expected? Yes, it has always been there for the online pages because the big- pages use language content negotiation and aren't valid file names. You can see this by either running an old version through build-doc.sh or by looking at old web pages from previous release cycles. signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.2
On Sat, 2023-07-08 at 15:29 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > On Sat, 2023-07-01 at 15:02 +0200, Jonas Hahnfeld via Discussions on > LilyPond development wrote: > > I plan to build the binaries next weekend, July 8th or 9th, for > > the final release on Wednesday, July 12th. > > Unfortunately, this won't happen: My fiber is cut and I don't have > (fixed) internet 😞 and while I could work around this by using my > phone and / or driving to work (that's what I did for 2.25.4), I would > prefer not to for a stable release. Quick update: I still have no (fixed) internet and no time estimate at the moment. In the meantime, I asked Jean if he could try doing an unstable release 2.25.7. Jonas signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.2
On Mon, 2023-07-17 at 07:08 +0200, Jean Abou Samra wrote: > Le samedi 08 juillet 2023 à 15:29 +0200, Jonas Hahnfeld via Discussions on > LilyPond development a écrit : > > Unfortunately, this won't happen: My fiber is cut and I don't have > > (fixed) internet 😞 and while I could work around this by using my > > phone and / or driving to work (that's what I did for 2.25.4), I would > > prefer not to for a stable release. > > > > I will have a technicien come on Tuesday, I will see for an updated > > plan afterwards (though neither Thursday nor Friday). > > Let us know in case you'd rather have someone else build the binaries > for this release. I should have enough time and Internet access for that > this evening or tomorrow evening. Thanks for the offer. However, I don't think that's a good idea for a stable bugfix release. Time isn't really an issue this week, but my internet is still not working... signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.2
On Sat, 2023-07-01 at 15:02 +0200, Jonas Hahnfeld via Discussions on LilyPond development wrote: > I plan to build the binaries next weekend, July 8th or 9th, for > the final release on Wednesday, July 12th. Unfortunately, this won't happen: My fiber is cut and I don't have (fixed) internet 😞 and while I could work around this by using my phone and / or driving to work (that's what I did for 2.25.4), I would prefer not to for a stable release. I will have a technicien come on Tuesday, I will see for an updated plan afterwards (though neither Thursday nor Friday). C'est la vie... Jonas signature.asc Description: This is a digitally signed message part
Re: `make bytecode && make doc` broken
On Sat, 2023-07-08 at 10:20 +, Werner LEMBERG wrote: > Currently, `make bytecode && make doc` is broken: https://lists.gnu.org/archive/html/lilypond-devel/2023-07/msg8.html (it's not like there are hundreds of messages every day, a duplicate thread doesn't serve anybody...) signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.2
On Sat, 2023-07-01 at 21:34 +0200, Jean Abou Samra wrote: > The idea of the delay between the build and the release is to let people test > the binaries first, right? Yes, I will upload the binaries to GitLab but only do the tagging + announcement + website upload on Wednesday, in case anything comes up. (It also reduces the time I have to allocate on one day, even though that would likely be fine on a weekend.) Jonas signature.asc Description: This is a digitally signed message part
Plan for LilyPond 2.24.2
Hi all, after the unstable release 2.25.6 is out and the included update of bdwgc seems to resolve the rare crashes on Windows (not backported yet), I would like to go ahead with the stable version 2.24.2. If there is anything else that needs to go in, please ping me on GitLab. I plan to build the binaries next weekend, July 8th or 9th, for the final release on Wednesday, July 12th. Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.6
We are happy to announce the release of LilyPond 2.25.6. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.1, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing This release of LilyPond includes an updated version of the library for garbage collection that should finally address some rare crashes seen on Windows. If you have scores that were crashing with previous versions, including the stable LilyPond 2.24.1, please give this development version a try and report back the results. Unless problems are reported, we are planning to backport this update and release it as LilyPond 2.24.2, along with a number of other bug fixes. signature.asc Description: This is a digitally signed message part
Re: MR milestones
On Thu, 2023-06-22 at 14:32 +0200, Jean Abou Samra wrote: > Recently, GitLab gained a "bulk edit" button in the MR view. This button has "always" been there ... > That means the person doing the release (currently Jonas) can > easily assign all the MRs merged during the release in a few > clicks, without having to go through each MR ... and I already use it (and Phil used it before me). > which reduces the incentive to assign milestones manually just > after merging. Should we declare having the milestone assigned > on release as the norm? It doesn't really matter, the step in the release procedure is just there to catch merge request without a milestone assigned. If there are some where the author has already taken care of this, that's fine. Cheers Jonas P.S. Can you maybe update your mail client's settings to break lines more reasonably? Right now, it seems to break at column 200 which is extremely long and for example in my clients means it looks quite weird... signature.asc Description: This is a digitally signed message part
Re: 2.25.6 release
On Fri, 2023-06-16 at 19:46 +0200, Jean Abou Samra wrote: > Le vendredi 16 juin 2023 à 18:11 +0200, Jonas Hahnfeld a écrit : > > I think I'd still lean towards doing the release as planned because (a) > > the issue is already there with the current 2.25.5 and (b) it's also > > not clear that a fix will land before the next weekend. > > Regarding (b), I've now submitted > https://gitlab.com/lilypond/lilypond/-/merge_requests/2041 which I hope will > be satisfactory for everyone. Thanks! In light of that fix, let's delay the release by one week (there's no point in merging early since I'm away tomorrow). > TBH, I feel guilty about that issue and would prefer to delay the release, > but no strong feelings. Well, issues like these happen, especially with many components involved in a complex way. I don't think it's worth it to worry about this too much, it affects one development version for a subset of users on Linux... Jonas signature.asc Description: This is a digitally signed message part
Re: 2.25.6 release
On Fri, 2023-06-16 at 10:37 +0200, Jean Abou Samra wrote: > I know that 2.25.6 was planned for this weekend. Unfortunately, due to > https://gitlab.com/lilypond/lilypond/-/issues/6620 , current master is not > going to work on Kubuntu and possibly other distros. > > I will try to find time this evening to experiment with the alternative > approaches proposed on > https://gitlab.com/lilypond/lilypond/-/merge_requests/2033 . Meanwhile, > should we delay the release, or do it nevertheless? I think I'd still lean towards doing the release as planned because (a) the issue is already there with the current 2.25.5 and (b) it's also not clear that a fix will land before the next weekend. If wanted, I can add a note in the release announcement that there is a known issue, notably on Kubuntu. That said, even though it's been four weeks since the last release, we only have 46 commits in master since the tag. I usually try to limit that number around 100, so from that perspective we'd be fine to wait a bit longer if somebody feels strongly about it. Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.5
We are happy to announce the release of LilyPond 2.25.5. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.1, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Next releases
Hi all, due to various constraints, I am kind of restricted when I will be able to do the next releases, so I thought I might as well let you know: LilyPond 2.25.5 will happen on the weekend of the 20th/21st (unless I get too bored this next weekend...). I'm planning version 2.25.6 for the second weekend of June (10th/11th) or the one after (17th/18th). I also think it might be a good idea to have another bugfix release of stable/2.24, towards the end of June / early July? Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: No writable cache directories
On Fri, 2023-04-28 at 15:14 +, Werner LEMBERG wrote: > Creating font configuration... > Adding fontconfig configuration file: > /usr/local/share/lilypond/2.25.5/fonts/emmentaler-font.conf > > Fontconfig error: No writable cache directories Let's state the obvious candidate here: This is very likely related to https://gitlab.com/lilypond/lilypond/-/merge_requests/1955 which added the emmentaler-font.conf defining a single cachedir. I wouldn't be surprised if it starts working again after you revert that commit. Jonsa signature.asc Description: This is a digitally signed message part
Re: Musings on our translated documentation build
On Wed, 2023-01-04 at 14:39 +0100, Jonas Hahnfeld via Discussions on
LilyPond development wrote:
> Now, this works in our current setup, but it seems to me that there is
> an easier way to achieve this with "native" Texinfo tools: Instead of
>
> @node Translated
> @section Translated
> @translationof Original
>
> we could also write
>
> @node Original
> @section Translated
>
> which would take care of the .html file names automatically (modulo the
> lower-casing which we do for aesthetics, but that's easy and
> potentially even more debatable).
>
> The obvious downside is that references in the translated documentation
> get a bit more complex:
> * For references in the same document (say inside the NR), we'd have
> to write @ref{Original} instead of @ref{Translated}. Together with
> @xrefautomaticsectiontitle on, this will still show the translated
> section title for PDF and HTML (does not seem to work for .info, but
> see first paragraph why this isn't actually a problem), even if it
> looks a bit weird / funny.
> * For cross-references, we'd have to manually provide the mapping. So
> instead of @ruser{Translated}, we'd have to write
> @rusernamed{Original,Translated} to make the link text appear
> translated.
I've been working on this over the past weeks, and the changes in
https://gitlab.com/lilypond/lilypond/-/merge_requests/1973 implement
the new setup described above. If possible, please have a look so that
we can find potential problems before merging (and the subsequent
cleanups).
Cheers
Jonas
signature.asc
Description: This is a digitally signed message part
LilyPond 2.25.4
We are happy to announce the release of LilyPond 2.25.4. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.1, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: Build binaries in CI?
On Mon, 2023-04-17 at 22:52 +0200, Jean Abou Samra wrote: > Hi, > Just a thought related to > https://gitlab.com/lilypond/lilypond/-/merge_requests/1950: maybe we > could add optional CI jobs running on CentOS 7 to compile Linux > official binaries + MinGW binaries ? Windows binaries are cross-compiled from Ubuntu. > I have a faint remembrance that Jonas preferred to keep the build > environment definitions in the Ansible playbooks rather than creating > Docker images; however, for something run infrequently, I think the > overhead of deploying the Ansible playbook during the CI job itself > would be acceptable, right? This is only part of the reasoning: For some platforms (macOS and FreeBSD, if we ever want to have binaries again), we cannot compile using Docker containers. For that reason, I prefer to focus on one setup with full VMs / bare metal instead of containers. Also installing packages during jobs and downloading all packages for the binaries is quite some data volume. I remember that this wasn't ideal for Dan's runner, but we would need to evaluate specifics. > It could help testing proposed changes to the release scripts, and > also reduce the manual building work during each release to only the > macOS binaries. The latter point is not really solid since the manual work right now amounts to starting a VM, extracting the produced tarball and then running the scripts and waiting. In fact, it's probably going to take longer for a CI system to build the binaries than for me locally. There's also the second disadvantage that it means we're not building all binaries from the exact same tarball anymore. And even if we're fine with that, it means I have to push the release preparations to a remote before I know that it works (if I was to run into a problem right now, I'd just abandon the release and fix the issue first). In the longer term, I also want to sign the source tarball and the official binaries, and I'm only going to do that if I can attest the whole build chain, not with a company owned source forge and CI system or community provided runners. In summary, I see the point of testing proposed changes and potentially nightly builds at some point (only for some platforms though), but I don't really see an improvement of the actual release process. Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.3
We are happy to announce the release of LilyPond 2.25.3. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.1, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing P.S.: This is not an April Fool, but just an ordinary and boring unstable release... signature.asc Description: This is a digitally signed message part
Re: Musings on our translated documentation build
On Mon, 2023-03-13 at 22:20 +0100, Jonas Hahnfeld via Discussions on
LilyPond development wrote:
> On Wed, 2023-01-04 at 23:36 +0100, Jonas Hahnfeld via Discussions on
> LilyPond development wrote:
> > 1. All @ref{Translated} become @ref{Origin}, but as far as I understand
> > that may actually be an advantage.
> > 2. All @ruser{Translated} become @rusernamed{Origin,Translated}, ie you
> > have to provide both the original @node *and* the translated display
> > text. For @unnumberedsec, we may even need a third argument to get the
> > anchor correct - not sure how often that is actually needed.
>
> Actually, I'm not even sure if it's possible to reference a target that
> is not the @node determining the file name. I haven't found a way so
> far with "native" Texinfo tools... I will keep looking or actually
> educate myself why we have a custom splitting mode and whether we want
> to keep it.
I come to the conclusion that it's not possible to have cross-manual
references to an @unnumberedsec whose file name is determined by a
different @node. I'm proposing to remove our custom split mode in
https://gitlab.com/lilypond/lilypond/-/merge_requests/1885.
signature.asc
Description: This is a digitally signed message part
Re: Musings on our translated documentation build
On Sun, 2023-03-19 at 23:56 +0100, Federico Bruni wrote: > Actually I was curious to check the html output rather than the changes > in the source. > If it doesn't break working links, it's fine for me. In the parts I touched, it is almost generating identical HTML (except for the links to unnumbered sections; but I'm coming to the conclusion that probably want to stop treating them specially anyway). I will follow up on this once I have more time. > If you eventually proceed, write the scripts, etc. I'd be happy to > check if the Italian manuals look good and links work correctly. CI > builds the doc also, right? Yes, the documentation gets built for every merge request, but it's not available for inspection (and also pretty big). > Maybe English manuals only? Not sure I understand this question, CI builds all languages. English is also pretty boring with respect to this change because it's not translated and doesn't have @translationof and the related machinery. Jonas signature.asc Description: This is a digitally signed message part
Re: Differences in `web.html`
On Mon, 2023-03-20 at 14:34 +, Werner LEMBERG wrote: > Comparing > > http://lilypond.org/web.html > > with a self-compiled > > .../out-www/offline-root/Documentation/web/web.html > > I see the attached difference. Is it an oversight that > `scripts/build/fix-docsize.sh` is not executed while building the > website on 'lilypond.org'? Yes, intentionally so: "make website" does not execute it because it doesn't have access to the linked manuals and cannot fill in its size. Based on the path above, you've been executing "make doc" which also generates the website as part of it. Btw, there are a number of other differences, search for "web_version" in the Documentation/web/* files. > PS: That we now see 'web.pdf' instead of 'Web.pdf' seems to be a > consequence of commit d638af5410936d255f. No, this has nothing to do with that - it's not even a button in a navigation bar! It is because of weblinks.itexi and which macros are used depending on "web_version" (see above). signature.asc Description: This is a digitally signed message part
Re: Musings on our translated documentation build
Hi all,
sorry for dropping the ball on this topic...
On Wed, 2023-01-04 at 23:36 +0100, Jonas Hahnfeld via Discussions on
LilyPond development wrote:
> On Wed, 2023-01-04 at 22:58 +0100, Federico Bruni wrote:
> > Il giorno mer 4 gen 2023 alle 14:39:47 +0100, Jonas Hahnfeld
> > ha scritto:
> >
> >
> 1. All @ref{Translated} become @ref{Origin}, but as far as I understand
> that may actually be an advantage.
> 2. All @ruser{Translated} become @rusernamed{Origin,Translated}, ie you
> have to provide both the original @node *and* the translated display
> text. For @unnumberedsec, we may even need a third argument to get the
> anchor correct - not sure how often that is actually needed.
Actually, I'm not even sure if it's possible to reference a target that
is not the @node determining the file name. I haven't found a way so
far with "native" Texinfo tools... I will keep looking or actually
educate myself why we have a custom splitting mode and whether we want
to keep it.
> > I would like to see a test for a language in order to better understand.
Here's a proof-of-concept for the French Usage Manual (sorry, if I had
correctly remembered that it was you and not Jean-Charles, I would have
picked an Italian manual):
https://gitlab.com/hahnjo/lilypond/-/commits/poc-no-xref-maps
It works for all links inside the Usage Manual and cross-references to
other manuals (e.g. the NR), except for those to unnumbered sections
(see above). Note that external links into the French Usage Manual are
broken, the other manuals would need similar treatment.
> > Would you take care of all the changes required in translated files?
> > ("swapping" @translationof and @section, changing the @ref occurrences,
> > ...)
>
> Yes, this would be automated, I hope.
(the above proof-of-concept was mostly by hand, but I'm certainly going
to write a script for the actual conversion...)
Jonas
signature.asc
Description: This is a digitally signed message part
Re: Lilypond for Apple Processor
On Sun, 2023-03-12 at 22:16 +, Werner LEMBERG wrote: > > Well, what I was trying to say, and what I probably should have > > made more explicit, is that "official" binaries from our side > > require a bit of work. In fact, the support in our scripts needs > > to be dealt with in advance, so "patches welcome" *hint, hint*. > > Apple wants that binaries for Apple machines are built on Apple > hardware. What about cross-compiling M1 stuff on a non-M1 system? > Would this be a possible solution? Even if possible, I would really like to avoid this direction; see also the release/binaries/README.md file. The only platform where I'm ok with cross-compiling is for Windows, because actually it's working better (and much faster) than native compilation on Windows. Jonas signature.asc Description: This is a digitally signed message part
Re: Lilypond for Apple Processor
On Sun, 2023-03-12 at 21:50 +0100, Ben wrote: > Hi Jonas, > > Thanks for your answer. > > I don't know how works macports, but it already managesto provide > compiled versions for Apple ARM of lilypond (and frescobaldi). > > In fact, I can live with that, so I will wait. Well, what I was trying to say, and what I probably should have made more explicit, is that "official" binaries from our side require a bit of work. In fact, the support in our scripts needs to be dealt with in advance, so "patches welcome" *hint, hint*. Jonas signature.asc Description: This is a digitally signed message part
Re: Lilypond for Apple Processor
On Thu, 2023-03-02 at 02:28 +0100, Ben wrote: > Hello everyone, > > Thanks for the list. > > I would be interested in a version of lilypond natively for > Apple processors. > > I work with a mac M1 and if someone explains me the procedure > for the compilation, I can gladly compile this version myself. Sorry for the very late reply! Thanks to Jean, I was able to find the thread on lilypond-user-fr: https://lists.gnu.org/archive/html/lilypond-user-fr/2023-03/msg00018.html In short, as also discussed in there, the x86 binaries will also work on ARM, thanks to Apple's translation layer. For now, this should cover the most urgent use cases. Of course, it would be nice to provide native ARM binaries for macOS because sooner or later, Apple will want to remove the x86 translation. There are currently two blockers for this: a) The scripts in release/binaries need to produce a working version for macOS ARM. Jacques Menu had a try on this some time ago, but if I re-read the discussion correctly (which was off-list, unfortunately) Ghostscript did not build back then. This needs to be figured out. b) I need to have access to a machine where I can build official binaries during the release process. Alternatively, but less preferred (because it requires synchronization and introduces delays), somebody else will need to build the binaries. However, depending on need, this would probably be feasible at least for the stable releases. But let's worry about this after a) is solved. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: Text font installation
On Thu, 2023-03-02 at 13:17 +0100, Jean Abou Samra wrote: > ArchLinux gets it almost right, however I think that TeX Gyre fonts > should be made required, https://bugs.archlinux.org/task/77700. > Manjaro takes the package from ArchLinux. FWIW I strongly disagree here: 99.9% of the users are fine without the extra fonts, so it should not be made mandatory. I've commented on the bug report, and I'd appreciate to discuss things upstream first before running to all downstreams and recommending them something else. > Debian also made the fonts-texgyre package optional. I've opened > https://gitlab.com/lilypond/lilypond/-/merge_requests/1855 to > document that they should be required and posted about this on > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1026200 (should > appear soon). Same here. Actually even more, apt installs recommended dependencies by default IIRC, but the user is free to not install the extra fonts. signature.asc Description: This is a digitally signed message part
Re: LilyPond 2.25.2
On Sat, 2023-02-18 at 14:43 -0500, Shane Brandes wrote: > That is great, but where can one find a list of changes between > versions? The current Changes document can be found here: http://lilypond.org/doc/v2.25/Documentation/changes/ In general, all manuals for the development releases are linked from http://lilypond.org/development.html Cheers Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.25.2
We are happy to announce the release of LilyPond 2.25.2. This is termed a development release, but these are usually reliable for testing new features and recent bug fixes. However, if you require stability, we recommend using version 2.24.1, the current stable release. Please refer to the Installing section in the Learning Manual for instructions how to set up the provided binaries: https://lilypond.org/doc/v2.25/Documentation/learning/installing signature.asc Description: This is a digitally signed message part
Re: RFC: stop doing "grand replace" updates to copyright years
On Mon, 2023-02-13 at 13:36 +0100, Janneke Nieuwenhuizen wrote: > Han-Wen Nienhuys writes: > > Hey, > > > Every year, we go over the source code to update the copyright years > > that are found in the source headers. I propose to stop this. > > +1 > > > Also note that many other projects (eg. git) seem to survive just fine > > without yearly exercise like this. > > Yes. Of course, git is not a GNU project but I see this in projects > like Guix too. usually, $author includes a copyright year update in > their patch when they make a change to a file. For trivial changes, it > could be skipped but that's often usually up to the courtesy of $author. This is the approach I like the least of the three options, the others being the status quo and updating all files (as recommended by GNU, see Jean's reply) or to not have any years at all (like for example curl does: https://daniel.haxx.se/blog/2023/01/08/copyright-without-years/). Updating years together with actual changes just calls for conflicts when two merge requests update the same file, or even worse when picking a fix to the stable branch. I'm against that if the "solution" is to just keep doing what we have in place right now. Han-Wen, could you please clarify which option you are proposing exactly? Side comment: IANAL, but my understanding is that copyright notices are notoriously wrong (at least for LilyPond) because every author retains their copyright. For that, it is simply irrelevant what a comment at the top of the file says, or even factually wrong if it only lists one (primary) author. Jonas signature.asc Description: This is a digitally signed message part
LilyPond 2.24.1 released!
We are proud to announce the release of GNU LilyPond 2.24.1. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version includes a number of fixes since the release of the previous stable version in December 2022, and we recommend all users to update. Scores converted to or written for 2.24.0 will continue to work with this release. A list of added features and other user-visible changes for 2.24 can be found at https://lilypond.org/doc/v2.24/Documentation/changes/ Among others, version 2.24.0 switched to Guile 2.2 and features a completely rewritten infrastructure for creating the official packages, finally allowing us to offer 64-bit binaries for macOS and Windows. These pre-built binaries are linked from https://lilypond.org/download.html and available from GitLab: https://gitlab.com/lilypond/lilypond/-/releases/v2.24.1 Please note that there is a known issue on Windows where compiling very large scores (several hundreds of pages) can result in crashes. We hope to address this in a future bugfix release. signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.1
On Wed, 2023-02-08 at 19:08 +0100, Jonas Hahnfeld via Discussions on LilyPond development wrote: > > Otherwise, I plan to build the binaries on Thursday, February 9th, or > > Friday the 10th, with the final release foreseen for Sunday the 12th. > > I didn't hear objections on this, so I plan to go ahead with the > release towards the end of the week. I finished building and uploading the binaries to https://gitlab.com/lilypond/lilypond/-/packages/12459380 For people interested, please test in your favorite setup. I will officially tag and announce the release on Sunday. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: Plan for LilyPond 2.24.1
On Wed, 2023-02-01 at 22:39 +0100, Jonas Hahnfeld via Discussions on LilyPond development wrote: > Hi all, > > after the situation with Debian seems to be resolved (guile-2.2 and > lilypond-2.24.0 are in unstable and they should get into bookworm), I > would like to come back to the plan of releasing LilyPond 2.24.1 as a > bugfix version. > > I just backported the last outstanding merge requests that I had marked > as such and some other chore work; in total we are 34 commits past > v2.24.0, addressing 12 issues, see the branch for details. If there is > anything I missed or a critical issue that must be addressed before the > next release, please let me know. > > Otherwise, I plan to build the binaries on Thursday, February 9th, or > Friday the 10th, with the final release foreseen for Sunday the 12th. I didn't hear objections on this, so I plan to go ahead with the release towards the end of the week. The draft release announcement text is: --- We are proud to announce the release of GNU LilyPond 2.24.1. LilyPond is a music engraving program devoted to producing the highest-quality sheet music possible. It brings the aesthetics of traditionally engraved music to computer printouts. This version includes a number of fixes since the release of the previous stable version in December 2022, and we recommend all users to update. Scores converted to or written for 2.24.0 will continue to work with this release. A list of added features and other user-visible changes for 2.24 can be found at https://lilypond.org/doc/v2.24/Documentation/changes/. Among others, version 2.24.0 switched to Guile 2.2 and features a completely rewritten infrastructure for creating the official packages, finally allowing us to offer 64-bit binaries for macOS and Windows. These pre-built binaries are linked from https://lilypond.org/download.html and available from GitLab: https://gitlab.com/lilypond/lilypond/-/releases/v2.24.1 Please note that there is a known issue on Windows where compiling very large scores (several hundreds of pages) can result in crashes. We hope to address this in a future bugfix release. --- I'm leaning towards leaving out the contributors this time - the text is already quite long because I wanted to mention that scores from 2.24.0 continue to work and re-iterate on the new binaries. That said, I'm open to being convinced otherwise. And any other feedback. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail
On Sun, 2023-02-05 at 13:05 +, Werner LEMBERG wrote: > > These are *ancient*, the last version 10.11.6 was released in 2018. > > Even if we find one, I think we must not introduce any workaround > > for such outdated systems. > > *Must not*? This is a bit harsh IMHO. Any workaround we introduce will have to be removed at some point. When? 5 years after the last system goes EOL sounds like a reasonable time, don't you think? So yes, in my opinion "must not". > The problem could also be in the used clang versions, which are > probably used on non-macOS platforms, too. ... which is also 5 years old, so the same rationale applies. signature.asc Description: This is a digitally signed message part
Re: MacPorts builds for 'Yosemite' and 'El Capitan' fail
On Sun, 2023-02-05 at 12:54 +, Werner LEMBERG wrote: > Looking into MacPorts 'lilypond-devel' log files for Yosimite > ( > https://build.macports.org/builders/ports-10.10_x86_64-builder/builds/ > 211914/steps/install-port/logs/stdio) > and El Capitan > ( > https://build.macports.org/builders/ports-10.11_x86_64-builder/builds/ > 209146/steps/install-port/logs/stdio) > [...] > > @dan: I guess this is a problem or bug with the XCode clang versions > of these two macOS versions since both older and newer ones compile > fine. I'm not a C++ expert, but maybe there is a simple fix > available? These are *ancient*, the last version 10.11.6 was released in 2018. Even if we find one, I think we must not introduce any workaround for such outdated systems. signature.asc Description: This is a digitally signed message part
Re: GSoC 2023
On Mon, 2023-01-30 at 08:55 +, Werner LEMBERG wrote: > The deadline for registering LilyPond as mentor organization for GSoC > 2023 is February 7th. Do we want to participate? > > Who did the registration the last time? If necessary, I'm willing to > do the registering process if we agree on participation. > > AFAIK, the LilyPond's GSoC pages are up to date, but maybe some minor > adjustments or additions are necessary/useful, so please have a look! > > https://lilypond.org/google-summer-of-code.html I think one point that could be improved wrt the last years is the planning to upstream the changes and have them merged in a timely manner. I can participate as a co-mentor from the technical side, if wanted. signature.asc Description: This is a digitally signed message part
Plan for LilyPond 2.24.1
Hi all, after the situation with Debian seems to be resolved (guile-2.2 and lilypond-2.24.0 are in unstable and they should get into bookworm), I would like to come back to the plan of releasing LilyPond 2.24.1 as a bugfix version. I just backported the last outstanding merge requests that I had marked as such and some other chore work; in total we are 34 commits past v2.24.0, addressing 12 issues, see the branch for details. If there is anything I missed or a critical issue that must be addressed before the next release, please let me know. Otherwise, I plan to build the binaries on Thursday, February 9th, or Friday the 10th, with the final release foreseen for Sunday the 12th. Cheers Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Switch Docker images to Ubuntu 20.04 and bump requirements
On Sun, 2023-01-29 at 20:41 +, Werner LEMBERG wrote: > > That said, I just noticed /usr/share/icons/ going from 0.5M to 64M. > > It's split between adwaita-icon-theme, humanity-icon-theme, > > ubuntu-mono, all pulled in transitively by fontforge (via libgdraw6 > > and libgtk-3-0). I guess we can just manually delete that > > directory? > > Sounds sensible. We only use FontForge in batch mode, thus all GUI > stuff is unnecessary. I also found some static libraries to delete, now we are back at 859 MB for the ci image. Still a bit sad, but ok for the moment, I hope. Jonas signature.asc Description: This is a digitally signed message part
Re: [RFC] Switch Docker images to Ubuntu 20.04 and bump requirements
On Sun, 2023-01-29 at 16:37 +, Werner LEMBERG wrote: > > Another "pain point" is that the images are much bigger (997MB > > compared to 823MB with Ubuntu 18.04). > > Ouch. > > > I had a quick look and most if it seems to come from TexLive. If > > somebody has ideas how to "install less" or otherwise reduce the > > size, I would welcome contributions. > > Here is a comparison of the installed sizes of the TeXLive packages > (I took the info from https://packages.ubuntu.com). > > package bionic (18.04) focal (20.04) > - -- - > texlive-base 52MB 73MB > texlive-binaries 36MB 36MB > texlive-fonts-recommended 18MB 15MB > texlive-font-utils 4MB 4MB > texlive-lang-cyrillic 40MB 40MB > texlive-metapost 2MB 3MB > texlive-plain-generic 53MB 56MB > > texinfo 7MB 11MB > texi2html 2MB 2MB > --- --- > 214MB 240MB > > This doesn't explain the difference of 160MB... I don't have enough > time to do more size comparisons, sorry. /usr/share/texlive/ is 126M on Ubuntu 18.04 and 153M on Ubuntu 20.04, that's the biggest absolute increase of one package (group) that I could find. That said, I just noticed /usr/share/icons/ going from 0.5M to 64M. It's split between adwaita-icon-theme, humanity-icon-theme, ubuntu-mono, all pulled in transitively by fontforge (via libgdraw6 and libgtk-3-0). I guess we can just manually delete that directory? signature.asc Description: This is a digitally signed message part
