>> Please try the attached patch. It now calls `bindtextdomain` a
>> third time to take care of setting `LILYPOND_LOCALEDIR` in the
>> relocation files.
>
> I’d really rather not patch the code if I don’t have to, and three
> attempts to do anything seems smelly to me (it suggests that the
>
elf use that setting, or do only
> the child programs use it?
Please try the attached patch. It now calls `bindtextdomain` a third
time to take care of setting `LILYPOND_LOCALEDIR` in the relocation
files.
Werner
>From fb1c6fea888450974eafc0b31add9a2d926d0106 Mon Sep 17 00:00:00 2001
Fro
> how do I set LOCALEDIR (in this case, to match the packaged app
> bundle rather than the build-time path)? Unlike everything else of
> this nature, neither the .reloc files nor environment variables work
> (and I've tried setting both LOCALEDIR and LILYPOND_LOCALEDIR in
> both places): when I
> I'll open up a ticket and upload a patch as soon as it's finished
> (it already works, but I want a proper solution).
Great, thanks!
> *By the way:* how about TABs? Obviously, gitk, Rietveld et al. seem
> to use 8 spaces per tab.
I've just committed a patch that converts tabs to spaces in
> Unfortunately, mf overlaps can hardly be avoided in many cases,
> because lots of glyphs are being composed out of several overlapping
> predefined components.
Yes, and avoiding overlaps everywhere would lead to unnecessarily
complicated code. Tools like FontForge should be used to fix this
>> What do you think about converting all tabs in the .mf files to
>> spaces?
>
> I consider this a good idea. [...]
OK, so I will do this within the next couple of days.
Werner
> I see they reviewed SourceHut, which seems to be actively trying to
> comply with FSF's repository expectations. I'd come across SourceHut
> earlier, and its minimalist design and a few other things reminded me
> a little of LilyPond's culture.
SourceHut looks very nice!
BTW, here's an FSF
>> I'd need someone to take this sketch and integrate it into the
>> build system (I just don't really understand the build system).
>
> Do we really need this?
Yes, I think this is *very* useful. It's always nice to know big file
sizes (i.e., files larger than, say, 1MByte) in advance. Not
>> PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
>> branch.
>
> Ugh, that's giving me a nice set of conflicts.
Sorry for that.
Werner
> I know it says
>
> /usr/bin/ld: final link failed: No space left on device
> collect2: error: ld returned 1 exit status
>
> but I have plenty. I moved the build dir to a place I know I have
> plenty of space (just to be sure) and still get the same problem.
>
> Could this be some permission
> /usr/bin/ld: final link failed: No space left on device
This looks suspicious. Have you verified that you have enough free
disk space?
Werner
>> PPS: I see that we have a file `.dir-locals.el` in the git
>> repository; doesn't its contents contradict our tabs policy?
>
> No, it implements it.
Ah, ok. Thanks for the explanation.
> Yes, does not read well to human readers. Maybe one should tack on
> the redundant . nil here,
What do you think about converting all tabs in the .mf files to
spaces? If you agree, I would apply this to the staging.
Werner
Folks,
something that can be easily missed while doing reviews with Rietveld:
Since a long time we avoid tabs if possible.
Werner
PS: I've cleaned up `configure.ac` and `aclocal.m4` in the staging
branch.
PPS: I see that we have a file `.dir-locals.el` in the git repository;
Some time ago I was asked to document how to prepare MWE for reporting
FontForge problems with Emmentaler. Here it is.
How to report `FontForge` problems while creating LilyPond fonts
The output produced by the `mf2pt1` script
> I think the download text would warrant correction.
Yes.
> I just naively assumed it to be automatically generated in
> correspondence with reality.
This is an excellent suggestion. Not sure how to implement that
easily, but please open a tracker issue so that the idea is not lost.
> The download size for the notation manual comes out at 35MB which is
> about double than what we had for 2.16. I actually find that
> somewhat irritating. I'd have to check the old conversations about
> extractpdfmark and see whether this is indeed where our change of
> text fonts would have
>> LilyPond Error
>
> Does it ship with Python, or using the native? The 2.19.83 from the
> site uses 2.6, not 2.7.
> python --version
Python 2.7.17
Werner
For fun I tried to execute
https://bintray.com/marnen/lilypond-darwin-64/lilypond-2.19.83/2.19.83.build20200207173449
on my old MacOS Lion box, with the following error.
Traceback (most recent call last):
File ".../LilyPond 2.app/Contents/Resources/__boot__.py", line 98, in
It seems that the recent version of 'gettext' (0.21 from Dec. 2019) on
MacOS – at least on my Lion box – has changed language handling. In
the NEWS file I read
* Runtime behaviour:
- The interpretation of the language preferences on macOS has been
improved, especially in the case
>> Please all take a look and let me know what you think!
>
> For a first pitch certainly impressive. It's nice that the SHA1 ids
> have become live.
+1 Very nice!
Werner
Snipped 446 ('Modifying default values for articulation shorthand
notation') still talks about 'dashBar', which has been replaced by
'dashBang' in 2013.
Please fix. Alternatively, please make me (user 'lemzwerg' on LSR) an
editor so that I can do it myself :-)
Werner
>>> See the line above which is in CMU Concrete!
>
>> ??? I use Emacs to read my e-mail, and emacs is configured to use
>> the font 'DejaVu Sans Mono' on my GNU/Linux box. This font
>> contains Cyrillic glyphs...
>
> I composed that line in the email using CMU Concrete. Presumably
> your
>> However, I'd like to hear from David Kastrup and James Lowe
>> first. To me, their opposition registered as the strongest.
>
> I remain strongly opposed to a CoC.
Hmm. What about simply using the GNU Kind Communication Guidelines,
maybe adding 'LilyPond' at some strategic places?
> Теноры
> Very odd - I've just installed a CMU font and it's got all the
> Russian alphabet.
What exactly do you mean with 'installing'? I'm talking about the
creation of PDF files using xelatex, using only standardized fonts
(this is, avoiding fonts that are accidentally present on your
>> I could try to cherry-pick my own patches into 2.20 – this is, I
>> prepare a set of commits and send them to you for further testing.
>> Does this sound reasonable?
>
> I'll just pick the examples, they will likely go quite clean.
OK.
> But if you think about what you want to do about the
> Werner basically is the person most affected by changes I have not
> yet cherry-picked because of problems, changes that likely would be
> a good idea to have in 2.20.
>
> Those are his extensive indexing review, and reworks of several
> examples. The indexing review is hard to apply to the
> * Because the build happens inside a container, we can test multiple
> builds. We could build against guile 1.8 and 2.2 at the same time,
> for example.
I have zero experience with docker, but your suggestions sound quite
interesting!
Regarding image comparison: The Chromium team uses
> I'd like to recommend that everyone argues with him [David K.], if
> you think he is wrong. Otherwise take his posts literal and _not_
> offending.
That's it.
Werner
David,
> [...] the principal impact to be expected on LilyPond development
> appears to have an official body entitled to censure my behavior and
> eventually, out of a sense of duty, remove me.
I won't definitely do that.
> The general stance of the GNU project on its internal lists is to
>
[Being on the return from Hawaii I'm late with everything, so please
don't be surprised if I answer to stuff that has already been
discussed to death.]
> The preamble and intent is one thing; adding a corrective committee
> with the authority to enact punishments based on anonymous reports
>
> * statically linked binaries of clang-format are available here:
> https://github.com/angular/clang-format/tree/master/bin ;
Aaah! This is very nice, thanks.
> 1. Recognize clang-format as a "good enough", so I can use it
> locally on my diffs and not get reviews on style.
I did a quick
> I put up a .clang-format code that mostly mimicks our style at
>
> https://codereview.appspot.com/561340043
>
> I have a lot of good experience with automating code formatting. It
> removes drudgery for code authors, obviates discussions over style
> in code review, and generally elevates
> I'm going to call
>
> git push --mirror g...@github.com:lilypond/lilypond.git
>
> to update the github mirror. However, this will cause the following
> changes:
I've now done a push, and it seems to have worked correctly. Please
check.
Werner
> The minimum length of the stem of the middle note is forcing the
> beams down.
Sounds sensible. Can you provide a patch to fix that? The minimum
stem length for french beams must be handled identically to the
non-french case.
Werner
> What is "french beaming" supposed to do/be?
No stems within the beam.
Werner
Before adding it to the bug tracker I want to check this group's
knowledge whether there is a reason that French beams are longer than
normal:
\relative c'' {
r16 f d f
\override Stem.french-beaming = ##t
r16 f d f
}
Looking into scores from French publishers this behaviour
> What I meant to say: I guess I should be able to handle those
> comparatively obvious merge conflicts.
>
> https://codereview.appspot.com/579240043/
Thanks for taking care of Han-Wen's patches. My back is still not OK;
I must avoid sitting too much in front of the computer currently...
> A problem with the policy "trivial things can just be pushed" is
> that "trivial" is open for interpretation.
Of course, but this shouldn't be a hindrance.
> Even a change that was intended to affect only comments could have a
> bad impact if, say, it inserts an accidental stray character
> Almost exactly a year ago, there was a sizable "Please test gub"
> effort initiated by Knut Petersen.
By the way: Any idea what has happened with Knut? He doesn't respond
even to private e-mails since a few months...
Werner
>> At any rate: we haven't had a protocol for patches not going
>> through the regular process. Maybe we should use the
>> Signed-off-by: convention for such patches, including the original
>> submitter and the LGTM votes? It's probably mostly psychological,
>> but it suggests a bit of
> Trivial things from a developer with push access can be just pushed.
> Complex or otherwise contential things warrant a chance for
> developers to take a look at it. "Half a chance" seems an
> unnecessary complication.
Anyway, I was misled. Han-Wen actually *did* create proper SF issues,
>> Han-Wen has recently pushed a bunch of changes directly to
>> Rietveld, most of them quite uncontroversial. I assume that this
>> is as good as an e-mail :-)
>>
>> I thus suggest that after his patches have been reviewed,
>
> How are they going to get reviewed when there is nothing pointing
>Send an email (must be less than 64 KB) to
> briefly explaining your work, with the
> patch files attached. Translators should send patches to
> . After your patches are reviewed, the
> developers may push one or more of them to the main repository or
> discuss them with you.
Han-Wen
>> To github.com:lilypond/lilypond.git
>> - [deleted] stable/2.18
>> * [new branch]origin/stable/0.0 -> origin/stable/0.0
>
> It looks like you are trying to push a normal clone of the savannah
> repo, where as you should be pushing from something that was cloned
> as
> So go wild.
Thanks. Copyright years are now updated in staging.
Werner
It's January. This means we should run
make grand-replace
David K, do you have objections, especially w.r.t. cherry-picking?
Werner
I'm going to call
git push --mirror g...@github.com:lilypond/lilypond.git
to update the github mirror. However, this will cause the following
changes:
To github.com:lilypond/lilypond.git
- [deleted] refs/changes/31/482031/1
- [deleted]
> While that may be true, there are already GNU projects using GitHub
> as their host, for example gnucash and gnuradio.
Gnucash uses github as a mirror only, see
https://wiki.gnucash.org/wiki/Git#code.gnucash.org
But gnuradio admittedly uses github. I'm 100% sure that if RMS knew
that he
> I assume that many of the talks and discussions would be interesting
> for lots of developers who cannot come. Is there a possibility to
> document the unconference day, f.e. by recording video and
> distributing it (if not public then protected by password that only
> users asking for it get
> 11:15 Frescobaldi
> 15:30 openLilyLib
> 16:00 edition-engraver
Program changed accordingly; I now use »Vormittag« and »Nachmittag« as
block names.
Werner
>> It seems you have to set LDTL_LIBRARY_PATH.
Typo! I mean LTDL_LIBRARY_PATH/
> I saw that, of course, but I’m not sure what that variable even is.
> In particular, I have no reason to believe that it affects Guile’s
> load path...but I’ll try it and see.
It's documented in the guile manual,
> There is one lingering problem: when LilyPond calls Guile, Guile is
> not finding the library files specified in load-extension
> expressions, even though they *should* be in the right place.
> Before I go too crazy searching, does anyone know what controls this
> path choice? I'm assuming it
>> There is no guarantee that `FlexLexer.h` found during compilation
>> is the one that is used by a recent flex version. Unfortunately,
>> `FlexLexer.h` doesn't contain any version information, so it is
>> really impossible to protect against this situation automatically.
>
> Akim Demaille made
[Sorry for this off-topic message, but it's really urgent...]
Hello Kieren,
did you receive my recent e-mail messages that I sent to
?
Werner
> `configure` should warn or bail on incompatible flex versions. I
> suggest we add a version check in configure.ac to ensure that flex
> version is between 2.5.37 and 2.5.39 (given that 2.5.38 and 2.5.39
> actually works).
What you suggest wouldn't work as expected. There is no guarantee
This looks interesting!
https://lgtm.com/projects/g/lilypond/lilypond
Werner
Hello Han-Wen,
> I'll be at the Salzburg music engraving event.
now registered :-)
> I was wondering if there is anything regarding LilyPond that you
> want my input on.
Being at the conference for the discussions and talks on Sunday is
already a big bonus. I'm sure there will be a lot of
>> 2. ./configure found mpost but it's complaining about missing
>>metapost CTAN package. Should I be worried about this error?
Yes, you should be worried if you are building lilypond. It means
that the `mpost` binary could be found, but not its basic input files
like `mfplain.mp`.
>>
>>Sure! IIUC, I need to upload the patch to the code review tool and
>>update the issue tracker? If so, could you (or someone else) give
>>my account yassinec write access to the issue tracker? Otherwise I
>>can send the patch by email
Both is OK.
> I've added yassinec to the issue tracker
> Thanks for your answer, I managed to install Lilypond from macports,
> it works like a charm. We could include a note in the
> website/documentation about this workaround, what do you think?
Could you provide a patch to either the .html page or the
corresponding .texi file? (The latter
>> Is there a specific reason that issue #5621 is not on this list?
>
> If there exists a patchset on Rietveld, neither is it linked to on
> Sourceforge nor is 5621 set to Patch:new.
Oops. Silly me. Here it is now.
https://codereview.appspot.com/553290043
Werner
> New:
>
> 5633 musicxml: Replace new module by type() builtin - Jonas Hahnfeld
> https://sourceforge.net/p/testlilyissues/issues/5633
> http://codereview.appspot.com/555070043
>
> 5632 Replace string exceptions by RuntimeError - Jonas Hahnfeld
>
>> Please try again with
>>strace -ff -o ~/mf2pt1.strace mf2pt1 feta11.mf
>> so that we can see the strace messages from `t1asm` also. Note that
>> you will get at least two files called `mf2pt1.strace.X`, where
>> `X` is a process ID.
>>
>
> Four log-files were created, and the 3
>> Strange indeed. Can you temporarily replace `mf2pt1` with a script
>> that calls `strace`? Something like
>>strace mf2pt1 ... &> ~/mf2pt1.strace.log
>> You could then investigate in more detail which files `mf2pt1` tries
>> to open and/or execute.
>>
>
> [jcharles@pc1 mf]$ strace
> which t1asm
> /usr/bin/t1asm
>
> so I don't see any reason why, just at once, it failed at running…
> after a good sleeping night!
Strange indeed. Can you temporarily replace `mf2pt1` with a script
that calls `strace`? Something like
strace mf2pt1 ... &> ~/mf2pt1.strace.log
You could
> I notice, upwards in the log, that
>
> Invoking "t1asm feta11.pt1 feta11.pfb"...
> mf2pt1: You'll need either to install t1utils and rerun mf2pt1 or find
> another way to convert feta11.pt1 to feta11.pfb
>
>
> despite I've t1utils-1.41-1.fc31.x86_64 installed.
Can you execute t1asm?
Folks,
the music engraving conference in Salzburg (January 17.-19.) aims to
present as much note engraving programs as possible. While some
companies send representatives (e.g., Dorico, Capella, Finale) – some
even with talks – we don't have something similar for LilyPond in the
main part of
>> This is very, very non-standard and completely undocumented.
>
> Not completely undocumented. The CG has said to run configure with
> --disable-optimising for as long as I can remember.
I don't mean this option but the fact that CXXFLAGS as set by the user
gets almost completely
Most developers expect that you can easily adjust C++ compiler flags
in a GNU package using CXXFLAGS. With LilyPond, however, this is
quite problematic. Reason is that it internally uses the following
variables to compute the final list of compiler flags (see files
`c++-vars.make` and
> Below is the console output. Any ideas?
Clone the repository anew, and everything should be fine again.
It seems that git has been upgraded on Savannah; a comparison between
the old and the new clone shows a lot of differences in the `.git'
directory...
Maybe they forgot to set a
>> 0deb785f64 Update texinfo.tex from Texinfo git master branch
>
> not sure about this one...
IMHO this should be skipped. Instead, right before the 2.20 release,
the newest `texinfo.tex` from texinfo's git master branch should be
used.
>> 804faebc79 Issue 5481/1: main.cc, relocate.cc:
>> > [dev@lilydev:lilypond-git]$ git fsck
>> > Segmentation faultrectories: 45% (116/256)
>>
>> Ouch. I've never experienced such a thing with git. Maybe
>> something is broken with your installation? Does removing and
>> installing again help?
>
> Do you mean removing git itself? I'd like to
>> There is git-fsck .
>>
>
> [dev@lilydev:lilypond-git]$ git fsck
> Segmentation faultrectories: 45% (116/256)
Ouch. I've never experienced such a thing with git. Maybe something
is broken with your installation? Does removing and installing again
help?
Werner
>> This package is written by Urs Liska , who is
>> quite busy these days. In case you have experience with Python 2
>> to 3 conversion, please help produce a new version!
>
> Should it still be backwards compatible with Python 2.7 if possible or
> is it ok to drop Python2 backwards
On the TeXLive mailing list, Norbert Preining , one
of the maintainers of TeXLive posted the following today.
With the end of 2019, Python2 will be deprecated and not receive any
security updates. Most distributions will throw out Python2
completely. (Don't ask me about my opinion on
>> It's not a regression, right.
>
> My first probably-not-very-correct thing to do next was check out
> stable/2.18 and make LP from there (on the same system am building
> latest master on) and search for the same errors. [...]
>
> So is this a regression?
My answer is still no. Our glyph
>> Now that Dan has made default make commands 'terser' I am noticing
>> while building our fonts that I see quite a few 'errors' that look
>> like this:
>>
>> Internal Error (overlap) in clefs.petrucci.c5_change:
>> Winding number did not return to 0 when x=25.9951
>> Internal Error (overlap)
As the title says: A complete gub build succeeds again on my GNU/Linux
openSUSE platform if I apply
https://github.com/gperciva/gub/pull/70
to gub's master branch.
Werner
> When I run configure, an error is returned saying that makeinfo is
> too old (5,2). When I run sudo apt-get install texinfo, I'm told
> that I have the latest version. makeinfo --version still returns
> 5.2.
Ouch. `makeinfo` is part of texinfo. Version 5.2 was published
September 2013!
>> [...] because the `share' tree present in
>>
>> gub/uploads/webtest/v2.21.0-1-unpack/v2.19.83-1/
>>
>> is not created by the script in
>>
>> gub/uploads/webtest/v2.21.0-1-unpack/v2.21.0-1/
>
> This fixes the lilypond-test stage:
> https://github.com/gperciva/gub/pull/70
Thanks a lot! What
> I installed Ubuntu 19.10 on a spare computer, installed some
> necessary packages, cloned https://github.com/gperciva/gub.git, and
> ran "time make -j7 PLATFORMS=‘linux-64’ lilypond". This got as far
> as package linux-64::lilypond, stage pkg_install, and then exited
> with error 2. The last
> I will attempt to build gub to reproduce and diagnose this issue.
Thanks!
> If you think my time would be better spent preparing a patch that
> cleanly undoes the 'share' change, I'm open to hearing it.
I second Carl's opinion, namely to fix the issue rather than to
circumvent the problem.
> In the past month, I've devoted many hours to testing my
> submissions, but clearly the effort is not achieving the goal.
Don't worry. Some of the problems are very hard to catch and only
show up under certain circumstances.
> I request some help to understand how I can improve my pre-commit
>> I still cannot do make-check this morning based on current master.
>
> I have no idea why the problem is only being discussed instead of
> fixed, but I'll revert
>
> commit 911788f173eb58438fc9c850a005638d053b8bba
> Author: Dan Eble
> Date: Thu Oct 17 18:17:44 2019 -0400
>
> Issue
> BTW, what I’ve done so far is at
> https://github.com/gperciva/gub/pull/69 if anyone wants to take a
> look.
Looks good, thanks (I left one remark).
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
> Not directly related, but a consideration this comment reminded me
> of: to make these dylibs as portable as possible they must be built
> using as early of an sdk as possible. While we could choose to
> simply start supporting 64-bit at 10.15 (Catalina) and instruct
> users on 10.14 and below
>> What dependency?
>
> The port lilypond-devel has been updates now to using gcc9 as a
> build dependency; earlier today, it was gcc8.
Yep.
> But port lilypond does not have any gcc, nor libgcc as library
> dependency. The latter is perhaps required for a standalone
> package.
Why do you
>> Well, that homebrew occupies `/usr/local' is far from optimal.
>
> Bear in mind usr stands for Unix System Resources (allegededly), not
> user. And as I understood it, /usr is for distro stuff, /usr/local
> is for system-wide stuff that is built locally.
This is the thing: `built locally'.
> The standard explicitly says it should not be there, but in
> /opt/. Also, MacPorts is in /opt/local/ but should have been in
> /opt/macports/, as it suggests /opt≮provider>/.
Yes.
> But on the hand, I have never seen anything installing in /opt/
> besides MacPorts on MacOS. And also packages
What about `/opt/lilypond’?
>>>
>>> The location /usr/local/ is for user installations on BSD systems,
>>> there is for example /usr/local/texlive, so it seems natural.
>>
>> Well, I don't care enough to argue :-)
>
> Why not? :-) Here are some links:
>
>
>>> I think I put it into /usr/local/lilypond or
>>> /usr/local/lilypond-devel. Which location would you prefer?
>>
>> What about `/opt/lilypond’?
>
> The location /usr/local/ is for user installations on BSD systems,
> there is for example /usr/local/texlive, so it seems natural.
Well, I
>> > Though the title contains backslashes, thus it's not searchable
>> > in LSR. Not sure what to do!?
>>
>> Hmm. I just entered `\mark' in the LSR search box, and it *does*
>> return snippets with backslashes in the title. What exactly is the
>> problem?
>
> From here:
>
>
>> To build a distributable `mpkg', you have to install MacPorts with
>> a *different* prefix (i.e., not `/opt/local') so that it doesn't
>> interfere with the `standard' MacPorts a user might have installed.
>> And for such custom MacPorts installations only building from
>> source works.
>
> I
> gcc8 doesn’t build in MacPorts on Catalina, at least it didn’t build
> for me on Thursday.
OK, I misunderstood.
Werner
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
> Done.
Thanks!
>> http://lsr.di.unimi.it/LSR/Item?id=857
>
> Done.
>
> Though the title contains backslashes, thus it's not searchable in
> LSR. Not sure what to do!?
Hmm. I just entered `\mark' in the LSR search box, and it *does*
return snippets with backslashes in the title. What
>> Well, right now you have to build MacPorts from source on MacOS
>> 10.15 – I guess this takes almost a day of compilation. (I don't
>> have such an OS, by the way).
>
> The link I gave has an installer for MacOS 10.15, and it works. :-)
>https://www.macports.org/install.php
This is
>>> A problem with the [MacPorts] lilypond-devel package is that it
>>> listed all dependencies for the build as required for the
>>> installer, including GCC, making it very large, so it should be
>>> slimmed down.
>>
>> This is not correct any more, I think. See
>>
>>
> A problem with the [MacPorts] lilypond-devel package is that it
> listed all dependencies for the build as required for the installer,
> including GCC, making it very large, so it should be slimmed down.
This is not correct any more, I think. See
> I did have to make one change to the Portfile for lilypond-devel. I
> added macports-gcc-9 at the top of the compiler.fallback-append
> list, because MacPorts was mistakenly trying and failing to build
> gcc8 as a dependency.
Please send me a patch so that I can add it to the Portfile.
801 - 900 of 3179 matches
Mail list logo
