Re: [David Kastrup] [translations] Branches rededicated!
Hi David, it looks like now both branches have master merged and are identical: $ git diff origin/dev/translation-merge origin/translation [empty] Is that intended? To me this sounds conceptually wrong, given that you want to use one of them (I didn't understand which one) for 2.20.1 - I don't think we want to have the Python 3 switch in there. Jonas Am Montag, den 02.03.2020, 23:38 +0100 schrieb David Kastrup: > I am forwarding a message I sent to the translators list for the > information of everyone. > > I would like to merge what is now the translation branch into staging > soon (at the current point of time, this would be a fast-forward but I'd > probably make it an explicit merge commit). > > Please check whether you think this could interfere with your current > work or might cause problems. It is a prerequisite to releasing 2.21.0 > next, something that we should be able to do next without any delay > apart from getting GUB to compile it. > > Unless something else breaks in the mean time: so if you fear that you > would be responsible for that, just wait with your next commit and get > it into 2.21.1 instead. > > Assuming that everyone else is fine with that, we should return to our > fortnightish development release schedule straight off whatever happens > to be master. > > The next larger hickup should be the move to a different development > platform once we figure out where we are good to go. > > All the best! > > David > > Start of forwarded message > From: David Kastrup < > d...@gnu.org > > > To: > translati...@lilynet.net > > Subject: [translations] Branches rededicated! > Date: Mon, 02 Mar 2020 23:31:38 +0100 > > > Hi, > > I've now pushed to the translation branches an update/merge to current > _master_ (namely what is to be released as 2.21.0). This version passes > the basic tests though I haven't merged/pushed it to master yet again. > > If you want to do any outstanding work for what may become 2.20.1 at > some point of time (an update to stable), please use the branch > translation-staging for that instead. It has been kept at a state > useful for merging into stable/2.20 . > > If you want to do work suitable for _both_, be sure to commit it as a > separate commit, preferably to translation, so that it may get > cherry-picked from there (after it has passed muster) into the stable > branch. > > So in summary: > > translation: work for 2.21 > translation-staging: work for 2.20 > > That means in particular that any updates to the changes files for > 2.18–2.20 should go into translation-staging, and for 2.20–2.22 should > go into translation. > > And you probably want to clean out the translations of the Changes files > in translation, making them reflect only stuff that is in the main > Changes file (because it has been added after the stable/2.20 branch has > been created). > > All the best, and thanks for all the work that went into 2.20 so far! > > -- > David Kastrup > > > > End of forwarded message > > signature.asc Description: This is a digitally signed message part
Re: Does the following Python error in the musicxml tests ring a bell?
Am Montag, den 02.03.2020, 21:40 +0100 schrieb David Kastrup: > Jonas Hahnfeld < > hah...@hahnjo.de > > writes: > > > Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup: > > > dev/translation-merge > > > > > > Fails at make test (at least on my system). > > > > Ah, the merge re-instantiated some code for Python 2. The following > > diff fixes 'make test' for me: > > [...] > > > But very please DO NOT MERGE your branch dev/translation-merge into > > master: It will pull in most of the cherry-picked commits from > > stable/2.20 which will probably render 'git bisect' useless. Not sure > > if that was done for previous releases but it certainly doesn't seem > > right for that many commits in stable/2.20 that are not in master. > > This is a travesty. I was sure that I checked out every... every merge > conflict outside of Documentation/?? ... > > Darn. Those files weren't conflicting. > > Good that we talked about it. I'll paste over everything else outside > of Documentation/??/ that differs from master still. > > If the merge commit touches nothing other than that, we should be fine, > right? Only for the final outcome. 'git bisect' will still walk into (most of) stable/2.20 which is likely not what we want it to do. I'll try to have a look later today if we can do better. Jonas signature.asc Description: This is a digitally signed message part
[David Kastrup] [translations] Branches rededicated!
I am forwarding a message I sent to the translators list for the information of everyone. I would like to merge what is now the translation branch into staging soon (at the current point of time, this would be a fast-forward but I'd probably make it an explicit merge commit). Please check whether you think this could interfere with your current work or might cause problems. It is a prerequisite to releasing 2.21.0 next, something that we should be able to do next without any delay apart from getting GUB to compile it. Unless something else breaks in the mean time: so if you fear that you would be responsible for that, just wait with your next commit and get it into 2.21.1 instead. Assuming that everyone else is fine with that, we should return to our fortnightish development release schedule straight off whatever happens to be master. The next larger hickup should be the move to a different development platform once we figure out where we are good to go. All the best! David Start of forwarded message From: David Kastrup To: translati...@lilynet.net Subject: [translations] Branches rededicated! Date: Mon, 02 Mar 2020 23:31:38 +0100 Hi, I've now pushed to the translation branches an update/merge to current _master_ (namely what is to be released as 2.21.0). This version passes the basic tests though I haven't merged/pushed it to master yet again. If you want to do any outstanding work for what may become 2.20.1 at some point of time (an update to stable), please use the branch translation-staging for that instead. It has been kept at a state useful for merging into stable/2.20 . If you want to do work suitable for _both_, be sure to commit it as a separate commit, preferably to translation, so that it may get cherry-picked from there (after it has passed muster) into the stable branch. So in summary: translation: work for 2.21 translation-staging: work for 2.20 That means in particular that any updates to the changes files for 2.18–2.20 should go into translation-staging, and for 2.20–2.22 should go into translation. And you probably want to clean out the translations of the Changes files in translation, making them reflect only stuff that is in the main Changes file (because it has been added after the stable/2.20 branch has been created). All the best, and thanks for all the work that went into 2.20 so far! -- David Kastrup End of forwarded message -- David Kastrup
Cross-staff spanners?
Hi, Some time ago, I heard of a fantastic GSoC project aimed at enabling cross-staff spanners. [1]https://lilypondblog.org/2016/08/google-summer-of-code-2016-cross-vo ice-spanners/ However, this is not yet in any release. For the score I'm engraving, it would be tremendously helpful to get this working. I tried to compile the gsoc-2016-spanners branch from [2]https://github.com/starrynte/lilypond but it didn't do the trick. I know this will be unstable, but still, is there a patch somewhere that I could apply to use this feature nevertheless? Thank you very much! Regards, Jean Abou Samra References 1. https://lilypondblog.org/2016/08/google-summer-of-code-2016-cross-voice-spanners/ 2. https://github.com/starrynte/lilypond
Re: Does the following Python error in the musicxml tests ring a bell?
David Kastrup writes: > Jonas Hahnfeld writes: > >> Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup: >>> dev/translation-merge >>> >>> Fails at make test (at least on my system). >> >> Ah, the merge re-instantiated some code for Python 2. The following >> diff fixes 'make test' for me: > > Pushed something To dev/translation-merge . Should have mentioned that. > that is hopefully clean. Doing the tests again. Also had to retain > Documentation/pictures which had gained Japanese images in > translation. -- David Kastrup
Re: Does the following Python error in the musicxml tests ring a bell?
Jonas Hahnfeld writes: > Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup: >> dev/translation-merge >> >> Fails at make test (at least on my system). > > Ah, the merge re-instantiated some code for Python 2. The following > diff fixes 'make test' for me: Pushed something that is hopefully clean. Doing the tests again. Also had to retain Documentation/pictures which had gained Japanese images in translation. -- David Kastrup
Re: Does the following Python error in the musicxml tests ring a bell?
Jonas Hahnfeld writes: > Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup: >> dev/translation-merge >> >> Fails at make test (at least on my system). > > Ah, the merge re-instantiated some code for Python 2. The following > diff fixes 'make test' for me: [...] > But very please DO NOT MERGE your branch dev/translation-merge into > master: It will pull in most of the cherry-picked commits from > stable/2.20 which will probably render 'git bisect' useless. Not sure > if that was done for previous releases but it certainly doesn't seem > right for that many commits in stable/2.20 that are not in master. This is a travesty. I was sure that I checked out every... every merge conflict outside of Documentation/?? ... Darn. Those files weren't conflicting. Good that we talked about it. I'll paste over everything else outside of Documentation/??/ that differs from master still. If the merge commit touches nothing other than that, we should be fine, right? -- David Kastrup
Linking 64-bit Mac builds from website
Folks-- It seems that I've got a working process for 64-bit Mac builds of LilyPond, and I will soon automate the process to build Mac .app bundles for every tagged release. Which brings me to the next question: what is the process to update the LilyPond website so that download links for these builds are directly available? Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org
Re: How do I change LOCALEDIR?
On Mon, Mar 2, 2020 at 1:15 AM Werner LEMBERG wrote: > > > 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 use the .reloc file, it clearly finds the > > setting in the file, but then later blithely prints out > > LOCALEDIR="the/old/value/I/didn't/want". > > What exactly do you want to achieve? I want LOCALEDIR to point to where the locales will actually be in the .app bundle (under $INSTALLER_PREFIX). > If I understand the code > correctly (in file `relocate.cc`), the two calls to `bindtextdomain` > happen before relocation files are read.[*] In other words, the > `LILYPOND_LOCALEDIR` environment variable is honoured but a > corresponding assignment in relocation files are ignored (for the > lilypond binary itself – child programs do get the updated environment > variable). > > Maybe this approach should be changed? > Perhaps! What is the point of overriding the environment setting for LOCALEDIR? Does LilyPond itself use that setting, or do only the child programs use it? Best, -- Marnen Laibow-Koser mar...@marnen.org http://www.marnen.org
Re: Does the following Python error in the musicxml tests ring a bell?
Am Montag, den 02.03.2020, 20:10 +0100 schrieb David Kastrup:
> dev/translation-merge
>
> Fails at make test (at least on my system).
Ah, the merge re-instantiated some code for Python 2. The following
diff fixes 'make test' for me:
diff --git a/python/musicxml.py b/python/musicxml.py
index 06cfe6fd39..2af7eacc17 100644
--- a/python/musicxml.py
+++ b/python/musicxml.py
@@ -39,7 +39,7 @@ class Xml_node(object):
if not self._children:
return ''
-return ''.join([c.get_text() for c in self._children]).encode('utf-8')
+return ''.join([c.get_text() for c in self._children])
def message(self, msg):
ly.warning(msg)
diff --git a/python/utilities.py b/python/utilities.py
index dfde3cc9fd..7fb2e897b5 100644
--- a/python/utilities.py
+++ b/python/utilities.py
@@ -63,8 +63,6 @@ def hex_to_color(hex_val):
return None
def split_string_and_preserve_doublequoted_substrings(value):
-if isinstance(value, unicode):
-value = value.encode('utf-8')
import shlex
lex = shlex.shlex(value)
lex.quotes = '"'
But very please DO NOT MERGE your branch dev/translation-merge into
master: It will pull in most of the cherry-picked commits from
stable/2.20 which will probably render 'git bisect' useless. Not sure
if that was done for previous releases but it certainly doesn't seem
right for that many commits in stable/2.20 that are not in master.
Jonas
signature.asc
Description: This is a digitally signed message part
Re: Does the following Python error in the musicxml tests ring a bell?
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 19:53 +0100 schrieb David Kastrup:
>> I am currently trying to merge translations and master. make test gives
>> me
>>
>> [...]
>> Making input/regression/lilypond-book/out-test/html-musicxml-file.html <
>> htmly
>> langdefs.py: warning: lilypond-doc gettext domain not found.
>> lilypond-book.py: error: `musicxml2ly --out=- - ' failed (0)
>> lilypond-book.py: error: The error log is as follows:
>> musicxml2ly: Reading MusicXML from Standard input ...
>> Traceback (most recent call last):
>> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3288, in
>>
>> main()
>> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3282, in main
>> voices = convert(filename, options)
>> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3144, in
>> convert
>> score_information = extract_score_information(tree)
>> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 263, in
>> extract_score_information
>> set_if_exists('texidoc', ids.get_file_description());
>> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 225, in
>> set_if_exists
>> header.set_field(field, utilities.escape_ly_output_string(value))
>> File "/usr/local/tmp/lilypond/scripts/out/../../python/out/utilities.py",
>> line 19, in escape_ly_output_string
>> needs_quotes = not re.match ("^[a-zA-ZäöüÜÄÖßñ]*$", return_string);
>> File "/usr/lib/python3.7/re.py", line 173, in match
>> return _compile(pattern, flags).match(string)
>> TypeError: cannot use a string pattern on a bytes-like object
>> Making out-test/xref-maps/suffix-texinfo.xref-map < texi
>> Making input/regression/lilypond-book/out-test/suffix-texinfo.html < texi
>> Making input/regression/lilypond-book/out-test/tex-musicxml-file-options.tex
>> < lytex
>> Making input/regression/lilypond-book/out-test/tex-musicxml-file-options.pdf
>> < tex
>>
>> Please check the logfile
>>
>>
>> /usr/local/tmp/lilypond/input/regression/lilypond-book/out-test/tex-musicxml-file-options.pdflatex.log
>>
>> for errors
>>
>> make[2]: *** [../../../make/lilypond-book-rules.make:38:
>> out-test/tex-musicxml-file-options.pdf] Error 1
>> make[1]: *** [GNUmakefile:22: local-test] Error 2
>> make: *** [GNUmakefile:333: test] Error 2
>>
>>
>> I think we had something like this fixed in master previously. Any idea
>> what I might be missing here?
>
> Looks like you've found yet another code path that I didn't trigger
> with the transition to Python 3 and is not run by 'make test' on
> current master 😕 There's likely a decode / encode missing or to b
> e removed. Could you share a WIP branch that I could take a look at?
dev/translation-merge
Fails at make test (at least on my system).
--
David Kastrup
Re: Does the following Python error in the musicxml tests ring a bell?
Am Montag, den 02.03.2020, 19:53 +0100 schrieb David Kastrup:
> I am currently trying to merge translations and master. make test gives
> me
>
> [...]
> Making input/regression/lilypond-book/out-test/html-musicxml-file.html < htmly
> langdefs.py: warning: lilypond-doc gettext domain not found.
> lilypond-book.py: error: `musicxml2ly --out=- - ' failed (0)
> lilypond-book.py: error: The error log is as follows:
> musicxml2ly: Reading MusicXML from Standard input ...
> Traceback (most recent call last):
> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3288, in
>
> main()
> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3282, in main
> voices = convert(filename, options)
> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3144, in
> convert
> score_information = extract_score_information(tree)
> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 263, in
> extract_score_information
> set_if_exists('texidoc', ids.get_file_description());
> File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 225, in
> set_if_exists
> header.set_field(field, utilities.escape_ly_output_string(value))
> File "/usr/local/tmp/lilypond/scripts/out/../../python/out/utilities.py",
> line 19, in escape_ly_output_string
> needs_quotes = not re.match ("^[a-zA-ZäöüÜÄÖßñ]*$", return_string);
> File "/usr/lib/python3.7/re.py", line 173, in match
> return _compile(pattern, flags).match(string)
> TypeError: cannot use a string pattern on a bytes-like object
> Making out-test/xref-maps/suffix-texinfo.xref-map < texi
> Making input/regression/lilypond-book/out-test/suffix-texinfo.html < texi
> Making input/regression/lilypond-book/out-test/tex-musicxml-file-options.tex
> < lytex
> Making input/regression/lilypond-book/out-test/tex-musicxml-file-options.pdf
> < tex
>
> Please check the logfile
>
>
> /usr/local/tmp/lilypond/input/regression/lilypond-book/out-test/tex-musicxml-file-options.pdflatex.log
>
> for errors
>
> make[2]: *** [../../../make/lilypond-book-rules.make:38:
> out-test/tex-musicxml-file-options.pdf] Error 1
> make[1]: *** [GNUmakefile:22: local-test] Error 2
> make: *** [GNUmakefile:333: test] Error 2
>
>
> I think we had something like this fixed in master previously. Any idea
> what I might be missing here?
Looks like you've found yet another code path that I didn't trigger
with the transition to Python 3 and is not run by 'make test' on
current master 😕 There's likely a decode / encode missing or to b
e removed. Could you share a WIP branch that I could take a look at?
Jonas
signature.asc
Description: This is a digitally signed message part
Re: 2.21.0 release plans and considerations
Jonas Hahnfeld writes: > Sure, the solution is to apply #5799. Turns out the solution is not > only for x86_64-w64-mingw32 but also for 32 bit mingw that GUB > uses. So I'm arguing that it should go in before 2.21.0 is cut. Well, the rationale for being conservative with new patches is so that we can figure out at some later point of time what might have caused a difference in workability. Seems like we know this for this patch now. -- David Kastrup My replies have a tendency to cause friction. To help mitigating damage, feel free to forward problematic posts to me adding a subject like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Does the following Python error in the musicxml tests ring a bell?
I am currently trying to merge translations and master. make test gives
me
Dissecting...
All snippets are up to date...
Linking files...
Compiling
/usr/local/tmp/lilypond/input/regression/midi/out-test/collated-files.texi...
Writing
`/usr/local/tmp/lilypond/input/regression/midi/out-test/collated-files.texi'...
Making out-test/xref-maps/collated-files.xref-map < texi
Making input/regression/midi/out-test/collated-files.html < texi
Making input/regression/musicxml/out-test/collated-files.texi < tely
langdefs.py: warning: lilypond-doc gettext domain not found.
lilypond-book.py (GNU LilyPond) 2.21.0
Reading out-test/collated-files.tely...
Running texi2pdf on file /tmp/tmpn2kovsp4.texi to detect default page settings.
Dissecting...
Converting MusicXML file `01a-Pitches-Pitches.xml'...
lilypond-book.py: error: `musicxml2ly --out=- - ' failed (0)
lilypond-book.py: error: The error log is as follows:
musicxml2ly: Reading MusicXML from Standard input ...
Traceback (most recent call last):
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3288, in
main()
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3282, in main
voices = convert(filename, options)
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3144, in convert
score_information = extract_score_information(tree)
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 230, in
extract_score_information
set_if_exists('title', movement_title.get_text())
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 225, in
set_if_exists
header.set_field(field, utilities.escape_ly_output_string(value))
File "/usr/local/tmp/lilypond/scripts/out/../../python/out/utilities.py",
line 19, in escape_ly_output_string
needs_quotes = not re.match ("^[a-zA-ZäöüÜÄÖßñ]*$", return_string);
File "/usr/lib/python3.7/re.py", line 173, in match
return _compile(pattern, flags).match(string)
TypeError: cannot use a string pattern on a bytes-like object
Making input/regression/musicxml/out-test/collated-files.html < texi
Making input/regression/abc2ly/out-test/collated-files.list < 5 files
Making input/regression/abc2ly/out-test/collated-files.tely
Making input/regression/abc2ly/out-test/collated-files.texi < tely
langdefs.py: warning: lilypond-doc gettext domain not found.
lilypond-book.py (GNU LilyPond) 2.21.0
Reading out-test/collated-files.tely...
Running texi2pdf on file /tmp/tmp8pfaev2e.texi to detect default page settings.
Dissecting...
Writing snippets...
Processing...
Processing
/usr/local/tmp/lilypond/out/lybook-testdb/snippet-names-b53926dca385e98934494c04397097be.ly
Linking files...
Compiling
/usr/local/tmp/lilypond/input/regression/abc2ly/out-test/collated-files.texi...
Writing
`/usr/local/tmp/lilypond/input/regression/abc2ly/out-test/collated-files.texi'...
Making out-test/xref-maps/collated-files.xref-map < texi
Making input/regression/abc2ly/out-test/collated-files.html < texi
make[2]: warning: jobserver unavailable: using -j1. Add '+' to parent make
rule.
Making
input/regression/lilypond-book/out-test/html-musicxml-file-compressed.html <
htmly
langdefs.py: warning: lilypond-doc gettext domain not found.
lilypond-book.py: error: `musicxml2ly --language=deutsch --absolute
--no-beaming --compressed --out=- - ' failed (0)
lilypond-book.py: error: The error log is as follows:
musicxml2ly: Reading MusicXML from Standard input ...
musicxml2ly: Input is compressed, extracting raw MusicXML data from stdin
Traceback (most recent call last):
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3288, in
main()
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3282, in main
voices = convert(filename, options)
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3144, in convert
score_information = extract_score_information(tree)
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 230, in
extract_score_information
set_if_exists('title', movement_title.get_text())
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 225, in
set_if_exists
header.set_field(field, utilities.escape_ly_output_string(value))
File "/usr/local/tmp/lilypond/scripts/out/../../python/out/utilities.py",
line 19, in escape_ly_output_string
needs_quotes = not re.match ("^[a-zA-ZäöüÜÄÖßñ]*$", return_string);
File "/usr/lib/python3.7/re.py", line 173, in match
return _compile(pattern, flags).match(string)
TypeError: cannot use a string pattern on a bytes-like object
Making input/regression/lilypond-book/out-test/html-musicxml-file-options.html
< htmly
langdefs.py: warning: lilypond-doc gettext domain not found.
lilypond-book.py: error: `musicxml2ly --language=deutsch --absolute
--no-beaming --out=- - ' failed (0)
lilypond-book.py: error: The error log is as follows:
musicxml2ly: Reading MusicXML from Standard input ...
Traceback (most recent call last):
File "/usr/local/tmp/lilypond/scripts/out/musicxml2ly", line 3288, in
Re: 2.21.0 release plans and considerations
Am Montag, den 02.03.2020, 19:38 +0100 schrieb David Kastrup:
> Jonas Hahnfeld <
> hah...@hahnjo.de
> > writes:
>
> > Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
> > > Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
> > > > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
> > > > to be a thing rather soon. Assuming that things like the Python3
> > > > migration don't cause more of a standstill for 2.21.0 than we imagine,
> > > > but then one can still decide to stop being disciplined until things are
> > > > fixed enough to get 2.21.0 done.
> > >
> > > Understood. In that case I'll work to prepare GUB for 2.21.0, at least
> > > something I can likely help with.
> >
> > See
> > https://github.com/gperciva/gub/pull/71
> > . Incidentally this only
> > works for mingw after #5799 is applied (or at least the first commit).
> > So while it has the potential to break, it actually fixes things 😉
> >
> > FTR: I guess the offending commit is b51e6224ab ("Issue 5776/1: Drop
> > check for std::vector::data()") where I innocently removed an inclusion
> > of config.hh. I'd argue that it has been broken before, this was only
> > uncovered by removing the include.
>
> Frankly, I am not overly interested in arguing what level of brokenness
> is really "somebody else's problem"™. Since you are the person who
> currently appears to have the best overview, could you design a fix you
> consider less broken?
Sure, the solution is to apply #5799. Turns out the solution is not
only for x86_64-w64-mingw32 but also for 32 bit mingw that GUB uses. So
I'm arguing that it should go in before 2.21.0 is cut.
Jonas
signature.asc
Description: This is a digitally signed message part
Re: 2.21.0 release plans and considerations
Jonas Hahnfeld writes:
> Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
>> Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
>> >
>> > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
>> > to be a thing rather soon. Assuming that things like the Python3
>> > migration don't cause more of a standstill for 2.21.0 than we imagine,
>> > but then one can still decide to stop being disciplined until things are
>> > fixed enough to get 2.21.0 done.
>>
>> Understood. In that case I'll work to prepare GUB for 2.21.0, at least
>> something I can likely help with.
>
> See https://github.com/gperciva/gub/pull/71. Incidentally this only
> works for mingw after #5799 is applied (or at least the first commit).
> So while it has the potential to break, it actually fixes things 😉
>
> FTR: I guess the offending commit is b51e6224ab ("Issue 5776/1: Drop
> check for std::vector::data()") where I innocently removed an inclusion
> of config.hh. I'd argue that it has been broken before, this was only
> uncovered by removing the include.
Frankly, I am not overly interested in arguing what level of brokenness
is really "somebody else's problem"™. Since you are the person who
currently appears to have the best overview, could you design a fix you
consider less broken?
I am currently trying to get the translation infrastructure moving over
to unstable so that translators can, at their choice, do some
after-the-fact polishing of 2.20.0 (then due to appear in 2.20.1 at some
point of time) or dive into 2.21. The reason is that we want to get
2.21.0 out the door as fast as possible and return back to business. Of
which there does not seem to be a dearth...
Thanks!
--
David Kastrup
My replies have a tendency to cause friction. To help mitigating
damage, feel free to forward problematic posts to me adding a subject
like "timeout 1d" (for a suggested timeout of 1 day) or "offensive".
Re: 2.21.0 release plans and considerations
Am Montag, den 02.03.2020, 10:48 +0100 schrieb Jonas Hahnfeld:
> Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup:
> >
> > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going
> > to be a thing rather soon. Assuming that things like the Python3
> > migration don't cause more of a standstill for 2.21.0 than we imagine,
> > but then one can still decide to stop being disciplined until things are
> > fixed enough to get 2.21.0 done.
>
> Understood. In that case I'll work to prepare GUB for 2.21.0, at least
> something I can likely help with.
See https://github.com/gperciva/gub/pull/71. Incidentally this only
works for mingw after #5799 is applied (or at least the first commit).
So while it has the potential to break, it actually fixes things 😉
FTR: I guess the offending commit is b51e6224ab ("Issue 5776/1: Drop
check for std::vector::data()") where I innocently removed an inclusion
of config.hh. I'd argue that it has been broken before, this was only
uncovered by removing the include.
Regards
Jonas
signature.asc
Description: This is a digitally signed message part
Re: Missing link
I've just put an update in staging. -- Phil Holmes - Original Message - From: "Trevor" To: "Lily-Devel List" Sent: Sunday, March 01, 2020 11:10 PM Subject: Missing link Congratulations to all involved in getting 2.20 out the door! This is a big step forward. One minor glitch I noticed: in http://lilypond.org/website/all.html the link to the 2.18 documentation in the list of previous stable versions has gone AWOL, although the documentation itself is still in the correct place in http://lilypond.org/doc/v2.18/Documentation/web/manuals Current users of 2.18 will still need this until they get around to migrating. Trevor
Re: Issue 5806: Tweak mf files to avoid FontForge internal overlap error (issue 571780043 by torsten.haemme...@web.de)
LGTM, thanks! https://codereview.appspot.com/571780043/
Re: Issue 5806: Tweak mf files to avoid FontForge internal overlap error (issue 571780043 by torsten.haemme...@web.de)
OK, now I got it. Suppose I've erroneously treated these cases as broken line + 8-char indent. Now it should be the way you want it to be. Cheers, Torsten https://codereview.appspot.com/571780043/
Re: How do I change LOCALEDIR?
> On 2 Mar 2020, at 01:46, Marnen Laibow-Koser wrote: > > On Sun, Mar 1, 2020 at 7:04 PM Hans Åberg wrote: > > > On 1 Mar 2020, at 23:45, Marnen Laibow-Koser wrote: > > > > One question as I continue to work on 64-bit Mac packaging: 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 use the .reloc > > file, it clearly finds the setting in the file, but then later blithely > > prints out LOCALEDIR="the/old/value/I/didn't/want". How should I deal with > > this? > > I use a script, see [1]. It may work in an app bundle, too. > > 1. https://lists.gnu.org/archive/html/lilypond-user/2020-02/msg00425.html > > Your script appears to set the LC_* locale variables, but not LOCALEDIR, > which is what I was asking about. Am I wrong? Yes, but I see from Werner’s post it wouldn’t work in our case.
Re: mf: use python scripting for generating Emmentaler fonts (issue 553580043 by hanw...@gmail.com)
On 2020/02/29 22:53:43, lemzwerg wrote: > > > Can we assume that FontForge's python support and is > > > always enabled? Shall we check this? > > > > the FF page doesn't say that python is optional. > > It's a build option in both the old (configure) and new (cmake) builds... GUB doesn't have it, so this change should stay out until 2.21.0 is done (see lilypond-devel) https://codereview.appspot.com/553580043/
Re: 2.21.0 release plans and considerations
Am Sonntag, den 01.03.2020, 15:39 +0100 schrieb David Kastrup: > > But fortunately, we are now at the point where 2.20 _and_ 2.21 are going > to be a thing rather soon. Assuming that things like the Python3 > migration don't cause more of a standstill for 2.21.0 than we imagine, > but then one can still decide to stop being disciplined until things are > fixed enough to get 2.21.0 done. Understood. In that case I'll work to prepare GUB for 2.21.0, at least something I can likely help with. Regards Jonas signature.asc Description: This is a digitally signed message part
